Announcement: Slickback v0.2.1

Version 0.2.1 of Slickback is now available. Slickback is a javascript library that makes it easier to use Backbone models and collections with the SlickGrid jQuery datagrid. New features in this version include support for displaying and editing Backbone model fields as text, integers, fixed precision numbers, and for selecting field values from dropdowns. Constructors for non-paginated Slickback collections are also new in this version. Slickback v0.2.1 is released under the MIT license and available on github or via npm.

Announcement: A Plugin Named Slickback

Slickback version 0.1.0 is now available on Github and via npm. Slickback is a javascript library that adapts Backbone collections to work with SlickGrid, a jQuery-backed datagrid. Extensions to Backbone include support for paginating collections and composing filtered queries using an interface modeled after Ruby on Rails ActiveRecord's "named scopes". Slickback, like Backbone and SlickGrid, is released under the MIT license.

At home he's a tourist: FFI for Ruby internals

FFI stands for "foreign function interface". That describes the most common use case: Creating Ruby bindings to external native libraries. But it's also possible to use FFI to spelunk Ruby's internals. Consider:

Foreign? Far from it. You've now got access to all of C-ruby's innards. For example, if you're using Ruby 1.9:

With this you've got a handle on the otherwise inaccessible RubyVM core object. As a pointer, it's not all that useful. But with a little more mischief...

... now you can treat the RubyVM core like any other object. One interesting (if unwieldly-named) method that it offers is "core#define_singleton_method". It accepts an InstructionSequence -- compiled YARV bytecode -- and uses it to set up a singleton method in the object where it is invoked. Let's make it a little easier to use:

Now it is easy to create methods using bytecode sequences:

(Complete code example)

Good Reasons to Use RSpec

It's been recently suggested that RSpec owes its popularity to fashion, and that people don't understand the alternatives. My experience is different.

I've been using RSpec to test Ruby code for about five years. Before RSpec, I used Ruby's Test::Unit, as well as a number of other xUnit-style frameworks for Perl and Java. I was never happy with the earlier frameworks, but I was convinced that unit testing was worthwhile so I made do with what was available.

I switched to RSpec because in very little time I found it more helpful than other frameworks I had used. The reason is this: RSpec helps me to alternate between writing code and writing tests without having to switch contexts.

By using the description of behavior as the model of testing, RSpec answers the question of what to test before you have to ask. It's more than syntactic sugar. It's conceptual sugar. I find that not having to think so much about the testing framework, I'm freed up to think about the tests themselves, so I write better tests and more of them.

RSpec has "no discernible benefit" over other frameworks? It depends on who is doing the discerning. I find plenty of good reasons to use RSpec, and I have a lot of company.

Agile Software Development: The Good Parts

Like Javascript, Agile has become all but unavoidable. In Javascript: The Good Parts, Douglas Crockford briefly imagines the world as it might have been if Java applets had not been displaced by Javascript as the client-side web application platform of choice. "But Java did fail, and Javascript is flourishing, so there is evidence that Javascript did something right."

There are reasons, too, for Agile's popularity, and some of them are good reasons. As with Javascript, it pays to identify the bits that work and avoid those that lead to unnecessary problems.

Agile boils down to a series of tradeoffs. Some of the things that Agile sacrifices may not be dispensable in some or even most projects. And some of the things that it optimizes for may not figure into a project's viability.

Here are a few ideas associated with Agile that I have found to have broad application, and which, if they continue to prove useful, I hope will be preserved by future trends in the management of software development. This list isn't complete.

• Development is research and should inform design, not just execute it
• An incomplete implementation and the feedback it elicits is often a better guide to what users need than a priori requirements
• Tests make it easier to introduce new behavior while preserving the old
• Pay the cost of change on the installment plan