Think of a professional who has changed the history of IT for a second. If the person who came to your mind was Steve Jobs, Bill Gates or any other male name, it’s no wonder. Although the history of computing is marked by contributions from great women, such as Ada Lovelace, Grace Hopper, Sister Mary Kenneth Keller and Hedy Lamarr, women are still seen as if they played a secondary role in this market.
JS’s objects are so beautiful: we can copy them, change and remove properties and do many cool things.
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.