Bug of the Day: nil.include error with create_time_zone_conversion_attribute
This was an 'orrible bug. Tired and midway through writing up a Ruby on Rails tutorial on setting up emailing with AR Mailer and a little postfix configuration I wasn't exactly in the mood for a bizzarely cryptic issue to waste my time. Enter the mysterious create_time_zone_conversion_attribute? method in all it's glory. Basically you will get this error if you set ...
config.cache_classes = false
... wherever it is set in your environment files (in my case config/development.rb) but the error goes away if you change it to ...
config.cache_classes = true
... bloody daft! Here is the bug on lighthouse. Arrgh!!!!
Anyway here is the full stack trace which may help someone googling to pick up this page
NoMethodError in UsersController#create
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.include?
/usr/lib/ruby/gems/1.8/gems/activerecord-2.2.2/lib/active_record/attribute_methods.rb:142:in `create_time_zone_conversion_attribute?'
/usr/lib/ruby/gems/1.8/gems/activerecord-2.2.2/lib/active_record/attribute_methods.rb:75:in `define_attribute_methods'
/usr/lib/ruby/gems/1.8/gems/activerecord-2.2.2/lib/active_record/attribute_methods.rb:71:in `each'
/usr/lib/ruby/gems/1.8/gems/activerecord-2.2.2/lib/active_record/attribute_methods.rb:71:in `define_attribute_methods'
/usr/lib/ruby/gems/1.8/gems/activerecord-2.2.2/lib/active_record/attribute_methods.rb:350:in `respond_to?'
/usr/lib/ruby/gems/1.8/gems/activerecord-2.2.2/lib/active_record/base.rb:2587:in `attributes='
/usr/lib/ruby/gems/1.8/gems/activerecord-2.2.2/lib/active_record/base.rb:2583:in `each'
/usr/lib/ruby/gems/1.8/gems/activerecord-2.2.2/lib/active_record/base.rb:2583:in `attributes='
/usr/lib/ruby/gems/1.8/gems/activerecord-2.2.2/lib/active_record/base.rb:2283:in `initialize'
/usr/lib/ruby/gems/1.8/gems/activerecord-2.2.2/lib/active_record/base.rb:691:in `new'
/usr/lib/ruby/gems/1.8/gems/activerecord-2.2.2/lib/active_record/base.rb:691:in `create'
vendor/gems/ar_mailer-1.3.1/lib/action_mailer/ar_mailer.rb:92:in `perform_delivery_activerecord'
vendor/gems/ar_mailer-1.3.1/lib/action_mailer/ar_mailer.rb:91:in `each'
vendor/gems/ar_mailer-1.3.1/lib/action_mailer/ar_mailer.rb:91:in `perform_delivery_activerecord'
/usr/lib/ruby/gems/1.8/gems/actionmailer-2.2.2/lib/action_mailer/base.rb:526:in `__send__'
/usr/lib/ruby/gems/1.8/gems/actionmailer-2.2.2/lib/action_mailer/base.rb:526:in `deliver!'
/usr/lib/ruby/gems/1.8/gems/actionmailer-2.2.2/lib/action_mailer/base.rb:392:in `method_missing'
app/controllers/users_controller.rb:47:in `create'
app/controllers/users_controller.rb:45:in `create'
Happy hackin'
Hackin on Gruff – A Brief Overview of Gem Development with Ruby
Ah such is the life. Chillin' in Havana (the bar, unfortunately not the city), hackin' away on Gruff of all things. This is the my first attempt at development on a gem and it has to be said is surprisingly satisfying. Getting gems to build is a doddle. Here's a great link that shows how it's done in moments. Also a handy thing to know is how to suck the code out of your OS's gems directory and unpack them to under your app's vendor/gems directory - all courtesy of VendorEverything. You can create the vendor/gems directory manually if it doesn't already exist.
When developing on the gem, I found that the best strategy was to clone down the gem source code from GitHub or Rubyforge to under the vendor/gems directory of my application rather than using the OS package unpacking technique of Vendor Everything (though they do it more for deployment than development - which is a great idea). That way I could easily stay on top of the latest source code using git. Actually, to make things even cleaner I downloaded the Gruff gem source code to a different directory totally unrelated to my sample project and then symlinked to it from under vendor/gems of my app. Clean as an (unused) whistle!
And with Gem, Git and GitHub behind me life was trouble free. Now back to my search for great Cuban cigars...
Did Vista contribute to Dell’s Limerick closure?
Chris Mellor's recent article on Channelregister.co.uk concerning Dell's Limerick manufacturing exodus covered various reasons for Dell's decision. Many of these break no new ground - it is simply the economics of the situation Dell finds itself in. But there were some subtleties that he unearthed that haven't been stated by many commentators. Firstly, had there been sufficient demand for the notebooks that Dell were producing, then it would have taken both the Irish and Polish plants to satisfy that demand. The downturn clearly put a dramatic dent in the purchasing of notebooks but even before that Dell had been overtaken by HP as the world's biggest supplier; and both Dell and HP were suffering at the hands of Apple. In June 2008, Jordan Golson reported in The Industry Standard that at Apple notebook sales were up 61% since Q1 '07. It seems that the Leopards and Tigers that populate Steve Jobs virtual zoo of operating systems were propelling Macbook sales to new heights while Vista was dragging Windows Notebook sales to down to Davy Jones locker.
Meanwhile a completely new category of computers arrived - Netbooks - small low cost devices, pioneered by Asus and their initial range of Linux-based machines. These began to cut into the low end of the laptop sales and proved to be a disruptive force in the market. After years where people were paying extra money for small form factor laptops, Asus came along and made the cost of small portables proportional to their size, in a game changing move that would haunt the mainstream laptop manufacturers as time wore on. Things got so bad for Vista's adoption figures that Microsoft had to begin counting Windows XP sales as Vista sales via their controversial 'downgrade licence' program that allowed the likes of Dell to continue offering XP as an operating system on the machines they sold and allowed Microsoft to claim that another copy of Vista was now in circulation. But it wasn't the kind of thing that marketing dreams are made of. Even in August of 2008 research suggested that more than one in three new PCs were still being downgraded to from Vista to XP.
So we set off into 2009 with more battles looming in the desktop, notebook, netbook and server markets. And who knows, maybe a completely new computing category will yet again be invented this year. Apple, Windows and Linux continue to vie for the position as the OS supreme. And with Internet Explorer's market share falling to 68% from near dominance a few years ago, gaps are still appearing in the browser market that will encourage Mozilla, Google and Apple to continue to innovate with Firefox, Chrome and Safari.
Windows 7 is somewhere on the horizon. It will come too late for Dell and its Limerick workers - will it come too late for Microsoft?
Uninstalling Gems from ~/.gem in your Home Directory
"It's installed Gem but not as we know it"
-- Bones, if he was a Ruby Developer --
Unfortunately, a careless keystroke can leave gems in lots of unusual places. About five minutes ago, that fate befell me as I ended up with gems under my home directory at ~/.gems. Not what I was expecting. To make matters worse when I tried to remove them I had no success - possibly there were PATH or GEM_PATH issues
Fortunately, Google was to the rescue before you could say 'gem is no apt-get', with the command...
gem uninstall ruby-debug-ide --install-dir $HOME/.gem/ruby/1.8
... where in this case ruby-debug-ide is the misplaced gem in question.
Thanks to this thread for the solution.