ruby n00by

"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" 

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

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.

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.

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

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:

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"

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.

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.

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.)

I had an infinite loop occurring in an application due to a merging of hashes.  Given the following:

1.9.2p290 :003 > model.update_attributes(:first_name => 'a', 'first_name' => 'b') 1.9.2p290 :007 > model.first_name => "a" 1.9.2p290 :009 > model.update_attributes('first_name' => '2', :first_name => '1') 1.9.2p290 :011 > model.first_name => "1"

We would try to merge a Hash that used quoted keys into a Hash with symbols as keys and then update the model.  My suggestion is to always use HashWithIndifferentAccess or at least .symobolize_keys before merging any hash.

TDD is great for building new application and features but sometime overlooked for defect and debugging.  If you are having to work hard to debug a defect then a red flag should be going up.  If we have followed all our normal best practices we wouldn't have to look to hard to find the issue.  Most cases the single responsibility principle will take care of tricky troubleshooting.  

The best thing we can do if we find something is hard to debug is to write tests to cover the steps we are following.  This will help us a) recreate the defect and b) flush out any code smells in a hurry.

If you don't already know, the schwartzian transformation is a way of sorting lists/arrays/hashes that is optimized when an expensive function has to be called in order to get the value needed for comparison.  Normal methods of <=> would need to call the expensive operation twice.  Schwartzian creates a list of comparison values, values first, then compares, so that we only run the operation once.

Between CI, development and production imports, google got a bit pissy at our geocoding.  Add to that the extra time it takes it was obvious that we really needed to look at stubbing or using HTTP request mocking/stubbing. Luckily factory_girl provides hooks to allow you to stub each model

factory :suburb do sequence(:name) {|n| "suburb#{n}" } sequence(:postcode) {|n| 3000 + n.to_i } state "victoria" after_build { |suburb| suburb.stub!( :geocode ).and_return( [1,1] ) } after_create { |suburb| suburb.stub!( :geocode ).and_return( [1,1] ) } end

I released the first iteration of the Archive 2s gem.  This gem will allow you to archive a meaningful field of your ActiveRecord model.  There are a few gems out there that will archive/soft delete an entire record but sometime you only need one piece.  It has a simple interface and will instantiate a readonly version of the original class although it will only contain the id.  This allows you to use relationships even on archived models.  We are using this for events/stats tracking where the item is no longer available on the website, but we still need historical information regarding it and have some meaningful display value (hence Archive 2s).

Check it out on github or rubygems.org:

https://github.com/smashtank/archive_2s

Last time we went over the benefits of a single code base and how we can use configuration options to tune an app.  While this can seem like a great way to tweak an app to each installation, it does have short comings and limitations.  For example, you configuration file could become very unwieldily try to change the whole look and feel of a site or internationalize an app.

To overcome this we can setup a custom view path that we can put customized views in.  Our app has the ability to run multiple sites off the same app.  We used liquid markup originally and found that it became a maintenance nightmare.  Our solution was to use the combination of a configuration option to turn on the option and set the base path for the views.  A before_filter in the controllers then would prepend the view path with the path to the websites custom views. (Big thank you to craig ambrose for the refactor and extracting the template logic to a model)

The other issue was that being international, countries called (and I hate myself for saying this) "things" by different names even though they both speak the same language.  Rails makes this easy with the i18n locales.  We used a locale file to rename models and attributes.  This is something that is built into rails and easy to take advantage of but might not be considered as both sites are in english.  Rather than having to define everything we set our locale (from the config) and then map a fallback to en for it.   This could also be done in a before filter so user can set a locale.

#set i8n default I18n.locale = AppConfig['app_config']['default_locale'] #lets not have to define everything I18n.backend.class.send(:include, I18n::Backend::Fallbacks) I18n.fallbacks.map(AppConfig['app_config']['default_locale'] => 'en')

This got us 90% of the way.  The next issue was trying to overcome the difference in require business logic.  One deployment requires controller to redirect one place and another somewhere else.  One might need an extra column for a model or relationship.  It became increasing clear that if we didn't change the models or controllers they were going to be filled with case statements 100's of lines long.  This would defeat the entire purpose of using a single codebase.  What we needed was a way to monkey patch the application.  

We decided the use of gems made the most sense.  Rails 3 would allow the use of a engine but unfortunately, we are still using 2.3.  The Rails initialization process loads gems well in advance of the app, so if you define the classes in the gem, your app will override them, not vice versa.  We had to come up with a way to force rails to load the gem (but not all gems) after the app.  Todo this we used the after_initialize configuration hook.

#init.rb config.after_initialize do Dir.glob(File.join(File.dirname(__FILE__),'..','lib', 'app','**','*.rb')).each { |f| require f } Dir.glob(File.join(File.dirname(__FILE__),'..','lib', 'sunspot','**','*.rb')).each { |f| require f } end

The only problem was how rails reloads the application in development mode for every request.  This meant that only the first request ever made it through our customization gem.  For this problem we monkey patch rails and add a load directive in the Dispatcher method "reload_application".

#init.rb if config.cache_classes == false require 'dispatcher' class << Dispatcher require 'action_controller/routing/route' def reload_application # Run prepare callbacks before every request in development mode run_prepare_callbacks ActionController::Routing::Routes.reload Dir.glob(File.join(File.dirname(__FILE__),'..','lib', 'app','**','*.rb')).each { |f| load f } end end end

The initializer of your gem can also do things to the view paths and action mailer paths if you like but this would be on an app level, where as with a filter in the controller it is per request.

And with that, we were done.  Our gem will reload anything we override in the app after the app with each request in development mode and load after the app is initialized originally.