Yes, you read it right. I took the liberty to adapt Daft Punk’s song title to talk about code review. As I write this, I’m wondering if it is going to pass the thorough examination of the chief editor, but I like how the title sounds (and it really describes how a Pull Request should be). And you see, even this harmless piece of text is going over a rvesoin revision process before you can have the chance to be struck by my insights, so why shouldn’t we do the same with our code?
Continue Reading
As a software developer, I must deal with asynchronous programming on a daily basis. In order to provide the best user experience possible, all tasks like performing a server request, getting data from my database, waiting for some background process to finish or downloading an image should be executed asynchronously.
Even with some years of experience, I sometimes forget the syntax for a particular asynchronous call. How should I implement the callback for a specific task and how should I handle the error if anything goes wrong? There are hundred of ways of dealing with responses, and as a developer it’s my job to know which one fits best in every situation. When I first read about ReactiveX I thought: “Great, another asynchronous API to memorize…”. Well, I couldn’t be more wrong.
Continue Reading
By definition, user engagement is exactly what the name suggests. For a mobile app to work well, users should understand its main value proposition to then keep using it repeatedly until it becomes an essential part of their life.
According to eMarketer, nearly 200 billion apps will be downloaded in 2017. In contrast, currently about 25% of downloaded apps aren’t used more than once. Creating an engaging user experience is increasingly becoming essential as brands develop their mobile presence and hope to meet user expectations. Based on this data, how can we change the upcoming scenario for 2017? By tracking user engagement metrics and using these to create solutions to possible problems.
Continue Reading
When developing an interface, I used to be really attached to the visual part–perfect layout, distributed weight of objects, adequate alignments and counted pixels. I had been considered once an overly-meticulous designer, always checking thoroughly if the developer was implementing the project with a high fidelity to the delivered mockups. Until then, I thought this was enough to be a good professional–after all, Design should be all about visuals
This line of thought, established by previously working at companies where accepting crazy estimates was part of the job and the main goal was to please clients (the ones who were paying) made me forget what Design is really about: methodologies, tests and process. Following the latter vision makes you leave aside personal taste, opinions and assumptions to focus on metrics and the real client: the end user. Not always what we believe is the most pleasant look leads to the best results, and that starts to make sense when you have a logical explanation powered by metrics.
Continue Reading
As an NFL fan, MVP has different meanings for me on weekends and business days. Without diving into the curiosity, today I’ll talk about the latter, starting with some general analogies and moving further with specifics on the mobile & web app design and development lifecycle. So let’s get started.
Continue Reading
Onboarding new developers in a project is always nice: they bring new ideas, different expertises and outside-the box thoughts. They tend to tackle problems and create solutions in a creative way, adding even more enthusiasm to the team. But before getting down to code, they need to set up their own development environment, which can easily become a headache.
Installing a local database, compiling the right program language version and solving library dependencies – possibly across different operating systems – are a few tasks inside this challenge.
Today I’ll introduce to you Docker and Compose – a container platform and its simple configuration tool – to help your team get up and running as fast as possible. Continue Reading
Smartphones have been in the market for a while now. After some comings and goings of different players, Android and iOS were established as the main contenders and now represent almost 99% of the global market share. Because of that, virtually any new app idea will focus on these two platforms.
In this article I’ll be talking about the main differences and similarities that every designer should consider when designing UX and UI for iOS and Android. You can be starting from scratch or already have a published app that needs to be adapted for the other platform. For both cases, I’ll be constantly linking the platform guidelines, as they are the main source of reference when designing a new interface.
Continue Reading
Hybrid technologies have been employed for quite a while in mobile application development. Frameworks such as PhoneGap and Ionic come with an appealing motto: Develop once, run everywhere. And they actually do what they promise: you write a web-based app once and release it everywhere, from iOS to Android and the Gates of Mordor, as long as it gives support.
I do believe that they play an important role in the mobile app development scene: the huge community of web developers can write mobile app code and are able to deploy fast. But, in my opinion, the idea of developing one shared application for all platforms is dead per se.
That’s where React Native lands. It has a slightly different motto: Learn once, write everywhere. It might seem the same but with a closer look, you’ll spot the difference: it’s still JavaScript code, but with a dedicated one for each platform. And that changes everything. Each platform has its peculiarities and user expectations vary from one to another.
Continue Reading
As an iOS developer working at a startup focused in collaborative development, I’ve been involved in several projects so far, and most of them share common tasks such as downloading and caching images, performing network requests, and building Auto Layout views.
At first, I had a flow that I thought was good enough to accomplish these basic tasks (or any other, for that matter):
- Try to implement using the iOS SDK
- Get stuck at a problem that doesn’t have a straightforward solution
- Look up the solution on StackOverflow and implement it
- Move on to the next task
That seemed like a good flow at first, but got a bit tiresome in the long run – after all, nobody likes to hack for a living.
Continue Reading
Bernardo SmaniottoPosted on 
