Thursday, October 24, 2013

Magical path/url helpers

Magical path/url helpers

Where do those magical path/url helpers pull the values together? I found this interesting.

b /Users/davidvezzani/.rvm/gems/ruby-1.9.3-p194@rails328/gems/actionpack-4.0.0/lib/action_dispatch/routing/route_set.rb:222


Convert Haml to ERB

There are plenty of tools for converting from ERB to HAML. I'm not ready to drink the kool aid, even though HAML has been around forever and there seems to be a great following.

script/plugin install

hamls = Dir["app/views/**/*.haml"] - ['app/views/layouts/screen.html.haml'];
hamls.each do |haml| 
  puts haml
  erb = haml.sub(/\.haml$/, '.erb'), 'w') do |file| 
    file.write Haml2Erb.convert( 

Friday, October 18, 2013

Automatically generate ERB

There are plenty of hits on how you can tell Rails to automatically generate HAML, but I still love using ERB. Taking a guess with the pattern for automatically generating HAML, it appears I got it right.

Somehow, Comfortable Mexican Sofa buries the setting for automatically generating HAML in some dark corner of it's codebase. Setting the preference in config/application.rb takes precedence, thank goodness.

    config.generators do |g|
       # g.template_engine :haml
       g.template_engine :erb

Monday, July 1, 2013

The Ruby Community: with open arms

New, budding software developers are always coming to the scene.  Even older developers like trying out new languages because, well, programming is fun!

My brother wanted to try something a little new.  To my knowledge, he had never written a lick of code in his life.  So one day he asks me about what I do.  I introduce him to Ruby and to Rails since my career has mostly encompassed web application and service development.

I love teaching what I know to people who are ready to learn.  Admittedly, I'm not the best teacher, but I do get a kick out of seeing the twinkle of understanding in a student's eye and the 'aha' look on his face.

What drew me to the Ruby programming language?  It was fun.  Yes, that's it -- for too long I had spent time coding and debugging with a compiled programming language.  Waiting oodles of collective time for the code to compile just to run my tests was getting old.  Perl was cool, but oh so cryptic.  I often times felt so lost admit the many versions of documentation and different flavors of Perl available.

Ruby provides built-in methods to introspect class and instance variables, what classes and modules are in the inheritance path, what constants are available, and many other pieces of information that can help me answer questions without having to go Google them and get lost in the myriad of possible answers.  Many times the question is, "What methods are available for my object?"  No problem.

my_object_instance.methods.grep /find/

And now I get a much smaller list that can tell me what methods I might be interested in.  Then I go Google for more details.  Isn't that beautifully elegant?  Try doing that with Java.  Not nearly as fun and liberating.

Yes, Ruby is an interpreted language.  Yes, it will be slower than a compiled language, but no so much that it still doesn't have a useful purpose.  As with any software development and programming language, the time it takes to develop code translates into dollars invested to both write the code and maintain it.  If I can get Ruby code whipped out and tested in a fraction of the time it takes to do so in a compiled language, there might be enough money to spend on perhaps a little more expensive hardware that can compensate for the slightly slower Ruby-based applications -- and still come out more cost effective.

Then there is the culture.  The Ruby community, like many others, seems to embrace anyone who wants to learn.  My brother was not disappointed when he posted his questions to a Ruby forum.  I suspect they are so excited to teach because of how much they love working with Ruby themselves.  I guess that shouldn't be any surprise because Ruby is fun.

Happy coding!

Wednesday, June 26, 2013

Creating XML using Ruby's Builder class

Ruby provides a very simple way to generate XML.  It works well, especially when dumping values from your models in a specific manner that doesn't align with how ActiveRecord generates xml.
For reading in XML and inserting or updating nodes, you will need to use another library like Nokogiri.

Tuesday, June 25, 2013

Aggregate functions and your ActiveRecord app

When trying to calculate the sum across all database model records for a given attribute, there are a few things I suggest considering when designing your code:
  1. understand SQL aggregate methods; leverage the database
  2. understand ActiveRecord's convenience methods for executing queries with aggregate methods
  3. when all else fails, use Ruby to collect data

using SQL to get the sum

Here are some references that should provide an introduction to SQL aggregate functions and how they are used:

Home → Documentation → Manuals → PostgreSQL 8.2

Tech on the net


using ActiveRecord to perform the sum

Once you have an understanding of how SQL is used to perform the sum, you can use ActiveRecord as a convenience tool to get what you want.

Ruby on Rails v4.0.0
Module ActiveRecord::Calculations


sum column for all records in a given table


isolate the records of interest; sum only the returned records

Ucpathpersonjob.where("emplrecord < 7000").sum(:emplrecord)

Although it is not as efficient when compared with how the database performs aggregate functions like sum(), it can be done with Ruby.

using Ruby to perform the sum

Provide a single block parameter for each item in the array.  Also, you need to store the sum value outside of your #each block to sum up the values.

I am assuming you wish to sum up the :price attribute of your model.  The example should explain how you access the model attribute as you also asked.
sum_value = 0
Expense.all.each do |record|
  sum_value = sum_value + record.price

a more concise approach

  • a represents the compilation for the entire process
  • b is each item in the array

with plain integers

1 + 2 + 3 + 4 + 5 + 6 + 67 + 7 + 8 + 8 + 9 + 90 + 23
 => 233

using #inject

[1, 2, 3, 4, 5, 6, 67, 7, 8, 8, 9, 90, 23].inject(0){|a,b| b += a}
 => 233

applying to your model

Expense.all.inject(0){|expense, sum| sum += expense.price}

For more info on Array#inject see

Friday, January 16, 2009

RSpec not unstubbing?

I've been really struggling lately with a testing situation. I get different results for a couple of tests when I run the following commands:

spec spec/models/document.rb
rake spec

I verified that in both tests, the Document model was including the same modules and that I was using the same RSpec source to execute the tests (before rake spec was running code from my plugins directory and spec spec/... was running code from the gem repository. I have configured both to be using the same source code now.

Research on the Internet has revealed that others have also found that RSpec doesn't always seem to unstub methods as it should. Every 'it' block should stub out methods (using before do's) and unstub methods so that unit tests are not order dependent.

I am trying to test that when save! is called, certain callback methods are invoked given certain circumstances. Running rake spec shows 2 failures while executing the file with the failed tests alone passes. It seems that something is being set in another test that is persisting over the course of many tests. If spec spec/... is fed all the model tests, the two test cases in question fail as in the rake spec execution. There is a -R option that can be passed to spec to reverse the order of the tests. When that option is taken, all the model tests pass. Another thing that I've found to be true is that the order of the tests is random. I'm not sure what exactly determines the randomness, but small changes to an existing file or the addition of new files seems to change the RSpec test execution order. Bottom line, currently, you cannot depend on the RSpec tests being run in any given order.

When I finally get down to the bottom of things, I will run tests with -R and without to make sure that I have eliminated my problem.

Currently, I've defined blocks for all possible callback methods. I want to see where the callback gets short-circuited, hoping to get some more insight into what's happening.