One of the things I was not expecting when I moved to Amsterdam was its active and vibrant tech community. Appsterdam, a non-profit organization focused around aggregating people with a passion for technology, is probably one of the central forces in this movement.
In my year in Amsterdam I had been to a few meetups organized by people from Appsterdam and always came back home having learned something new. This is why when my colleague Matt (who himself is quite an active Appsterdam member) talked me into presenting a guru session on Google App Engine, I saw that as an opportunity to return the favor.
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.
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.
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.
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 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.
As I already had the chance to write in a previous post, I really appreciate distributed version control systems; I consistently use them at work and for many of my side projects. I typically switch between git and mercurial repositories, with the former being my primary choice lately, and there is one specific command that always troubles me when I do that: pull.
There is one wonderful piece of inconsistency between the two systems, one that often leads to confusion for new adopters and unnecessary hassle for experienced users. If you are familiar with both systems, you may already be thinking about the culprits. If you are not, you may be more careful about the pull and fetch commands after reading this post. Continue reading Design horror: same command, different meanings
Last Friday, a blog post on Channel 9 announced Achievements for Visual Studio, an extension for the Microsoft IDE that tracks the actions of programmers as they write code and unlocks badges based on their behaviour.
Now that the concept of gamification has become (even too much) mainstream, it is not surprising that this is not the first time an idea like this is proposed. Jason Rudolph has published an excellent blog post about programming achievements. Websites like coderwall already inspect source code repositories on GitHub and others in order to build achievement-based profiles for coders. There even is an earlier project, called Strokes, that added achievements and challenges to Visual Studio.
Introducing mainstream achievement support right within the IDEs, however, can have a stronger effect on the way we write software, as those tools can inspect code right while we are writing it. The strong link between action and reward lead to a stronger feeling of accomplishment when we earn those achievements, and programmers are likely to be receptive towards game mechanics (most of us have a background as gamers). But there is more than that. Continue reading How achievements can improve software quality
While issue trackers originate as tools to manage projects more effectively, during the last years of work I have been through some situations where their misuse backfired.
Tools originally conceived to improve workflows and project lifecycle became a significant burden for the team using them, occasionally making difficult situations even worse.
This post is a collection of bad patterns I have seen happening. It is not a survey of all the possible situations that can occur. It is not meant to be an argument against issue trackers (if it tells anything, it will probably be about the teams I was part of), but rather an overview of things that went wrong because of the way a particular team used those systems.
In retrospective, most of the problems were due to a lack of discipline and experience of the project teams, and they are less frequent – if present – in a team of seasoned professionals. But, while training and education can certainly help, I would love to consider a different aspect: the issue tracking systems were not helping as they could have.
Here is a summary of the most common and annoying problems I encountered
I didn’t want to go through the hassle of setting up Apache on my Mac, though, and I was looking for some quick alternative to installing a local web server. After some Googling, I found a wonderful one liner that did the job, provided that you have Python installed.
Open a Terminal window and go to the directory containing the files you want to serve and run:
python -m SimpleHTTPServer
or, if you are using Python 3,
python -m http.server
you will then be able to access your files on http://localhost:8000/. (You can specify a different port number by passing the number as last argument, just remember that you need root permissions to open sockets on ports lower than 1024.)