It was over two years ago when I joined Everli. Besides usual duties, I was given the tremendous opportunity to migrate the frontend of a complex e-commerce system from Angular to Vue. It’s this type of a challenge you wait most of your life as a developer to be able to use all of your past experience and build something new and as close to “perfection” as it can be.
The most crucial requirement, at that time, was to avoid big rollouts and make every release as much valuable and smooth as possible. Back then, It sounded pretty complex, but it was vital for the company, which was about to double the number of users in the next months. We were growing fast, and new markets were about to be conquered. With my buddy Nicola, we decided to take the small steps and take the pressure off our shoulders by replacing Angular with Vue bit by bit.
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!
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.
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.