What are we talking about?

In the first of this series of blog posts about Data-Warehousing, I’ve been talking about how we use and manage our Amazon Redshift cluster at Drivy.

Drivy has been using Airflow to orchestrate tasks for 2 years now. We thought it was the best tool on the market when we wanted to start digging into data. The purpose was to understand how well our features were performing. We didn’t really know how the data was going to be used, and by whom. We wa...

We’ve recently extracted the checker_jobs gem from our codebase. It’s a simple alerting tool with a very specific purpose which this article will explain.

A few months ago we faced a memory issue on some of our background jobs. Heroku was killing our dyno because it was exceeding its allowed memory. Thanks to our instrumentation of Sidekiq, it was easy to spot the culprit. The job was doing a fairly complex SQL request, and outputing the query’s resul...

As your application gets larger and larger, the surface area for security issues expands accordingly, and security bugs become more and more problematic.

Parent Navigation has always been a tough topic on Android. There are not a lot of apps that implement the guidelines correctly, maybe because they are hard to understand or complicated to implement. Even the Google apps don’t implement them: it’s always frustrating to take a screenshot, press Up on...

If a user signs up to Drivy, we want to welcome them. If a driver has an upcoming booked trip, we would like to send them the needed information. If they want to reset their password, they need to receive a confirmation email and so on.

At Drivy, we use a lot of background jobs, called from service objects, API calls, cron, etc. A time came when we needed to add some context data across several of these code layers.

Rails 5.2 was released a few weeks ago and comes with awesome features like the new credentials vault, HTTP/2 early hints, Redis cache store and ActiveStorage, which I’m going to focus on in this blog post. The project was initiated by DHH in mid-2017 and has been merged into Rails core. It’s a buil...

Android Makers is the largest Android event in France, organized by the PAUYG and BeMyApp. This year the event was held in Le Beffroi de Montrouge - what a great place to enjoy a conference. There was much more space than the previous Android Makers event: we were really comfortable, with all we nee...

Drivy is growing, and the impact of this is particularly reflected in the evolution of our visual identity, conveyed by Drivy’s UI.

Trying out new technologies, exploring new ideas, investigating potential solutions: these are all fundamental parts of the problem-solving element of a developer’s work. As with any form of creative work, it’s important to keep motivated and one step ahead of ever-changing technological advancement...

At Drivy we have massively been using Redshift as our data warehouse since mid-2015, we store in it all our transformations and aggregations of our production database and 3rd-party data (spreadsheets, csv, APIs and so on). In this first blog post, we will discuss how we adapted our Redshift configu...

After recently upgrading to Rails 5.1, we noticed that certain model changes were no longer getting logged properly by PaperTrail. After a bit of digging, this turned out to be due to a subtle difference in the way that Rails now tracks changes.

At Drivy, we have an internal API to communicate with our native apps available on both iOS and Android. One of the main pain point we experienced is documentation.

Every 2 weeks we hold Tech Talks here at Drivy. These are an opportunity for our now 17-strong team of developers to gather for 1 hour in a non-squad setting. The Tech Talks are emphatically not about tackling issues or solving problems, but are instead an opportunity to explore new ideas, ask quest...

dotCSS is the largest CSS conference in Europe. The 2017 edition occurred late November in Paris and it was a great opportunity to exchange and learn from the community. As you can play back the talks on the dotConferences website, this post won’t dive into the details of all the conferences, this i...

At Drivy, we heavily use Embulk for our data needs. Embulk is an open-source data loader that helps data transfer between various databases, storages, file formats, and cloud services. It can automatically guess file formats, distribute execution to deal with big datasets, offers transactions, can r...

Recently, we had to send an e-mail to all our active users. For cost reasons, we decided to invest a bit of tech time and to go with transactional e-mails instead of using an e-mail marketing platform.

For a few weeks, Drivy has been available in the United-Kingdom. Unlike the others European countries where Drivy operates, the United-Kingdom uses a different currency: the pound (£). We had to make some changes in our Android apps to support this.

At Drivy, we store, process and analyse hundreds of gigabytes of data in our production systems and our data warehouse. Data is of utmost importance to us because it makes our marketplace run and we use it to continuously improve our service.

At Drivy, we use the Virtus gem to build form objects in our codebase. This lets us:

We’ve always valued releasing quickly, as unreleased code is basically inventory. It slowly gathers dust and becomes outdated or costs time to be kept updated. Almost 3 years ago we published an article “Drivy, version 500!” on our main blog, so I feel now is the time to get more into the details of...

We’ve recently introduced Preact to our Rails stack at Drivy, and the results have been rather satisfying so far. As a Vim lover, I was curious to see how to go about setting up Vim React or React-like project. As usual, the wealth of plugins out there didn’t disappoint.

When we write code, who is it for? Is it for the machine? It is the machine that will parse and run your code. Is it for the next developer? It is that person that will spend time reading and updating the code. Is it for the business? After all, the code wouldn’t exist if it had no purpose. Obviousl...

The command pattern is sometimes called a service object, an operation, an action, and probably more names that I’m not aware of. Whatever the name we gave it, the purpose of such a pattern is rather simple: take a business action and put it behind an object with a simple interface.

As developers, we sometimes find ourselves faced with feature requests that will take weeks of work and touch many areas of the codebase. This comes with increased risk in terms of how we spend our time and whether things break when we come to release.

Whether it’s on social media, on the app stores, through emails or phone calls, we receive hundreds of messages from our users every day, and answer each of them.