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.
A common way to describe a product development process is with the Design – Front-end – Back-end stack. This approach takes into account the disciplines involved on the process, and though it helps making things understandable, the distinction enforces the idea that the process is linear and phase-dependent.
This linear flow can also be defined as the waterfall model, and it’s rather common in the web industry. All pages are designed upfront, then a set of mockups are handed off to be translated into front-end code, and then, after all of that, the back-end logic is created. This causes an isolation of professionals on each phase, which leads to a series of implementation issues, mostly due to the difficulty of foreseeing all details and use cases on the early stages.
It also leads to the notion that there’s “my work” and “your work”. It’s not rare to hear developers saying: “Designers can’t touch my code!” or designers complaining that “The front-end developer messed up my layout!”. This creates barriers to the process. As obvious as it might sound, everyone is working towards the same goal: building outstanding products. And a more collaborative process is the way to achieve that.
Android is an awesome platform that enables you to impact millions of users, but, even after so many years in the market, there are still several basic problems that are still a pain to solve and haven’t been included in Android’s core Software Development Kit.
In order to solve these key problems, I’ll point some great tools and libraries – developed by the Android community – that are widely used and a breeze to work with. They are all open source, available on GitHub and actively maintained. Now, let’s start!
In the past few years, websites have evolved into complex web applications, and what once was land of simple business informative pages, now is home to Facebook, Slack, Spotify and Netflix, changing the way you communicate, listen to music or watch movies. Front-end development has reached a new level and now requires more attention than it used to.
However, when an application grows considerably, a couple of issues start being more frequent than expected: you forget to update all places where a value is displayed in the UI, no events are bound to the content added by AJAX, just to name some — this list can be very long. These are signs that your code is not maintainable, especially when developing together with a team. Using a front-end framework provides a formal way to write collaborative code that you can read, write and update.
When developing an iOS app, it’s important to think about what iOS project architecture you should use. Most developers use the pattern suggested by Apple: the so-called MVC (Model-View-Controller) architecture. However, as well-established as it is, the MVC has its flaws. For one, because of its simplicity, it leads even the most experienced engineers to put any code that doesn’t belong to a View nor to a Model in the Controller’s logic – generating huge chunks of code in the controller and really compact views and models.
In this post, we’ll present VIPER, one of the trending alternatives to MVC that might help you overcome its limitations while keeping your code modular and well-organized, improving your development process.
Internet of Things (IoT) is no longer something reserved for the future or limited to the realm of ideas. It is real and it’s begun to find its way into our homes turning lamps, locks, security cameras, and several other home appliances into smart devices controlled by your smartphone.
The crucial point, as a developer, is to know how to find and access these devices, allowing people to use this technology to its best extent. To help you in this process, this article lists some of the most popular approaches to finding and connecting to any device in your network when developing IoT apps, and presents some code snippets and examples to get you up and running in no time.