According to his biography,

Van Gogh began to draw as a child, and he continued to draw throughout the years that led up to his decision to become an artist. He did not begin painting until his late twenties, completing many of his best-known works during the last two years of his life. In just over a decade, he produced more than 2,100 artworks, consisting of 860 oil paintings and more than 1,300 watercolors, drawings, sketches and prints. [...]

Before focusing on painting, he worked as an art dealer, teacher and missionary. It wasn’t until he was 32 that he painted his first major work.

He did not have the fortune of being recognized as a talented artist in his young age like Michelangelo and others and yet still he did not let go of his desire of becoming a painter. The thing that strikes most of the museum is the quantity of studies and sketches Van Gogh made throughout his live in order to improve his skills. He wanted to paint so much that he kept practicing and put so much effort in improving that it eventually paid off: he is now remembered as the author of dozens of the most renown paintings of the history of art.

In an age where the reference point to define an accomplishment is starting a company at 16 and become a billionaire at 22, we risk underestimating the value of persistence. Sure, he did not reach fame and success while he was alive, and his life was not what you would define “happy”. But if he had quit because he was not an accomplished painter in his young age, art now would certainly be very different from what we know.

The works of Van Gogh are a proof that there is no such thing as being too late to accomplish something remarkable.

Posting source code on WordPress.com is quite simple: the platform already provides an extremely easy to use shortcode called sourcecode, based on a fairly flexible syntax highlighter plugin. By looking at the examples in the documentation page, however, it is evident that the default styling used to render sources is quite old-fashioned and does not fit most modern themes.

While the shortcode offers options to allow users to control many options of the rendering, it does not allow us to configure colors, fonts and size (the default size is so tiny that it is barely readable on high-resolution screens).

When I was writing the previous technical post, I did some investigations to figure out what options are available to post more readable sources if your blog is hosted on WordPress.com and I found out there are basically two alternatives.

Embedding Gists

The easiest option is to rely on Gist - GitHub’s tool for sharing snippets of code – which offers an extremely easy way to embed code in your blog. Just create a new snippet (gist) there and follow the instructions.
Unfortunately, the gist embed shortcode available on WordPress.com is less flexible than what you would get if you installed it as a plugin on your own instance of WordPress, but it will be enough for most cases.

Styling source code by customizing your CSS

While Gists work great most of the time, they are a pain to create and maintain if you are working on a post that should include multiple short snippets of code. In that case, the amount of bookkeeping you have to do is significant (you will have to create and link many small chunks of code) and you may want to be able to manage your code right within the post.

In that case, it may be more practical to fix the CSS theme used by the syntax highlight plugin to make it look post-2010. If you set your own custom CSS on WordPress.com, it will be supposed to be included as the last one to allow you to redefine the styles specified by the theme you are using.
Unfortunately, the CSS used by the syntax highlight module was clearly not written with extensibility in mind, but quite the opposite:

• all the style declarations it includes make use of !important,
• the plugin will dynamically include its own CSS as the last item in the head node, meaning that it will have preference on the custom one you define.

This makes sense in the original context – the original syntax highlighter offered several themes you could choose from by including different stylesheets, but that feature is not available on WordPress.com – but will make your life more difficult. You will need to add !important to all the CSS declarations you redefine and you will need to use CSS selectors that are more specific than the ones used by the plugin. You will be able to see the final result at the end of this post.

WordPress’s syntax highlight is not perfect, and some things are still quite annoying (e.g. line numbers get in the way if you try selecting and copying source code). Most issues could be addressed by upgrading the plugin to use version 3 of SyntaxHighlighter instead of the outdated version that is in use now, but it is something you will not be able to control unless the folks at Automattic decide to update it.

What did I choose?

Here is the stylesheet (embedded as a Gist) I am currently using  on this blog, based on the pygments theme used to style code at docs.python.org.

You can can see what the final result looks like in this post about User authentication with webapp2 on Google App Engine and in the image at the beginning of this post.

The webapp2 framework on Google App Engine for Python 2.7 is definitely a step forward from the original webapp.
Despite the increase in flexibility and functionality, however, there are a few items that are still more laborious than in other frameworks. The most notable aspect is user account management.

Unsurprisingly, since it is meant to run on Google’s App Engine, using Google Accounts with webapp2 takes one line of code. OpenID authentication, while still defined experimental, is almost trivial to implement as well. There are some open source projects like SimpleAuth that attempt to offer a standard and unified API to handle signing in with Google, OAuth and OpenID accounts.

While it generally makes sense to offer support for authentication through popular services – it decreases friction for new users to try a service – in some cases users may prefer having a special login to access your application.

As experience teaches us, managing passwords securely is not a trivial task, and users legitimately expect application developers to take all the necessary measures to protect their passwords.

Since this is a use case that has to be considered countless time, there is significant value in using library functions to handle user accounts.

Here is how to do that using the functionalities embedded in the webapp2_extras package that is distributed with all standard installations of App Engine for Python 2.7.

Basics and prerequisites

Our main interface when dealing with authentication is webapp2_extras.auth. This module leverages the rest of webapp2′s infrastructure to offer us a simpler way to manage user authentication.

In particular, it relies on

• webapp2_extras.security to handle password hashing (so that passwords are never stored in clear text) and random string generation;
• webapp2_extras.sessions to identify requests coming from the same user as part of a client-server conversation.

Since we are implementing our own user database, we will need to define a custom model class to represent users in our application. The auth framework described here works under the assumption that this model class defines the following instance method:

• get_id(self)

and the following class methods:

• get_by_auth_token(cls, user_id, token)
• get_by_auth_password(cls, auth_id, password)
• create_auth_token(cls, user_id)
• delete_auth_token(cls, user_id, token)

The specific role of each of those methods is described here.

In addition to that, if you are interested in using the code for password reset provided as part of this tutorial, you will also need to implement the following class method:

get_by_auth_token(cls, user_id, token, subject='auth')

For each request, our application will then be able to do the following:

1. read a cookie to figure out whether the current belongs to an existing session,
2. if a cookie is found, read an authentication from it and load the corresponding session (if present) from the session store backend,
3. loads some cached user information from the session.

We will be able to tune some details of the process via configuration options.

Extending the default User model

webapp2 already contains a reference User model for Google App Engine that uses NDB for storage. If you are willing to use that, you will find it good enough for most of the needs you may have.
In particular,

• it is an Expando model – it can include properties that were not specified as part of the class definition but are added at run-time, so it will not be a problem if your application needs to store some specific user information. New properties are indexed by default, so queries should still be fast.
• it allows you to set uniqueness constraints – while NDB does not support unique properties by default, webapp2′s User model uses a custom mechanism to allow to allow that.

Oddly enough – since the User class is clearly well designed – the reference implementation does not offer any method to update the password for a given user once it has been set. Because of that, it is a good idea to extend the User model to add a
set_password method that will have the responsibility to securely hash passwords using the security module.
You can find an example User model implementation below: it will contain the password setter and the get_by_auth_token class method (modeled after the one already provided by webapp2) that has been introduced in the previous section.

import time
import webapp2_extras.appengine.auth.models

from google.appengine.ext import ndb

from webapp2_extras import security

class User(webapp2_extras.appengine.auth.models.User):
  def set_password(self, raw_password):
    """Sets the password for the current user

    :param raw_password:
        The raw password which will be hashed and stored
    """
    self.password = security.generate_password_hash(raw_password, length=12)

  @classmethod
  def get_by_auth_token(cls, user_id, token, subject='auth'):
    """Returns a user object based on a user ID and token.

    :param user_id:
        The user_id of the requesting user.
    :param token:
        The token string to be verified.
    :returns:
        A tuple ``(User, timestamp)``, with a user object and
        the token timestamp, or ``(None, None)`` if both were not found.
    """
    token_key = cls.token_model.get_key(user_id, subject, token)
    user_key = ndb.Key(cls, user_id)
    # Use get_multi() to save a RPC call.
    valid_token, user = ndb.get_multi([token_key, user_key])
    if valid_token and user:
        timestamp = int(time.mktime(valid_token.created.timetuple()))
        return user, timestamp

    return None, None

Setting up the configuration

With what we have seen so far, we are now able to configure our application. We will need to set some properties as follows:

config = {
  'webapp2_extras.auth': {
    'user_model': 'models.User',
    'user_attributes': ['name']
  },
  'webapp2_extras.sessions': {
    'secret_key': 'YOUR_SECRET_KEY'
  }
}

In particular,

• user_model is the name of the custom User model class we described earlier,
• user_attributes is a list of attributes in the User model that will be cached in the session. Ideally, frequently accessed properties should be stored here. The full User model will be accessible by querying the datastore.
• secret_key is the key used to secure the hash signature calculation for session cookies.

Creating a base handler class

Before writing the actual handlers that will implement the business logic to sign up and authenticate users we will group some utility functions in a base handler class, which will be extended by all the following handler classes.

This will ensure that all handlers will inherit a set of useful utility functions and properties to access user data and infrastructure classes, but also ensures that all session data is properly saved on each request (see dispatch).

class BaseHandler(webapp2.RequestHandler):
  @webapp2.cached_property
  def auth(self):
    """Shortcut to access the auth instance as a property."""
    return auth.get_auth()

  @webapp2.cached_property
  def user_info(self):
    """Shortcut to access a subset of the user attributes that are stored
    in the session.

    The list of attributes to store in the session is specified in
      config['webapp2_extras.auth']['user_attributes'].
    :returns
      A dictionary with most user information
    """
    return self.auth.get_user_by_session()

  @webapp2.cached_property
  def user(self):
    """Shortcut to access the current logged in user.

    Unlike user_info, it fetches information from the persistence layer and
    returns an instance of the underlying model.

    :returns
      The instance of the user model associated to the logged in user.
    """
    u = self.user_info
    return self.user_model.get_by_id(u['user_id']) if u else None

  @webapp2.cached_property
  def user_model(self):
    """Returns the implementation of the user model.

    It is consistent with config['webapp2_extras.auth']['user_model'], if set.
    """    
    return self.auth.store.user_model

  @webapp2.cached_property
  def session(self):
      """Shortcut to access the current session."""
      return self.session_store.get_session(backend="datastore")

  def render_template(self, view_filename, params={}):
    user = self.user_info
    params['user'] = user
    path = os.path.join(os.path.dirname(__file__), 'views', view_filename)
    self.response.out.write(template.render(path, params))

  def display_message(self, message):
    """Utility function to display a template with a simple message."""
    params = {
      'message': message
    }
    self.render_template('message.html', params)

  # this is needed for webapp2 sessions to work
  def dispatch(self):
      # Get a session store for this request.
      self.session_store = sessions.get_store(request=self.request)

      try:
          # Dispatch the request.
          webapp2.RequestHandler.dispatch(self)
      finally:
          # Save all sessions.
          self.session_store.save_sessions(self.response)

Note – You may want redefine the view-related methods to something different if you use a different templating engine.

Registration: create new users

If we are using the model class discussed in the previous sections, in order to create a new User we just need to call the create_user method.

class SignupHandler(BaseHandler):
  def get(self):
    self.render_template('signup.html')

  def post(self):
    user_name = self.request.get('username')
    email = self.request.get('email')
    name = self.request.get('name')
    password = self.request.get('password')
    last_name = self.request.get('lastname')

    unique_properties = ['email_address']
    user_data = self.user_model.create_user(user_name,
      unique_properties,
      email_address=email, name=name, password_raw=password,
      last_name=last_name, verified=False)
    if not user_data[0]: #user_data is a tuple
      self.display_message('Unable to create user for email %s because of \
        duplicate keys %s' % (user_name, user_data[1]))
      return

    user = user_data[1]
    user_id = user.get_id()

    token = self.user_model.create_signup_token(user_id)

    verification_url = self.uri_for('verification', type='v', user_id=user_id,
      signup_token=token, _full=True)

    msg = 'Send an email to user in order to verify their address. \
          They will be able to do so by visiting  <a href="{url}">{url}</a>'

    self.display_message(msg.format(url=verification_url))

create_user will accept the following parameters:

• an authentication id: the token (such as a username or an email address) users will use to identify themselves when trying to access our application. While users can have multiple authentication ids, only one is allowed at creation.
• a list of unique properties (in this case, email_address): if this is specified, webapp2 will not allow us to create new users if others share the same values for the properties in this list.
• name/value pairs that are going to be set as properties of the resulting User model. If you want to add your own fields, this where to do it. If a parameter called password_raw is present, it will be assumed to be the user password that will be used for authentication; webapp2 will hash it and store the hash the password field: we do not want to store passwords in clear text, do we?

We also create a signup token and associate it to the newly created account: we will use to confirm the email address that has been provided during registration.

Note that we are accessing the model as self.user_model rather than calling it directly, so that we are free to change which implementation to use by updating the application configuration.

Login and logout

If users are created as in the previous session, login is quite simple: the get_user_by_password method can be used to retrieve a user by their credentials. In addition to the user credentials, the method accepts some additional parameters. The one we care about (and the only one we use here) is remember: when set to True, the cookie used to identify the session is saved as persistent and the browser will keep it even after the user will close its window.

class LoginHandler(BaseHandler):
  def get(self):
    self._serve_page()

  def post(self):
    username = self.request.get('username')
    password = self.request.get('password')
    try:
      u = self.auth.get_user_by_password(username, password, remember=True)
      self.redirect(self.uri_for('home'))
    except (InvalidAuthIdError, InvalidPasswordError) as e:
      logging.info('Login failed for user %s because of %s', username, type(e))
      self._serve_page(True)

  def _serve_page(self, failed=False):
    username = self.request.get('username')
    params = {
      'username': username,
      'failed': failed
    }
    self.render_template('login.html', params)

The implementation above renders the login form when the request comes via GET and processes the credentials upon POST. When authentication fails it renders the login form and passes the username to the template so that the corresponding field can be pre-filled.

Implementing logout is even simpler: it is sufficient to get rid of the user session.

class LogoutHandler(BaseHandler):
  def get(self):
    self.auth.unset_session()
    self.redirect(self.uri_for('home'))

Email confirmation and password reset

Signup tokens are one of the undocumented features of webapp2 (and they may possibly subject to change), but they can be quite handy when implementing a flow to confirming email addresses or recover passwords.

As mentioned before, the webapp2 uses authentication tokens to identify users after they logged in: they are meant to be securely shared by a client and the server and exchanged when a client needs to prove its identity.

As you probably imagine, this mechanism can be generalized to handle email confirmations and password resets: when websites send us an activation link after a registration, the URL usually contain their equivalent of signup tokens.

webapp2 sets a subject property for each of the tokens it generates, so the only difference between auth token and signup token is the value for that property. So, why do we want to use signup tokens?

Setting a different value for that property allows us to partition tokens by their purpose: we can then implement useful features as deleting all the password reset tokens that have not been used in 48 hours.

Here is a sample verification handler that is able to process email verification links:

class VerificationHandler(BaseHandler):
  def get(self, *args, **kwargs):
    user = None
    user_id = kwargs['user_id']
    signup_token = kwargs['signup_token']
    verification_type = kwargs['type']

    # it should be something more concise like
    # self.auth.get_user_by_token(user_id, signup_token
    # unfortunately the auth interface does not (yet) allow to manipulate
    # signup tokens concisely
    user, ts = self.user_model.get_by_auth_token(int(user_id), signup_token,
      'signup')

    if not user:
      logging.info('Could not find any user with id "%s" signup token "%s"',
        user_id, signup_token)
      self.abort(404)

    # store user data in the session
    self.auth.set_session(self.auth.store.user_to_dict(user), remember=True)

    if verification_type == 'v':
      # remove signup token, we don't want users to come back with an old link
      self.user_model.delete_signup_token(user.get_id(), signup_token)

      if not user.verified:
        user.verified = True
        user.put()

      self.display_message('User email address has been verified.')
      return
    elif verification_type == 'p':
      # supply user to the page
      params = {
        'user': user,
        'token': signup_token
      }
      self.render_template('resetpassword.html', params)
    else:
      logging.info('verification type not supported')
      self.abort(404)

This handler is meant to be used with a route using a template that matches URLs like /v/USERID-TOKEN. You can configure it as follows (please refer to the sample code at the end of this article for the full routes configuration):

webapp2.Route('/<type:v|p>/<user_id:\d+>-<signup_token:.+>',
  handler=VerificationHandler, name='verification')

Two minor notes on this item:

1. For increased security, we may require users to enter their password before authenticating them.
2. Ideally, we may want to use a different subject for email confirmation and password reset tokens.

Ensure users are logged in

Now that everything else is in place, we can decide whether users are allowed to access certain resources depending on their logged in state.
The following decorator can be used to annotate handler methods that require users to be logged in.

def user_required(handler):
  """
    Decorator that checks if there's a user associated with the current session.
    Will also fail if there's no session present.
  """
  def check_login(self, *args, **kwargs):
    auth = self.auth
    if not auth.get_user_by_session():
      self.redirect(self.uri_for('login'), abort=True)
    else:
      return handler(self, *args, **kwargs)

  return check_login

Just placing @user_required, as in the following example, before those methods will ensure that anonymous users will be directed to a login page when attempting to go through the annotated handler method.

class AuthenticatedHandler(BaseHandler):
  @user_required
  def get(self):
    self.render_template('authenticated.html')

Finishing touches

Before actually using this in code in production, there is at least one task we should take care of: calls that send passwords (like login, signup, password reset) should be using https.

This is quite easy to do and the documentation is quite straightforward: just follow the instructions here and you will be all set.

Your app.yaml file should include the following once you are done:

handlers:
- url: .*
  script: main.app

- url: /signup
  script: main.app
  secure: always

- url: /login
  script: main.app
  secure: always

- url: /forgot
  script: main.app
  secure: always

libraries:
- name: webapp2
  version: "2.5.1"

Of course, we will also need some views to be able to use this application. While this is the typical task that is left as an exercise to the reader, the example implementation you will find in the following section will contain a fully working application you can play with.

Reference code

You can find a ready to use application skeleton on GitHub. Feel free to play with it to experiment the full flow described in this post, use it to bootstrap your project and to improve on it. Just post a comment if you have any question or suggestion.

Keyboards, however, are still the most efficient way to interact with a computer, and not only for typing email. From code editors like Emacs to advanced image manipulation tools like Photoshop, it is no wonder that most advanced programs can be controlled more efficiently by means of keyboard shortcuts.
The learning curve for shortcuts is generally quite steep: while some of them are standard across programs and can be easily guessed, most shortcuts are complex abstract key combinations (as Command-Control-Shift-3 on Mac, that takes a screenshot to the clipboard) and therefore not easy to remember.

Some applications, however, are introducing smarter ways to control our computers using a keyboard.

Alfred: Mac at your fingertips

Mac OS has a long tradition of exposing keyboard shortcuts that allow power users to perform common tasks more efficiently. Introducing Spotlight was one more step towards keyboard driven interaction, as it allows to access applications, files and many other items by typing in a text box. Alfred, takes this approach to a new level: just like with Spotlight, pressing a combination of keys brings up a text box where you can enter anything from file names to simple commands (like empty trash, shutdown, and many more).

The advantage over the built-in solution is that those commands allow you to control many functionalities that traditionally would have required you to click through several items and menus. Alfred will even adjust its behavior depending on the way you use it: it will present you first the options you select the most.

Sublime Text: controlling a text editor through text commands

When working with a text editor, typing on a keyboard is – by definition – the main means of interaction and so these programs traditionally rely on keyboard shortcuts more than any other. The over 2000 keyboard shortcuts available in Emacs are the most significant evidence of the level of complexity shortcuts can reach: it is impossible to master all the key sequences, only the most common ones.

Sublime Text, one of the best editors available today, takes an innovative approach to keyboard interaction: instead of requiring users to memorize arbitrary key sequences, it offers a mode called Command Palette, that allows users to type the name of any command to launch it.

Compared to having to learn or remember keyboard shortcuts, this approach saves users also the need to sift through the application menus to find the feature they are looking for. As a side effect, it is also a much more effective way to discover application features than reading a manual.

Ubuntu: using HUD to get past menus

If the previous mode of interaction is still an exception on Windows and Mac, Ubuntu took some bold steps towards that: they designed a new system called HUD (as in Head-Up Display).

It immediately offers users the same benefit as Sublime Text’s command palette: faster interaction with menus items and easier discovery of features. In addition to that, however, it shares with Alfred its adaptive behavior and will learn by user behavior.

While HUD is ultimately designed with voice control in mind, keyboard commands are still extremely efficient and already effective today.

You can see it in action in the following video.

Embedding features like these in the operating system (or, more precisely, in the desktop shell) means that we will be able to control any application in a faster and more efficient way, regardless of whether its developers planned for that feature in advance or not.

Conclusion: why should I care?

Decades ago, keyboard shortcuts were born as a means to offer power users a more efficient way to perform their tasks. Nowadays, with fast access to command search (one or two keys) and smart algorithms to search through commands, anyone can become a power user in less time.

Not all applications will benefit dramatically from command search, but this pattern will become more and more common when web sites/applications start offering it: look at Google Docs menu search and GitHub’s command bar.

After a brief presentation of the services offered by the hackathon partners (Apigee, Esri, Spotify and Sendgrid) Diderik, Mattia, Mike and I teamed up to build the hack featured here. We started with the most obvious concept we could come up with: putting songs on a map and having people visualize them. We tried to elaborate the concept to include as many of the partners’ APIs as we could, but then we decided for something simpler, something we could build over the weekend.

Bring Your Own Music!

It took us a couple of iterations to get to the final idea we developed: Bring Your Own Music, a toy application that allows users to control music playback through NFC-enabled objects by using an Arduino-powered NFC reader driving a Spotify app.

BYOM is based upon the idea of attaching Spotify playlists to physical objects, provided they contain an NFC tag, like many of the cards we have in our wallet. Once you have done that, you can then bring your card with you to a party, tap it on an NFC reader, and have a Jukebox Spotify app like the one we built start playing your songs automatically.

A screenshot of the Spotify Jukebox app we built during the hack battle

If multiple people tap their own cards, the main Spotify playlist adjusts itself according to the general preferences of the party attendees. We even kept playing with NFC-enabled objects and linked Spotify playlists to all sort of cards, like London’s Oyster cards, OV-Chipkaarts and even the disposable tram tickets you get here in Amsterdam.

As Mattia noted,

wouldn’t it be great if passengers could listen to their favorite music when they check-in on trams?

How was BYOM built?

We collected the identifiers of a bunch of NFC cards, OV-chipkaarts and tram tickets using Mike’s Arduino connected NFC reader. We then created a collection on Apigee App Services to store the card ids and URIs of the Spotify playlists we wanted to link to them.

We programmed Arduino to make a call to Apigee whenever a card is tapped on the reader, in order to store the card identifier into a Swipes collection.

Hey, look, there is an Arduino in the box!

At the same time, we wrote a Spotify application that periodically queried Apigee for new swipes and, as soon as a new card was detected, fetched the songs associated to it and merged them into the main playlist (the one the Spotify Jukebox app would play).

What have we learned by it?

We (I, at least) walked away with some important teachings:

• focus is more important than ever: there is no point in imagining lots of features if you are not going to finish them. Pick a small set of features and make them work (or almost work: we had the inevitable demo-time malfunctions despite having tried the full example multiple times before presenting),
• build a story: having a story (in our case, the party) around your hack helps you focus and helps you when presenting it,
• get some constraints: there are thousands of interesting APIs, devices and ideas out there, and even more ways those can be combined. Choose some constraints to ensure you don’t wander off too much (in our case, we wanted to do something with Mike’s NFC-reader)
• have fun: while these sounds like rules, they are more of an advice. Do not let them distract you from your goal: having fun.

What about the technologies?

Arduino is indeed an extremely versatile tool and the amount of sample code and libraries available out there is surprising. While it can be a pain to debug at times, the fact that it allows you to add a physical dimension to your hacks is invaluable.

Spotify‘s wise choice to build their application framework on top of Chromium means that developers can leverage the tools they already got to know by developing web applications. The actual app SDK is a JavaScript library you an include and debug using the tools in Chromium. We were able to get started in minutes and, once Andrew put us on the right track (by pointing us at the experimental but more powerful 1.0 API), never hit a wall or get stuck at all.

Apigee App Services is indeed a valuable tool: it saved us a lot of time by taking care of storing our data and, more important, exposing it over the internet with no hassle. (The fact that we were even able to interact with it through an Arduino is not trivial.) It also took away the need of building an admin interface for most basic needs. Quoting Diderik

Apigee allowed us to get so much done on the first day of the hackathon that we could go home and get some sleep for the night.

How did it go?

Not bad at all. We managed to win a couple of prizes: each of us won a 6 months premium subscription to Spotify (thanks Andrew!) and a gift certificate courtesy of Apigee (thanks Tim!). All in all, we did not build BYOM for the prizes, but we were glad to get them.
The most important thing is that we had great fun coming out with a solution that worked and thinking about how to communicate what seemed so cool to us. We had even more fun seeing what the other teams had built (there were some really brilliant hacks indeed). Isn’t that what a hackathon should be about?

Can I see it?

Sure, you can check the source code. Beware: it’s hackathon-grade code, so it probably does not look like the clean code you would normally want to write during the day. If you are curious, here is a video with Bring Your Own Music and all the other cool hacks built at Kings of Code 2012 Hack Battle. (It is a bit dark, but you get the idea.)

More from us: Follow @diderikvw Follow @nldmike Follow @raibaz Follow @abahgat

Thank you guys for the great weekend!

This post is a bit unusual for this blog: a few months ago I moved from Milan to Amsterdam (curiously, four years after my first visit to the city) and gathered some advice from friends and websites in the process. That information helped a great deal during my first weeks here and ensured that my move was a smooth one. I believe others in the same situation may benefit from the notes I gathered, so I decided to post them here.

As an EU citizen with a job offer from a company that has an office in the Netherlands, my transition was quite easy, but there were still some aspects that took me a while to figure out: I will try to cover most of them within this post. For everything else, you may find a lot of useful information in the links at the end of this article.

Finding an apartment

I had started looking for apartments to rent a couple of weeks before flying in but soon realized it was an exercise in futility. The rental market is extremely dynamic here: properties that are up for rent one day may be gone the day after and new ones show up daily. Because of the high demand, both agents and landlords tend to ignore messages from anyone who is not already in the city. Start looking for apartments during the very last days before moving in: it will give you an idea about the market prices and you will have some chances of getting an appointment to see the places you want to see before they are rented out.

Here a few websites you can start from

• Funda – a website affiliated with the national association of real estate agents, it is one of the most reliable sources as the postings are reviewed and usually backed by an agency. The downside is that it is only in Dutch (you’d better get used to that), but you can Google Translate it.
• Pararius – you will generally find almost the same postings you found on Funda, but Pararius is translated in several other languages (I mean the interface: the contents of the posting are likely to be in Dutch, clearly) but sometimes you can find posting by landlords that are not relying on an agency (yet).
• Craigslist – less popular here than in the US, it is still possible to find a good number of listings for Amsterdam. Beware, however, that a good fraction of them are from scammers after your money or your personal details. If you are willing to invest some time to sift though the garbage, you may find some good deal without having to rely on an agency. You may use this IFTTT recipe to get email notifications of new posts straight in your inbox.

While there are other websites, they are likely to have the same information you can find on Funda and Pararius.

Once you are in Amsterdam you can visit agencies in the area(s) you are considering and tell them your requirements and your expectations. Do not overdo by contacting too many of them, though: most agencies have access to the same properties to rent, and they it is not unlikely that they will propose you the same properties you saw yourself on Funda.

Make sure you visit the areas where you are considering renting: while the city is small and commute is generally significantly shorter than in other European cities, each neighborhood has its own character and perks. Ideally, you will want to see what the place looks like during day and night.

Depending on where you live now, there are some details you may not pay attention to because they are not as relevant in the city you come from. A few examples

• tram lines – check whether there is a tram line running right below your window and the area is popular with tourists. The combination of those two is that you will frequently hear the loud bell noise conductors use to scare people away (literally) of the tracks. Most houses are built with bedrooms away from the road so the noise may be less of a problem at night, but still you want to know what to expect.
• bike stands – some neighborhoods seem to have a chronic shortage of bike stands. While usually you may be able to chain your bike to a signpost or a tree, it may still be difficult to find a place to leave it if you come back late at night.
• parking – if you are planning on driving a car, bear in mind that finding a place to park in Amsterdam is generally challenging, and usually it is not free. You can apply for a parking permit for the neighborhood you live in, but there may be a wait list several months long.
• shops – since there aren’t many malls but plenty of smaller supermarkets, you will not be shopping for groceries once per week, but you will find it easier to make smaller purchases more frequently. Surprisingly, butcher shops, bakeries and greengrocers are cheaper (and the food you find there often tastes better) than supermarkets. Having shops close to your place will make your file easier in this sense.

Once you find a place you like, it is time to look at how contracts work.

Understanding the contract

The laws regarding renting in the Netherlands are very protective of tenants. The market is strictly regulated and aspects like the conditions for breaking the contract, the maximum rent and standard contract conditions have to follow certain rules. I found this article to be a good source of information about how the whole system works.

Two important points about the regulations are that, under normal circumstances:

• only the tenant is allowed to break a contract,
• “temporary” contracts are extremely uncommon.

There is a points system according to which every apartment is given a score depending on many different factors (condition, location and many others), and that score determines the maximum price a landlord is allowed to charge. However, as soon as the score of an apartment exceeds the number points that correspond to about € 650, that apartment is considered to belong to “free market” and the score is not really important anymore. That explains why there is almost no apartment in the € 650 – 900 range: apartments that rent for less than € 650 are usually given to locals who have the patience to apply for rent and go through a wait list, and then there is a second market for expats, who don’t know the system or can’t afford to wait months in order to secure a fair rent. If you have a contract and you are not sure whether it is fair there is a non-profit organization, called Wijksteunpunten Wonen, that can help you: its members will review your contract and give you advice on how to proceed.

Understanding rent costs

Rent prices in the Netherlands can be exclusive or inclusive of expenses. Exclusive prices work as you expect: you pay the landlord the base rent only, and you have to pay all the service costs yourself. With an inclusive rent, you pay an estimated amount in addition to the base rent as an advance payment for service costs (like energy and gas). In this case, the landlord is expected to keep an account of the actual costs and settle the bill at the end of the each year (refunding you the difference if you paid more or asking you to pay the difference if you paid less), so that you will not have to take care of setting up the contracts for energy, gas and the rest.

Regardless which option you choose, you will also need to consider that you will be expected to pay all the bills that are in registered in your name (like the taxes for water and for waste disposal). Fees often depend on where you live, you may spend about € 300 per year in addition to the rent. You will start getting those bills by the moment you register as a resident (see the following sections) in your apartment.

If you rely on an agency, be prepared to pay a commission of roughly one month’s rent at least (generally it is calculated on the base rent, excluding expenses, plus 19% tax). This will effectively mean that you will need to be able to pay roughly three times the rent upon entering the apartment (the commission, the first month, and one month’s rent as a deposit).

Looking for shared accommodation

I have been focusing since the beginning in finding an apartment, but there certainly are plenty of options if you want to share a place with someone else. The two options I have been (shortly) considering are Craigslist (again, the same considerations in the previous section apply here) and Kamernet, a well-known website dedicated almost exclusively to rooms for rent. Even more than with apartments, being already in Amsterdam helps: you want to meet your possible flatmates in person and, more important, they want to meet you before making a decision. Do not make the mistake of underestimating the reach of your friends and acquaintances: they may know someone who is looking for a flatmate.

Registering as a resident and obtaining a BSN

Getting a BSN (Burgerservicenummer, a sort of social security number) is a necessary step if you are going to live in the Netherlands: you will need it to get your health insurance, to open a bank account and your employer will need it before they can start paying your salary.

You will get a BSN by registering as a resident in Amsterdam and you are supposed to do so within the fist five days of arrival if you are planning on staying more than four months. If you are a Highly Skilled Migrant the process is extremely simple and you can take care of everything you need in one single day at the Expatcenter, provided that you asked for appointment here (applies only to EU citizens).

You will need to provide:

• your passport (an ID card may suffice, depending on your nationality)
• a rental/tenancy contract or a home purchase agreement

Note that, if you have not found permanent accommodation by the time you need to register you may still register at your employer’s address. Doing so, however, requires you company to provide a stamped registration form that explicitly authorizes you to do so. Note that this is considered by all means a contingency situation, and you will be required to register at your permanent address within three months. If you have a work contract already you can get a registration certificate (a sticker on your passport) as well: you will need it if you want to purchase an apartment or vote, for example. Note that to finalize registration you will have to present your birth (and marriage, if applicable) certificate in long form. You will not need this immediately as you can present it later, but if you have not left your country already, you can get one in advance.

Note that if you are not an EU citizen and/or not have a work contract yet the procedure may differ (even significantly), but luckily the IND (the Immigration and Naturalisation Service) has a wizard you can use to discover what you have to do to get a residence permit depending on your nationality and other conditions. The rules are quite complex but the wizard helps a lot: I suggest you to go through it.

Registering as a resident will kickstart a series of processes that usually end up in you having to pay some money: taxes on water and waste disposal are usually computed from the day you registered and bills will follow you a few days after you moved in.

Note that you may also want to register at you local embassy/consulate as a national living abroad. Specifics depend on your country, but the process is usually straightforward.

Highly Skilled Migrants and the 30% ruling

The Netherlands apply a particularly attractive policy to foreign workers that meet certain criteria: if you are recruited or transferred from abroad by a Dutch company and have a skill set that is rare or inexistant in the country you may be eligible to a tax reduction.

In practice, you can apply for the ruling if you earn more than a certain amount (at the time of writing it means € 50,000 if you are older than 30, € 38,000 otherwise) and your employer is willing to certify that you possess rare skills. Note that you can not present the application yourself: your employer has to do it.

If you present your application within 4 months of the start of employment the tax reduction is retroactive, otherwise it applies from the month after the one you filed your request. If your application is accepted, you will pay at most a bit more than 36% in taxes and will be eligible to a few benefits.  You can find more details on the ruling here.

Opening a bank account

Opening a bank account is quite easy: there are less banks here in the Netherlands than there are in other countries and the difference in offering is not significant. If you do not know Dutch yet, you will be interested in banks that are able to deal with expats. The challenge is not in the staff (again, anyone is able to speak good English here) but in the correspondence: you will want to receive communications in a language you understand. ABN Amro is quite good in that respect (even though you will still struggle to find some documents in English) and I know that Rabobank has a special expat desk, but I am sure that you may the same with other banks as well. Just ask what they offer to expats and do not assume anything.

Once you made your choice, you will need:

• your BSN,
• your passport,
• (usually) a copy of your contract or a letter of employment.

Note that if you don’t have a BSN but you still need to open a bank account, the ABN Amro branch at Schipol Airport may be able to open one for you if you commit to communicate them your BSN as soon as you obtain one. Unfortunately I did not know that at the time, otherwise things would have been much easier.

Getting your health insurance

Health insurance in the Netherlands is mandatory, even if you already have a one in your country of origin. You will need to get at least a basic insurance package (around € 100 per month) for your company of choice. The contents of a basic package are regulated by law, insurance companies are not allowed to charge different fees depending on demographics and are not allowed to refuse assistance, regardless of pre-existing conditions. Unlike what happens in other countries, you have to pay for your insurance but your employer may provide additional coverage as part of the compensation package. There are many different insurance companies in the Netherlands but, if you are going to get any additional coverage as part of your compensation, you will probably sign with the ones your employer has agreements with.

Moving around

Amsterdam is a small city, especially compared with Milan, where I used to live until a few months ago. Commute is shorter and there are many different options for moving around.

Public transport

Public transport in Amsterdam is excellent: the network of trams, buses and subway allows you to get to most destinations in a reasonable amount of time and with a limited number of changes. While the regular service stops a bit after midnight, night buses are still frequent enough to be a realistic option (for everything else, there are taxis). You can get public transport tickets at vending machines that you can find at in all the subway stations, but you can purchase them on board of trams and buses as well. If you do so, you are usually surprised by the costs: € 2.70 for a 1-hour ticket (you can use it as many times as you want) and € 7.50 for a day ticket.

It is indeed a lot, but there are ways to pay less. If you get an OV-chipkaart you will pay as you go: the amount will be charged will depend on the distance you travel (with an average of about € 1.50 for a trip across the city). You will have to check by tapping your card against an RFID reader once you board and check out once you get off.

The card itself costs € 7.50 and it can be topped up online, at vending machines at stations and supermarkets. You can get an anonymous card or a personal one which will have your name and photo on it. The advantage of the latter is that you will be able to use it for seasonal passes or have it top up itself automatically with credit from your bank account.

You can travel on trains across all the Netherlands using the same chipkaart you use for public transport in the city, you will only have to visit one of the NS vending machines (the yellow ones) and select your preference between 1st and 2nd class.

Biking

Bikes are a symbol for the Netherlands, and you will find Amsterdam to be perfectly designed for cyclists. Locals prefer biking to any other alternative, and you will find people driving their bike to work regardless of the weather. Once you will have spent more than a few days here you will be inclined to do the same: if you spend most of your time within the city, biking is faster than any alternative.

Get a sturdy bike, as it will need to withstand harsh weather conditions. Do not buy a fancy bike, as it will get more than a few scratches when placed on bike racks (even if you pay attention to avoid that, people placing their bike next to yours will not be as careful as you). Buy a good lock, even if it costs a lot compared to the value of the bike, especially if you leave your bike on the street at night: crime rate in Amsterdam is lower than in other cities, but bike theft is incredibly common.

Driving

Owning a car in Amsterdam is expensive: the road tax is quite high and parking is very limited (bear in mind that even if you have a permit to park in your neighborhood, you will likely need to pay if you drive to another). Given the way the canals affect the road plan, traversing the city by car is generally not the quickest option. Should you decide to bring your own car, you will have to follow a strict procedure: you can find more information here. Depending on the country you come from, you may also have to exchange your driving licence with a Dutch one or get a new one.

Useful resources

I summarized all the information in my possession but I have not covered some topics that may still be of interest to you. The links in this section should provide you with all the information you need.

• I amsterdam – by far the most complete and accurate source of information about what you need to know about moving to Amsterdam
• IND – the official website of the Immigration and Naturalisation Service
• Moving to Amsterdam – a useful section on Internations that contains some more useful information (access is restricted to members, unfortunately)

In addition to that, if you are already in the Netherlands or can plan a visit before moving, consider visiting the Expatcenter in person: they will be able to help you and give a clear picture about what you need to do in order to move here.

Acknowledgements

Most of the information in this article comes from personal research but, even more, by friends that have been through the experience of relocating to Amsterdam. Their precious advice helped me making my move here smooth and painless. Thank you Andrea, Angelo, Matias, Nicola.

Top photograph CC by MorBCN

A man walking through a desire path.
Photo: Jan-Dirk van der Burg

While architects and garden planners often regard those paths as unesthetic and try to prevent them by using fences and the well known keep off the grass signs, desire paths tell a lot about the needs of people traversing a space. Some urban planners even use those paths to guide them when revising the original design by adding new roads or altering the original project.

Desire paths are important because they give insights about points where the original design is lacking from a functional point of view. Sure, they may not be as pleasant to the eye as a perfect, regular lawn, but they often show a more effective way to solve a problem: getting from one point in physical space to another.

I am posting about landscape design here because the same phenomenon can occur when observing the way users interact with software products. Users often compensate for missing features by and taking shortcuts and by adopting workarounds which, eventually, leave a persistent mark on the system they are using.

Here a couple of examples.

The first is a historical example. In 2007, allegedly following a convention proposed by Chris Messina, a group of Twitter users started using the # symbol to specify tags associated to their tweets.

how do you feel about using # (pound) for groups. As in #barcamp [msg]?

—
Chris Messina™ (@chrismessina) August 23, 2007

The habit spread fast among the community, without any kind of central direction, and after a while Twitter integrated support for hashtags as we know them today. This is one of the most significant examples of desire paths at work: users figured out a smart way to use a system that was eventually promoted to a full-fledged feature.

The second example is way more recent, and you may have noticed it if you spent some time navigating the open issues of some popular open source project hosted on GitHub.

The more popular the project, the more easy it is to find issues with never-ending threads of comments like the like the one on the right side of this page (click here to see it in full scale). At a first glance, those issues seem to be extremely severe or controversial to cause such discussions, but the truth is quite different.

On a closer look, all those comments do not carry much meaning: they often are just a long list of comments consisting in (verbatim) “+1” (and occasionally some variations on the same theme). Those types of comments have become a standard way for users to communicate to the development team that some issue is important to them.

While the intention is understandable, this is often perceived by some a “bad” way to use comments on issues. Regardless of what opinions we may have on that point, it is certain that this behavior is another clear example of desire paths at work. Users want a quick way to let developers know they care for issues: comments were not designed for this purpose, but people figured out that they can be used for that too.

And then who knows, GitHub may end up adding a “like” button equivalent on their issues.

Paying attention to patterns like these in software can give us important insights about features that would benefit our users if we were to implement them. They are like validated user needs, highlighting an area in which our product may be lacking.

His main point, one I agree with, is the disconnect between phone numbers and the identity of the people behind them. He says:

I have friends that have three numbers in their signature. US, UK, local-european-country-no-one-knows. This whole system assumes I want to call their cellphones. Which is not true – I want to call them. The people behind that numbers, simcards and devices…

Andreas stresses the need for a means to reach people regardless of where they are, what phone operator they are using or other details that are insignificant from the point of view of the caller.

In the era of email and, now, social networks, phone numbers are a legacy of the old days. Especially since the introduction of personal mobile phones, they often constitute an unnecessary level of abstraction between us and the person we are trying to reach.
As Andreas points out, what modern phones would need is an identity system to abstract phone numbers out of the way, just like DNS does with IP addresses.

While this is a significant problem that needs solving, it would require some infrastructure to be in place, as you can see by looking at the scenarios explored in the post.

However, there is a smaller problem that can actually be addressed with resources that already are in place. And I am sure we all experienced it at least once.

Consider what happens when you get a phone call from a number you don’t know, and you are not able to answer it. Your phone will display an entry in its call log, and it will just list the number and the time of the call. You will likely not have enough information to decide whether or when to return the call.

Email is different, even just the format of an email address, the name@organization pair we are now used to, can be used to communicate something. Just seeing newsletter@somestore.com or orders@shop.com as a sender can give us an idea about what the message will be about.

Social networks are even better at this: whenever we get a message from someone, we see their name, their avatar picture and some profile information that may help in recognizing them if we already met them, or understand who they are in case we do not know them.

Compared to the previous scenarios, the impersonal string of numbers we see when we get a phone call from someone can be quite annoying, to the point that I know a significant number of people who are not at ease when they need to return a call and do not know who will be at the other end of the line.

Can we fix this?

Modern smartphones (iPhones and my Galaxy Nexus, for example) attempt to provide their users with a bit more information when they receive a call from a number that is not associated to any contact: they display the country or region of the caller under the phone number in the call log.

Ice Cream Sandwich displays the state of the caller when displaying unknown numbers in the call log

Seeing this behavior on my Android phone, I started to wonder whether that system could be generalized to provide an even better service.

In my case, the contacts on my phone are integrated with my GMail address book and Google+ circles: whenever I add a new friend, their name shows up among my phone contacts along with their phone number, if they chose to share it.

What I would love to have is a system where, whenever filling in their own Google+ profile, users could choose to allow the people they call to retrieve their profile given their phone number. Whenever the phone of the receiver is about to display their call entry in the log, the device could lookup the phone number on the Google+ directory and retrieve the user profile corresponding to that number. Verified1 owners of a phone number could choose whether they want to give the possibility to lookup their profile given their number to anyone or only to the people they tried to call recently.

I mentioned Android and Google+ because Google’s position in both mobile and social sectors gives them access to all the components needed to have such a system in place. Of course, a solution like this could be implemented virtually by anyone, but it would be a lot more complex to an outsider to build such a system, and the costs would probably exceed the benefits.

If a system like this were to be implemented by a significant number of parties and adopted by enough users, it would probably be another move towards a consistent and healthy approach towards proper identity management.

1. Verification of the phone numbers is important as it necessary to prevent scams and frauds.

One of the major pain points I mentioned was linked to the many duplicate issues we were seeing and listed one possible solution to reduce the number of duplicate issues that were being raised. After reading my post, my friend Mattia came to me saying “Good point, why don’t we just build it?“. Well, we did.

After a few weeks spent coding in our spare time, we released Did you mean?, a Redmine plugin designed to warn users before they enter duplicate issues. It does so by performing a search among existing issues right before users submit new ones. The search is based on the issue subject and it is done in the background, in an attempt to make the process as effortless as possible to users. If you are familiar with StackOverflow, you will recognize it as the same strategy.

A couple of months have passed since then, but Code52′s initiative Show and Tell made me look in retrospective at what we accomplished.

We discovered that the problems we were facing in managing issues were more common than we imagined. We had great fun in developing the Redmine plugin, but we were surprised when other users started voluntarily contributing with localizations in their language and tips about how to make it better: we just released version 1.1.0, which features English, Bulgarian, German, Spanish, Italian, and Chinese.
The experience made us even more enthusiast about Open Source: the saying that you should start by “scratching your own itch” is true indeed. If you build something that really solves your problem, chances are it will be useful to someone else as well.

You can find the plugin on GitHub, and if you want to help us, please do! We could use more localizations and some help in making the search work better.

Having grown frustrated by Eclipse being too slow on my 4 years old work laptop (I will not comment on this), I decided to drop the IDE for a while, switching to an extremely powerful editor that offered me the one thing that matters the most to me: blazing fast navigation between different source files.

Of course I knew I would miss some of Eclipse’s advanced features but I wanted to give it a try, especially since Andraz’s post left me with a bit of curiosity: how much the tools we use affect our abilities? And why IDEs are so used by desktop developers while they are not so popular with web frontend developers who generally use scripting languages?

A commonly accepted explanation is that it is easier to write IDEs for static languages, when lots of information is known at compile time. It is easier to extract information from the code and use it to build powerful and useful features.

However, after a few weeks of experimentation, I ended up with a slightly different point of view on the whole matter: the popularity of IDEs for Java encouraged coding conventions would not be so widely accepted if the majority of coders used a plain text editor to edit their source files. Those conventions grew so popular that that today Java appears to be designed to be used with an IDE. Let me give a few examples.

Autocompletion harms API consistency

If we want to know the length of a collection (as an abstract group of objects) in Java, the code we have to write will be quite different depending what object we are working on. It can be length if we are working on an array, length() if we are working on a String, size() if we are working on a Collection (from the Java Collections Framework).

Compared to Python, where the length is always retrieved by calling len(_), or to Ruby, where each enumerable type offers a length method, Java APIs often look disorganized and inconsistent.

The cost of inconsistent APIs is mitigated by auto-completion: a quick glance at IDE suggestions helps us pick the right method by skimming a list of method signatures and, occasionally, reading the inline documentation.

Coders who are not used to this kind of support put a lot of value in predictability and consistency: if some popular library has a specific interface that resembles what their new library is going to do, they stick to the same interface, without reinventing the wheel every time. This means that switching from a library to another is almost effortless, and it is kind of fun to think that Ruby’s mixins achieved what Java’s interfaces could not, but that is another story.

Following the same pattern, iterating over an array, a String and a List was done quite differently in Java, although this has been mitigated by the introduction of the for each construct in Java 5. And yet again, dynamic languages tend to be very consistent and I believe that is not due to duck typing itself, but also to lack of an Intellisense-like autocompletion for scripting languages pushes coders to rely on habits, implicit knowledge and API conventions they learned by working with other tools and libraries.

Packages and imports work great until we need to manage them

A widely accepted convention among Java coders is to use fully qualified imports in source files, because this improves readability and makes dependencies on other classes explicit. This means that, even though there are a few notable exceptions of packages for which a general (*) import is considered acceptable, such as

import java.util.*;
import java.io.*;

generally Java sources start with a long list of imports, with one line per each class outside the current package.

The rationale behind this convention totally makes sense, and it is effortless to coders as any decent IDE is able to do a great job in managing imports automatically. But guess what? Once you are using a text editor to work on your source files, all the burden of taking care of imports is on your shoulders.

Now, the choice to make Java packages correspond to the way classes are arranged on the filesystem is a strong one. Compared to C++ namespaces, Java packages tend to be more structured: a complex project is likely to contain several nested packages with several a few classes each. This means that, even if you contemplated the option of using the import * notation, you would still need to do some menial work to manage imports.

I would not say that packages are a bad idea, but being forced to manage them was probably one of the things that made me miss Eclipse the most.

Code generation increases verbosity

A lot has been written about Java being too verbose, and I tend to agree with that argument. The design of Java privileges readability and non-ambiguity over syntactical conciseness, making it fairly easy to learn and use. Overloading operators, for example, is not allowed as it was one of the most common source of surprises in C++.

However, verbosity is not just about syntax: many of the common conventions in Java require developers to write lots of boilerplate code with little informative content. Take the example of accessor methods: for each property we add to a Java bean we have to write the corresponding getter and setter methods. The task is so repetitive and meaningless most IDEs offer the possibility to generate automatically the code for accessor methods.

The same thing in Ruby is extremely simpler: the attr_accessor method addresses the same problem in an incredibly concise way. It uses metaprogramming (which itself is not achievable in Java) to accomplish its objective, but still it is an effective way to address the same issue.

The developer community influenced the evolution of the language before with (e.g. with the introduction of Generics), but the availability of code generation within IDEs has made Java developers much more tolerant towards verbose patterns. Would manually writing code for getters and setters be acceptable if we had no support from Eclipse? Personally, I do not think so.

Conclusion

Working with Sublime Text is great, it is incredibly fast and outperforms Eclipse in text manipulation. However, I unsurprisingly missed Eclipse when I had to debug, refactor existing code or inspect some complex call hierarchies in multiple projects, tasks for which an IDE is perfect.

What surprised me the most, however, was that I did not really miss Eclipse because of the benefits it gave me, but because it saved me a lot of nuisances that are caused by the way we write code in Java, by the conventions we chose ourselves. It is not by chance that Java does have plenty of IDEs and scripting languages do not; it is by design.