Earlier this year at Rubyfuza 2013 I had the privilege to share with the audience how, at ValuationUP, we reuse our frontend JavaScript on the server side using The Ruby Racer, allowing us to push the SOLID principles to the max by crossing the language barrier using DI & IoC across the language barriers.

The video and the slides are below for your enjoyment.

The sample code lives at kennethkalmer/rubyfuza-2013, and the working demo is up on Heroku.

In the presentation I showed a 34 page PDF, and mentioned that the master branch was over 44 pages. As I’m typing this, we’re at 60+ pages and it shows no sign of stopping. Our clients are really loving the PDF output, and we’re getting better at crafting it for them.

If you’re an entrepreneur please check out ValuationUP, or pass it along to your entrepreneurial friends. We can really help a privately held business unpack what is going on in their financials, highlight dangers, and point out the healthy parts.

I’m just going to summarize here, you can find more information in the repo and on the wiki.

0.1.0 – Cleaned up Hoptoad support and added support for exception mails.

0.2.0 – Added a Log strategy for logging exceptions to the specified logger instance.

0.3.0 – Added support for logging all exceptions to a backtrace log when a Ruby application terminates abnormally.

Worth noting is the backtrace support in 0.3.0, which to me has been a super reliable feature of daemon-kit. When your program dies spontaneously (or from an unhandled exception), you’re usually left to wonder what just happened. With the new Backtrace class you will get the insight you require on a per-process basis in their own logs. Check out the Backtrace page on the wiki for more information.

I think for the time being I’m done with Safely, unless some bugs pop in. I’m contemplating a Rack middleware as well, but I fear for duplicating the efforts of others. If you’d like to have a Safely middleware, file an issue on Github (or vote it up if someone beat you to it).

I’m looking forward to ripping out this functionality from daemon-kit and bundling in Safely to do the dirty work. It is much better tested than daemon-kit’s implementation and feels cleaner overall.

safely do
  something_dangerous!
end

and your daemon would not die if something blew up. Instead the daemon would happily log the error to file (and possibly Hoptoad) and carry on working.

As part of resurrecting daemon-kit, I’ve extracted this functionality into a new gem called “safely“, available now on Github and Rubygems. At the moment it just supports Hoptoad via the Toadhopper gem, but soon will offer more!

I’ll expand on it in the coming days, and then tend to the daemon-kit fork queue while replacing the daemon-kit version with safely.

First off I’d like to thank a few people who have quietly and vocally contributed to or promoted daemon-kit. In no particular order, thanks goes to:

• Josh Owens (@joshowens) for actively testing bug fixes and promoting the project
• Mike Perham (@mperham) for actively reporting bugs, providing patches and promoting the project
• I’ve pulled in patches from the forks of Michael Hutchinson, Milan Novota, Joey Geiger, and John Merrels
• Greg Campbell reported an issue with the AMQP generated daemons only hours after pushing 0.1.8 to gemcutter

The two biggest changes for me has been converting all the generators to use Thor, and using Bundler in the generated daemons. Both of these projects have received some flack, but they both continue to serve me very well and I’m sure they’ll serve daemon-kit well.

The logger got some minor updates, to be more compatible with the standard Ruby logger class. A brand new XMPP generator is included, and it uses Blather for some awesome evented-goodness. Argument handling got fixed up, email exceptions got removed from the project (I might consider implementing them after overhauling the error reporting features of dk). Hoptoad error reporting got upgraded to the use the newer API. The generated rake tasks are more forgiving when rspec/cucumber or other gems are missing. The cron daemon got some love, allowing easier exception logging/notification for when scheduled tasks fail.

I’ll continue chipping away at the project, tidying up loose ends as they are reported, and start developing a proper test suite for everything.

Over the long term I’m hoping to reach the following goals:

• Always running the eventmachine reactor (think node.rb)
• Support for more modular daemons, including ‘single-file’ daemons
• Support for daemons inside Rails projects

Some things will probably get thrown out, like generating configs for god & monit. The more I use chef, the more I realize that those responsibilities lie with the infrastructure management (or devops), and not within the project itself. I’m aware this might cause an upset, however I firmly believe that a lighter and smaller daemon-kit will serve the greater community better.

Thanks for making daemon-kit the number 1 daemonizing project. Please share the love and send feedback, and more importantly use Github issues to log issues, feedback, and wishes.

John P Wood discussed some issues they faced with will_paginate and couchrest during the migration of TextMe to CouchDB, but l left out some code to work with. Couchrest itself had some pagination support that got pulled to some extent… This left me wanting, and wondering, since it was my turn to walk down this path.

CouchDB is a different beast, its aggressive use of indexes means that occasionally you loose some functionality that you’ve been accustomed to having in other persistence mechanisms, like the number of rows matching a query. Jan Lenhardt explains on the CouchDB issue tracker in more detail, but it boils down that you need a reduce function to calculate the number of rows. Sounds difficult? Not at all!

In my case I had a collection of announcements to deal with, and the announcement archives is a paginating collection of documents. Standard will_paginate stuff, nothing special.

Those reading in a reader would want to click through to the post to view the embedded gists further down, or view them directly at Github.

Below is a condensed version of the model from our paginating system:

I’ve included only one view and a corresponding class method, as it is enough to proof the principle. Lets dissect.

The map/reduce functions are extremely simplistic, they simply emit the announcer and the date the announcement was created. This allows for easy scoping and ordering of the announcements. The reduce simply counts our returned records. The magic is in the class method that sets up our WillPaginate::Collection with data from our views.

Line 30 creates a new WillPaginate::Collection instance, passing it the page number and total per page as parameters, it gives us back a pager that we can manipulate.

Lines 31 through 38 uses couchrest’s pagination support to pull out data from our view. The most important things to note here are that the page and per_page options are sent to the paginator and we skip the reduce step.

Once we have our records loaded, we ‘replace’  the pager’s collection with our results from our view (line 40).

The final step is to determine the total number of documents available to us, and for this we need the reduce function. On line 42 we call the same view, with the same arguments, except for requiring the reduce step to happen. We use the results (lines 43 to 47) to inform the pager (will_paginate’s pager) how many rows there are in total.

The controller and the views might look something like this:

It worked, and it shows that we don’t loose as much as we might think when moving away from ActiveRecord and the ton of plugins surrounding it.

Thanks to John for documenting the migration of TextMe, just knowing that it was possible to combine couchrest & will_paginate gave me the push I needed to figure this out.

Disclaimer: This code is extracted “as is” from a real life system and might contain idioms/phrases, and even code, that doesn’t make 100% when viewed in a gist. Please wear your thinking cap when applying this lesson to your own projects.

I’ve been lurking in the CouchDB world for quite some time and have spent a lot of time wrestling with how to loosely relate documents in CouchDB to each other. A big part of learning to use CouchDB successfully is to break away from the shackles of the relational world. Relationships between documents is one such a shackle that seems hard to break.

It is unavoidable that data has to be correlated, and I wanted to rethink how to do it. After plenty of discussions in #ruote with John Mettraux we came up with a model based on how the web works. Since CouchDB is “off the web”, the approach feels quite fitting to me and hopefully to you too.

First some insight into my thinking at this stage.

The web has been successful in loosely expressing relationships between documents. Take two examples:

and

For those of you reading this through a reader, click through to see the gist’s above.

Simple as it seems, in both cases we have a document that is somehow related to the page. The nature of the relationship is expressed via the rel attribute, and the target specified via the href attribute. This got me thinking. Since CouchDB is made off the web, can’t these same principles be applied?

Yes, they can. And here is how:

Currently you might be tempted to express relationships link this in your JSON:

Where changing it to this holds the key:

If anything this format, albeit more verbose, expresses the relationships more clearly and in a format that is web friendly. We’ve broken the shackles of relational thinking.

Enter Correlate

Correlate is an experiment in this line of thinking. It is a mixin for CouchRest’s extended documents that allows you to express these relationships:

Correlate generates getter and setter methods for working with your relationships and lot more (review the README). It also includes a compatibility layer for ActiveRecord to help when you’re migrating from ActiveRecord to CouchRest or building a system on CouchDB that needs to access legacy data via ActiveRecord.

The project is still pretty much a moving target, but I’d love to hear how others address the same issues. Correlate does a great job at maintaining relationship information in a web friendly manner and providing you with some convenience around the verbose data structure. Correlate also has a lot of room for improvement, but that will hopefully change over the coming days as I continue integrating it deeply into my existing projects.

Please fork the project on github and join the experiment with me.

Having screwed up my kernel configs for my VirtualBox Gentoo image, I needed a serial console to catch the boot messages scrolling past in order to see if all the required hardware was being loaded by the kernel. I’ve never done this on a physical machine before but I am converted now and will acquire a USB to serial port converter in the near future…

Using this article as a base you need to do the following:

1. Enable serial ports for your virtual machine
2. Select “Host Pipe”
3. Enter /tmp/vboxconsole as the filename
4. Use netcat to read the console: nc -U /tmp/vboxconsole

When booting you need to amend your grub boot line to have the following at the end:

console=ttyS0,38400

Making it look something like this:

kernel=/kernel-2.6.30-r6 root=/dev/sda3 console=ttyS0,38400

Proceed to boot and look at netcat to see the entire boot output scroll past without disappearing into thin air when the kernel panics.

Man, I love virtualization. I tested this on Mac OS X 10.5 with VirtualBox 3.0.6, but it should work on any *nix platform. Some more Gentoo serial console madness can be found on the old Gentoo Wiki.

The worst part of the process was getting the specs to run with rake spec. Using ./script/spec it worked on individual specs and on all the specs worked as advertised, but rake spec didn’t do anything.

After a lot of time spent in the debugger I wasn’t any wiser. The only difference was that in Ruby 1.8 the example groups were fully loaded, and in Ruby 1.9 they were empty. I gave up and started searching relentlessly for some information on the issue. I couldn’t find anything, until I found an indirect solution on the rspec wiki. It seems that if you have any versions of the test-unit gem after the 1.2.3 release installed, your Rails specs will simply not run. For me, removing test-unit 2.0.3 made the difference and the specs ran properly. PowerDNS on Rails has now joined the ranks of my Ruby 1.9 compatible projects.

Ruote in 20 minutes from Kenneth Kalmer on Vimeo.

The original post of the presentation is over here.

After I read this post on Labnotes I decided to “take the plunge” into the world of Ruby 1.9 properly. I mean, I was at RubyKaigi where the biggest lesson of all was “Change!” (and changing to 1.9). Ruby 1.9.1 has been stable for quite some time now, and 1.9.2 is due out on Christmas. And we’re still stuck on 1.8.6 ? WTF

Getting started with Ruby 1.9 is easy (only time will tell how much pain is caused). I have to admit I’m not as brave to wipe my rubygems installation, I might still need 1.8.6 (and I seriously hope I don’t).

So Relevance made this awesome bash script called ruby_switcher.sh that you absolutely have to try. Once you have it installed and working as per their instructions you need to make one small change to the very last line of ruby_switcher.sh. That change looks like this:

#use_leopard_ruby
use_ruby_191

Simple and I can easily toggle 1.8.6 mode if needed.

Yes, I did.

So over the coming days I’ll be working through all 28 of my github repos and making sure they run on 1.9. This is no small task, but I’m looking forward to getting my “house” in order.

At this stage I know acts_as_audited is 1.9 compatible, I fixed it earlier the week while testing ruby_switcher. I had a look at ActiveRecord::Tableless and decided to pull the plug on the project completely (see here).

I’m really looking forward to this adventure and sharing the ups and downs of the road with everyone. Ultimately I would love it if we can get the South Africa Ruby ecosystem on 1.9.X ASAP.

Follow my project updates over on my Ruby 1.9 Progress Report