I am a Software Engineer with 12+ years of experience. I currently work on Travel features at Google where I lead a team of engineers working on a brand new product. Previously, I worked for an Information Technology consulting firm on projects in Italy, Spain and the UK.
Prior to working, I spent some time at the Artificial Intelligence laboratory of the University of Milano–Bicocca and published articles on Genetic Algorithms, Neural Networks, Cellular Automata and Natural Language Processing.
If you would like to get in touch, the best way to do so is to email me .
I spent some time during the last weeks playing with the Open Data published by the City of Milan. I did not have a clear goal in mind, …
A few weeks ago I attended The Next Web Conference in Amsterdam and joined a bunch of fellow programmers for another edition of the …
I visited the Van Gogh museum in Amsterdam recently and, to my surprise, I left the exposition having learned something that matters …
A selection of popular articles
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 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.
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 would love to build on top of each negative experience, with a constructive attitude, by exploring how a better designed system could induce a better behavior.
As Software Engineers, we often tend to be overly optimistic about software. In particular, it often happens that we underestimate the probability of systems and components failures and the impact this kind of events can have on our applications.
We usually tend to dismiss failure events as random, unlikely and sporadic. And, often, we are proven wrong.
Systems do fail indeed. Moreover, when something goes wrong, either it’s barely noticeable, or it leads to extreme consequences. Take the example of the recent AWS outage: everything was caused by a mistake during a routine network change.
Right now, some days after the event, post-mortem analyses and survival stories count in the dozens. There is one recurring lesson that can be learned from what happened.
Things I built on my spare time
I love building software so much that I spent some of my spare time writing code, from algorithms and data structures to small products and web applications. Below some examples.*
More on LinkedIn
Part of the Google Travel team, led several successful user-facing features from inception to launch and contributed to many more. Notable examples:
Currently managing a team of engineers working on a brand new product in Travel.
Technical lead responsible for the design and development of several enterprise applications based on a diverse set of technologies, ranging from pure backend to full stack.
Routinely worked with clients across several industries (finance, retail, media and others) both during the sales process and later on as analyst and advisor.