Getting the Ruby 1.9 ball rolling
by Kenneth Kalmer on August 14, 2009
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
Looking beyond daemon-kit 0.2
by Kenneth Kalmer on August 9, 2009
I wrote daemon-kit to solve two big issues with writing daemon processes in Ruby:
- Everyone is re-inventing the daemons gem
- Individual daemons share a lot common code, apart from the daemonizing bits
As for #1, daemon-kit at first wrapped the daemons gem, and later ripped it out completely as it was difficult to wrap up the worst of the daemons gem properly.
#2 seemed to be a twofold problem that daemon-kit has also addressed with great success. The first was addressing the all too common issues of logging, pid file management, umasks, signal traps, config files, exception handling and other “low-level” issues. Everyone was implementing these things to a limited extent in their daemons and this could cause a lot of frustration when done wrong. The second part was the need, even if undiscovered, for higher level re-use and development speed. Daemon-kit addresses this with some limited generators, making it easy to get going with a cron-style daemon, AMQP & XMPP bots as well as the newest addition, Ruote remote participants.
All this is fine and well, and people seem to like the project. The mailing list is getting some noise, we’re over 200 watchers strong on Github and the IRC channel has some folks popping in to say hi.
However, daemon-kit quickly made me lazy and realize there is a couple of things it can do much better. If you’ve used a generator before, you’ll notice the generated code is very much stuck to that type of daemon. Changing from XMPP to AMQP (for illustrative purposes) would be best accomplished by generating a new project and copying over the lib/ folder only. This sucks.
Another problem is people, myself included, would like to have Sinatra-style daemons (i.e. one file) for smaller tasks. Currently this is not possible at all. Another thing I know people are doing behind my back is generating daemons inside Rails projects, which may or may not work, depending on whether you load Rails’ environment.rb.
So, what happens now?
My thoughts are to implement privilege dropping support and tag a 0.2 release. This gives us a feature complete framework, albeit not as good as it can be. I’ll maintain 0.2 as a stable while undertaking the rewrite. A rewrite? Read on.
I posted to the daemon-kit list a suggestion for stackable daemon environments. I’ve discussed this in IRC with a few folks as well. Jordan Ritter gave me an exceptional breakdown of the dangers of doing something because it is “neat” and I’ve taken his warning to heart. However, I cannot seem to argue against stackable daemon environments, it sounds too good.
The idea is pretty simple. Stack-entries can be compared to Rack applications, with two significant differences. The first is that they will be called only once. They have the opportunity to change the environment in which the final code runs. The second is that they can be called at four different stages of the daemon lifecycle: argument processing, pre-daemonization, post-daemonization and shutdown. This differs from Rack’s single call() method.
The stackable nature also gives the stack members easier ways to set conventions and can dramatically minimize configuration. It paves the way for plugins, sinatra-style daemons, rails-based daemons and easier packaging of distributable daemons, and so much more. Looking at the internals of daemon-kit, it would greatly help simplify the existing code as well as help separate utility classes from stack members.
The more I think about it, the more obvious this becomes, and the more possibilities unfold for the framework. This will definitely make daemon-kit a force to be reckoned with, and hopefully I can persuade other library developers to offload their daemonizing code to daemon-kit, just like rack developers offload their HTTP handling to rack.
DaemonKit Lightning Talk RubyKaigi 2009
by Kenneth Kalmer on July 18, 2009
Undoubtedly my worst time on stage ever! Ubuntu gave me issues with the projector, so I actually had to leave the stage to go to another conference hall to get the setup working again and run back up to the main hall… Once there, I was a mumbling mess, but made it through without the buzzer beating me.
Presenting a lightning talk at a Japanese conference is surely something else, the audience expects fireworks and the presenters deliver. It was truly an amazing experience, humilation and all, and I’m looking forward to the last day of the conference.
Getting “copy friendly” with jQuery
by Kenneth Kalmer on July 10, 2009
When I’m not busy writing backends for large service provisioning platforms, I get to spend some time in the user-facing interfaces of these platforms. We’ve prided ourselves so far on maintaining cross browser compatibility (excluding IE6), and to a certain extend mobile phone accessiblity as well. All the dynamics of the interface is done with jQuery, and it is done unobtrusively as well. We frequently test the site with Javascript disabled, to make sure that everything works as expected, and it mostly does. Webrat is a great help here as well, since it navigates the site without Javascript…
But enough blabbering, the ISP in a Box platform is huge, and interacts with various other service providers through a myriad of API’s, some of them as reliable as convicted mobster. Our support teams are constantly double checking the interactions between the autonomous participants and our service providers, and this means a lot of copying and pasting, from our interfaces to theirs.
They simply “double click” to select text in our interface, causing the browser to copy additional whitespace with the selected text. When pasting into a search box they need to prune the additional whitespace off manually, making the process even slower and more tedious than it needs to be. I can’t replicate this with Firefox on Ubuntu, but it happens to the Windows guys…
In the previous version of the system I solved the issue quickly and bluntly by simply placing all the information in text fields that were styled to be transparent. In this day and age of unobtrusiveness I thought it more appropriate to generate the text fields on the fly, since they’re a convenience and have no effect on the functionality of the system.
It took me 5 minutes to get this done in jQuery, and another 10 to figure out how to wrap it all up as a jQuery plugin. I love jQuery…
Ladies and gentleman, I present you with the jQuery copyfriendly plugin.
Usage
$(document).ready(function(){ $('.copyme').copyfriendly(); });
And then mark your “copy friendly” HTML elements like this:
<table> <tr> <td class="copyme">Hello</td> </tr> </table>
Or inline like this:
<code><span class="copyme">Heya</span></code>
copyfriendly() takes on parameter currently, which is optional:
copyfriendly( { klass: "borderless" } );
The ‘klass’ option tells copyfriendly which CSS class to apply to the inputs generated.
Sample CSS
You can make the inputs generated by copyfriendly invisible using this sample CSS:
input.borderless { border: none; }
Do be warned that it might take a little more to align the appearance of the remaining text with the surrounding text in the document.
How it works
Actually quite simple. All it does is extract the text from the element and then replaces that text with an input tag of type “text”, and the value is the original text extract from the matching element. The size of the element is dynamically calculated from the string length, so there might be room for improvement here.
