• Wojtek Zając’s presentation on web accessibility, full of practical tips.
• Zef Hemel’s talk about Cloud9 IDE. I had a chance to talk with Zef in person and I was quite impressed by the technical sophistication of Cloud9.
• Peter Gasston’s talk about new exciting features from CSS3 and CSS4. While I have heard before about flex box or CSS regions, it was interesting to learn how exactly they work. Peter presented upcoming solutions to problems that CSS currently suffers from, like difficulties with grid layouts.

Jake Archibald closed the conference with one the best talks I’ve heard on any conference. He managed to explain obscure technical issues with web fonts in a hilarious way that kept interested even people who are less-than-thrilled about typography.

In my presentation I shared learnings from working on a large front-end codebase at Nokia. For some time I’ve been obsessed with the problem of scaling up front-end teams, so they could stay effective when dealing with complexity. I didn’t dwell on architecture, but focused on workflow and tools. While preparing the presentation I assumed that some techniques popular among back-end developers, like unit testing or continuous integration, are still not adopted by most JavaScript developers.

I showed how these techniques can be applied to front-end development. I also demonstrated how to use jslint to detect mistakes before they show up in a browser and how to work with team mates to learn from them and improve code quality.

Just prior to the presentation I realized that instead of relying on accidental knowledge and assumptions it would be better to perform a research and verify how popular are these tools among JavaScript programmers. Thus the survey: JavaScript development practices.

I will share more of my own experiences in a future blog post, but I also want to know how much of what I have learned is a common knowledge. The survey will be active for about a week. In November I will publish the results, together with more practical tips on individual techniques covered in my Front Row presentation.

Big thanks to people who gave me feedback after the talk and everybody who has voted already! If you’re a JavaScript developer and haven’t completed the survey yet, please do so – it doesn’t take more than 2 minutes.

1. Testing; in practice it is about Test Driven Development, where tests are written before the implementation.
2. Minimizing code duplication.
3. Maximizing clarity; it comes to down to meaningful naming.
4. Removing unnecessary elements. That postulate usually is naturally met when previous two are done properly.

The event was free (thanks to sponsors) and attracted almost 50 passionate programmers. There were people not only from Berlin, but also other places in Germany, Poland, Sweden and Czech Republic. Our facilitator was Alex Bolboaca from Romania.

Retrospective. Photo credit by Łukasz Bałamut.

During a Retreat participants are given a practical programming problem to “implement”: Conway’s Game of Life. I put “implement” in quotes because the real goal is to work on the quality of the code and programming skills, not completing the solution. The day is divided into six 45-minute sessions. At the end of each session code has to be deleted and the whole group has short retrospective. Programming is done in pairs and you should switch your partner after each session. Usually sessions have particular focus, like working on more flexible implementation, better naming, shorter methods, etc.

The event started at 8am on Saturday (!) and it seems to be designed to work like a natural preselection. Only people truly enthusiastic about programming made the sacrifice. I was genuinely impressed by the atmosphere. All the people were really friendly, and since there was no pressure on finishing the project, everybody was relaxed.

I must admit that I fell in love with Code Retreat. The idea of pair programming with total strangers may look daunting (“Gosh, all these guys must be a thousand times better than me! I can’t possibly pair up with any of them!”), but the program is constructed in a way that lets one focus on the craft and co-operation, instead of competing for the solution. When you realize that it’s not about stitching together a functioning program with the help of duct tape, you can relax and focus on improving your craft. This realization reached me during the 3rd of 6 sessions :).

Getting the most out of it

Some practical advice from a one-time “veteran”:

• Bring your own computer and have your environment (editor, unit testing framework) ready. There’s really not enough time to setup everything during a session and you will loose precious time that could be better spent on writing the code.
• Pair up with different people, even if you don’t know the language they’re using. In Berlin we had people coding in Java, JavaScript, Scala, Python, Ruby, C# and I even heard Haskell being mentioned by somebody.

Hard at work. Photo credit by Łukasz Bałamut.

I wouldn’t mind at all to participate in another Retreat, as there are things I would do a bit differently the second time.

• I had most fun when I tried to do things differently from my normal programming routine. For instance, writing Ruby instead of JavaScript. Pairing up with a total stranger. Trying to remove duplication from the code that already seemed clean.
• Switch pairs each time. The event attracts passionate people, so use the opportunity to pair up with as many of them as possible.
• Focus on some aspect of the problem instead of the complete solution. Me and my partner literally wasted one session when we tried to analyze the problem with pen and paper, instead of WRITING THE CODE. It would be perfectly reasonable in real work, but this event is about improving programming skills, not analysis. However, I think it is OK to think about the problem up-front and even have the solution in mind. Optimize for having as much time as possible to write the code during the event.

If you’re a programmer yourself, why not to organize Code Retreat in your city? It may turn out to be awesome. If you’re willing to try, Alex Bolboaca has some advice for future facilitators.

The Front-Trends 2010 conference took place last week. How did it go? Excellent.

Subjects ranged from web and mobile design, through CSS and markup to unit testing and server-side JavaScript. With the name of the conference explicitly mentioning trends, I was looking for some of them in the talks. In fact trends did emerge.

Mobile

I have been hearing about the need for focus on mobile web since years. Phones with web browsers have been around for a decade. So what’s the deal? Well, we reached a point when designing for mobile is not an extra activity that requires knowledge about obscure phone-only technologies (anybody still remembers WAP?). We can finally apply existing knowledge about web standards such as CSS and HTML. Surprisingly, contemporary smartphones often provide better capabilities than their desktop counterparts: Webkit has become a de facto standard rendering engine for the phones, while desktop web still struggles with IE6 legacy. Last but not least, better touch screens make browsing on the phone a pleasure rather than sadomasochistic experience it was just few years ago.

The subject of mobile web appeared in few presentations:

• “You know WebOS” by Markus Leutwyler
• “Cross-Device Applications Development”, talk about PhoneGap by Kamil Trebunia
• “Mobile UX and Current Trends in Mobile Design” by Antony Ribot
• “JSON over SMS” by Peter Paul Koch

PPK and Douglas Crockford – Panel Discussion; photo credit by Krzysztof Danek

Koch’s talk was certainly one of my favorites. For the last two years PPK has been working for Vodafone on what he does best: discovering quirks and bugs in browsers. Except this time he’s been doing this in the wild mobile world, where the sheer amount of browsers, resolutions, viewports and phone models can give a headache. In his talk he tried to predict how the mobile landscape will look like in 2018, when phones as powerful as today’s iPhone 3G will be accessible at 10 euro price tag. Make sure to check back this blog post in eight years to verify PPK’s predictions:

• HTML5 apps are the future, not the native ones. Only applications written with open standards ensure cross-platform interoperability and thus the broadest reach.
• App stores are destined to die. There’s already at least 41 of them – Apple’s App Store is just one of the many. The value they provide is either overrated (discoverability), already provided by others (payments have been handled by operators for years) or will be replaced by open standards (common APIs). What I am missing on this list is the convenience for users, so I wonder how this particular prediction will turn out.
• Access to phone features (calls, camera, storage etc.) will be standardized across different devices. WAC initiative is a step in that direction.
• High-speed network coverage will not grow as fast as the computing power of mobile devices. Thus there still will be the need for efficient and cheap data transfer format. This format could be a streamlined version of JSON sent over SMS (thus the title of the talk).
• We are about to see some totally new JavaScript events untangled by mobile devices, way beyond desktop metaphors such as click and hover. Think events like orientationchange, phonecall, move (GPS location change), cameraopen. Mobile context enables creativity that’s been somewhat missing in the desktop web in the last ten years.

My personal takeaway from the talks on mobile is that it’s worth to invest time now in learning how to design for this new environment. It’s not that hard to adapt existing web sites and web applications to mobile devices, but it requires consideration during design and development phases. Reasonably working devices and standards are already there. The share of users accessing the web through phones will only continue to grow.

JavaScript as THE programming language of the web

JavaScript has been around for over a decade and from the beginning it was used to spice up user interface (as any other spice, it has been widely abused). In the last 5 years – after “Ajax revolution” – it has become indispensable ingredient of web applications with heavy client. So what’s the news here? I think there are two, actually:

Douglas Crockford; photo credit by Morgan Roderick

1. JavaScript is now used for more complex tasks than ever before. Animations and DOM interactions, integration of browser APIs and web services – all this is done with JavaScript. As the applications become more complex, development style for JavaScript has changed. It’s no longer the fragile cycle: write, reload, pray it works. With tools like JSLint, Firebug and unit testing frameworks it’s finally possible to efficiently develop and debug even large JavaScript codebases. With complexity came new design challenges and the notion of “JavaScript application architecture” doesn’t sound ridiculous anymore.
2. JavaScript expands to the server side. This idea is not new. Proprietary solutions utilizing JavaScript syntax on the server side have been around since 1990′s, with Microsoft JScript being the most popular. But with node.js there seems to be finally a framework that embraces language’s philosophy (like architecture based on asynchronous callbacks) instead of merely using familiar syntax.

This changed approach to JavaScript was reflected in several talks:

• “JavaScript: The Rise of the Middle-End” by Kyle Simpson
• “Testing JavaScript” by Morgan Roderick
• “Test-First JavaScript” by Christian Johansen
• “JS Performances vs Common Good Practices” by Andrea Giammarchi
• “Using Web Services with JavaScript” by Chris Heilman
• “Server-Side JavaScript” by Douglas Crockford
• “Reusable Code, For Good Or For Awesome” by Jake Archibald

While I skipped the talks about unit testing (having a conference with two tracks enforces tough choices), it’s encouraging to see that unit testing and Test Driven Development are not anymore alien concepts in JavaScript world. To the point that they deserved a 600-page book written by one of the speakers. (Fortunately it’s not obligatory to read it in order to start writing unit tests in JavaScript.)

Kyle Simpson’s and Douglas Crockford’s talks addressed the subject of server-side JavaScript. It’s still in its infancy – e.g. there are not many libraries out there and even node.js is in an early phase – but I hope that eventually we will be able to run the same code on the server and the client. That was the premise of Kyle’s talk about middle-end, which was a fancy name for JS code that bridges the gap between the client and the server. Think about solution for eternal problem of validation code repeated in JavaScript and server-side language.

An interesting point was made by Douglas Crockford during the (excellent) panel discussion with PPK and Tantek Çelik: JavaScript has become a Virtual Machine for the world. Any application doing anything interesting on the web right now has to execute JavaScript in the browser runtime. It’s especially striking with projects like GWT, that allow developers to use their language of choice (in this case: Java), but eventually compile to JavaScript for execution.

One of the most inspiring talks of the whole conference was delivered by Chris Heilman. He first showed how to use JavaScript to create mashups connecting data from different REST web services. While totally feasible and not too complex, the task can quickly become tedious when developer has to go through registration process for different APIs and learn their details. Therefore in the second part Chris showed how to reduce the whole effort to two lines of code. Silver bullet? In fact it’s YQL, a language for web service integration with syntax similar to SQL. It takes care of the mundane details and allows developer to treat RESTful services or even regular HTML websites as database tables that can be joined and queried. For instance, imagine a query that takes Twitter messages in Polish with the keyword “Warszawa” inside and automatically translates them to English using Google Translation API. Sounds like a lot of work, but in fact it can be done with one line of YQL code. I knew that YQL has been around for a while, but the presentation gave me a boost to create something new with that shiny new toy. I mean tool.

HTML5 and CSS3

A conference about front-end development cannot happen without addressing web standards. On Front-Trends CSS3 and HTML5 were all the rage. While both buzzwords were repeated like a mantra in most of the talks, three presentations went into details:

• “JavaScript & HTML – Brave New World” by Robert Nyman
• “Pragmatic CSS” by Lea Verou
• “HTML5: Right Here, Right Now” by Tantek Çelik

Lea Verou; photo credit by Krzysztof Danek

According to people who have seen it, Lea’s presentation was one of the best of the conference (unfortunately I missed it). She published her slides online and they’re definitely worth checking. The presentation itself is written in HTML5 and styled with CSS3. Lea went through several new CSS3 properties, explained them and showed how they can be used to simplify the code and deliver features that were previously hard or impossible to implement. All this was accompanied with information about browser support, so one can tell immediately how feasible is the cutting edge. Spoiler: a lot from CSS3 can be used right now.

The talk by Tantek Çelik was in a similar spirit. Tantek went through most of the new features of HTML5 and grouped them into five buckets:

1. dependable now
2. roughly usable
3. awkward
4. interesting but ignorable
5. worthy of experimentation

I strongly recommend checking his slides as they give a primer of what’s possible now with HTML5 and what’s just around the corner.

One of the highlights of his talks was a call to action: send the following tweet to Internet Explorer 9 team:

Dear @IE: please implement Geolocation API, it’s Candidate Recommendation now!

Tantek Çelik; photo credit by Krzysztof Danek

Tantek is a former Microsoft employee and a person behind IE5 for Mac, known at the time for its excellent CSS support. Microsoft is usually implementing W3C specs that reached certain level of maturity, so there’s a hope that Geolocation API will make its way into IE9. I have sent a tweet, have you?

Truthy value

The conference was not without some flaws. In accordance with long tradition of tech gatherings, the wifi didn’t survive the rush of 300 bandwidth-hungry nerds. Nevertheless, the whole event was fantastic.

I’ve already heard about most of the new developments shown during the conference. Yet after leaving the venue I felt inclined to give some of them a try NOW, instead of waiting for IE8′s death in 2050. If the conference inspires you to try something new, could you wish for something more?

Szafranek’s constant equals 2

Soon thereafter, I applied this breakthrough discovery in my estimations. And a strange thing has happened: I was now able to provide correct numbers when asked for the time needed for a job. Though I regained some credibility, the damage was done and Szafranek’s constant is still a running joke among people I work with.

Proper estimation of front-end development tasks is hard and for any but the simplest tasks just applying the constant is not enough. How to estimate correctly? And first of all:

Why bother?

Estimation doesn’t sound too cool for the impassioned and young. Isn’t it better to start banging out the code right away? Well, surely, but unless you have unlimited amounts of time and money, you’ll need to face the reality and evaluate how much of the resources you need versus how much do you have. You’ll need to perform the estimation exercise whenever:

• You work alone as a freelancer. Your estimation will determine how much time you’ll need for the new project and how much you should charge.
• You work in a team. Other people (back-end developers, graphic designers) depend on you. They need the timelines from you to plan their own work. Most likely there’ll be also a manager over your neck, asking how much time do you need for this new task, so he could prepare a project plan and report the date to his boss or the customer. And if you think your manager is pesky about the dates, be assured that if he won’t ask you, he’ll come up with the (wrong) numbers himself. The results will be much more disastrous. For you.

Regardless of the context, you need to learn estimation fu to establish credibility. After all, people will like to work with you more if you’ll keep your own word.

Let me share with you few tips that I learned the hard way during the last few years. Let’s imagine a scenario: you work in a team of few people, building a simple web application. You have the vague idea what it will do, but the requirements are far from deserving the noble title of “specification”.

Lesson 1: Estimation takes time

This is probably the single most important fact about estimation. If you want to get any helpful numbers, you need some time to think about them. So if you are asked a question “How much time do you need to implement the user interface for this simple web application?” and you’re expected to provide the numbers immediately, they are unlikely to be relevant.

Lesson 2: Break it down

What you need the time for? To break the project into managable tasks. Don’t even think that a 2-week task is a managable one. The following quote from Getting Real nails it down:

Estimates that stretch into weeks or months are fantasies. The truth is you just don’t know what’s going to happen that far in advance.

So shrink your time. Keep breaking down timeframes into smaller chunks. Instead of a 12 week project, think of it as 12 weeklong projects. Instead of guesstimating at tasks that take 30+ hours, break them down into more realistic 6-10 hour chunks. Then proceed one step at a time.

Getting Real: Shrink Your Time

Simple page flow

I approach this analysis by drawing a user’s page flow. This a simple diagram showing what screens the application needs to have to satisfy all the tasks the user can perform, from start to finish.

This method is very user interface-centric and likely to underestimate graphic design and server-side development. Thus the next lesson is:

Lesson 3: Don’t do it alone

Unless it’s a one-man project you’re working on, the work breakdown can hardly be done by one person. I usually do it together with the back-end developer. This second person is able to spot missing elements on the page flow.

The page flow is a good starting point, but it doesn’t cover every activity in the project. If you’re a front-end developer, you also need to consider some common but often forgotten site elements:

• error pages
• print version
• mobile version

The list could go on, depending on the project and split of the roles. For instance, in my team front-end developer is also responsible for prototyping. Together with user testing this activity can take significant part of the project time. If you’re a project manager who wants to estimate the whole project time, you must also consider graphic design, data model design, server-side development, testing and a whole lot of other activities. It’s a topic for a book, not a blog entry. In fact, more than one book, as the search for software estimation on Amazon confirms. For the sake of the exercise, I’ll focus here on front-end coding only.

Even in this area it’s easy to fall into:

Lesson 4: Common pitfalls

Software developers are widely affected by a disease called optimism. Front-end engineers are no exception and I don’t exclude myself. It’s hard to find a developer who is not overly optimistic about the timelines and complexity of his tasks. 80 percent completion syndrome is very typical for this reality distortion: regardless when do you ask the developer how much work on the task he’s already done, the answer is usually around 80%. It’s fine after first day of the development, but too often the same answer is given on the deadline. “Only few fixes here and there and it’s done.” But it’s usually these “few fixes” that take most of the development time.

If you play an optimist in order to be nice to the manager or the customer, be asured it will backfire at you when you miss the deadline. I know at least one company where people are expected to give unrealistic estimates and cross the deadlines. But if the project manager respects himself and his people, he will treat underestimation as a mistake, not a rule. In that case developer is obliged to do his best to provide honest estimates. I’m lucky to know at least one other company that follows the second path.

How to avoid the trap of optimism and provide realistic numbers?

Development is more than just writing the code

This simple realization was something that helped me to recover from undue optimism. My own estimates were usually wrong because I didn’t consider work other than coding. But that work still needs to be done to finish the task. For a front-end developer it includes:

• Problem analysis and solution design. It’s the essence and the hard part of software development. It’s, basically, thinking. Because results of thinking are not very tangible, this part tends to be underestimated. However, it still needs to be included into estimates if they are to be correct. A proven way to make this activity more transparent is to create prototypes. One of the cool things about prototyping is that it forces you to think about the problem and allows you to experiment faster than you’d do with the fully-blown code. It’s also more effective than vague discussions or writing the documentation prose, since usually people think more effectively with visual aid than in pure abstract terms. Of course prototype could be an overkill for small tasks. In that case just make sure you have enough time to think about the problem, not only to code it.
• Communication with server-side developers and graphic designers. Especially in ajax applications server and client side are deeply intertwined. On the other hand, image files often require explanation or fixes before they can be implemented.
• Interfaces with other code. The more complex the application is, the more time is required to make sure that newly added piece of code won’t break some parts of it. It’s especially true for CSS which is highly reusable and thus can easily break a lot.
• Documentation is one of these things that everybody praises, but nobody does. If you won’t plan the time to write it, it won’t appear magically.
• Novelty. Unless the application you write is just another version of what you wrote a hundred times, you will need some time to research how to re-use other people’s code or write it by yourself.

Lesson 5: Try, fail, repeat

Taking all the above factors into account results in much stronger connection between estimates and the reality. It allows developers to provide project leader and other team members with numbers that can be actually used for planning. Still, developer’s input alone doesn’t automatically produce the delivery date for the product. Sicknesses, unpredicted hardware failures, sudden requirement changes and Jupiter phases will probably wreck the initial schedule anyway. In that sense software development is not far from the warfare:

In preparing for battle I have always found that plans are useless, but planning is indispensable.

Dwight D. Eisenhower

The good thing is that with each project you should come up with more sound estimations. Reality will always have the nasty property of surprise. But the experience you get through failures will allow you to reduce your own magic factor to a value smaller than the infamous 2 (or even more). If you repeatedly achieve the factor of 1, you can begin writing your own book on software estimation and future-telling.

The true value

Eventually, the value of estimation doesn’t come from predicting the future. Though vital in this business, it’s far from reliable predicting. But it forces you to think about the problem, analyze it and, eventually, solve it.

It was the second edition of the conference I wrote about last year. This time it was bigger, the list of sponsors was longer, and the speakers’ page included more famous names. Fortunately, the conference preserved its “geek camp” atmosphere. The organizers, who were the students last year and are now graduates, had much more experience this time. The talks went according to the schedule, which was probably the biggest change from the previous installment ;). The two talks I enjoyed the most were:

• Correlations and conclusions by Zed Shaw. Mr Shaw delivered a witty presentation on measuring performance of web apps. He compared web.py with Ruby on Rails in serving a “Hello world” application. To nobody’s surprise Python’s library won by an order of magnitude, confirming Zed’s proposition that “Rails sucks”. While one could argue whether it makes sense to compare the efficiency of a fork and knife in a spaghetti eating contest, the show was entertaining.
• TDD in Rails by Andrzej Krzywda. Andrzej is a Rails developer with a Java background. He shared his practical experience with a test driven development in different languages. While he advertised TDD as almost the only sane way to develop a software, I’m still a bit skeptical. I work mostly on the UI part of Ajax-heavy applications, and it’s hard for me to imagine even partial test coverage of complicated interactions. And what about automated testing of CSS layouts? I’m currently playing with Selenium, but my first impression is that it won’t be a silver bullet for front-end testing.

I also had my own talk. I covered a few of the Amazon Web Services: S3, EC2, SQS, SimpleDB and Mechanical Turk. I demonstrated their possible use cases and pitfalls, plus Ruby API’s. As I expected, people were mostly interested in Mechanical Turk, but unfortunately this service is available only for US developers.

As a side note, I had the worst possible time slot: Sunday morning, after the conference party. The party was good enough to stop most people from getting up in the morning.

My slides are shown below. RuPy folks have promised to put videos from the talks online on YouTube.

What’s coolest about the conference is the people. My personal highlight was Netguru, a small code house in Poznań. I met three nice guys from the company: Adam, Wiktor and Kuba. It turned out they have developed the main competitor for the web app I’ve been working on recently. It didn’t stop us, however, from sharing a beer at Saturday’s party :).

Now I’m looking forward for RuPy 2009!