When I’ve started writing this article, it was already outdated; as a matter of fact, during these days the 2nd Edition of the Firebreaks is happening.
Firebreaks were one brand new initiative that we tried for the first time three months ago; you may have already read something about it, but we never had the chance to properly describe what is it, why we decided to do that and how it works.
First of all – as you might guess – we didn’t invent this ceremony; on the contrary, it is something that we copied and adapted to our organization.
In short, Firebreaks are a huge, challenging and inspiring initiative, with all the Engineering, Product, Design and Analytics teams involved.
Now that I hope I’ve got your curiosity, we can dive deep into it!
EverliiOS apps get new amazing features every week, constantly growing bigger and more complex, this makes Xcode build times grow proportionally.
Of course, one solution might be to regularly update your hardware, but here we’re going to talk about a free software alternative to that. In the Everli iOS team, we decided to give PodBuilder a spin, and we did right.
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, as you could see from the previous post. We are going to integrate the key points of the book we are reviewing as we move forward and then we are going to share our learnings and outcomes.
Recently, the R&D Team at Everli embraced a super challenging initiative that we call Firebreaks! 🔥🔥🔥🚒
This served as a natural breakpoint as teams wind down their old missions and prepare to start their new ones. It’s an excellent opportunity to pursue other work that’s of interest to them and of value to the organization.
Our colleagues ventured into several workshops and tested themselves in a five days sprint!
In our work in Everli, one of the most important aspects is to provide reliable product info about products in stores. Product info is a bunch of different aspects of an item, like name, weight, price, and so on. All of them are stored in our Catalog and, for each of them, we use a specific logic in order to have the best info possible. Today we are going to focus on a very complex aspect: the seasonality.
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.