Blog

Google App Engine for Python ships with the capability to manage user accounts without the need of any additional library. This functionality is, however, insufficiently documented. This post is a step-by-step tutorial addressing user registration, login, password reset and a few other details.

In the age of touch devices, some days it seems like a day will come when we will not have to use a keyboard to interact with computers. A significant part of our relationship with technology passes through interfaces that were not common a decade ago: touch screens, accelerometers, cameras and microphones.

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 ⌘-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.

This post is a summary of the weekend we spent at the Kings of Code 2012 Hack Battle in Amsterdam. What started as an occasion to get to know smart people doing cool things in Amsterdam (something I look for since I moved here) turned out to be one of the funniest experiences I had in a while.

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 card reader

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.

A practical guide covering everything I had to figure out when I relovated to the Netherlands, covering topics such as the 30% ruling for Highly Skilled Migrants, finding where to live, registering as a resident, getting your accounts and getting around.

Desire paths are a common pattern in landscape design: born as simple footpaths when someone takes a more direct, shorter way to their destination, they often evolve to proper paths and roads after a while.

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.

For many people like me, the phone system is broken. And it is not all about costs or devices: as Andreas Klinger once said, telephone numbers are a disgrace to our generation.

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.

A while ago I wrote about a few problems we were having with the way our issue tracker was misused and concluded that the tools we use have a crucial role in directing our behavior towards good or bad behavior patterns.

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.

I spend most of my days at work on powerful IDEs like Eclipse or Netbeans, tools so advanced in functionalities that their feature lists span over several pages. Their power, however, has its own drawbacks: their memory consumption is measured in the gigabytes, and running them on underpowered computers is the most frustrating of experiences. Issues that any Java developer on Earth will have to face, sooner or later.

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.

Summary: accepting objections is one of the most valuable skills a manager can learn, and yet the role models we get fail to highlight this

As many other geeks, I have always been fascinated by aviation and its history. One of the things that kept intriguing me was a simple question: what could cause the dramatic decline in the number of plane crashes attributable to pilot error?

I recently found an answer to that question in a How We Decide by Jonah Lehrer, crediting two different factors for the increased safety.

Looking for a job in the tech sector is a challenge. A lot has been written about the process itself and its quirks, ranging from programming puzzles to whiteboard interviews. However, there are still a few details that are often overlooked by most companies and can make a significant difference for perspective applicants.

Even when recruiters try to do all they can to make the application and hiring process as easy as possible, it is extremely common that the jobs or careers sections of their websites do not contain all the information applicants would need to make an informed choice. And when the information is present, it is often arranged in a way that is not effective or clear enough.

This article contains a selection of the most frequently neglected details; information that is valuable for applicants but, for a combination of good and bad reasons, is often hidden or not present at all.

If your company is hiring, try to figure out how easily a candidate can find an answer to these questions by looking at your website:

If the answer to any of these questions does not come immediately, the careers section of your website may be cleverly designed and communicate a great image of your company, but it is probably disconnected from the needs of its users: the people you are trying to hire.