# Uber Updates Question



## Maven (Feb 9, 2017)

Uber often performs updates to the driver-App, the rider-App, or both several times a week. Does anybody know where or how we can find out what changes ave been made as part of a particular update? Perhaps an engineering web page that gives release notes for the various updates.


----------



## Retired Senior (Sep 12, 2016)

That would be good to know. I have been having issues with APP all week. Not being all that tech savvy, some of it may be more related to my phone rather than the app.... but I'm like a bat without sonar... essentially operating in the dark.


----------



## Maven (Feb 9, 2017)

Retired Senior said:


> That would be good to know. I have been having issues with APP all week. Not being all that tech savvy, some of it may be more related to my phone rather than the app.... but I'm like a bat without sonar... essentially operating in the dark.


Not release notes that I would prefer, but a peek into the Uber Engineering Blog. including:

*ENGINEERING THE ARCHITECTURE BEHIND UBER'S NEW RIDER APP*
DECEMBER 20, 2016 BY VIVIAN TRAN & YIXIN ZHU

*Why Uber Started Over*
Uber is based on a simple concept: push a button, get a ride. What started as a way to request premium black cars now offers a range of products, coordinating millions of rides per day across hundreds of cities. We needed to redefine our mobile architecture to reflect and support that reality for 2017 and the future beyond.

But where to begin? Well, we went back to where we started in 2009: with nothing. We decided to completely rewrite and redesign our rider app. Not being held back by our extensive codebase and previous design choices gave us the freedom where we otherwise would have made compromises. The outcome is the sleek new app you see today, which implements a new mobile architecture across both iOS and Android. Read on to learn why we felt the need to create this new architecture pattern, called Riblets, and how it helps us reach our goals.

*Motivations: Where To?*
While connecting riders to on-demand transportation remains the driving idea behind Uber, our product has evolved into something much bigger, and our original mobile architecture just couldn't keep up. Engineering challenges and technical debt accumulated over years as we stretched the rider app to fit new features. Additions such as uberPOOL, scheduled rides and promotional vehicle views introduced complexity. Our trip module grew large, becoming hard to test. Incorporating small changes ran the chance of breaking other parts of the app, making experimentation fraught with collateral debugging, inhibiting our pace for future growth. To maintain the high-quality Uber experience for all users, we needed a way to recapture the simplicity of where we started, while accounting for where we are today and where we want to go in the future.

The new app had to be simple for riders as well as Uber engineers, who develop improvements and features daily. To rewrite the app for these distinct groups, our two main goals became increasing the availability of our core rider experience, and allowing for radical experimentation within a set of product rails.

*Reliability is Core*
From the engineering side, we're striving to make Uber reliability a reality 99.99% of the time for our core rider experience. Achieving 99.99% availability means we can have just one cumulative hour of downtime a year, one minute of downtime a week, or one failure per 10,000 runs.

To get us there, the new architecture defined and implemented a framework of core and optional code. Core code-everything needed to sign up, take, complete, or cancel a trip-must run. Changes and additions to core code go through a stringent review process. Optional code undergoes less stringent review and can be turned off without stopping Uber's core business. This encouragement of code isolation allows us to try out new features and automatically turn them off if they aren't working correctly, without interfering with the ride experience.

*Rails for the Future*
We need a platform from which a hundred different program teams and thousands of engineers can build quality features quickly and innovate on top of the rider app without compromising the core experience. So we gave our new mobile architecture cross-platform compatibility, where both iOS and Android engineers can work on a unified ground.

Historically, shipping the best app on iOS and Android involved divergent approaches to architecture, library design, and analytics. The new architecture, however, is committed to using the same best patterns and practices across both platforms. This enables us to capitalize on the learning opportunities from both platforms. Instead of making the same mistake twice because we have separate teams for each platform, the lessons from one platform can preemptively solve issues on the other. Thus, iOS and Android engineers can collaborate more easily and work on new features in parallel.

_*Scalability Challenges for Our Service*
(Remainder truncated for brevity, but full article is on the blog.)
______________________

*HOW UBER ENGINEERING MASSIVELY SCALED GLOBAL DRIVER ONBOARDING*
SEPTEMBER 2, 2016 BY JONATHAN PEPIN

Here's the behind-the-scenes story about how Uber Engineering's Driver Team continues to develop our virtual onboarding funnel to get hundreds of thousands of driver-partners on the road earning money with Uber.

*The Consequences of Scale for Driver-Partners*
Our team cares about growth. We built the first partner web onboarding process to solve our scaling issues, and we had to completely revise that initial version for the same reason. Uber grows fast.

Signing up as a rider with Uber might be straightforward, but partnering with Uber is inherently a more complex process. As late as 2013, onboarding was purely manual. Potential driver-partners had to go to a local Uber office-before we created regional Greenlight locations-and go through a series of paperwork with an operations manager to create an account.

After six years of operation, we recently reached 2 billion trips on our platform. Uber is now in 400+ cities and 70+ countries. Delivering rides in all these places means we need to attract and approve driver-partners all over the world. Each week, hundreds of thousands of new drivers take their first trip and start earning money on our platform. At this scale, doing everything in person is not a solution. We had to make a better experience for our driver-partners, so we took this on as an engineering challenge.

*The Web Onboarding MVP*
We went into our driver-partner onboarding centers (what are now known as our local Greenlight hubs) and analyzed in detail how the process worked. In most cases, when someone wanted to become a driver-partner, the routine was short:

What is your vehicle?
Can you go through a screening process?
Provide your driver documents (driver's license, vehicle registration, and vehicle insurance).
Watch a video on how the Uber app works.
Wait a few days for the screening process. If OK, you are finally activated.










To allow driver-partners to go through these steps online, we built an MVP of what we called Web Onboarding with several components:

Monolithic app
Flask, a Python microframework
Server-side template rendering with Jinja2
Simple HTTP calls (no AJAX) to submit forms and transitions between steps
jQuery when additional design and DOM manipulation was needed
We stored the data in our main PostgreSQL database (we've since switched to MySQL) in two main tables:

onboarding_steps represented a step (e.g., vehicle or screening_process) for a pair of city and product (e.g., uberX in San Francisco)
onboarding_step_instances represented a user's status in a step (i.e., incomplete or complete).
When a user successfully submitted a step, we marked it as complete and found the next incomplete step. The steps varied slightly by city, but overall users had the same experience. Very simply, Web Onboarding allowed people to become driver-partners from any location.

Soon enough, Uber outgrew its Web Onboarding.









Uber's growth climbs up and to the right, with exponentially more operational cities each year.

(Remainder truncated for brevity, but full article is on the blog.)_


----------



## Retired Senior (Sep 12, 2016)

Maven. That was very interesting, and something that I need to read again later in the day. Granted that this was about the Rider's app, I still have a lot of questions as to why the Driver's app has been so flakey lately. (Not including the 3 - 4 hours of white-out last Monday).
I don't expect you to answer them! It all becomes sort of moot anyway if we are to be replaced by SDCs in 5 - 10 years. Personally I don't see wide-spread acceptance of SDCs until all the Baby Boomer's pass away. Plenty of my neighbors still use flip cell phones and vow to never change.


----------

