Senior iOS Software Engineer @ Twitter
I love to discover iOS in depth
and do the right thing,
no the fastest one.
I’m a really passionate Software Engineer working on iOS since 2008.
Currently @ Twitter, previously in London @ Trainline and @ busuu.
I spend part of my free time writing articles and contributing to the open source community on Github and Stackoverflow.
I have a Bachelor Degree in Computer Science and a Master Degree in Computer Engineering.
Making cocktails and dubbing, are the others my two passions.
Making experiments on a product is one of the most powerful technique for a company to get the best response from its customers. But sometimes, especially when they are more than 2 or 3 at the same time, it may become a bit frustrating for developers who find pieces of experiment blocks around the whole project.
In this article I’ll explain an easy architectural approach to keep our code clean and dynamic.
A team is like a machine. We can imagine it as a car, travelling along a straight road. Like a car, its engine needs to be designed and built to be bug-free. Its speed is the energy of any team member. The fuel is the passion.
In this article I’ll explore some good approach to making sure a team works effectively and with the right attitude. The methods that I’ll discuss could probably be applicable to any kind of team, however, in this post, I will be making specific reference to life in a tech team.
Read on →
Any tech company which has a team of developers working on a project, needs to have a repository and to use a revision control system, as for instance Git.
Unfortunately, even though the choice of platforms/tools seems to be pretty standard for most development teams, many companies and particularly many teams, still don’t use a strong Branching Model and a powerful Continuos Integration configuration.
This article wants just to show how we sorted these important things in busuu, giving an idea of what we think is nicely organized.
UITableViews are part of our projects since the very beginning of the iOS SDK. But even if they are kind of our “old friends”, many of us still don’t use them properly. No, wait. I know you use them to “show cells”, of course. For “properly” I mean: in a well architected way.
Probably you have been in the situation to being writing a category and at some point exclaim “F**K! It’s a category!”. Yes, and probably was because you accidentally tried to override a method without remembering that effectively, you were writing in a category.
In the largest percentage of situations, when you need to override a method, you want to write a subclass; when instead you want to write a category for a class, it is because you probably need to have some new methods or properties that you’d like to be used from every subclass.
There is only another situation which could confuse you, and this is when you are in both the previous cases, together.
Read on →
As a developer I often find myself in the situation where I have to face the problem to store and get some kind of information in the most possible handy way.
In particular, this happens when you design a static menu list (e.g side panel or harburger menu) using a UITableView.
In this article I will go to explain how to implement it using the concept of Interaction Object in order to keep our code clean and testable.
Read on →
Since this is an argument less touched but much important, I decided to write an article to organize the informations and explain how autorelease, or better autorelease pool works.
The main goal of this article is not to explain the base of what is an autorelease pool and when autorelease should be used, but anyway, this is really important to understand these concepts before proceeding. For this reason, the first paragraph will be dedicated to explain them. Experts developers, can safely skip it if they want.