aBlog

It seems Ken Thompson, one of the people who wrote Unix, was asked what he thought of the date-rollover problem in Unix (In the year 2038, the Unix date value wraps around to 0). His reply was that he didn't care as he was going to be dead by then. A speaker at the UniForum NZ 97 conference at Rotorua quoted this anecdote. When I mentioned this to a friend, he said that this speaks a great deal for Unix since the questioner implicitly assumed that Unix was still going to be around in 2038. Well is it? Is it worthwhile learning Unix skills and still be employable in the decades to come?

1. Introduction

In spite of Faye's repeated insistence that Mike leave the toilet seat down, Mike made the unfortunate mistake of accidentally leaving it up one day, only to suffer its dire consequences. Faye threw such a fit that Mike had to sleep on the couch almost that whole week until he made it up to her.

In spite of Mary's repeated insistence that Peter bring her a bunch of red roses every day on his way home from work, Peter made the unfortunate mistake of forgetting to do so one day, only to suffer its dire consequences. Mary threw such a fit that Peter had to sleep on the couch almost that whole week, until he made it up to her.

In a certain village on the remote plains of Fornicalia there exist some men who are having affairs with the wives of other men. Now there is a gruesome custom in this village which requires a woman to kill her husband the morning after she discovers that he is having an affair with another woman. It also happens that every woman knows whether every other man is having an affair or not except her own husband.¹ So life in this village goes on peacefully since no woman can know for sure that her own husband is cheating on her. Unfortunately, an Oracle from the pure and untainted shores of distant Stobon visits the village one day and proclaims that at least one man in this village is having an affair. What happens after this?

Readers are urged to think of a solution themselves before proceeding further. We first present the solution and its proof and finally go on to discuss the information theoretic aspects of this remarkable problem.² A similar treatment of this and some other aspects of the puzzle can also be found in Moses et al. (1986) and Halpern and Moses (1990), both of which also cite other sources where further discussion of the topic can be found.

"The sex of your baby predicted CHEEP! Guaranteed Results. 150% REFUND for wrong predictions"

There you have it - a simple and sweet business plan if ever there was one. But people who ponder can promptly peer past its imposturous garb. This is just gambling in disguise. Suppose the service costs $1.00 and a thousand naive couples paid for it. On average, five hundred of them will receive a refund of $1.50; the rest will presumably be happy to have been told the sex of their baby. Despite the refunds, however, the service provider is $250 better off than she was before, and for no more effort than flipping a coin for each customer. Immediately, one can tell that the scheme is a rip-off, aimed at defrauding innocent parents-to-be of precious baby-dollars.

To the uninitiated, that is exactly how CPA advertising is being framed by ad-networks steeped in profiting from traditional methods: "Give us your ads. We'll show them. You only pay for ads that result in a sale, but not a cent on the rest." On the surface, yes; this does look like a scam. But fortunately, this is not what CPA is about. In fact, CPA represents the exact opposite. CPA ad-networks don't just flip a coin to show an ad. Considerable effort and investment go into determining where each ad is most likely to appeal, and, of course, web real-estate on which to show ads does not come free either. A CPA network will actually "lose" money if you don't make it and therefore it is in their best interest to make sure you are successful.

If you could see the individual molecules of air in a perfectly still room, you would see that the molecules are anything but still. They are moving in all directions, apparently randomly. Each has its own spin, and its own story to tell. Yet the room itself, made up of millions of these molecules, has the picture of perfect calmness as though nothing in it is even stirring. In the calm of this room lies buried the solution to the most pressing problem in objective journalism.

Today, Linux is a beautiful thing and I typically waste no opportunity to evangelize it to friends considering a new desktop purchase. I mean, if the average user today calculates how much of his or her computer time is spent either on-line or within office applications, it seems like common-sense to buy a Linux desktop with Firefox and Open Office rather than buy expensive Microsoft products. Homer Simpson captures the sentiment best in the opening line of the latest Bart Simpson flick. Why would someone pay hard-earned cash to get something we can get for free? We're all giant suckers!

Forget OLAP cubes and pivot tables! As is the case most of the time, 90% of the insight can be gleaned from very simple data plots. To be sure, the remaining 10% does shed valuable new light, but is also orders of magnitude relatively more tedious to distill.

One of my favorite tools for performing quick sanity checks on data and even for inferring high-level trends is a histogram; it simply partitions your data points into a fixed number of buckets, with each bucket holding points that fall within a given range. The resultant bucket sizes are then available to eye-ball, often plotted as bars whose lengths are proportional to the number of elements in the corresponding buckets.

Can you process the entire Facebook network from a PC in your garage?

In today's agile world, software projects typically demand strategic choices over a plethora of possible solutions to most problems. Some solutions are appropriate for some problems and some aren't. It's important to choose a solution for all the right reasons, and it's doubly important to not choose it for all the wrong reasons. Human factors complicate this issue because inappropriate solutions to some problems are appropriate and good solutions to other problems. And these "other" problems are sometimes faced by reputed technology companies, who lend "celebrity" status to the solutions. This leads the young engineer astray, and coerces them into thinking that just because Google or Microsoft have found great success with a particular paradigm, they ought to as well. Further, within most companies, there are bound to be a number of non-engineering execs whose bandwidth is almost completely soaked up by non-engineering matters. It is consequently easy to get their buy-in for adopting such technologies using that unfortunately untrue magic phrase, an egregiously extant engineering enchantment and the mother of all modus ponens if I can call it that: If it is good enough for Google, it ought to be good enough for us". It behooves every company to have at least one theoretically and practically savvy engineer to protect precisely against this kind of thing happening. And to support decisions that are data-driven, rather than driven by subjective matters such as coolness and esthetics. At worst, data-driven decisions are at least likely to prevent general resentment among staff - one person's sense of beauty may not always be another's. On the other hand, a truly creative idea or proposal is bound to bubble up and find general support in the numbers. Those that shirk experimentation, calculation and testing are the prophets of faith that every organization should strive to avoid hiring into engineering, in preference to those that support the voice of empirical reason.

In this article, I want to focus on two specific cool technologies that frequently go hand-in-hand: Google's Map-reduce (e.g. Hadoop), and Cloud Computing (e.g. EC2). For whatever reasons possibly including those I've mentioned above, temptation is high among many engineers today to use these sledge hammers to crack nuts. As an illustrative case in point, I'd like to take one of our typical problems and talk about how we address it at 33Across. Our customers often express amazement at how we manage to process their gargantuan data sets and produce results in short order, seemingly with ease. We are often asked probing questions that try to get us to divulge our core data-processing techniques. Needless to say, I won't be describing any of our proprietary procedures or secret sauces here. But a great deal can be said without going into such matters. Most of what we have done to get where we are at is simply to follow published information you can find in any decent computing journal on occasion, but most of the time in good Computing-101 texts. Before we dive into using a framework that has any overhead associated with it, we always do quick back-of-the-envelope calculations (not unlike Rapleaf's nice analysis of whether to host or cloud) to determine if it will really be worth it.

Welcome! If you got here, you probably searched for "Could connect to localhost, but not to its IP address" or some variation of that phrase.

That's how I got here. To writing this post, that is. After unsuccessfully trying many clever variations of my query theme in finding an answer to this problem, we decided to troubleshoot it ourselves, ended up fixing it, and decided to blog for the benefit of the wider community.

If you're lucky, (a) our solution works for you and (b) this post shows up in the first few pages of your Google results saving you much time you might have wasted in following dead-ends.

Earlier this week, Mathangi wanted to know if it's possible to crop an image in the browser and then upload it to the server for her website. I promised I'll think about it over this weekend. So I got up early today and spent a good hour looking around for a solution. There seems to be a ton of code out there that lets you crop an image using JavaScript and PHP, including the excellent JCrop library. However, these all seem to be written for pre-HTML5 days. While you can define the crop area on the client, actual cropping is done on the server. See for example, at the time of writing, the disclaimer in the JCrop manual.

Jcrop creates an interface to crop an image. However, actually creating a new, cropped image file is obviously beyond the scope of a client-side plugin. It may also be the most challenging part of implementing such a process in your web application (now that you've found Jcrop).

Unfortunately, this defeats the whole purpose of the upload for my wife. She wants the image cropping to be done on the client because the upload will be much smaller, and only consist of the area of interest that the user wants to upload. Not the whole 10MB JPEG file. But fortunately, the task may not be as challenging as the disclaimer suggests.

So I put together a quick and tiny solution using a combination of JCrop, JQuery, HTML5's neat File and Canvas APIs, and a "clever" trick. Here is the full code in its awesome smallness (only about 32 lines for the HTML file and 55 lines for the JS including comments). Obviously you need to embellish it considerably.

You can see this code in action at this demo here. Of course, it only works in HTML5 compatible modern browsers, such as Chrome, Firefox and Safari.

If you're just interested in the code, feel free to grab it by Viewing Page Source, and then linking through to the JavaScript in the file crop.js.

If your family is anything like ours, and your home is anything like ours, then you probably have one laptop per member on average, but everyone seems to prefer to use the "living room laptop" that's always sitting on the coffee-table. Thank Google for this - We don't really need to live down on earth any more, preferring instead the lofty locale of the clouds wherein most of our data resides.

The upside of this situation is that we are much more tolerant of individual computer crashes, since every machine to us is pretty much the same once we login. But the downside is that we invariably forget to log out of sessions in the common pool of machines we tend to use. This is normally no big deal, but the living room laptop tends to get used by our guests too. I have too often had to log out of private email sessions left open by our guests (as I hope my hosts will do for me in their homes :-)

To save time, worry and potential embarrassment, I've always wished that Gmail provided a configurable Autologout feature that users can turn on in their personal profiles. This would save them the trouble of having to remember whether they logged out of their sessions before they left for home.

Finding no such "Labs" feature and waiting all too patiently for it to appear, I eventually ended up writing my own (based on Chris Nguyen's cool Greasemonkey script for Searching Unread mail in Gmail). Because I have it on good authority from my friends at the big G that a full featured auto-logout will likely make its appearance in Gmail Labs sometime soon, I saved myself the trouble of embellishing the bare-bones functionality of this feature. But I find it useful, and hopefully so will you, until the official feature is released from the plex.

Here are the few really simple instructions on how to get a timed Gmail session with auto-logout within your browser. Oh, BTW, I implemented a Timed Session, rather than auto-logout based on inactivity - it's a quicker hack; I didn't have to listen for events and such.

I wrote this for my wife's recipes website a few months ago. But I like it so much that I have decided to share it with everyone :-) :-)

PS. BTW, I know at least one other person (Stewart Alsop of Alsop-Louie) likes this poem. But he's a self-confessed foodie like me.

Last week, on the way back from my swim at the Y, I noticed a number of cop cars outside the house opposite the Y. I was consumed with curiosity as any sane person would be, but wouldn't dare stop and ask them what it was all about. We all know how much cops like lookie loos.

A room with two doors and scant else. I love Google and its products. Despite some points made in Steve Yegge's fantastically well-written and enjoyable rant, I've always thought its obsessive product focus and extreme emphasis on minimalistic designs a wise investment. After all, you can always furnish an empty house with furniture of your liking (as long as the doors are wide enough), but you can't reconfigure a home crammed with someone else's favorite furniture that's bolted right down.

But then I recently noticed an alarming misstep in Google's product design - Almost half as bad as LinkedIn's horrible home page that has 'Sign Up' fields showing by default rather than 'Sign In' fields with an optional link to 'Sign up if not already a member'. The latter and better design makes it easy for returning visitors (which a CEO should hope to be many). The former makes it one search-and-click harder for loyal users while embarrassingly making this implicit admission - that there is a greater business need for new users than for retaining existing ones. The latter says we'll take good care of you once you're with us. The former says "We love those that don't love us more than those that do - That's natural human psychology, and you better get used to it right now, so there!"

I'm lucky to have stumbled upon Mike Bostock's excellent D3 library when I was looking for a good implementation of force-directed layouts for certain kinds of graphs. I now use it for many more things than graph rendering. Data Driven Documents are indeed the future of the web and HTML5 apps, and d3.js is sure to have an enormous impact.

As an example of how D3 helped me greatly simplify things I'd hitherto put together using plain ol' javascript and jQuery, Here's an adaptation in D3 of a lazy image loader I'd written last year. The old code was over 50 lines long and not as simple as befits an obviously simple task such as lazy loading.

Now, using D3, the code is an awesome 10 lines of pure simplicity. See the demo here. (View Source to copy).

&