At Drivy, we’ve been using Capybara and PhantomJS to run our feature specs for years. Even with its issues, PhantomJS is a great way to interact with a browser without starting a graphical interface. Recently, Chrome added support for a headless flag so it could be started without any GUI. Following...

I recently saw another article highlighting the many ways in which recruitment in software development is broken. Whiteboard coding, random trivia, poorly trained interviewers… it’s all very painful and it seems to be the situation in a lot of places.

State machines are a very powerful tool but are often underused in web development. The design process forces you to think hard about how you want to model your data, about the different objects lifecycles, about the way you want to expose your data and communicate with your whole team, and about th...

Android Makers is the biggest Android event in France, it occurred last month in Paris. It’s always a great time to connect and learn from the Android community. For this first edition, a lot of great speakers from all around the world were in Paris. This post is not intended to dive into the detail...

Hey, I’m Jean, a Junior Full Stack Developer at Drivy. I joined the company after graduating from a two-month full stack program at Le Wagon. Except from being passionate about tech at large, I didn’t know anything about web development last year but from now on I am coding full time and I love it! ...

Understanding the application’s state at a given point in time is valuable. You and your team must make efforts to keep the cognitive load required to reason about its state as low as possible.

This is an introduction to a serie of articles about code simplicity. The concept itself is a bit abstract but don’t worry: I aim to provide some good examples and explainations for you to get something out of it!

At Drivy, we make extensive use of pull requests to ensure that our code is up to our standards and to catch possible issues.

As Drivy continues to grow, we were interested in having more insights on the performance of our jobs, their success rate and the congestion of our queues. This would help us:

At Drivy, the product is often changing. To be as reactive as possible, we want to be fast and iterate a lot of features. For mobile teams, it’s a challenge to keep up the pace for our iOS and Android apps. You have to deal with the release cycle of the App Store for iOS, and with the users who don’...

At Drivy, our main repository is a Ruby on Rails application that we run on Heroku. Sometimes, things don’t go as planned and we need to run one-off commands to fix a particular piece of data or to investigate a bit further about an issue. To do this, we use the rails console command in the producti...

When you need to share a file with other apps, the easiest way could be to use the external storage as a temporary place where to save this file. For example, if you need to take a picture with a camera app, you need to specify a file where the camera app will save the picture, and using external st...

Taskqueues are used to asynchronously run tasks (indistinctly called “jobs”). They are very useful to enqueue actions for later processing in order to preserve short response times. For example, during the signup you may want to send the confirmation mail asynchronously. Or you may have a slow task ...

It is very important to have a minimal number of bugs in production. I would love to say that we have absolutely no issues, but problems are bound to happen and it’s really a matter of reducing risk. The question is really about how fast and how efficiently can you react.