Currently you can't tell the colour from the mobile app but it's a good idea. I've passed it along to the mobile team to see if it's feasible.
(Disclosure: I work for Zipcar)
They should definitely not be showing an image with the wrong color, but having the information is better than nothing.
I also had a fun "gypsy black car running uber app trying to extort me" experience in NYC last trip, and a bunch of black cars who took 15-20 minutes to arrive (despite initially saying "3 minutes" and showing as around the corner). In a few cases I had the driver call me and give me useless directions to where he was, so I cancelled the trip and booked another Uber, and got someone dramatically better.
I apparently have a 4.6 rating.
I also made a web scraper to get my uber trip details (incl. route driven), save it to JSON and map the trips all at once. http://i.imgur.com/Q1W59rD.jpg. Here's a quick dump of the code https://github.com/joshhunt/uber. It's pretty rough and it makes a lot of assumptions (e.g. metric system and AUD). I never really plan on looking at it again, so your milage may vary.
I also found their API structure to be quite unusual: They make a call to something like `api.uber.com/` with POST data of something like
{
url: '/api/user/123123123',
method: 'get',
location: [lat, long]
}
{
responseData: {
username: 'madeofpalk'
...rest of requested data...
},
vehicles: [
...list of all vehicles and their locations...
]
...other data that wasnt explicitly requested but comes through with every request...
}
You have two classes of services:
1. Technical Services
2. Business Services
The technical services may be REST, SOAP, etc. These deal with the nuts and bolts of: update this one thing, fetch a load of these things (where they are the same thing).
The business services are usually some flavour of RPC JSON or XML, and only occasionally are REST (think of a resource that is actually a composite of other resources, it's usually a business service).
The business service wraps the underlying technical service with the orchestration of which granular services to call, and returns something useful to the user (the client, in this case an app which is also made by the company).
What you quoted was the result of a business service, but you can imagine that behind that are services that individually fetch vehicles, user info, etc. The business service is just wrapping it and doing a useful thing for the user by returning the composite.
It should be noted, there's an idea of a "service catalog". Some people think this is wholly comprised of the business services, but actually it's the superset of both business and technical services. You might have 2 catalogs, one external and one internal... but both are made up of a mix of business and technical services. The goal is simple: Help users to get shit done. In the scenario given, "get shit done" means "perform multiple calls, and because it's mobile and calls are expensive return everything in one call".
Some of this is remainders from when they just had consultants working on this. Look at hash_password() at client.py :)
That's so... what? Is the API not https? If they wanted to avoid even knowing the password, then why not use something standard like SRP (https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...)?
That animated GIF with the CLI session is very cool, by the way.
They don't have to modify any of their restful APIs to fetch or serialize more data than intended. Instead, the / endpoint might act as a wrapper, which does three things:
1. gets the entire app state
2. makes an internal API call of its own (proxies the one from the request)
3. merges the two results and returns them
in this case it is pretty clear they sped up requests by returning some generic data every request needed to update the app all at once as well. that's a pretty common requirement. netflix even allows client code to upload server code to pack responses into the least number
What I thought was strange is that we're not in the 'old SOAP days' any more.
I get what they wanted to do - speed things up by including common data in every request, and avoid state in apps. What I found strange was the way they solved it, esp. given they're (apparently) using Python and Node.js - writing a middleware to insert the common data would be far easier than implementing their own routing layer or whatever they've done.
Of course I'm making a lot of assumptions about what kind of stack exactly they're using (assuming they're using a web framework that we've heard of)
Anyway, looks like you can go and pull the token out of the page and just do
curl https://m.uber.com/cn --data '{"messageType":"PingClient","token":"xxxxx","app":"client"}' | jq .client.ratin
to check it programmatically. Could be interesting to have a service detect somehow that you'd just finished a ride and show you the new score (and possibly the change, etc)
Joking above but the whole concept of dual rating scares me a bit .......
This would be really cool.
Tyler Cowen extensively discusses the potential future of symmetrical ratings in Average is Over. The book is too complex to summarize here but it is worth reading.
I've used Uber only once - to help my mom to a doctor's appointment after she broke her hip.
I guess we were slow and a bit of a burden . . .
* Compliment their car or music
* Ask them about themselves (how are you doing, where are you from, how long have you been driving)
* Make small talk (how about this crazy weather/traffic/drunk people, do you have any weird stories, have you ever been to place xyz)
* Tell them a little about yourself or where you just came from/are going to
* Have the address of your destination or tell the driver how to get there
* Leave a tip for efficient service
* Don't throw up in the back seat * Leave a tip for efficient service
However, I do most of the rest (never really thought of complementing anyone's car, they pretty much all run together to me), and have a 4.9. I never even thought about making smalltalk as a way to get your driver to rate you better; it's just a nice thing to do when you're getting a ride from someone.
One of the interesting things I've noticed about Uber is how diverse the drivers are. I've gotten (at least) Russian, Kurdish, Moroccan, and Nigerian drivers, so that's led to some interesting conversations about where they're from and what it's like. From the conversations, Morocco sounds like the best place to go visit; the guy from Morocco waxes the most poetic about his homeland.
Then again, I don't feel bad rating drivers because they sell me a service, I'm rating that (it wouldnt even have to include their name - it probably shouldn't. then again I'm european, we seem to have slightly different ethics).
I feel bad that they rate us because we don't provide them with anything.
That rating is going to be saved, sold and shared eventually.
In rough order of importance to drivers:
1) Not causing damage to their vehicles.
2) Giving good enough directions on pickup such that they waste a minimum of (unpaid) time getting to you, and exiting the car in an expeditious manner. An Uber driver's KPI is "number of minutes per day with the car in motion with a passenger in it." (This is the biggest reason why many of them keep multiple phones with multiple apps open -- minimizing time between trips maximizes the number of trips they take per day and, thus, revenue.)
3) Not contravening the usual covenants of civil society.
Much of that value is automated in the form of our credit card details in our Uber app. But we do provide value in a few other forms: not being obnoxious, not trashing/puking in their car, not harassing them physically or verbally.
All these things happen to taxi and Uber drivers regularly, so there IS a need to keep the demand-side riders in check. It's analogous to eBay or AirBnB's two-sided rating systems.
Also, it's not fair to state as fact that our consumer buyer ratings will be "saved, sold and shared eventually." If Uber were a free consumer app with an unclear revenue source, that'd almost certainly be the case. But Uber isn't in the business of needing to sell that data. On the contrary, any marketplace data they hold is competitive advantage over other driver/rider services. They have at least some incentive to keep that proprietary.
Both people in a transaction value the thing they have less than the thing the other person is offering, otherwise there's no reason to bother making the transaction.
At least, in theory.
also at the minimum they should make clear the passenger (you) is going to be rated IMO. Maybe that'd solve the issue of passengers not being courteous or whatever.
You provide them with the "I didn't vomit in your car" service.
I don't see how this it the case, assuming that drivers don't know what passengers rated them before rating the passenger.
If they decide to start being ridiculous, I'll decide to start taking cabs again -- at least the cabbies generally have a clue about how to get to places, and don't bother with questions about "what route would you like me to take you on". The fastest route, thanks.
I'll decide to start taking cabs again
I suspect most drivers, like most passengers, give a 5.0 to almost everyone, but dock points for being a dick. It just seems there's no other way to differentiate passengers, since they'll be paying the fee regardless.
This is not very scientific. I got 4.8 which means absolutely nothing to me.
You don't tip with Uber - 'gratuity' is already included. Regardless, the rate-the-customer screen is seen immediately after stopping the trip
edit: This tweet said exactly what I was thinking when I saw all of this. https://twitter.com/s_m_i/status/493609377958723584
"Also this uber thing shows folks will copy and paste commands they don’t understand without a second thought if the incentives are right"
Drivers are prompted to rate their passenger immeditely after the trip, in the exact same manner as riders rate their driver. Then, when a trip is offered to a driver, they're shown the potential customers rating (and other details), then the driver will choose to accept the job or not
window.Uber.pingData.client.firstName, lastName, email all work, but rating is now "undefined".
Anyone have some insight into why this data is there in the first place? Is this an accidental leak, some sort of optimization or something else?
It's an optimization for their developers. They probably don't want to write a bunch of "if user.driver?"'s in their API responses, so just return all the data all the time and let their clients decide what to show.
Probably careless API design.
They'll use lat/long to determine if the user is in China or not and then pull up google maps or baidu.
Beautify this (https://d1a3f4spazzrp4.cloudfront.net/web-mobile-client/js/m...) then check out line 13185 for loadMap (Map loading resources on # 13094)
They also create a gorgeous map "blur" effect when the user is ready to pull the trigger on a ride: http://snag.gy/rlBYX.jpg
Seems kind of like a win-win-win for all three parties (Uber, driver, myself)
What's actually going to happen is that you're going to get degraded service from Uber without knowing why. You're never going to get a cab in the quoted time, because drivers won't pick you up, and you'll assume it's the same for everyone, tell your friends how slow Uber is ... I would say the disillusionment, blame, offence, etc are going to be aggravated by consistently slow service.
<script> window.Uber = { development: false, jswLocale: 'en_US', pingData: false, version: '3.0.0' }; </script>
I use uber multiple time per week and have for years. So I guess I'm not an asshole.
`curl -H "Authorization: fbAccessToken <fb access token>" https://api.lyft.com/users/<lyft user id>` provides some basic profile, credit card, location and referral information but nothing about ratings. The lyft user ID can be obtained by logging in at www.lyft.com/login and viewing the source.
Just ask.
My suspicion is that zero is equivalent to unrated, so shouldn't be in the sum?
window.Uber.Ping.Client.attributes.rating