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.

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.

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.

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.

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.

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 “@”.

Logic-driven Design
To me LDD has a few key markers that make it stand out:

1. The persistence engine is used to store data and little bearing on the logic of the larger system.
1. There is no abstraction layer in which to place business logic.
1. The business logic emerges out of the flow of logic, rather than from some modular abstraction.

Most PHP programs that I have looked at fall in to this category.  Only as the project size grows past a certain complexity does one see PHP projects with more explicit abstractions around the persistence layer.  The reason this is done is because at a certain size in a project a programmer can no longer track all lines of logic in their head and continue to develop the application efficiently.

Data-driven Design
This addition of an abstraction layer around the persistence engine that is used for managing business logic is what has been called data-driven design.  This is obviously not a new idea.  In fact one of the points of pride for me in using Ruby on Rails is it’s particular grace in working in this manner.

Data-driven design aims to drive the logic and output of the application directly from the persistence engine; the data source.  The convenient side-effect of this design approach is the adjustment of most of the business rules and how the application behaves is matter of changing records in a database.

PHP to Ruby on Rails
Ruby on Rails employs an MVC architecture.  This architecture is designed to support data-driven design by providing a powerful abstraction layer for the persistence engine (the model).  Rails has a particular sweet spot for social web applications for this reason.  The framework excels in user generated content, as this is a form of data-driven design.

Developers moving from PHP to Rails often miss this shift in thinking when they make the jump.  The result is code that is primarily located either in the controller or the view layers, since this is analogous to PHP’s logic-driven model.  The end result is very heavy controllers with big functions that do a bunch of logic on database records, and then render it out to the user.  In this paradigm the Rails models are only used to retrieve the record and nothing else.

When Rails moved from solely MVC to a resource-based approach a few members of the community had some negative feedback.  Some people feel like the resource concept makes development in Rails more complicated.  What I’ve seen in practice however leads me to believe that the real difficulty with the resource based approach is that it forces you to make the jump from logic-driven to data-driven.  PHP style development becomes contradictory in a resource based rails application.  Instead you have to think about the “resource”, the entity that will affect and be affected, and build your application around that.