As a software developer, I know how hard it is to contain the urge to start coding as soon as we can. After the first sprint planning, our fingers – uncontrolled, hungry creatures – want to start smashing the keyboard, translating our ideas into code fastly and furiously.
Despite how great we feel while developing, it’s always a good idea to take a step back, especially when building something that could be used by many different users – like an API is. A. In this post, I’ll show you why and how to design a properly-thought API.
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?
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.
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.
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.
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
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.
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.
Let’s face it: developing scalable front-end code isn’t piece of cake. No matter how well-structured the framework/architecture you’re using is, everything will be converted to ye olde HTML, CSS and (vanilla) JS.
Well, the good news is the open-source community already created solid frameworks (like AngularJS and ReactJS) to make your life incredibly easier, so you can work on high-level code and nevermind the hardcore stuff.
This brings up a new scenario, though – after getting used to building things the old-fashioned way (or not-so-old-fashioned, with tools like Backbone.js or Ember.js), you’ve decided to try what is trending on front-end development now: ReactJS, using the Redux architecture. You got excited with the possibilities this opens (and – oh my! – the ability to ditch jQuery once and for all), and, after working for a few weeks you realize that your code is a total mess.