Reusing your frontend JS on the server with The Ruby Racer

I can’t tell you how much fun it is typing out a blog post again. It has been nearly two years since the last post. I hope this will be the end of the dry spell for me.

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.

Safely weekend updates

I took some time today and released three new versions of Safely in a row, 0.1.0, 0.2.0 and 0.3.0. Safely also has a nice wiki now which breaks down exactly how to use the different 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.

Practicing safe Ruby, with safely

One of the things that makes daemon-kit such a great project (at least to me), is the built-in “safely” method wraps your code in a loving embrace of error reporting comfort. You could at any point do this:

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.

daemon-kit 0.1.8 released

I’m proud to announce that daemon-kit has finally made it to 0.1.8.1, almost a year after the last patch release. There has been a lot of changes since the last release, mostly cleanly up and staying with the times (so to speak). Github has an awesome compare view, detailing the historic moment, and I’ll go through it here in some detail as well.

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:

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.