adpowers

I don't believe they idled their factories. In fact, there was an article about how they had to find parking for all their newly assembled airplanes while they were grounded:

http://www.nytimes.com/2013/02/20/realestate/commercial/to-b...

The NYT just did an article about how employers will skip over potential hires that have bad credit, especially in a time of high unemployment when they have the option of being choosey.

http://www.nytimes.com/2013/05/12/business/employers-pull-ap...

Parts were shot in Pittsburgh, LA, Manhattan, and London. The Freedom Tower under construction was obviously visible in some skyline shots.

In one scene Batman and Bane were fighting on the steps of Wall Street. From one angle the shot was filmed in front of the Mellon Institute in Pittsburgh and another angle was actually on Wall Street.

http://moviemaps.org/movies/7y

It was sitting on the ground at the end of the table where you collect your belongings and repack your laptop. I showed it to TSA agent and went on my way.

I flew yesterday and found a rifle bullet+cartridge on the "secure" side of the TSA checkpoint. Yet somehow the gift-wrapped paperbacks in my checked luggage were deemed suspicious and unwrapped. Useless fools.

The jobs manufacturing iPhone/iPad/iPod aren't coming back, but I could see Apple bringing the manufacturing of computers (especially desktops) to the US.

For one, the computers have a higher BOM and price, so an increase in manufacturing costs takes a smaller share of the total profit. Plus they only make 5 million computers a quarter, compared to 41 million iPhones+iPads.

iDevices are released on an annual schedule, which means delays are extremely costly (especially if they are timed for the holidays). This requires a very tight supply chain. It isn't as big a deal if the iMac slips by a month.

Finally, the market for iDevices is extremely competitive compared to desktops. Execution matters way more for iDevices and a lot more money is on the line. It is easy to experiment with iMacs because there is much less pressure in that market segment.

Because most users have a relatively fixed base load, and buying reserved instances for that base load lets you save lots of money. The ideal setup would look like: reserved instances for base load, on-demand for natural daily curves, and spot instances for batch or price sensitive work.

They are doing that with the Bay Bridge:

http://www.nytimes.com/2011/06/26/business/global/26bridge.h...

Yeah, I used to demonstrate this my typing "Americ" and then touching down directly over the 's'. Even though I pressed the 's', it was the 'a' that appeared. You could clearly see I wasn't even touching 'a'.

I think they got rid of this feature a few versions ago because I haven't been able to reproduce it. I suspect (but have no evidence for) that this is related to the typing lag that was really bad in ios 2 or 3. From my perspective, it seems they weren't able to fix the realtime correction so they made it asynchronous and just fix up words after you hit space. This is how it seems to perform now (and let's them offer more features like multi word correction).

I worked on a project that implemented a task queue using a database table. Workers would SELECT FOR UPDATE a couple of rows, mark themselves as owners, commit the change, and then do the work outside of the transaction.

The workers were configured to fetch new tasks every 30 seconds. With 10 workers you'd expect tasks to get fetched from the queue every 3 seconds, but that is not what we were seeing. The tasks were only getting picked up on 30 second boundaries. What was going on?

It turns out that the tasks were piling up. As soon as one task tried to update at the same time as another it would get blocked on the database lock. Its own transaction would then run really quickly following the first transaction. However, since these two tasks were run in immediate succession, now they were synced for life. They both slept for exactly 30 seconds, the first one wakes up a few tens of milliseconds earlier and grabs the lock, the second one wakes up and blocks on the lock, and this happens in perpetuity. Eventually, due to small randomness, all tasks entered lockstep and would be a small thundering herd against the database.

This was noticed by a developer and fixed by introducing a small jitter in the sleep time. After the push our tasks were picked up in three seconds and our end-to-end workflow time got substantially shorter.

Humans are very easy to train compared to robots, and aren't that expensive. I'd imagine each facility is laid out slightly differently, with different generations of hardware. To make the robot work well you'd either have to program in each hardware variation or make the software sufficiently advanced to understand the differences itself and adapt. I imagine the cost/benefit wouldn't pan out when you look at how many datacenter techs you replace with how many software and hardware engineers.

Humans are great at adapting, so if you throw a new enclosure at them or a new motherboard design which has the CPU sockets in a different location, they'll be able to learn the new system in 30 minutes.

A former coworker of mine trained to work with factory robots, but he realized that there wasn't much of a current job market for it because humans are still way cheaper (and will be for some time). Instead he went into software.

Uhh, Safari? Safari is the number one browser on one of my (non-technical) websites, primarily because of mobile traffic (iPhone and iPad).

If we are sharing anecdotes: both my condo building and office building have reserved spots for charging electric cars. However, I'm not a fan because they were both installe by government subsidy and currently offer free power. Just why we need: to subsidize the drivin habits of people rich enough to afford an electric car (as they currently command a price premium).

A believe many people enjoy movies and don't want to pirate them (I am one of them). They won't pirate and don't want to abstain from movies, so the only option is to provide a credible alternative entertainment that doesn't involve sending money to those who lobby against us.

Exactly, compare this to SimpleDB. SimpleDB started out with an advanced query language that let query and filter your results in all sorts of ways. And guess what? SimpleDB is still limited to 10 GB per domain (aka, database). Want to horizontally scale? The official suggestion is to shard your data across domains. This is a really messy solution because you have to preshard based on estimated database size and resharding is nearly impossible (you'd have to rewrite your entire DB).

AppEngine went the other route and provided a very simple database API at first and all queries had to be range scans over an index. Any query you wanted to perform had to be precalculated by defining a composite index and some things (like inequalities on multiple fields) weren't supported. Over time they've built upon their basic database and added features such as a zigzag merge join algorithm which lets you perform queries that were otherwise impossible with a given set of indexes.[1]

I bet DynamoDB will be going the AppEngine route by starting with a simple, scalable base which can be used to build more advanced query engines and features.

1. http://code.google.com/appengine/articles/indexselection.htm...

I'm running a bunch of t1.micros for different websites, now I have to pay twice as much to get an ELB for each to use v6? And I still can't SSH over v6. Amazon needs to stop pretending that ELB is the final solution for v6 and give each instance their own v6 address.

Try searching for [poison control] or [suicide]. Both of those bring up one boxes with phone numbers to call. Those probably help save a couple lives per day. Sure, you could call 911 and have them give you the poison control number, but now you've tied up 911 resources.

If anyone cares, I found out what the problem was. Chrome updated to a new version of the web socket standard back in version 15 or so. I wasn't aware of the change and so didn't update my version of socket.io which supports the new standard, thus an incompatibility. It should work now.

This just goes to show that you have to be vigilant if you are building sites with the latest and greatest, as they are still under development and likely to change out from under you.

Heh. Well, mine wasn't completely arbitrary. If I remember correctly I was trying to trade off server CPU usage with memory usage. One chunk at a time is buffered on the server, so I wanted to keep it small enough that I could have a bunch of ongoing transfers on my puny t1.micro. However, too small of a chunk size resulted in too many roundtrips and lots of CPU load on the server. I settled on this value because I was able to pump a couple megabytes per second through it using one stream, which seemed reasonable.

Also: in further testing, it looks like Safari works with the drag and drop, but not the uploading. I purposely disabled all socket.io transfer types except web sockets in order to encourage adoption of modern browsers. Unfortunately, since I used such bleeding edge, unstandardized technology (drag and drop, file API, and web sockets), the browsers have changed and broken my implementation, each in a slightly different way, such that none of them work end to end anymore.

I made almost exactly the same thing a few months ago: http://www.transfury.com/

The server is written in node.js and it uses socket.io to do the transfers. I think it only works in Chrome because I didn't bother getting the drag-and-drop working with anything else. Actually, it seems to be broken in the current dev channel of Chrome. I announced it back in September:

https://plus.google.com/116396240707733722472/posts/d9ydb8o2...

That sounds like some of the posts on this blog: http://google-engtools.blogspot.com/

Also, related to source control but not Git, a few years ago Google had a tech talk about writing a Mercurial storage system on top of BigTable: http://www.google.com/events/io/2009/sessions/MercurialBigTa...

Ha! I love that they are using Hipster Ipsum:

http://developer.android.com/design/static/content/ui_overvi...

http://hipsteripsum.me/

My major take away from the MG Sieler post was that Rubin deleted a tweeted, which makes it look like he's trying to hide something, regardless of the true reason for deleting it. Why does he need to delete a tweet that whose commands no longer work? A tweet is a point in time snapshot that represents a thought or opinion at a certain point in time. They aren't wikis that need to be constantly updated and maintained. If someone tried the command and it didn't work, they could always search for the up to date instructions. I'm not sure how this became a platform flame war.

I was skeptical of the new pricing plan at first, but then I realized it was introducing more accurate price signals to users. This helped a lot of people realize that their apps were doing really stupid things. I argue this here:

https://plus.google.com/116396240707733722472/posts/EHpaKDWM...

Sadly no mention of multipart upload. If you use S3's multipart upload feature you can get similar performance for one file by uploading multiple parts of the file at once. I saw a substantial throughput improvement when I implemented some multipart upload code, even when uploading from EC2.

I'm surprised content aware image resizing didn't make the list. It is a few years old but still pretty neat:

http://www.youtube.com/watch?v=qadw0BRKeMk

That reminds me of this page in which the author created a large binary tree of pages and watched how various crawlers walked the tree.

http://www.drunkmenworkhere.org/219

Not all, if you look at the south part of the drawing there is still an above ground parking structure :(

Isn't that Chrome OS? Just enough OS to get your employees on to the websites that they use to do their job. (Only applicable for certain types of jobs, though)

But many of the backend services powering Kindle are based in Seattle.