Hungry, horny, sleepy, curious.

defining the interface for rubymonk

noreply@blogger.com (Steven Deobald) — Sat, 05 May 2012 05:43:00 +0000

Discussing an interview I had yesterday --quite interesting when delivered with Aninda-- with a non-technical friend, we stumbled on the fact that everything in Computer Science is an interface. From the moment you differentiate data from code, which wasn't immediately obvious to even the first computer programmers twiddling individual bits....

Everything you build in software is defined by an interface. These are the boundaries, but they're also where the magic happens.

Here are some interfaces:

http://www.c42.in/a_url_is_an_interface/

(We'll come back to this.)

$ ps aux | grep clojure

At this point, I had to stop to explain how a function works. Does this help? (Hey Blogger or Google or whoever the heck is in charge: why can't that image be an SVG?)

Objects are the next interface to consider. They are a bundle of functions. Actually, they're more complex than that. They are a bunch of closures... actually, dispatching closures. (Okay, I've lost my non-technical friend at this point. Oh well.) There are other ways of looking at them, but we'll take the perspective of the function, which we already agree is quite simple. To the function, the object looks like a set of rules about how one defines interfaces with functions. Objects can be made of functions but it's not quite so the other way around (though the object may consider this point contentious or even academic). The function doesn't care. To him, an object is just a cluster -- however small -- of functions who have been told in advance that part of how they behave must change, because of the way they were set up... this time, at least. And what's worse, just because an object has been set up -- it won't necessarily stay that way! Yikes. Looking at it from the outside, the function pities the object. The function can choose to behave this way but the default position of the function is, "I never change!" The object changes himself (or worse, allows other, unknown objects to change him). It takes some work for the function to behave so sloppily; you need multiple functions -- and functions returning functions, no less (as a type's constructor returns a function whose sole purpose is dispatch based on the type of the first parameter and the name of the second -- usually with these parameters taking special positions, like first_is_an_object.second_is_a_method. I digress.). Such effort forces a conscious choice on the part of the person writing that function. "This risk is worth it!" you say, and an interface of your choice, with complexity of your choice, emerges.

Finally, at the top of this scale are languages. They themselves are composed of functions and objects. In fact, most compilers and interpreters for languages can be thought of as pure functions: I give you the language, you give me the binary, assembly, bytecode, or runtime language (JS, these days). This is the most complex interface. Usually, a human still speaks to this interface. In 2012, this interface is fully-manual. These humans are called programmers. And the best of them will make it their task to automate away their own job. But, as of 2012, programs that write programs are risky and difficult. Automation can be seen on any of these other scales (functions and data) without writing your own macro or yet another compiler or parser. Choose a language which gives you this option when you have no other choice, but be careful to wield such a weapon when you see no other way out. Otherwise, it is a simple interface you want.

Kitty pointed out to me that I haven't called out a very important point: All these interfaces are fundamentally the same. They accept some input and produce some output (even if that output is a side-effect). Objects are built of functions, and they're both built of languages. And the languages are built of objects and functions. What differentiates each one is the mental energy required to contend with the interface's complexity. Stateless interfaces -- such as immutable objects, pure functions, and HTTP -- are always easier to understand because there are fewer balls in the air. The "given" of given-when-then doesn't apply if there's nothing to set up. There's only when and then.

This makes the interface for RubyMonk interesting. There is of course a very cute visual style to rubymonk.com (yeah, we love it too), but the real interface is the user's interaction with the mentor -- how we evaluate their progress and the programs they write. How we assert that something they've done is correct -- because the programs they write are data to us. As we teach more complex concepts, this interface itself will become increasingly complex by its very nature. Or, perhaps, we will realize the beautiful intrinsic quality of data that is code and code that is data, leading us to discover an elegant solution to the automation of the Hacker Mentor.

zero to emacs in under 5 minutes

noreply@blogger.com (Steven Deobald) — Sun, 25 Mar 2012 15:16:00 +0000

You want to write Clojure. You want to write it in Emacs. Here's how.

1. Grab Leiningen.


mkdir -p ~/bin
cd ~/bin
wget https://raw.github.com/technomancy/leiningen/stable/bin/lein
chmod +x lein
echo 'PATH=$PATH:~/bin' >> ~/.profile
lein self-install

This will get you leiningen, Clojure's build tool.

2. Grab Clojure.


cd ~/code
lein new my-first-clojure-project
cd my-first-clojure-project
lein deps

`lein deps` will bring down a local copy of Clojure. Look in ~/code/my-first-clojure-project/lib !

3. Grab swank-clojure.


lein plugin install swank-clojure 1.4.0

This gives you the `clojure-jack-in` command in emacs. It's your samurai sword.

4. Grab a healthy .emacs config.


mv ~/.emacs ~/.emacs.bak
mv ~/.emacs.d ~/.emacs.d.bak
git clone git@github.com:c42/dotfiles.git
ln -s dotfiles/emacs.d ~/.emacs.d

5. Grab an emacs.

Ubuntu: https://launchpad.net/~cassou/+archive/emacs
OS X: http://emacsformacosx.com/emacs-builds/Emacs-pretest-24.0.94-universal-10.6.8.dmg

Running emacs for the first time will automatically install all the packages you need. Now run your first emacs repl!

M-x clojure-jack-in

TADA!

finger brains

noreply@blogger.com (Steven Deobald) — Tue, 06 Mar 2012 22:26:00 +0000

Okay, so now I'm back on my own computerand it's a race against myself. Crap. I still seem to be making mistakes. I guess I just can't type all that well when I've had ad couple. Shit.

Well, this is all I can think of so I'm going to stop typing in 3 2 1....

My housemate Nikhil (and not my other housemate Nikhil) and I had a typing race on our two respective keyboards. It lasted only a few seconds. We were racing ourselves to test the keyboards (MacBook Air vs. ThinkPad 410-something-something). We each preferred each other's machines but I would only trade this for an X1 covered in leather. Our conversation led to a cross-comparative question "why should I care about my typing speed?" to which was returned one of my favourite stories:

Duke Huan was in his hall reading a book. The wheelwright P'ien, who was in the yard below chiseling a wheel, laid down his mallet and chisel, stepped up into the hall, and said to Duke Huan, "This book Your Grace is reading--may I venture to ask whose words are in it?"

"The words of the sages," said the duke.

"Are the sages still alive?"

"Dead long ago," said the duke.

"In that case, what you are reading there is nothing but the chaff and dregs of the men of old!"

"Since when does a wheelwright have permission to comment on the books I read?" said Duke Huan. "If you have some explanation, well and good. If not, it's your life!"

Wheelwright P'ien said, "I look at it from the point of view of my own work. When I chisel a wheel, if the blows of the mallet are too gentle, the chisel slides and won't take hold. But if they're too hard, it bites in and won't budge. Not too gentle, not too hard--you can get it in your hand and feel it in your mind. You can't put it into words, and yet there's a knack to it somehow. I can't teach it to my son, and he can't learn it from me. So I've gone along for seventy years and at my age I'm still chiseling wheels. When the men of old died, they took with them the things that couldn't be handed down. So what you are reading there must be nothing but the chaff and the dregs of the men of old."

Wait. Maybe I meant to read him the one about the buckle-maker who focuses so intently on his craft of making buckles that he couldn't see anything else. It wouldn't be the first time I've confused them. Anyway, if you can't type in one continuous stream (higher speeds are largely irrelevant but a 100wpm minimum wouldn't hurt), you're losing little tiny brain spasms to figuring out which keys to hit. These little tiny brain spasms could be helping you figure out what `self` is in the median of your code while trying to remember how to write a class method which generates class methods in Ruby. Because that's how brogrammers like you and me get our tickles. These little tiny brain spasms are basically the opposite of sleep. Shoot them down with your giant space laser-equipped pelican-shaped airship! And then just run under Bowser because you don't actually have to kill him. The beautiful Mavis Beacon awaits on the other side.

Programming is for girls!

noreply@blogger.com (Steven Deobald) — Wed, 14 Dec 2011 22:53:00 +0000

My buddy Anne recently posted some of her favourite articles on the subject of women in Computer Science. I wrote an article last year which presupposed her question, "Programming is for girls?" My answer? Programming is for everybody!

Granted, not everyone who writes an Excel macro will be so enamored with their creation that they feel the need to master Haskell. The wonderful thing about Computer Science today is that they could. Thanks to the tiny (almost negligible) barrier to entry, the only thing left to tackle is the stigma.

Programming is already social. I prefer pair programming because I'm ADHD and it's the only way I can ever accomplish anything. But I also get to hang out with friends all day as a side benefit. Code is literature, a communication medium. It's fascinating that our little code-robots do something but it's a great deal more important that it speaks to people.

But: Not every software company is an inherently social environment. Yet.

Programming is already creative. In many ways, it's a purely creative endeavour. Outside the speed of light, there aren't many limitations placed on the raw imagination in a world of code.

But: Many software projects are still about doing the same old thing to a different piece of data.

Programming is already sexy and relevant. Startups are sexy by their very nature. Everyone knows what you're talking about if you say you work for Google or Apple. Most people you know already have a phone they've used to install software while they ride the bus.

But: Not everyone gets to work for a startup or Apple.

You can't have it all but you can certainly have most of it. Think your job isn't sexy? Automate the boring parts or quit. It's a seller's market these days. Try out a new technology, if that excites you. Talk to your coworkers. Work with them directly. Find a broader solution to an entire category of problems. Send your resume to that one company you think is really kicking ass.

There is a real spectrum of significance to the machines we build and the companies we build them for. Create some partial orderings to demonstrate this to yourself. Which is more significant? Clean water or banking? Auto insurance or rice? Diabetes research or zinc? Middle school education or vodka? Public transportation or plywood?

Not everyone considers the world in the same way and most of us will change our opinions over the course of our lives... but some parts of our society have obvious gravity. If you're already in software, let that gravity pull you in. If you're considering a career in software, contemplate the fact that a career in software really means a career in any field you want: from water purification to zinc froth flotation.

Girls, software is already sexy. Get on the trolley.

Clojure Macros: How Evil?

noreply@blogger.com (Steven Deobald) — Sat, 29 Oct 2011 22:39:00 +0000

Dan asked me at the Chicago Clojure Meetup this week if Clojure macros tend to send developers into the death spiral of metaprogramming Ruby's various hooks did when we first discovered those.

tl;dr: no.

The canonical example of evil Ruby metaprogramming is everyone's favourite this-will-trim-8-lines-of-code hack: strings to method names. Have you ever written something like this?

x.send("#{a}_#{b}")

Sure you have. It's okay. We've all sinned. Are you prevented from doing this sort of thing in Clojure? Nope. No more than you are prevented from doing it in Java. But in Clojure and Java, the apparent innocence of Ruby's `send` method is revealed to be a sham: Reflection feels bad in these languages.

All of Ruby's other metaprogramming hooks have something in common: define_method, const_get, method_missing, every flavour of eval, monkey-patching... and all their friends... happen at runtime.

The behaviour of my first few Clojure macros confused me because I was accustomed to Ruby's runtime powers. Clojure's macros are expanded, go figure, at macro expansion time. As such, they have a few interesting and related properties:

macros feel like adding a feature to the language
ruby metaprogramming feels like mutating the language
macros cannot use runtime data to generate dynamic code
ruby metaprogramming requires runtime data to generate dynamic code
macros require a new way of thinking about code generation
ruby metaprogramming is just a higher-level imperative layer

Macros also have a very clear usage pattern (see Christophe's wonderful (not= DSL macros) presentation from the first ClojureConj):

data formats > functions > macros

This is to say: Build your functions on top of your data. Build your macros on top of your functions. Macros should always be a convenience rather than a requirement. This one little rule is often enough to remind yourself that "write a macro!" usually isn't the solution you're looking for.

We're probably better off to avoid comparing Ruby's metaprogramming facilities with macros at all. It makes more sense to compare Ruby's hooks to Clojure's reflection and Ruby's eval to Clojure's eval -- neither of which I've seen used in a production Clojure application. Macros actually stand out on their own, since Ruby doesn't have an equivalent feature.

Can you still write a steaming pile of magic in Clojure? Of course. Once you suffocate your desire for elegance, you can reflect and eval and macro your way into a painful and confusing labyrinth of obfuscated code just as you can in any other modern language. But Clojure's libraries and language features usually display enough power on their own that you aren't tempted to shortcut your way into an impenetrable structural abstraction. At least, I haven't seen it yet.

Open Letter to Pascal

noreply@blogger.com (Steven Deobald) — Tue, 10 May 2011 23:00:00 +0000

My friend Pascal recently asked me what books I would recommend he read to learn the basics of programming. He'd been looking into it for a while but simply couldn't decide where to start, given the multitude of programming books available.

I'd be the last to claim I've swum a majority of the book lagoon, but I have found over the years that the majority of programming books are neither timeless nor all that well-written. Pascal's response seems obvious, in retrospect: if I could start it all over, what would I read?

In Pascal's case, I'd recommend The Structure and Interpretation of Computer Programs. As a Math teacher, he should find the calculus-based examples in the early chapters relatively easy -- if not downright intuitive. SICP is easily the richest and most thoughtful programming book I've ever read. Were it not for all the math it assumed familiar to the reader, I'd recommend it to everyone above and beyond all other texts in the discipline.

For everyone else (myself included), I'd put The Little Schemer at the top of the list, quickly followed by The Seasoned Schemer and The Reasoned Schemer. The books are a joy to read thanks to their peculiar style and between them convey many of the ideas SICP presents as a more traditional academic text.

Why not Learn to Program or Learn Java in 21 Days?

Most introductory programming books and online tutorials (even Why the Lucky Stiff's Poignant Guide to Ruby, in all its humour and beauty) make a grave mistake in their introduction to programming: They misrepresent syntax as the first principle of writing code.

If the first chapter of your introductory literature explains the representation of strings and numbers in [insert-your-language-of-choice-here], you've already started your reader off on the wrong foot. Worse yet, there's a temptation to teach new programmers about variables, mutation of state, and side-effects -- such as printing to the console.

One does not require dozens of books and years of practice to understand the essence of writing software. But in my case, it took as much to unlearn the bad habits taught by my first texts.

FlyMake does not like JRuby

noreply@blogger.com (Steven Deobald) — Fri, 11 Feb 2011 18:54:00 +0000

JRuby often works out-of-the-box wherever MRI does. FlyMake is not one of those cases.

Flymake expects a particular format for error messages returned from the interpreter: MRI error messages. Charlie and Friends have decided the MRI error messages can be a bit opaque, and upgraded them to something a little more readable. Sadly, this breaks anything attempting to parse those messages.

Gaz and I decided to try switching things back to MRI so we could get our syntax errors highlighted in emacs. Lo and behold! Everything's happy again. As an added bonus, you don't need to wait for JRuby (and thus, a JVM) to start up every time FlyMake runs.

You can grab our changes with our latest emacs-starter-kit: https://github.com/drwti/emacs-starter-kit

If you're using Phil Hagelberg's emacs-starter-kit, make the appropriate change to starter-kit-ruby.el:

-    (list "ruby" (list "-c" local-file))))
+    (list "/usr/bin/ruby" (list "-c" local-file))))

Enjoy!

TiddlyBuild, the single-file build light.

noreply@blogger.com (Steven Deobald) — Wed, 08 Apr 2009 03:53:00 +0000

Joel and I threw together a super-simple build light for TeamCity today. The standard project views are too cluttered for broadcasting big colourful messages.

Enjoy TiddlyBuild.

Tech Leaderisms.

noreply@blogger.com (Steven Deobald) — Tue, 10 Jun 2008 19:13:00 +0000

Are you a developer? Yes? Then I'm sorry to tell you, friend: There is a Tech Lead in you. Rather, someone will try to make you a Tech Lead one day. For your future Tech Lead self, I recommend reading the corresponding articles, A Tech Lead Manifesto and Behaviours of a Tech Lead (written by colleagues Sam Newman and Pat Kua, respectively).

To those insights, I add these recommendations:

Know Your Teammates

Before you start, talk to everyone. Understand each developer's goals and fears with respect to your upcoming project. Know the strengths and weaknesses of everyone on your team, and formulate a plan for dealing with both. Sketch out your team roster and ensure that the experience and skill level is balanced.

Use Two-Pizza Teams

I'm not sure who first coined this, but I love the idea. I also like the idea of trying it out in reality: Have an in-office team dinner. Order two pizzas. Were you left hungry? Your team is too large. Or you have one gluttonous developer. But probably your team is too large.

Given an oversized team by this yardstick, work with all stakeholders involved to divide up the project. You may even find additional value in simplifications required to divide up your previously bloated project.

Develop Horizontally Until Release 1

It may seem obvious, but I'm still surprised how often this rule is ignored. If you haven't deployed into a production environment yet, build out -- not down. Complex business rules will materialize in every story. They always do. Create new stories from these rules and put them on the shelf until they are truly more important than the next functional story coming down the pipe.

As a Tech Lead, you share this responsibility with your stakeholders. At the end of the day, they will decide what is most important. However, the unseen complexity of a business is visible to you because it materializes as code; share this with everyone.

Build It Yourself First

All too often slogans such as "You Aren't Gonna Need It" are thrown around the the software community until they're almost law. Lately, I find the most troubling to be "Not Invented Here Syndrome"; more often than not, I find the opposite Syndrome afflicting developers: "There's a Framework For That! Syndrome"

Sure there is. Build it yourself anyway.

The majority of frameworks are simply implementations of patterns. Whether as ubiquitous as Dependency Injection, or as domain-specific as a shopping cart, try implementing the pattern yourself before reaching for the nearest third-party library. You very well might throw it away, but often you'll end up with an implementation which is significantly lighter and easier to test.

Keep Metrics and Ratchet Your Build

Chris wrote about "ratcheting" recently. Go read it! The flip side of ratcheting is, of course, preventative medicine. Why wait until you have 60 TODOs before breaking the build? Place as many reasonable limits on yourself as you can, early on. In the thick of the project your motivation to do so might be overruled by the desire to Just Write Code. Tools such as Panopticode, metric_fu, PMD, and Gendarme will help you a great deal, but they're just the tip of the iceberg. Be creative not only in the tools you choose, but the rules you write and the metrics you extract.

The C# expatriate: Tips for settling in Java.

noreply@blogger.com (Steven Deobald) — Mon, 09 Jun 2008 13:13:00 +0000

Friday signaled the end of my first Java project in 6 years. Coming from a C#/.NET background, the learning curve was not steep -- but by the end of the project I had learned enough small lessons to serve as the basis for this little document.

If you happen to move from a .NET project to a Java project, have a look through these pointers. This is all the advice I wish I had when I started this project six months ago.

1. Learn all your new tools, inside and out.

As a C# developer, you're already utterly dependent on ReSharper. You will undoubtedly feel at home in IntelliJ. The majority of your day-to-day keyboard shortcuts will remain the same. Those that map directly map closely (CTRL+- is replaced with CTRL+ALT+LEFTARROW).

However, ReSharper is a plug-in which makes .NET development tolerable. IntelliJ is a work of art -- and it makes programming a joy. Install the Key Promoter plug-in and never look back.

2. Find New Tools

As far as I know, nothing like Panopticode exists for C#. Guice almost certainly doesn't. Explore the landscape and enjoy the rich open source bibliotheque that we're missing on Microsoft-funded frameworks.

3. Testing and Mocking

Use JUnit 4. Use Mockito. Try jBehave.

4. Collections

Eagerly write custom collections and provide yourself with methods for collecting, filtering, and all that other fun stuff. You can augment this with Hamcrest Collections, but keep in mind it's still v0.1.

5. Other Wrappers

Be even more aggressive about wrapping standard APIs than you would be in .NET. Why? Like collections, the .NET base class libraries have a (small) leg up on Java, thanks to watching Java grow and change. Because of this, you will periodically find features missing you might expect from the standard API. To be fair, once you've become accustomed to eagerly wrapping standard APIs in Java, carry that back to .NET with you. Chances are good you weren't wrapping enough stuff when you were last writing .NET. (I know I certainly wasn't.)

6. Dates and Times

The Java DateTime libraries are beyond useless; use JodaTime from day one. If anyone imports the JDK DateTime packages, fail the build. Joda comes with all the Hibernate jazz you need to persist Joda's DateTimes, so you're good there.

7. Apache Commons

Use it. It rocks. When you go back to .NET, steal ideas.

I am that alien.

noreply@blogger.com (Steven Deobald) — Fri, 30 May 2008 19:01:00 +0000

"Somehow the competing teams of aliens can see our world through our eyes when they want to, and can influence our actions by ramping up or down on our desires. They can't control our specific actions, just our general propensities, making us, for example, hungrier or hornier or lazier than normal whenever that would be a strategic advantage in the game."

Scott Adams - Sci-Fi Plot

Tables.

noreply@blogger.com (Steven Deobald) — Sun, 18 May 2008 05:40:00 +0000

Human beings can comprehend mathematics. At some point, we discovered the triangle -- a brilliant, reusable piece of beauty and simplicity.

Why do we still build tables with four legs?

Cartoons and comic books.

noreply@blogger.com (Steven Deobald) — Sun, 18 May 2008 00:42:00 +0000

The curiosity of my coworkers at ThoughtWorks often leads to a number of healthy and interesting debates, which often occur in the pub, on internal mailing lists, and anywhere in-between. One such discussion, of the mailing list variety, revolved around the topic Chinese economics and politics. Inevitably, the recent Angry Red Dragon issue of The Economist was mentioned in passing as participants shuffled over the topic of general Western opinions on China.

Most people I know were furious when they saw the Angry Red Dragon. I was elated. For years, I've taken to ribbing any of my friends who read The Economist; although the writing is entertaining, the topics various, and the grammar impeccable, I still find it offensive that such a magazine sells itself as "news" for the same I reason CNN disgusts me. It's not news. It's entertainment. It's a comic book.

Fox News has been getting it right for years now. Kurt Vonnegut's obituary-thing is the perfect example -- no one at Fox is pretending they're running a news channel. It's a cartoon and that in itself is not entirely disagreeable. No one I know would take such material at face value.

Other sources of information, though, seem to slip through this filter simply because their content is well-delivered and free of lunacy. Why is this the case? Even if we find a media outlet without opinion or agenda, what on earth makes us think they could possibly collect all the facts or perform a complete analysis?

Although we all ask ourselves that exact question and respond with "of course that's silly! I always question everything I'm told," sometimes it's not so obvious. As human beings, we're remarkably fallible. I've read Economist articles in the past and forgotten, mid-stream, that the material I'm consuming is For Entertainment Purposes Only. It's an easy rule to forget -- we all do it -- and there's nothing quite like thinly-veiled racism (or other abhorrent messaging) to remind us that media we consume is largely trash.

We need more onomy.

noreply@blogger.com (Steven Deobald) — Sat, 17 May 2008 16:14:00 +0000

The other day I was listening to assorted tracks in my reading room while enjoying a glass of scotch and puttering away in the codebase of my current project. I was feeling chipper, the sun was shining. On Saturdays I'm willing to play the music loud enough to feel engrossed and I was looking for a bit of a beat in most of what I was listening to.

I own an iPod Video, and if we discount the fact that Winamp seems to be the only reliable way of getting data on and off the device, it does a satisfactory job of playing music. Selecting music, however, is a chore. None of the predefined labels in the iPod taxonomy (or the taxonomy of any other music player I've ever used) satisfy my needs: Artist? Genre? Just what is a "genre," anyway? And how do I differentiate between Electronic, Electronica, and Electronica/Dance? Or Folk, Folk/Country, Folk/Rap, and Reggae/Folk?

I'd love to see a taxonomy for music based entirely on well-articulated emotion or situation. That is, the primary detail describing the music would be details of potential consumer environments, rather than details of the musical quality itself. Because music is so notoriously difficult to classify in the first place, I don't see why a difficult, albeit inverted, classification scheme isn't worth a go.

An open-ended tagging scheme would work well for this, so perhaps the folks at last.fm or MusicBrainz have already solved this problem... I don't know. I don't use the internet often enough to pay attention to this stuff. But searching one's own collection for tags such as 'emotion:elated,complacent' and 'situations:alone,underground coffee shop' would save those of us who don't have the energy to invest in memorizing albums.

Such a system would actively encourage group classifications to avoid the obvious potential single-minded environmental appreciation of music stemming from individuals producing this meta-data. But then, these classification parties would tend toward an eventual situation of 'classification party'.

...so maybe it wouldn't work after all. But I still wish UIs for music-selection had improved in the last 15 years.

Design oddities from another universe.

noreply@blogger.com (Steven Deobald) — Fri, 22 Feb 2008 17:15:00 +0000

Man. Whose job is it to come up with this shit? Here is what this dialog box says to me:

Hey, sorry. Because the software we wrote for you is riddled with security holes, we have to turn your computer off at random... in the night. Like ninjas. Or vampires. Or ninja-vampires who come in the night to destroy your data and then tie you down to your bed and tickle your feet until you scream. And then suck all the blood out of you through... your nipples. Yeah. And maybe then we'll throw salt on your bloody nipples just for good measure, even though you're already dead. Because we hate you. A lot.

Well, I'm starting to hate you too, Microsoft. My current project requires that I use a Windows laptop on a daily basis. I've grown quite accustomed to Ubuntu and OS X over the past few years. As much as I'll harp about the fact that Apple's computer platform blows Windows out of the water when it comes to "how much proprietary do ya gots?" -- at least it works. Windows XP is the new OS/2: it's cute, it worked once, but now we need to convince our co-workers it's time to move on.

Rock the shortcuts.

noreply@blogger.com (Steven Deobald) — Fri, 22 Feb 2008 16:49:00 +0000

Brilliant. I'm not sure how I got through life without this before: ? (or shift+/) displays all the Gmail and Google Reader keyboard shortcuts immediately on-screen. Hooray!

Devcamp Bangalore, Barcamp Pune!

noreply@blogger.com (Steven Deobald) — Wed, 06 Feb 2008 16:58:00 +0000

If you are near the south or west of the subcontinent this college fest season, be sure to sign up for devcamp Bangalore and Barcamp Pune. Each unconference will run out of the respective ThoughtWorks office, and Sexy MF will be in attendance. If you're coming to Barcamp, let me know!

Outdone.

noreply@blogger.com (Steven Deobald) — Wed, 06 Feb 2008 14:37:00 +0000

Life in India incurs smaller expenses than life in Canada. (Unfortunately, it also involves a smaller salary; my Indian salary is approximately minimum wage in Canada.) Rent is reasonable ($225/mo) and food is as cheap as you'll find it anywhere -- even to eat out ($2 will stuff you in a cheap restaurant).

But if Geoff can accomplish the $10/day February he has planned, he'll blow me out of the water.

I don't even have the energy to be angry about this anymore.

noreply@blogger.com (Steven Deobald) — Tue, 05 Feb 2008 18:50:00 +0000

One of these things is not like the others.

cnn.com

in honour of russian girl

noreply@blogger.com (Steven Deobald) — Tue, 05 Feb 2008 18:27:00 +0000

Mike gave up on his blog, but apparently someone else hasn't.

Here's one that recently slipped through Gmail's filters. You have to admit it's pretty money.

Enormous shlong drive girls mad

Your woman lived you alone along of she had done it with your friend.

By reason of the size of his machine drove her crazy with him.

Dont worry chap. At present you have good chance to Enlarge your male machine length.

Lengthen your male device size and you'll forget about troubles surely enough.

-Doctor Samantha Mcgraw

Testing strange web applications using Selenium? Take note.

noreply@blogger.com (Steven Deobald) — Sun, 03 Feb 2008 11:22:00 +0000

Update to: Workaround for alert() and confirm() during onload()

A change in Selenium has caused this workaround to stop working for those inclined to simply copy and paste Alistair's original solution. These days, if you want to give Selenium access to alert() and confirm() dialogs your application pops up during the onload event, you'll need to reference parent.selenium.browserbot instead. As per the original solution, execute the following code anywhere (either statically in the page or in the onload event itself) before the JavaScript which pops up a dialog:

var browserbot = parent.selenium.browserbot;
if (browserbot) {
browserbot.modifyWindowToRecordPopUpDialogs(window, browserbot);
}

Tada! You're home free and your QAs can happily automate testing through the UI once again.

Also of note: If you're popping up alert and confirm dialogs in an IFrame (egads!), you'll need to reference parent.parent.selenium.browserbot.

Happy testing!

How to be succinct.

noreply@blogger.com (Steven Deobald) — Sun, 03 Feb 2008 06:19:00 +0000

Regarding Singletons, Steve Yegge writes:

In my Data Structures course in college, when we got to AVL trees, my prof turned and wrote on the board, in huge, clear letters:
 AVL Trees are EVIL
...and that's all we had to learn about them. He had us implement red/black trees and splay trees instead. To this day, I have no idea how threaded AVL trees work. But if that's OK with Dan Weld, it's OK with me.

But now I know how he felt.

Steve, Steve. Follow Mr. Weld's example. Or you could just point people toward "Test-Driven Development By Example", since Mr. Beck has already covered this one pretty well:

"How do you provide global variables in languages without global variables? Don't. Your programs will thank you for taking the time to think about design instead."

Singularity.

noreply@blogger.com (Steven Deobald) — Sat, 02 Feb 2008 14:54:00 +0000

At lunch the other day, Anay and I were lamenting the sharp bug-detection skills of our team's Business and Quality Analysts over dry, flavourless rotis. At one point, while defending a feature he hadn't implemented yet against accusations of systemic circumvention, Anay blurted out, "That's because you haven't filed a bug for it yet!" (With the standard XXL Anay Grin plastered on his face, of course.)

However, our humour inadvertently led to revelation. The differences described by experts between "defects" and "features" are purely semantic. And after considering the application of this theory wholesale to our current project, we arrived at a much juicier solution: Bug-Driven Development. Submit a bug, have it implemented by our crack team of developers.

Subversion is here, but we'll probably move to Google Code when we write... some code. (I tried making an issue tracker on Lighthouse... but lo-and-behold! It sucks. Thanks Web 2.0 for providing the world with a bunch of over-simplified applications written by 15-year-olds which are only free when they're totally useless. I'm not bitter.)

Anyway. No software exists yet, but you are welcome to submit bug reports. No development environment exists yet, so bug reports are welcome as comments on this blog post or emails sent to me. A good first bug report would be the lack of a bug reporting system. Maybe the software should be a bug reporting system? Oh, we also don't have any developers yet, so another suggestion for your first bug is recommending the assembly of a team.

Enough hints! Welcome to Singularity: The First and Last Real Software Ever.

Dupies.

noreply@blogger.com (Steven Deobald) — Sat, 26 Jan 2008 23:17:00 +0000

The Theory

Moving to a new country often involves adjusting to a new currency. As much as my mind can't intuitively wrap itself around miles, I have a hard time with the feeling of Rupees here in India. Thankfully, the current economic situation provides us with some easy answers.

The present economy helpfully provides us North Americans with a nearly-round conversion rate:

$1 CAD / USD : Rs. 39.1

We can exploit this fact by rounding up to Rs. 40 per dollar and taking other factors into consideration. The economy of India is significantly different than that of North America. Housing is much more expensive. Food is much cheaper. Compared to the cost of living in your average Canadian or American city, the cost of living ratio is approximately:

1 : 4

You see where we're going with this, ya? To get a feel for prices in India, all you need to do is apply this ratio:

1 : 10

Canadians/Americans: That is to say, for every dollar you would spend in the US or Canada, you should prepare to spend Rs. 10 in India. This obviously won't be the case. I've spent Rs. 2000 (which feels like $200) on a bad bottle of wine. I've spent Rs. 5 (which feels like $0.50) on a sandwich. But you get the idea.

Indians: Conveniently, the inverse is true. If you move to the US on a US salary, imagine every dollar you spend is Rs. 10. A $50 bottle of wine should taste as good (probably better) than an Rs. 500 bottle of wine. $400 for an iPhone? That should hurt as much as spending Rs. 4000.

Details

The difficulty here is that India's economy is a great deal more interesting than North America's. Some people in India live on Rs. 500/month. Could you live in Denver for $50/month? On the other end of the scale, we have inflated prices driven by foreign currency, which complicates the conversion even further. For now, let's assume you're a member of the youthful middle class in either country and examine some sample costs.

Cleaning Lady
Rs. 1000 /mo => $100 / mo

Salary
$50,000 => Rs. 500,000

Rickshaw / Cab ride
Rs. 50 => $5

Cheap meal
$4 (McDonald's) => Rs. 40 (delicious)

Expensive meal
$200 (delicious) => Rs. 2000 (Meh.)

Imported iPod stereo
Rs. 16,000 => $1600 (in India)
$400 => Rs. 4000 (in Canada)

Delicious street-side masala chai / disgusting Starbucks coffee
Rs. 2.5 => $0.25 (in India)
$4.25 => Rs. 42.5

Those last two items are intended to illustrate the sliding scale. You would never pay $1600 for an off-the-shelf iPod stereo (one hopes), nor would you ever find a coffee shop willing to serve you a cup for $0.25.

In general, "the high life" is better lived in Western countries... or in India on a Western salary, if you have such a luxury. Otherwise, you'll find the cost of living comparable in India, with regular expenses such as food or tea accounting for very little of your budget.

Is there an easy conversion rate for two countries you've lived in?

A new theme.

noreply@blogger.com (Steven Deobald) — Sat, 26 Jan 2008 08:56:00 +0000

In the past I've applied "don't think, just do" only when I felt like doing. No more! If you aggregate this thing, you'll probably want to stop. A scratchpad will all facets of my life become.