One of the questions I get more frequently when I say that I am a Data Engineer is “but what do you do?”. Depending on who you ask, you can receive a variety of answers, especially related to the tools and skills we may use. If you ask me that question and you know about data processes, I will answer “we’re the backend of the Data Scientists”. If you don’t have a clue about data-related jobs, I will answer “we organize big amounts of data”. And by “organize”, what I mean is “clean, model, calculate, store and make available”.
In Everli, I’m in charge of data related to our shoppers, from the moment they apply to one of our job offers until they deliver an order to a customer. This process involves more factors than you may think because we need to have the right amount of shoppers recruited and the right amount of shoppers working exactly when they are needed. The main goal is to balance a good service to our customers and the wellbeing of our shoppers.
This balance has been a challenge since the beginning, and this example is only one more step in finding the best fit for our needs. It has also been a data modeling challenge, and a great opportunity to dig deeper into shopper data. And now I can explain one of the things a Data Engineer does!
Here we go again. This is the second episode of our docuseries about how we are managing retailers’ data for our beloved customers. If you did not read our previous post about this topic, you should spend a few minutes catching up on it. With this part, we would like to introduce the hidden aspect of our product and I promise, it is not a buzzword: Machine Learning. In the following paragraphs, we are going to show new technical improvements and the analytics aspects under the hood.
Reading Time: 5minutesTL;DR: We developed Uppy, an on-premises way to distribute Android and iOS apps via the open web. The SDK for iOS is here and the one for Android is here, whilst the backend will be published later because it needs a bit more polishing! 😜
I’m so excited to unveil this project publicly that I’d like to go straight to features, but first, let me introduce some of the backstories!
Why we built Uppy
As you may already know, internally we are developing two apps: one for customers and one for shoppers and while the first one is publicly available on major stores, the other one has very specific needs that can’t be achieved on those platforms.
Specifically, we value the shopper app as a Working tool with a capitalized “W”, meaning that the app should be not only as efficient as possible but updates must be on-point and align with regulations and new features in a timely fashion.
Reading Time: 4minutes
DISCLAIMER: this article is the transcription of an internal talk.
You can find the presentation here.
In Everli we have recurring internal moments that we use for sharing knowledge.
We are going to integrate the key points of the book we’re reviewing as we move forward and then we’ll share our learnings and outcomes.
Today I’d like to talk about one of the most interesting and educational books that I’ve recently read.
Hold onto your seats; I am going to guide you around our brief history of the price updating process. Prices must be updated every day, following our Retailers procedures to provide the best experience to our customers. If you think it should be a simple procedure, consisting of just updating the right record and go on with the next one, I totally agree with you!
When we were in the start-up phase back in the days it was that simple, but soon we had to forget about doing it this easily when we had to scale it up from a few thousand updates to millions. In the next paragraphs, I will show you the evolutions of this process during the years.
Covid-19 changed and is changing everything. From customer behaviour to customer spend, no one could have expected this. Our servers neither. This post would like to be a simple overview of what we did to maintain our website and apps reliable during this time. And yes, you have read properly, how we kept the infrastructure responsive while serving more than 4000% new users (and of course the previous one) plus a few DoS attacks.
I’ve thought a lot about writing on remote work in Supermercato24.
I know that this topic has already been extensively discussed, examined and studied; I honestly think that it should not be considered and described every time as the new thing, but unfortunately it seems that there are a lot of concerns and fears (some of them are actually reasonable) around it that sometimes prevent it to be supported and implemented.
Supermercato24 is an Italian scale-up born in late 2014, we have just overcome the 100 employees threshold and our technical team (25 people at the time of writing) is fully remote; if we’re specifically considering the Italian startup ecosystem, I can say that we were among the first to believe in this work philosophy.
Behind the word remote there are many related aspects and the theme is certainly wide and complex; hence we’re going to split it into a series of blog posts, making it easier to dive deep into its different faces.
In these series of posts (don’t worry, they’ll be only 3), I would like to dig a bit deeper on the experience of using Room for Android and how it compares to other existing technologies. Please, note that I won’t explain how everything works and how to wire together all the components – there are plenty of tutorials for that – but I will focus on some aspects of the library and on how it feels to use it every day. Moreover, we will try to give a few insights on why you might want or not to use it.
I think it’s best to hear first the bad news and then the good ones, so I’d like to start these series highlighting a few parts of Room which we didn’t find great. Let’s start!
Only two things are infinite, the universe and the number of design patterns used for Android development.
He’s still got it.
But seriously, architecting an Android app has always been a mess. There was no “official” standpoint about that and everyone was doing what they felt was good. And that’s good, because there is nothing like an absolute truth and every app and every developer is born different, but without a common and solid starting point, this quickly escalated to a jungle, making it really hard for new developers to find their way. Continue reading “Our View on Android Architecture – Part 1”