Developers are sometimes a grumpy set of people.

To a certain extent, I understand my fellow developers - deadlines are tight, features creep in and out from time to time and uncertainty is your daily companion.

Asking the right questions before starting to hack away is crucial but pretty hard at the same time.

It’s hard, because it’s likely that you never did something alike and before sitting down and thinking it through carefully it’s hard to ask the interesting questions to other stakeholders.

So why would you do that?

First of all, estimations help everyone to get the expectations straight. That tough deadline is in two weeks but the estimated work says 2 months? Well, then there’s some sort of problem and you should talk about that.

The work is finished faster than expected? Well, then you may have a problem as well (somebody may have missed important bits & pieces or the code is poorly written, docs may be missing, …)

What can be the reasons that estimations are wrong?

There’s a pretty long list. My top 3:

1.) The task wasn’t thought-through. Sub-task were missed, uncertainties weren’t identified or the requirements weren’t documented. 2.) A lack of experience. It takes some try&error to get a feeling for the common tasks and problems. 3.) Scope creep happened between the estimation and the (delayed) delivery.

Yes, in that particular order.

How do do better estimations?

That’s not a one-shot thing. It took me a couple of attempts to get to acceptable and apropriate estimations for different tasks. Basically you oscillate around the right estimation - sometimes you’re over, sometimes you’re under, but you should always aim to make it as close as possible. If you get your performance to +/- 5%, you’re good. For example: In sprints of one week I tried to be within 2 hours of my estimations. I am pretty sure I never reached that goal, but I wasn’t too bad at it (I think).

A fun look back to the history of computing and the origins of some things we wonder about nowadays. Don’t let the title of the video trick you: This is a lot of fun to watch, it has not too much to do with Javascript and it’s worth watching.

The internet is fast-paced and to build great stuff, it’s vital to manage your project properly.

Because if you don’t, you’ll never build something truly great. You may say “Yup, that’s obvious”. Like everybody does.

The TL;DR: * Focus on building what the customer needs * You don’t know what the customer needs, so ask the customer early on * Measure the use of the features, optimize for the real top features * Waterfall doesn’t work, the original paper (1983) even says so, be agile and deal with it.

But for some reason, whenever I’m on an event or I look at fellow developers I hear the same things over and over and over again?

Here are the top 5: 1. The managers give us not enough time and budget to build giant, complex apps and expect the outcome to be great. 2. The deadlines are unrealistic the moment they’re set 3. Nobody asked us about it, the decisions were made without the developers 4. We’re behind schedule, the set of features is steady (sometimes this is even “it actually grows”) and the deadline can’t be delayed. 5. We don’t have time to really think about anything, we just have to code code code.

It’s not coming from people working in the same company. I hear this a lot and thinking back, I encountered that myself as well. Often.

When you ask people who know enough about coding but are in a managing position, I often get the following reply:

I know, but the management…

I have a theory that has proven to be right pretty often: The project management gets under pressure from the higher management and doesn’t stand their ground, which transitions into putting the pressure on the development team… which doesn’t stand their ground either.

So here’s my suggestion to this: When somebody demands something unrealistic, tell them about the Scope Triangle.

The scope triangle is one of the most-obvious yet most-ignored things in management of IT projects. It looks like this:

It means: From Quality, Time or Money you can pick two or you end up with something shitty. You should now read this article for further details on this.
Seriously, click the link and read that really thoroughly, then come back.

Alright. Now that you understand the key thing there,start by focusing on the only really important aspect: The user.

• If your project looks really great, but doesn’t really do the right job perfectly, it’s shit.
• If your project has a ton of features, but doesn’t really do the right job perfectly, it’s shit.
• If your project has the best user experience, but doesn’t really do the right job perfectly, it’s shit.

Period. No excuses, no “Yeah but…” - the first thing you have to release is something the user wants. What makes people want something? If it does something really good. Everything else is toys.

Do you know what the user needs or wants? No you don’t..
Try it for yourself, make up something you think a given group of people would love. Then go to a coffee shop and offer people from that group a coffee in exchange for telling them your idea.
You’ll be surprised how different their desires and needs are from what you had in mind.

Now that you understood how important it is to get the real user feedback to your idea (actually even before having built the first release), you could do different things:

• Create a simple clickable prototype and do the coffee test again.
• Create a simple real version with only the features you think are the most vital but not more than one or two features. Even if you think “Oh this is useless to the user, because it’s missing XYZ**, do it that way. Then show it to test users and ask them, what they miss. Then extend your product.

Release it early and have a few early-adopters play with it. Proactively ask them and gather analytics on how they use your product and what they need.
Your anticipated killer-feature is not used at all? Throw it out, focus on the most popular thing and direct your design efforts to make this as pretty, easy and useful as possible.

It’s generally a really bad idea to go a top-down approach like waterfall. Be agile. It you think “bah, the modern pseudo-management stuff? Never! I trust my waterfall”, you should finally read the original paper from 1983 - focus on the foreword page 2 and following. Even the author says it doesn’t work that way and they had done prototypes first to minimize uncertainty and risk.

Money quotes:

The great majority seemed to espouse the following approach: we must write the initial top-down specification […], so we will know precisely what our objectives are before we produce one line of code. This attitude can be terribly misleading and dangerous.

(p. 3, line 13ff. ) and

To stretch an analogy slightly, it is like saying that we must specify the characteristics of a rocket engine before measuring the burning properties of liquid hydrogen.

(p. 3, line 17/18)

Native, web, hybrid?

When it comes to mobile application development, there’s far too many evangelism out there.

The web fans sing their

“write once, deploy everywhere”

the native party yells back

“But it’s slow and doesn’t look native!”

but both lack the understanding of the advantages and disadvantages of each approach, as well as the rationalism to re-decide on this matter, based on the project at hand.

Does native always mean better?
Certainly no. Facebook is a great example for this. Their claim was, that the Android app’s quirks and issues originated in its hybrid nature.
The reality is: The new native Android app does not really work any better and Sencha gave an impressive proof that a non-native app could do better.

So a native app is not by definition better.
If you write inefficient code, the performance will be bad and the development iterations may be longer, as you can’t easily test on many different platforms simultaneously without having to repeat modifications in the code for each platform.
If you also run a web version of your project, the mobile web or the hybrid approach allows you to quickly iterate on both of them.

As always you should pick the right tool for the job, which can be a native or web app. It can even be a hybrid app.

The tricky thing is to find out when to use what.

Quick overview of what’s what

• Native: Requires code tailored to each supported platform but gives you direct access to the native features.
• Mobile web: The same code runs on many (if not all) platforms. Can also be delivered to desktop browsers, but can not be installed via app stores and can not access all device features. As the code is run in the browser which runs on top of the operating system, some features may be slower than native features.
• Hybrid: Combination. Same code can run everywhere, all native features can be accessed and native components can be used to get a good performance. Hybrid apps can also be distributed in the app stores.

If you have a big team of experienced mobile developers for the different platforms at hand, you can of course leverage that.

But when you have a team of experienced web developers instead and need to quickly get an app out there (maybe even flanked by a web app), mobile web or hybrid apps are a great tool for achieving this.

The thing many people miss is: It’s not only good for prototyping and quick iterations - it is a viable option for building great apps.
With modern Javascript frameworks and libraries (such as Angular and Lungo in combination with PhoneGap) you can use web technologies to your mobile apps that can play in the same league as native apps.

It needs to look&feel native, right?
First of all: If you want to achieve perfectly native look&feel, you’re not going to have a good time with a hybrid approach. But do you really want that?

Let’s look at the Foursquare app for a second:
©Foursquare

and why not take another look at the Facebook app:

© six revisions, see their great article about native vs. mobile web

It’s easy to spot that even the native Facebook-App doesn’t really look native. And that’s no problem! The user doesn’t really care, as long as it looks great and feels right.

This is something most people get wrong - you can have your very own look in your apps. Stop mimicking the native look and feel and start delivering something great and useful to your users.

But to get in the stores, you need native, right?
No you don’t.
You can for example use PhoneGap to package your hybrid app for many different platforms (e.g. iOS, Android, Windows phone, Blackberry).

Okay, but what if I need the native features, like the camera?
Again, PhoneGap is the answer.

But how do you build a great app?
There are many different ways to build great hybrid apps. To achieve the best results, you should focus on the following aspects:

• Responsiveness - the app has to respond quickly to user input
• It has to feel right - don’t imitate the perfect native transitions. Use decent transitions that are not giving the impression of “wanna be native”
• Be aware that the user won’t always have a good internet connection (or any at all) - leverage local storage whenever you can and minimize the data to transfer
• Use native components (e.g via PhoneGap plugins) whenever needed
• be careful: Not all platforms already support every HTML 5 feature. Provide fallbacks
• test your app on different devices, especially on older ones

Recently on HackerNews, Robin Ward explains why Discourse uses Ember.js.

In the first part he describes, why Javascript client-side MVC is a good thing - and boy, kudos for that, he’s right there.

In the second part however, he explains why they chose Ember from the giant jungle of framework choices out there. And having evaluated Ember, Knockout, Backbone and Angular, I disagree.

The very first example of Angular.js he shows, is Transclude. One of the far more advanced features. What he doesn’t tell you about are the really simple examples of the documentation, including one typical project, you find right on the homepage of Angular.

It’s easy as one two three and took a job applicant with little JS experience a few minutes to get started with it.

Tell me, what’s complicated here.

it is important to me that the Ember community didn’t spring out of a corporate sponsorship

Fine. But this, to me, is not a valid argument. This is blah-blah. Google backs Angular.js. While Yehuda Katz is a great guy with a great track record in Open Source, some people consider Google “the internet”.

There are only a few bigger players out there - and as Angular is open source, you can pick it up and do whatever you feel like with it, if Google abandons it (pssh, as if) or develops it in a direction you dislike. Stop bitching about rockstar people or “corporate is bad, mhkay?”. I wanna get a job done and Angular.js does this pretty well.

Plus: When I went to StackOverflow a few months ago because I had a few problems, there was one (in numbers “1”) thread for one of them. One. With no answers. The rest was fishing in the dark. Is that an “excellent support of the community”? For Angular I only had to look something up once. And found a lot of support activity in various channels.

This may have changed, as Ember.js is moving forwards, but Angular was at that point already and is moving forwards in a very fast pace as well.

Another thing that is only marginally mentioned, is the fact that Angular.js uses vanilla-style Javascript and the DOM in a pretty normal fashion. No fancy-pants .extend() stuff, no class-hierarchy magic. No “attr()” or set()/get() stuff. Just plain JS ala “$scope.blah = 123”. That’s it.

Also, you can comfortably consume APIs of different flavors.

Is it proper REST? Yay, just throw in the ngResource!

Oh its unRESTy? Well, just throw in ngResource with adapted methods or use $http. Quick&easy. No tears.

Even if this article may sound a little harsh and rant-y, I think Ember.js is nice. But looking at it from a more practical perspective (e.g. having developers that are familiar with “the good ole Javascripte” vanilla JS and HTML, as well as having to deal with complex systems and non-REST APIs) Angular.js comes at lower cost when it comes to adoption and producing most of the web applications, you wanna build these days (and possibly tomorrow).

LEAPiano - a LeapMotion demo using the Javascript API, HTML5 and CSS.

The actual LeapMotion is set in front of the display and allows precise & responsive controls using your hands (or other things) floating over the device.

The audio comes from DataURIs, no audio files are needed.

The code is available on GitHub

Lately, the web has become a really powerful platform.

With things like UserMedia, WebRTC and WebGL it can do many things you may not expect to be possible in your browser.

This article wants to shed a light on one more use case: Developing and deploying a web application from scratch - only using your browser.

Cloud9 - the IDE is your browser

First of all, you need a place to write and test your application, basically you need some sort of development environment. Cloud9 provides this.

It allows you to build web applications, run ruby or node.js applications, install gems as well as node packages and run them.

It integrates well with Git-, FTP- or SSH servers. The free plan includes public workspaces, but you can have private workspaces with the paid plan.

Cloud9 serves your application from a globally reachable address but stops processes like node or rails after a certain time (which is long enough for testing, though).

Bonus: Cloud9 is open-source.

For a full-power web application you may need a database… the next step describes how to set up and manage a mongo instance from your browser. If you don’t want mongo, check Appfog below.

MongoHQ - your database as a service

MongoHQ allows you to create and manage mongo databases via a simple web interface.

You can also view, edit or delete documents or collections from your browser or connect using the mongo shell (which also integrates well with Cloud9).

Appfog - cloud hosting made really easy

Appfog is like Heroku, but it offers you a lot of different languages, frameworks and tools.

You can start by creating an application from their web interface.

Deployment is done via their “af” rubygem from the console (I use the console from Cloud9, which works like a charm).

Afterwards you can create and bind services, which is basically one of the many supported databases (mongo, redis, postgres, mysql,…) to use with your application.

In addition, you can scale your application by adding more RAM or instances to it.

Now we created our web app + database and host it on the cloud - all from our browser.

But this is not the end of the story - let’s test how well it performs!

Blitz.io - load testing as a service

Blitz.io allows you to test how your application reacts to a given amount of users hitting your website over a given time.

You can configure from where the bombardement with users should come (they have a bunch of regions, scattered all over the world), the pattern of the users hitting your application (e.g. linear growth or saw-tooth patterns) and how long the “rush” should last.

Afterwards you get a summary of how many hits per second were successful, how many errors and timeouts happened and some more details.

For the impatient readers: If you run into this, try sending the POST params in the querystring instead of the body. This does not only apply to node.js twit, but is generally valid.

The longer version:

I was playing around with twit lately. It’s a wonderful node module that allows you to interact either with the Twitter REST or the Streaming API in a very easy way, possibly the easiest way I’ve ever seen.

I tried to post a new Tweet saying “Hello World!” which didn’t work.

The REST API responded with “Status 401, Could not authenticate you” and I started googling.

The first hint that came up, was trying to use v1 instead of v1.1 of the API. This resolved the issue! But as v1 is going to deprecate soon, I didn’t want to go that way, but find the root cause.

I ran the tests for twit and found, that it actually was abled to tweet. Even with v1.1.

The only difference was the text for the new tweet: The (successful) example from the tests did not contain an exclamation mark, while my (failing) example did.

So I removed the exclamation mark from my example - and it worked.

I looked through the many discussions of the “Code 32” issue on the Twitter developer portal and finally found https://dev.twitter.com/discussions/11280 that answered this:

If you, for some reason, send the parameters for the POST via the querystring - instead of the “right way” for HTTP POST where the parameters go in the HTTP body - it works!

I changed that and it worked surprisingly well - my pull-request to twit is currently pending.

In our office we had a spare TV and wanted to use it as an information radiator in our room.

As our setup involves Github where pull requests are built with Jenkins to verify everything is working as expected, I wanted to put the success rate of the builds, the build health and the latest open pull request on the screen.

The screen is hooked up to a Raspberry Pi, so I had a vast amount of possibilities to get something on screen.

After having a look at Dashing, I decided to go for it and build the project-cockpit project on top of it.

It uses the Jenkins API to get the ration of successful / non-successful builds as well as the latest build state. It also calls the Github API to get the latest pull request to display the name and picture of the author and the title of the pull request on the dashboard.

This is how it looks like in action:

In case the latest build is broken, it plays a Youtube Video of an exploding nuclear bomb.

The next step will be to show the JIRA tickets in the different stages (open, in progress, done).

If you look for a nice way of documenting your Javascript, apart from the Java-based JSDoc  and want something easy and comfortable to use, check out YUIDoc.

Getting started is as easy as installing the node.js module:

$ npm install -g yuidocjs

and generate your docs with

$ yuidoc .

The syntax for documenting your code is similar to what you may already know from tools like JavaDoc, Doxygen, et. al. See the reference here.

YUIDoc server auto-regenerates the docs while you develop

The nastiest part, during the development, ist the need to regenerate the docs, whenever you change something. YUIDoc is nice enough to provide a server, that automatically regenerates the docs for you, when your files change. This way, you just need to refresh the page in your browser to see the latest changes in the docs.

You can start the server with

$ yuidoc —server .

See the manual for more.

Optionally show private, protected or deprecated docs as well

Despite the fact, that the documentation says that private documentation is not displayed, you find a checkbox in the generated HTML documentation, that allows you to also display private, protected or deprecated documentation blocks.

All in all, an easy to use tool that makes documenting your code less painful and produces use- and beautiful documentation for your Javascript code.