A new kind of socially-biased search engine: Blekko

A new kind of socially-biased search engine: Blekko.

This idea of a simple query language that actually is geared towards normal people is interesting.  SQL was supposed to be that way back when, but no one today would ever claim that a search engine that exposed SQL to users would be better for the masses.  But a simpler version could have some really awesome broad impact in other areas.  As people become more comfortable using semi-structured queries we can use them in our own web apps without extensive education or making them “advanced features”.  I don’t know if Blekko can succeed, but if they can I think the web will benefit in some interesting ways.

Google Wave: why we didn’t use it

Google Wave: why we didn’t use it.

I really am disappointed that Google Wave has failed.  I think the Ars article does a good job of summarizing why it didn’t really take off despite the best press you could ask for not to mention Google backing it.

I’m still hopeful that the underlaying protocol can still be salvaged in some alternate clients.  It really would be interesting to see it reanimated in a different form by someone else.  Even if it were just added as a new account type in Mail.app or iChat and literally only provided feature parity with that tool initially, that might be a more logical progression to introducing what should be a more powerful and flexible communication protocol.  This will also give users a better understood starting point and we can more gradually figure out what people what to be able to do and how they want to do it along the way.  The fully baked solution the Google’s implementation provided really didn’t enjoy much user feedback to influence its development until way too late in the process.

JustinFrench.com: Pagination Alternatives

JustinFrench.com: Pagination Alternatives.

Great description of some of the deficiencies of pagination as well as a number things to think about when presenting large quantities of data to users.

User Stories and Mind Mapping

I read an article recently by Robert Dempsey about how he has recently discovered mind mapping as a way to manage user stories.  His technique was interesting and it gave me the excuse I needed to take another shot at mind mapping.

I’ve tried mind mapping in the past and it never really stuck for me.  It was a little too free form.  I needed some structure for my ideas, that’s why I was looking for something in the first place.  Robert’s post briefly describes the structure that he has used for forming user stories.  The method made the idea click a little bit better.  Basically he starts with the project in the center and then the ring out is the different actors.  Hanging off the actors are the actions that they should be doing.

I downloaded the 30 day trial of MindJet MindManager and tried Robert’s technique out on my current project.  It was a lot easier to get started that it had been on previous attempts with mind mapping, but I kept feeling like something was missing.  Here’s what finally clicked for me: what the user does is less important than why they want to do it.

In the classic user story we have an actor, an action, and a business value that the story provides (As an <actor> I want to <action> so I can <business value>).  I slightly modified Robert’s approach and added a level for business value — the “so I can” clause of a user story.  Now I have the project in the center, next the actors, and then I start listing out the business value that each actor wants to get from the app that we are building.  Under each of these leaves I can then start describing actions that would provide the actor with the business value.

This really make things click.  My ideas started to come together and I feel like the result is clear user stories that are customer business value focused.  I need to thank Robert again for convincing me to dig in to mind maps again.  I think this will be a big help in focusing my ideas in to something communicable and implementable.

SPDY looks… possible

Google recently announced their SPDY protocol that they’ve been working on to address a number of inherent non-performant aspects of the HTTP protocol that most of the web depends on.  In the last few years the web has shifted much more towards real-time applications.  Web application development is starting to think about interaction experiences much closer to desktop apps.  It’s not out of bounds to consider the response times of certain queries on a website in terms of keystrokes (~200ms).  Moving the request/transmission protocols to catchup with this change makes sense.

One thing that I am happy about with SPDY is that is appears to be built with deployment clearly in mind.  This isn’t the first attempt to improve web speeds, it’s not even the best, but it does appear to be the simplest to deploy in to the wild and see rapid adoption.  If Apache and Firefox gained support for SDPY out of the box, and it was show that using the protocol would improve server throughput, it would be enough to shift most websites over.  That’s only two players.  That’s pretty promising.

Should I use an instance variable?

No.

If you are in a position to ask this question I humbly recommend you default to: “No, I do not need this as an instance variable right now.” There is a tendency to plan for every potentiality when doing software development and this is a prime example of such a situation. Resist the temptation.

Instance variables represent state associated with an object in memory. When you declare an instance variable you are saying to all future developers: “This piece of state needs to last for the life time of this object because it will be used elsewhere.” Think very hard about that. We are saying loudly here that this variable is coupled to other fragments of code. Which code? Dunno, do a global search ;) .

This is called tight coupling. I will go so far to say that coupling is the source of all evil and complexity that we deal with as programmers. With every step that we, as programmers, take in building a system should be with an eye to reduce or at least not increase the coupling in the system that we are working on. The fewer instance variables that we have in a Rails controller the smaller the potential coupling between the view and other method calls that have access to those instance variables. Each method, each action in a controller, should be as self contained as possible. The less leakage of state out of a function the better. Generally your view doesn’t need to see that temp variable of the calculations that you made to set a model attribute keep it local, drop the “@”. Worst case scenario you go back and refactor your code to include that “@”.