daemon-kit 0.3.0.rc2 is ready

The second 0.3.0 release candidate has been pushed to Rubygems. Please read the 0.3.0.rc1 announcement for the changes between 0.2.x and that version.

What changed since 0.3.0.rc1?

Safely usage is now optional, see #73 for the details. Safely is still included by default in the generated Gemfile, but to remove it you simply remove that one line. This was heavily inspired by Rails’ default SASS behaviour.

The XMPP abstraction has also been fixed for blather versions ~> 0.8.0, so be sure to update the version by running bundle update blather and locking the version with “~> 0.8.7″.

Support for “freezing daemon-kit into vendor/daemon-kit” has been removed. In this age of bundler awesomeness, that functionality is quite useless. To use the edge version of daemon-kit simply update your Gemfile with the following:

gem 'daemon-kit', github: 'kennethkalmer/daemon-kit'

Then run bundle and you’re all set. Oh, delete anything in vendor/daemon-kit too.

When generating a new daemon you can simply pass the “–edge” parameter to get a Gemfile that tracks Github instead of Rubygems:

$ daemon-kit vuvuzela --edge

Tracking edge is probably the best choice up until 0.3.0 final is released.

Please give 0.3 a test drive

Get going with:

$ gem install daemon-kit --pre

or update your Gemfile:

gem 'daemon-kit', '~> 0.3.0.rc2'

Afterwards run the following to get your local daemon updated:

$ rake daemon_kit:upgrade

Blocker for a 0.3 final

There is only one blocker preventing a 0.3.0 final release. It is obscurely hidden in #72, and affects daemons running on Ruby 2.0 and later. Mark Perham has already resolved the issue in Sidekiq, so I have some inspiration to work from.

After that I’ll very quickly increment the minor & patch versions with improvements and start deprecating features. The project has come a long way, and some baggage needs to be cleared out to ensure a bright future for the project.

Thanks for facing your daemons!

flattr this!

Daemon-kit 0.3.0.rc1 is ready

I barely managed to get a 0.3.0 release candidate out before today’s release of the Ruby Rogues episode on daemonizing Ruby projects, which focussed a lot on daemon-kit, but also general advice for going down this path.

Listen to the show if you haven’t already, it really went great.

Also, big shout out to Marc Bowes for looking after daemon-kit while I’ve been living the startup life. Thanks Marc!

So what changed since 0.2.x?

I ripped out the old nanite generator since the nanite project seems pretty much abandoned. It was initially added to help daemon-kit attract some mindshare in the early days, and it worked. But given the state of the nanite project today, we had to part ways. This alone is the reason for the minor version bump.

This leads us to starting with a more semantic versioning approach. Going forward there is going to be plenty more minor version bumps leading up to a 1.0.0 release and beyond. My original version policy sucked, daemon-kit should have been 1.0.0 already since it is being deployed to production all over the world with great success.

I believe that semver also demands better transparency, so I’ve added travis support and got all the tests to pass. I’ve also switched a lot of old generator specs over from old Rubigen dependent test/unit tests to using the excellent aruba gem. I’m also dabbling with using Relish for documentation.

I’ve also added us to CodeClimate so we can get the code up to a 4.0. It started off as a 3.1, which surprised me (in a good way).

Some documentation files have been updated to Markdown, and if the Relish docs work out well will be moved to there.

Please give 0.3 a test drive

$ gem install daemon-kit --pre

or add it to your Gemfile

gem 'daemon-kit', '~> 0.3.0.rc1'

No real bug fixes except for running ‘daemon-kit’ without any arguments now shows a friendly help message.

I’ll push the 0.3.0 final in the next few days, I just want to expand the cucumber coverage off all the generators.

After that I’ll very quickly increment the minor & patch versions with improvements and start deprecating features. The project has come a long way, and some baggage needs to be cleared out to ensure a bright future for the project.

Thanks for facing your daemons!

flattr this!

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.

flattr this!

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.

flattr this!