JS’s objects are so beautiful: we can copy them, change and remove properties and do many cool things.
If you are not considering the user experience when designing a new mobile application, it’s time to start thinking about it. One of the most important things to have in mind when you design a mobile app is making sure that it is useful and intuitive for the users. If it’s not useful, it won’t have a practical value. At the same time, if the application is useful, but it takes too much time and effort to be used, people won’t engage with it.
Defining the personas that represent the audience of a product is a very important step of the design process. There are many methods out there to help us figure them out. But the question is: do we empathize with them the way we should?
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.
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.
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.