I have a domain registered through Go Daddy that is my mail domain for email. This domain expired on Saturday and mail stopped arriving! Shouldn’t Go Daddy have sent me some email about this expiring domain and asking me to renew it?

They probably did.

However, they insist on sending me so much junk email that I’ve been conditioned to ignore all email from them.

If you are going to send important emails from time to time, don’t condition your users to ignore them by sending them junk in the quiet times.

Some time ago, I used this Lifehacker article to add an Intel SSD to my Macbook Pro. The end of this article includes the information on how to change the disk to boot from to use the SSD as your boot drive.

What this article doesn’t mention is that this selection is just for that specific boot time. The next time you boot up, the original disk will be used.

For the last 4 months, I’ve been booting off my original disk, and barely using my screaming fast SSD drive. Since I rarely reboot this machine, and I have 8GB of RAM, the slowness of this solution hasn’t been obvious to me. Today, I installed Parallels, and this insists on being on the boot disk, so I noticed that I was booting from the wrong disk.

With a bit of poking around in Google, I found this document in the Apple Knowledge Base which tells of how to change the boot disk during boot time, and in the very last paragraph, has this useful information:

This startup volume selection is temporary. To set the default startup volume for your Mac after your computer is running, open System Preferences and choose Startup Disk from the View menu (in Mac OS X) or open the Boot Camp control panel (in Windows).

So now I’m running my Macbook Pro as fast as it should be – after performing the necessary OS updates that were previously installed on the other disk.

Some time ago, I used this Lifehacker article to add an Intel SSD to my Macbook Pro. The end of this article includes the information on how to change the disk to boot from to use the SSD as your boot drive.

What this article doesn’t mention is that this selection is just for that specific boot time. The next time you boot up, the original disk will be used.

For the last 4 months, I’ve been booting off my original disk, and barely using my screaming fast SSD drive. Since I rarely reboot this machine, and I have 8GB of RAM, the slowness of this solution hasn’t been obvious to me. Today, I installed Parallels, and this insists on being on the boot disk, so I noticed that I was booting from the wrong disk.

With a bit of poking around in Google, I found this document in the Apple Knowledge Base which tells of how to change the boot disk during boot time, and in the very last paragraph, has this useful information:

This startup volume selection is temporary. To set the default startup volume for your Mac after your computer is running, open System Preferences and choose Startup Disk from the View menu (in Mac OS X) or open the Boot Camp control panel (in Windows).

So now I’m running my Macbook Pro as fast as it should be – after performing the necessary OS updates that were previously installed on the other disk.

It’s been a while, but it’s time to restart this blog.

Over the last year and a half, a lot of stuff has happened. My co-founders and I sold our social game company to Playdom at the start of 2010. We then spent time integrating our games into their systems and build our team and new games. At the start of August, Playdom were bought by Disney and I decided to leave the business we’d spent the previous two years building. I’m not a big company guy.

During my time off, I’ve been getting fitter and losing some weight. I started a running program in November and ran my first ever race, a 10K, in January.

I’m also starting the process of learning some new technologies – I’ve heard that mobile might be worth exploring – and looking for a new business to start at some point this year.

I’m adding a feature to a production application that I’m using MongoDB to implement. I’ve rolled this feature out to our production servers in a mirror mode so I can see it perform, but no production users are effected by this new code.

The first thing I notice is that my code to update a specific record is running in 400 to 4000 miliseconds! I need this to be running in 10-100ms for this to be a useful feature. What’s going on here?

I check the production MongoDB, and the mongo server is running at 95-100% CPU and and is outputting a bunch of slow lookups to its log.

I add some more processing units to add more capacity, but this doesn’t work at all! In fact, everything is now taking 1000-8000 miliseconds to process. It looks like MongoDB is single threaded on a simple query. Since everyone is raving about how great MongoDB is, how is it my code is making it look really, really bad?

My app is a Rails application using MongoMapper, and a common pattern I use in my Rails apps is to use this code to get a single record:

1   def self.load(id)
2     Model.find(:first, :conditions => { :_id => id })
3   end

This code returns a nil if the record isn’t found. This version will throw an exception if the record isn’t found.

1   def self.load(id)
2     Model.find(id)
3   end

In MySQL, the difference in query speed is essentially zero!

In MongoDB – not so much.

The difference in performance on my data set between the two queries is staggering:

The find(:first) method takes about 200ms, locks the collection during this time, and sucks CPU. The find(id) method takes about 1ms and, even if it locks the collection, returns fast enough to not matter in my case. CPU usage is now reasonable again.

A quick update to my code, and now my operations are taking 6-400ms (there’s some other work in there too that causes the variation in timing)

Received our new iPhone 3G[S] via UPS today. They arrived before 10am on the day of availability!

We hook them up to iTunes to activate, run through the entire process, and get to the point where it says ‘Activation may take 48 hours’

WTF?

We’re now 12 hours in, and our phones are still just expensive iPod Touch devices!

Maybe at&t will have them activated tomorrow. I’m guessing not though.

Recently, we’ve had reports on our apps that users are getting 400 Bad Request errors from our servers. On checking out our log files, there was nothing to see! All is working well. Yet the reports continue. What’s going on?

We’re using nginx 0,6,34, and the reports the users are seeing mention this. These errors are definitely coming from our servers, but still nothing in the error logs for the server.

After a lot of head scratching and diagnosing, it seems that we have a number of large cookies being set, and the users who are getting these large cookies are the ones having problems. Lets check the interwebs for some help here. Here’s a relevant post on the Ruby Forum

It seems that we need to increase the size of the header space that nginx needs to process headers. The setting for this is large_client_header_buffers, and the size part of this needs to be big enough to handle the entire cookie header being sent.

We set this to 8K and tried again. Still getting errors!

Putting a little test app together to play with cookie sizes, I quickly find the documentation for large_client_header_buffers and see that it works at the http or the server level. Well, it doesn’t work at the server level at all! That’s where we had it. The same setting at the http level works great though!

Now we have a fix!

Put the setting for large_client_header_buffers at the http level and set them big enough to handle large cookies! How big can that be? HTTP defined a max number and size of cookies, right? Lets go see what that is!

Oh dear. Modern browsers have given up on these size restrictions! You can now expect to be able to handle 40 cookies of 4K max each, or Safari could decide to send you 100 of those. On every request. Nice job browser makers! Just what I need is a 50K request to get my 1K icons or 10K images from my site.

So, watch out for large cookies and configure your nginx correctly before your users get those Bad Requests!

I just got a new laptop to replace my 3 year old E1505. Its orange.

I’ve been looking at getting a Dell M6400 Mobile Workstation, and had got the configuration setup just the way I wanted: 8GB Ram, fast dual core CPU, SSD, 17" 1920×1200. I liked the color of the Covet version, but Dell is offering 10% off the regular one, and the Covet configured the way I wanted was $1,100 more at $4,600!

When poking around looking for discounts, I saw a link to the Dell Outlet store, and here’s the page I found for the M6400 Outlet – when I first visited, there were 3 pages, now I’m typing this, there are 8 computers total! The availability changes fast, and what you see is what’s available.

I saw a configuration that was close enough to what I wanted to go for it, the only major missing piece was the SSD drive. Total price: $2,700 for 8GB, 160GB disk, 17" RGB 1920×1200, 3.06GHz dual core. With the addition of an 80GB Intel x25 SSD from NewEgg for $315, this is my $3,500 for just over $3,000. Just add credit card!

When the box arrived, and I opened it up, inside was a Covet version!

So now I have a computer that Dell is selling for $4,600 for a total cost of $3,000.

This is a refurbished computer, but it has a full 3 year warranty.

What is wrong with it for someone to have sent it back? When I received it, the OS was Vista 32 bit. This OS was reporting 3.5GB RAM. In the box was a recovery disk for Vista 64bit. I wonder if someone received it, saw that there was less than 4GB RAM when 8GB was ordered and then returned it.

As a benchmark, this laptop runs my apps test suite in 1/3 the time of my Dell E1505, and the 17" screen is much easier to work with many windows.