A few weeks ago I attended The Next Web Conference in Amsterdam and join a bunch of fellow programmers for another edition of the Kings of Code Hack Battle, the same kind of event as the one where Bring Your Own Music was born.
Following the usual schedule, after a brief presentation from the API partners (Spotify, SendGrid, Braintree, Deezer, Pearson, Nokia, Rebtel, Bol.com, Smart TV Alliance and LinkedIn), all the attendees started evaluating ideas about what to build.
I teamed up with Alexander, a friend of mine I already had the chance to work with back in the days when I when I was consulting.
Having LinkedIn among the sponsors seemed to encourage us to build serious applications for serious professionals, but after discarding a few alternatives that would have been better projects for a Startup Weekend than a hackathon, we decided to take the opposite direction: building the silliest possible thing with the APIs we had access to.
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.
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 will be structured as a step-by-step tutorial addressing user registration, login, password reset and a few other details.
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.
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 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. Continue reading →
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!
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.
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.
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.
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.