daave

"The problem with Admin control panel / API should be resolved. We apologize for the inconvenience and thank you for your patience and continued support. Please rest assured that system reliability is a top priority at Google, and we are making continuous improvements to make our systems better. Users were unable to use Google APIs, or were receiving errors when using Google APIs."

"We're investigating reports of an issue with Admin control panel / API. We will provide more information shortly."

"CupidWithFriends would like to access your public profile, friend list, email address, custom friends lists, birthday, current city and your friends' relationships, birthdays, current cities and photos." -> Cancel

(In general, I don't feel like Facebook should let me give my friends' photos [not just mine, but theirs] away to a 3rd party without their explicit consent first).

Relatedly, the 'Why Facebook' hover text says: "We use Facebook to make it easy to see which friends use the service, add existing friends, and prevent certain friends from seeing your profile. We do not post to your wall or spam your friends."

So my friends who I don't want to have see my profile will know I'm hiding it from them? Because they'll know I'm using the service, but they can't see my profile?

Why is that so unreasonable? Though, I think it's likely that the hosted solution would be much cheaper than self-hosting, since you don't need to rent one server per user, a hosted solution could be much more efficient.

-The home page, after rendering the search box and all that, asynchronously downloads the css, images and html needed to display the chrome around the results listing.

-That way it is cached on the client, and when they perform a query, less data has to be downloaded from Google's servers (just the actual results & ads), making the result page render faster.

-It knows not to download all the chrome due to the presence of the 'fp' GET parameter, the absence of that parameter will cause the entire results page, including chrome, to be downloaded.

I presume the rest of the parameters are useful for similar reasons.

It should also be noted that for non-HTML5 compatible browsers, modifying the hash fragment with JavaScript is the only way to change the url that gets bookmarked without causing a page reload (which would add latency), so if you want a bookmarkable local results page for images with certain preferences, adding a bunch of crap (latitude, longitude, preference hash, query, search type, etc.) to the fragment is the only way.

All in the name of productivity! If the author feels parties are taking too much of his time away from work, can't he just not attend? No need to try and ruin everyone else's fun just because he wants to be miserable.

Even though I can't be bothered reading the whole list, this post inspires me to resolve that I will read more books in 2013 than I did in 2012.

At this point, we have stabilized service to App Engine applications. App Engine is now successfully serving at our normal daily traffic level, and we are closely monitoring the situation and working to prevent recurrence of this incident.

This morning around 7:30AM US/Pacific time, a large percentage of App Engine’s load balancing infrastructure began failing. As the system recovered, individual jobs became overloaded with backed-up traffic, resulting in cascading failures. Affected applications experienced increased latencies and error rates. Once we confirmed this cycle, we temporarily shut down all traffic and then slowly ramped it back up to avoid overloading the load balancing infrastructure as it recovered. This restored normal serving behavior for all applications.

We’ll be posting a more detailed analysis of this incident once we have fully investigated and analyzed the root cause.

Regards,

Christina Ilvento on behalf of the Google App Engine Team

https://groups.google.com/forum/#!topic/google-appengine-dow...

I find it really off-putting that it's not possible to find out what your pricing plans are without signing up (and signing up requires giving you write access to my GitHub account).

PS: If you were 'anonymous user 21' looking at the spreadsheet around 20 mins ago, sorry I was screwing with things, making all the bills look like $0, it's fixed again now.

https://docs.google.com/spreadsheet/ccc?key=0AnYE99fIo31idFd...

In short, the scheme very heavily penalises doing a large restore from backup, but it's quite cheap if you just spread your restores gracefully across the month.. which makes a lot of sense if they're using tape drives.

I find it hard to imagine a manager could get away with saying that, but even if they did, I think it would be an empty threat. Perf is designed so that the manager is not a SPOF, your peers' reviews are considered at least as important as your manager's review. It would be pretty obvious if there was a big discrepancy between what your manager says and what your peers say, which would call your manager's review into question. The only way this would be a problem would be if your peers give you bad reviews too (and if that's the case, then maybe, just maybe, you need to take a look at yourself).

Gmail: I can't think of anything negative that's happened to Gmail in recent times (unless you didn't like the UI redesign - there are certainly mixed opinions on that), and certainly the performance and uptake of Gmail has only improved.

Google Reader: Not much new happening, but it's still running. Are you referring to the changes in the sharing model? Whichever sharing model was better, surely you can agree that having one unified sharing experience across Google produces results in a more streamlined product, and at least this was a step in the right direction.

Google Labs: Was closed down, yes. I still don't understand how this relates to the parent post. My thoughts on closing down labs: Labs was supposed to be a way to get ideas out there in the wild before turning them into a fully-supported core product. This was great for the engineers who had built these things (they got to see them used), and the early-adopters who tried Labs products. However, as time goes on and nobody's doing any development work on a particular thing in Labs anymore, there is still an operational cost to other engineers at the company who have to keep the thing up and running. Since it's a 'Google' product, the brand image is at stake, so we can't just let them wither. So I think it's reasonable to decide to have each labs product either shut down or integrated into a core (supported) product. Perhaps it would have been better to chuck all the old labs and start again, with a published policy that things in labs will either be fully supported or completely gone 1 year after launch (or something). The removal of labs is a signal that there's more red tape around launching new products than there used to be, but I think that's inevitable as a company grows, and more than some engineer's weekend is on the line if a lunch goes badly.

20% Time: Still as strong as ever, from what I can tell. About half the engineers I know have a 20% project, and there's nobody who doesn't have one who wishes they could have one. Most of the time if people don't have a 20% project it's only because they find their core job interesting and diverting enough that they don't have a desire to split their time with a side-project. Despite what some people have claimed on HN, your manager can't deny you from having a 20% project if you want one.

(I work for Google, but not on any of the products mentioned above, and I (willfully) don't have a 20% project. These are my opinions and not necessarily those of my employer.)

I wonder if they know how those particular hashes that were leaked got stolen, if not, they should assume the whole database was stolen and only some of it has been leaked publicly, thus necessitating that this action be taken for all users accounts, not just the ones that match the hashes in the leak.

> It is worth noting that the affected members who update their passwords and members whose passwords have not been compromised benefit from the enhanced security we just recently put in place, which includes hashing and salting of our current password databases.

Huh? For people who change their password, fine, but 'for members whose passwords have not been compromised', how are they re-hashing them with salt unless they have the original (plaintext) passwords on file. Or are they doing H(salt + H(pass)), rather than H(salt + pass)?

If the latter, then hopefully they are at least re-hashing your password next time you log in, but most people don't log in very often - my cookies certainly haven't been expired. A co-worker tells me that even after changing his password through the website, the login credentials on the Android app were not expired!

I typically arrive at Google about 9:20 (until recently the breakfast cafeteria at the NYC office closed at 9:30, although that's no longer the case I've kept the habit), but don't really start working until ~10. If I have plans in the evening I'll leave around 6, if not, I'll stay for dinner and keep working until 8-8:30. I've never come in on the weekend.

One coworker on my team is always there before I arrive, and is always still there when I leave, but everyone else on my team floats in gradually until 11:30 (when we have our daily standup), and leaves sometime between 7 and 10.

While some days I may spend 10 hours in the office building, consider that this includes 3 meals and usually at least one other major distraction (a tech talk, a break in the game room, TGIF, or something).

Edit: I've been in the NYC office around 4 months.

In that case, my response is that that sounds awfully paranoid. Earning and maintaining our users' trust is far more valuable to us than stealing some hypothetical secret business data that someone has stored in Drive, and new engineering employees (like myself) go through extensive privacy training to ensure we don't/can't do anything that would be a breach of our privacy policy. As it turns out Googlers have the same concerns about privacy as everyone else here, and we design all of our user-data storage systems with privacy as a key design goal.

The YouTube HTML5 player is still in trial mode, just not stable enough to use on the homepage of a major product launch.

All in good time, there are definitely people at Google working on it :-)

Perhaps that's part of the reason why more than half the people at Sydney's weekly meetup group for startups (Silicon Beach) seem to be well over 30.