“The fallacy in traditional “waterfall” development has been to view software coding as production, and to apply manufacturing principles to it. Coding is more of a fine-grained design activity than a production activity – we are creating the first instance of a product.” - Agile 101: Beginning the Agile Journey for Software Design in Healthcare - 2012

I started reading this paper and the quote above really struck me.  There is an art to writing good code and many developers refer to what we do as a craft.  Our product is not stamped out like a car door.  It is sculpted like the clay models used to perfect the final design of the car.

Design by nature is iterative, fails quickly and requires conversations with the customer.  Marketing and design firms don’t go for months without talking to their customer.  A design is sketched out and a conversation is had with the customer to refine and adjust it to meet their needs and timeframe.  Software is no different.  

A production line assumes the input is perfect and checks the output is identical to the input.  Design takes an idea, describes it on paper, and creates something new from those ideas.  Agile treats software as design, as it should be.

EDIT: When I find the place with the quote above I will post it.  Another good quote:

“Customer Bill of Rights As the customer, you have the right to:

• An overall plan, to know what can be accomplished, when, and at what cost; • Get the most possible value out of every programming week;
• See progress in a running system, proven to work by passing repeatable tests that you specify;
• Change your mind, to substitute functionality, and to change priorities without paying exorbitant costs;
• Be informed of schedule changes, in time to choose how to reduce scope to restore the original date, even cancel at any time and be left with a useful working system reflecting investment to date.

Developer Bill of Rights As the Developer, you have the right to:

• Know what is needed, with clear declarations of priority;
• Produce quality work at all times;
• Ask for and receive help from peers, superiors, and customers;
• Make and update your own estimates;
• Accept your responsibilities instead of having them assigned to you” 

The bill of rights originally came from here: http://practicalagility.blogspot.com/2011/06/worth-repeating-xp-bills-of-rights.html

Garbage collection in such a high level language is obscured from the language itself so most of the time there is no need to write a deconstructor.  Still, on the off chance you do, here is some information on its use.  Ruby deconstructors are set using ObjectSpace.define_finalizer method.  It takes two params, first is the object to add the finalizer to, and the second is a lambda.  The lambda gets the object id passed in.

Caution must be taken to not reference the object being garbage collected.  In doing so you will create a reference to it that is in scope and stop garbage collection.  Defining variables prior to setting the deconstructor and using a lambda will allow you do escape if needed with return.  If you need some extra logic and want to call a method, use a class method and pass in the variables rather than calling the object’s getter methods.

def initialze(args*)
  file = args[:file]
  define_finalizer(self, lambda{|id| file.respond_to?(:unlink) ? file.unlink : File.unlink(file) })
end

This is somewhat similar to what I used to cleanup files created for the instance except that I created the finalizers after initialize.  And yes, you can have multiple and each will get called.  They are basically callbacks.

I use InheritedResources a fair bit in apps that I build simply because it makes it quick to get up and running.  It allows for faster setup because you don’t have to write anything for the typical CRUD.  I particularly find it useful with JSON, until yesterday.

I rely on the server to build the HTML and return both the object and html in the json (when needed).  In doing this I added the line

success.json { render :json => {:object => resource, :html => render_to_string(:partial => 'resources/resource_row')} }

The exception occurs in trying to render the partial.  There is not resource_row.json, just html.  The problem I found was that it was swallowing the exception and returning the default response which in json case, was just the resource standard to_json

So, hopefully I can patch it so that it won’t swallow the exception and leave others chasing the issue.  In the meantime, if you have something standard coming back even though you have overode the default, check if it is throwing an exception.

(InheritedResources can be found here: https://github.com/josevalim/inherited_resources/ and I will be writing a patch for this issue shortly)

The amount of times I have had to tell people you can’t count on SQL to give things back in the same order that you put them in is probably in the hundreds.  The irony is anytime we use .first for a AR we aren’t using any specific order, yet .last we are.  One might assume they should be ordered the same but the only way to get the last without order is to load it all and pop the last record off the results.  Really not feasible.

The question is, as they “appear” to be the inverse of each other, should they work the same way or should we just accept this limitation.  I can hear arguments both ways, but with rails everything is convention over configuration so I say yes, enforce the default order on first just as we do on last.

irb(main):005:0> User.first.id
  User Load (2.1ms)  SELECT "users".* FROM "users" LIMIT 1
=> 6
irb(main):006:0> User.last.id
  User Load (3.5ms)  SELECT "users".* FROM "users" ORDER BY "users"."id" DESC LIMIT 1
=> 6
irb(main):007:0> User.count
   (27.0ms)  SELECT COUNT(*) FROM "users" 
=> 2

I have long tried to figure out how to make AR make the SQL I have in my head a reality. The problem is most of the time I end up writing it myself in a finder or some method that doesn’t allow for nice chaining that I so dearly love of AR. As with most things, if I can easily find it, I won’t post it. But this took a lot of digging, though this is my use, the do block I found here http://stackoverflow.com/questions/5856838/scope-with-join-on-has-many-through-association.

  
class Assignment
  belongs_to :enrollment
  belongs_to :user
  belongs_to :role
end
  

has_many :users, :through => :assignments do
  def admins
    joins(:roles).where('roles.name = ?', Role::ADMIN)
  end
end

The following then allows us to do assignment.users.admins will select all the users that belong to an assignment and has the role of Role::ADMIN

It still feels a little dirty to me, but best I got for now and it does produce the sql (with a little extra) that I want

We have all had those clients that log defects with details that are less than helpful.  Whether it is not enough details or the details are vague and non specific, it doesn’t matter.  Our job is made impossible until we can drag the information out that can get us looking in the right direction.  

Using metaphors has proven a most useful tool.  Anytime you can relate one subject matter to another that has meaning to the audience the light bulbs seem to go off.  Recently the following metaphor has become useful:

A defect is like a mugger and the developer is the police trying to find the mugger.  You would want to give the police the as much useful and specific information as possible.  Obviously the smell of the muggers breath won’t help them find the mugger but the best possible description will yield the best possible results.

Many times I have accused the business I work for of using scrum but.  Scrum but is the practice of trying to use scrum, but making excuses not to fully go agile.  The excuse always is someone or some department, doesn’t understand and is “old school.”  I am not sure I will ever understand why that is thought of as a valid excuse, but I digress.

We also have external customers that don’t understand agile and are stuck in a spec and wireframe world.  So, as to appease the paying customers, a version of scrum but has been created.  While it still feels dirty, it seems like the best option we have as people that pay the bills rule the roost.  

Wireframes and specs are all drawn up and written as normal.  Instead of the standard vague and implied details we use the verbiage you would normally have in a story.  For example, a wireframe with button A would have the notation similar to “As a user, when I press button A, A user with details in form B will be created”

We have struggled to get the business to help customers understand why agile is beneficial to them so we have to slow walk them.  Anyone else have experience converting “old school” clients to agile practices, please let me know what you did.

There is a lot of momentum with ruby, particularly in the web arena.  Ruby on Rails has provided a killer framework that allows for rapid development.  There is a lot of info out there but finding a class can be hard.

Ask any rubyist and you will get a list of books probably starting with Pick Axe as good starting points.  The only problem is not everyone learns the same way.  Some can read, some can do, some can listen.

This is where the guys at Inspire9 have stepped up.  The have introduced a class aimed at giving people a taste of Ruby and Rails.  Run across 3 nights the workshop is aimed at people with HTML/CSS skills looking to take the next step in developing web apps.

And for those of us with the little ones I found a awesome little site for kids to learn ruby (http://kidsruby.com/) 

The current organization I work for has a fairly small team of developers that are geographically diverse (not to mention the time difference.)  We have been working on ways to up the quality of work and make the team more cross functional and less dependent on a single person for any particular area.  We add a fourth column to our board and use the headings: Do, Doing Tests, Doing Code, Done.

As normal everyone pulls from Do into Doing Tests. Once the tests are written the card can be pulled by anyone besides the person that wrote the tests, into Doing Code.

As this approach is just an amalgamation of XP and Kanban, lets call it XK.  Once we start this (next iteration) I will post updates on the good and bad from each retro and any updates we make for the following iteration.

I have been pondering whether or not helpers are actually needed or of any value.  I have been reading a couple post about using domain driven design for Ruby on Rails applications over at http://rubysource.com/ and I been thinking does Rails need helpers.

I have gone over a few of the helpers that are in our codebase and so far have been able to refactor them out into modules or “concerns.”  I am not sure if it will be true in all cases but curious as to if there is any value of helpers vs modules/concerns.

I suspect some of the issue is that we assume too much with helpers.  When we place a method in a helper we are stating that it will only be needed in views.  In many cases this isn’t true, especially if you render html, xml and json depending on the call (though I guess you could have a view for json rather than to_json.)

So more thought and real life situations seem to be needed before I can commit to concerns over helpers.