I ran into SSL timeouts on in local development setup when I was re-factoring some integration code with facebook and using their SDK. It was tricky to diagnose, I was sure that my changes couldn\'t be the cause, and I finally confirmed it by running our production codebase. Since it was having the same timeout error, I knew the bug had to be in an underlying layer.

For the record, I\'m running this version of curl on my Archlinux box:

curl 7.25.0 (x86_64-unknown-linux-gnu) libcurl/7.25.0
 OpenSSL/1.0.1 zlib/1.2.6 libssh2/1.4.0

I also got the error from the command line with

curl "https://graph.facebook.com/oauth/access_token"

But it is fixed with

curl --sslv3 "https://graph.facebook.com/oauth/access_token"

Debian Server

On a debian squeeze server, with the latest (4/3/2011) version of curl:

curl 7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0
 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6

The timeout does not happen with either of the following commands:

curl "https://graph.facebook.com/oauth/access_token"
curl --sslv3 "https://graph.facebook.com/oauth/access_token"

OS X

The time out does not happen on OS X which runs curl 7.21.4

Thoughts

So, this timeout only seems to affect users with very new version of curl. Fixing it requires adding a line to the Facebook PHP SDK, which while minor, you have to remember if you ever upgrade it. At the same time, this bug could come back and bite you down the road if your operating system sneaks in a newer version of curl. You can see a fork of the PHP SDK with this fix on github.

Other references:

1. Facebook bug ticket
2. Maybe related PHP bug

I came across Dan Crow\'s insights into startups and older workers this morning, and I couldn\'t stop myself from nodding in agreement through out the article. Part of it, surely, is that I am now closer to 40 than 30. But everything he says about the value of spending time with family, the pointlessness of working grueling hours, and the skills that come from experience had an air of \"I\'ve been there\".

Many startups, especially in Silicon Valley, have a macho culture of working extremely long hours. I vividly recall a long stretch of consecutive 100+ hour weeks at Apple early in my career --- which came on top of a 3 hour commute to San Francisco. The quality of my work noticeably declined, and it took me months to get my focus and energy back afterwards.

It seems that both corporate america and silicon valley startups, while vastly different cultures in almost every regard, still see people as expendable resources that can be used up and replaced. Sure, if you\'re working non stop for a startup, you can tell yourself that there\'s a huge payoff at the end, or the chance of it. But the risk is that you spend your 20s and early 30s working forever without much to show for it. That was never something I wanted to do, and I\'m lucky that I didn\'t have to, either.

Why startups shouldn't just be for the young

One of the joys of testing with IE8 is the added google time that I get to spend hunting down bugs and solutions. If you find something mesbehaving in Redmond\'s browser, then the Internet knows about it and has a fix somewhere.

Todays culprit was caused by using jQuery\'s fadeIn effect on a div containing text. The way that jQuery has to animate the opacity transition causes the font\'s to not be anti-aliased, appearing all rough and blocky during the animation. It\'s due to the use of the filter property to affect the opacity, There are a couple of fixes, including hooking into jQuery to alter how the fadeIn/fadeOut/fadeTo effects work, but the simplest solution is to give the element containing the text a background-color.

Although littering your CSS with redundant background-colors will be a pain when you redesign your site, I think its preferable to relying on a javascript solution.