When faced with real life complexity there rarely is an easy way out or a silver bullet solution. Here I will describe the model I’ve come up with during years of trial and error. The solution presented here is as far as I know not a mainstream one and it could be considered somewhat controversial.

Object Oriented Approach

Here we’re living in OO land. Each and every problem can be broken down to objects - we test them out both individually and jointly. We combine them in beautiful ways and then they produce the result we aim for.

Pros

• purist
• allows for modular design

Cons

• can be slow
• complicated for complex cases
• ravioli code syndrome
• additional layer of complexity by wrapping raw data into other structures

Few days ago as I was happily chopping away on my duck taped Rails application I decided it was a good moment to measure up bottlenecks and optimize a bit. Here is overview of what I did. It consists of common sense actions that I picked up here and there, in my ongoing battle with slow applications.

Starting position

Application main index page is loading in about 4.5 seconds, Apache Benchmark tool (just ‘ab’ from now on) measured speed of 5 pages/second.

Paging

Paging is a pet peeve of mine. As a user I hate it, as a developer I need it to make application work. Special annoyance is deciding how many items per page is enough. My rule of thumb is 20-25 items so the users doesn’t have to click pages like crazy (Deep down I am always wondering if anybody is even using paging).

One tweak I had implemented before performance tuning was using jquery.pageless plug-in. It helps in getting rid of paging altogether by loading content as it is needed. In this light I’ve reconsidered the number of items to preload. I opted out to have 6 elements per page (just one screen worth of data). If users wants more it is just a scroll away.

This reduced load time dramatically down to 1.5 second.

I was an avid Linux user. I love tinkering with computers and Linux provided more than enough material. You need a lot of love and time to pursue things of such vast complexity.

There was this one thought in the back of my head that kept bothering me. I understand that not everything has to work, but the fact that sound stops working on (almost) every upgrade was troublesome. It did not work any better for anybody else, so why did it break? Sound cards are not exactly new concept.

It was almost as nobody did not care about this. After a few years of feeling “paranoid” this confirmed my fears - What Killed the Linux Desktop.

I think it was Josh Susser that first said:

Ruby is the love child of Lisp and Smalltalk, raised by Perl the eccentric nanny.

After a couple of years of looking at Lisp, Smalltalk and Perl I would say: “Ruby is a Perl sister that’s not doing drugs”. She is more lovable but also less intriguing and wild.

Sweet Tooth

At the one side we have a Lisp. It has no syntax sugar. It’s even proud of it. On the other side we have Perl. It has ALL the syntax sugar and then some. It’s even proud of it.

These are both valid approaches. It depends on personal taste where on the scale you decide to settle. My pick is Ruby, some other people may prefer Python.

I pity them because Python feels like jail to me since it has all of those “purity”, “sanity” (however you want to call them) constraints. They pity me because I shoot myself in a bart every once in a while (and only occasionally cut my throat) because Ruby lacks some of those constraints.

This goes in circles as a classical holy war tends to, but I had an epiphany yesterday, while watching Perl vs Python debate live from OSCON 2011.

If you are not a movies fan, just to clarify that title is referencing movie that Keanu Reeves was playing in. It’s not that famous one about the bus that needs to maintain speed over 50 MPH (I forgot the name, according to reddit it’s called “The Bus That Would Not Slow Down”).

It is referencing that other movie about computers and shit.

I can tell you that Lisp is indeed the red pill of truth. If you happen to live in a world where you think all languages are equal, you need to check out Lisp.

Since Lisp has EVERYTHING it will be a real eye opener. After that experience you will gain the ability to properly rate your current technology.

Today I’ve decided to put a stop on the ‘Variable Reinforcement Machine’ effect.

For quite some time, it was making me feel like a rat, constantly looking for another dopamine hit.

Action plan

I’ve deleted accounts for:

1. Facebook
2. Twitter
3. Google+
4. Reddit
5. Google analytics

Smartphone

Every time I am outside and I have more than 5 seconds of idle time I will usually pull out my phone, hunch over it and check news that I don’t really care about.

I’ve removed:

1. Mail, facebook & twitter clients
2. Trash news portals

My online presence

1. Gmail
2. Rubygems
3. Github
4. This blog

I am writing this post just to prevent chickening out of this ‘revolution’.

Now that I think about it, there is a problem - no one will know this since I can’t tweet about it.

At least I am free :) this is what freedom looks like.

Usual arguments for not doing TDD are:

1. We have no time
2. Brittle tests
3. Too much work
4. No “real” benefits
5. Bad experiences with too much imposed testing (after manager single day agile training)
6. “We get payed for features, not tests”

Those are all valid arguments.

I have no problem with that. If you’ve tried it and it is not working for you, that’s great.

Some people try testing and are not quite sure what to think about it.

My heart goes to those people that linger between ‘doing it’ and ‘not doing it’.

I’ve realized, in hindsight, that I have two simple rules that help me yield much better results in ROI sort of way. Who knows, they might help tip over some more people.

First to clarify what I mean by borderline.

Borderline cases

People that use TDD, but are insecure about benefits.

They generally:

1. Write tests after writing code
2. Worry about time spent on writing tests
3. Worry about not being able to quantize benefits(to self or manager)

I am assuming:

1. You are on OSX & using Gmail
2. You can live without being in Gmail web interface 100% of time
3. You don’t mail that much from iOS
4. You secretly hate Google and want to use their infrastructure as a dumb data pipe

I suspect many, many people hate Gmail interface (and maybe even the whole Google interface approach). That’s why Sparrow was doing rather well until it was “neutralized”. Anyways now that Sparrow is more or less finished, many people from the “native” camp are looking around for alternative mail client.

Do you love Vim? Do you love modal editing and motions?

Do you hate terminal Vim not playing nice with OS X? (copy&paste problems). Do you hate Mac Vim occasional slowness(and OCD is making it worse)? Do you hate not being able to see the project tree that looks decent? Do you hate having to compile Vim to the specific version of Ruby in order to make the Command-T plugin work?

Even though the hate list is way bigger than the like list, modal editing is such a big deal for me that I was coping with everything else.

I am going to list a couple of great features that are marked for Ruby 2.0 milestone.

Combined map/select method

Let say you want to map over an Enumerable and only keep elements that meet a certain criteria.

You can do it in two calls like this:

[1,2,3,4].select(&:even?).map {|i| i + 1}
==> [3, 5]

[1,2,3,4].map { |i| i + 1 if i.even? }.compact
==> [3, 5]

The idea is to have one method that combines those two. The name is still not clear but filter_map seems like a possible choice.