life.events.each { |event| learn_from(event) }

So Software Without Incident (the site) kind of disappeared a little while ago due to some accidents while I was toying around on the server. The SVN repository’s still sitting there on my server, though, so my code’s still around. And I still pull magic_fields into my new projects. I am a particular fan of the collection handling, if I do say so myself. The name, however, clashes with a term given to Rails’s built-in `magic fields’ for ActiveRecord, things like updated_at and created_at. So I took advantage of the situation to rename the plugin awesome_fields, too, so it’s a little more distinguishable.

Anyway, I went ahead and used git-svn to pull the code from the SWI repository into a git repository and then pushed it off to GitHub. I’m more a fan of Bazaar myself (the documentation for it is amazing, and the commandset is readable; plus, there’s no required -a parameter for committing everything, which is the way I happen to work), but I know the Rails community is on git-mania now, so git it is. For the interested, it’s under awesome_fields at GitHub.

Documentation and a README await there.

In my forays into the world of creating a Qt journal application, part of what I wanted to achieve was a really easy way to get to common actions like tool changes. My two biggest gripes with Xournal were always (a) that I had to keep adding an extra page after the one I was working on if I wanted to be able to see the bottom of this one (I fixed this in Quill, and made adding a new page easier, by introducing a `virtual’ last page, which does not appear on any output but gives you scrolling space and, when drawn upon, becomes a regular full-blown page) and (b) that if I wanted to change tools or colors, I had to shoot up to the toolbar to do it. That’s just no fun.

So, my latest foray into Quill has been adding a radial menu to the canvas area, so that you can get a menu for doing stuff in a way optimized for the stylus. The coolest aspect of this was that it let me develop my own Qt widget, of course. The results, though, were pretty good, I thought:

Details follow…

What’s been keeping me up late at night recently? Well, recently, it’s been a side job; however, somewhat less recently, I started a program called Quill. Quill is a Qt equivalent to Xournal, which is a tablet journaling program written in Gtk. But I didn’t just want to make a Qt clone, as that’s neither here nor there. Instead, I used Quill to brush up on my Qt skills, as well as to play with some of the cool technology in Qt 4.3 (like the Graphics View framework and, to a much more restricted extent, scripting (which I haven’t yet been able to figure out very well)). Quill is hanging out on Launchpad at https://launchpad.net/quill. I chose Launchpad in part because I wanted to play with Bazaar, which I have been using since I set up the Launchpad site, and damn it’s hot. I only hope I get more opportunities to use it in the future.

Anyway, a couple of the features I’m playing with Quill. First off, I’m adding buttons to the bottoms of pages to allow inserting pages in the middle relatively easily and with no menu interaction. Likewise with deletion of a page. In addition, there’s always a ``virtual page’’ after the last actual page. Writing on this page will make it a full-fledged page, but it does not appear in any printing or PDF exports. This basically makes it a very easy way to add a page to the end of a document. Finally, if you hold the cursor relatively still once you stop writing, a toolbar pops up with some commonly used tools.

A lot of things need work. Right now I’m working on getting the movement of a selection to work appropriately across saves. Currently, since such a change doesn’t break up strokes, reloading the page will connect the moved lines back to their original strokes, yielding some very strange streaks. I’m working on breaking strokes apart when moves like that happen, so that this works correctly. Also, the way the toolbar appears and when it does and where it does can get annoying. This is definitely an area for improvement.

And there is also, of course, performance. QGraphicsView and QGraphicsScene are fantastic pieces of technology, but their performance has some issues—especially when moving a selection, for example, where paint clipping becomes very apparent. I intend on looking at some of these issues to see if they can be resolved with clever coding, or if I’m just being an idiot to begin with. Additionally, after a random time period, the drawing based on stylus input becomes very very very noticeably slow. I’m still not sure why this is happening, but it’s definitely my fault, as saving the document at this point and then reloading it and continuing works fine.

There’s a common pattern in Ruby for setting up keyword parameters—optional parameters with default values that are accepted as a hash at the end of the method call. Ruby’s syntax facilitates this, with end-hashes not requiring curly braces; instead, you can do this:

obj.method :keyword => 'value', :keyword2 => 3

Many people have written about various ways of implementing this in as painless a syntax as possible, but they all involve writing a lot of boilerplate. My intent is to write code that doesn’t require such boilerplate at all, instead providing a declarative way to say `here are the optional parameters, here are their default values’ and have everything taken care of for you. Moreover, the ability to provide introspection into what optional parameters are expected at runtime and the default values thereof is also something I want to try and give.

So it’s been a while since I’ve made a post on RubyShell. I’m still working on it, so no worries, I’ve just got a little less time than usual. Anyways, an update on some things I’m working on right now; namely, a better validator and some improved path handling.

The latest release of RubyShell is so cool, it’s skipping right over 0.4 and straight to 0.5. If you want to skip the explanation, you can go ahead and download it now.

It bears mentioning also that this release marks the first release of RubyShell on Rubyforge. Thanks to Rubyforge for being awesome :)

It turns out, RubyShell 0.2 ran code twice when you asked it to run it once. Whoops…

Anyway, once again that’s only one of the several new features (okay, that one was a bug fix, too…) in RubyShell 0.3. If you want to skip the explanation, you can go ahead and download it now or look at the list of fixed/implemented issues.

It turns out, RubyShell 0.1 couldn’t handle method definitions or local variables because of the way Ruby code was being evaluated. Whoops…

Anyway, that’s only one of the several new features (okay, that one was a bug fix…) in RubyShell 0.2. If you want to skip the explanation, you can go ahead and download it now or look at the list of fixed issues.

Once again, I put the Rails tutorial on the back burner (sorry folks :-/) for a coding project. This one wasn’t quite so little as the last one, though. While thoughts went through my mind about writing something similar to JAXB called RAXB, and I created the project on Software Without Incident and all, that’s not what I ended up working on. Instead, my focus the last month or so has been RubyShell: a UNIX shell written in Ruby with Ruby as its primary language. I’m ready now to make an initial release, so here it is: RubyShell 0.1!

As a completely random exercise a month or two ago, I sat down and hacked out a very simple implementation of the Javascript with keyword for Ruby. with basically works like this:

with(object)
{
    instanceMethod(); // no need to prefix with `object'
    var test = 5;
    other_instanceMethod(5);
}

So basically it temporarily scopes function calls to a given object. If you call something in there that isn’t an instance method, it’ll then look for a local function with the appropriate name (note that this is contrary to the assertion I originally made in the aforementioned implementation; I’ve since verified that this is the expected behavior).

Initially, I just passed the block on to instance_eval and happily went my way. It was a satisfactory solution, but not an ideal one, because, as pointed out after the snippet, it failed to respect encapsulation. Moreover, if you called something in there that wasn’t an instance method, it would fail. Now, after being spurred on by my brother’s mention of a friend’s solution that involved proxy objects, I’ve got an implementation which does not have those problems and in fact seems to largely behave the same way as the Javascript construct it is based on.

I saw an interesting post on something that allows you to annotate Java fields for caching. That’s shiny and all, but I like to live in the Ruby world (though annotations in Java are finding some very neat uses).

In case you came hunting for Part III of the Rails tutorial, don’t worry—it’s coming, but this caught my attention first.

In Part II of this Ruby on Rails tutorial, I’m going to hit the ground running with the concept of Behavior-Driven Development, or BDD. We’ll get into RSpec, its syntax, and why we use it, all while creating ourselves an `author’ resource that will form the basis of our blog system. I’ll be assuming that you’ve got Rails installed, an application started, and your database set up (though, currently, table-less), since Part I covers how to do those. Before starting to work on this, you’ll want to fire up the database server so that we can use it.

Back last July, I wrote a Ruby on Rails tutorial as I was learning Rails. On the one hand, I’m rather proud of the tutorial. It’s pretty plainspoken and straightforward. On the other hand, in the year since I wrote that tutorial, I have learned vast amounts about Ruby and Rails. I still wouldn’t come anywhere near calling myself an expert, of course. That would be foolish. But I have a firmer grasp of what’s possible, and of best practices, and of many other things that could make that tutorial Better™. So I decided it was about time I did that.

What I’m about to do is nab the Rails tutorial and redo it. I was intending on the original tutorial having several parts, each covering some more ground on a single application. I ended up only writing two, but mostly because of time constraints. This time, I hope to update those two and then write several more, so as to complete my original vision. This is part I, which covers about the same ground as half of the original first part, but from a Rails 1.2, REST, BDD, etc, point of view. I think what I really liked about my original tutorial was the fact that it started at the most basic level (installing Rails) and started going into neat things like before_filter and such with real examples (like authentication). I intend on bringing in some plugins and things like that later on, in part to show refactoring and in part to introduce a lot of the neat plugins that already exist out there and can make a Rails developer’s life easier.

Anyway, without further ado, following is A Ruby on Rails Tutorial: Blogification, Part I: Introduction and Setup.

ePiX is an extremely cool and powerful little C++ library to allow you to generate eepic (and, from there, pdf, eps, or other) images. Amongst other things, it’s useful for, say, generating plots for a math presentation. This is wicked cool functionality, and it’s actually quite straightforward. The only issue is that, for most people, C++ isn’t exactly the most accessible language¹.

So it occurred to me, someone should write a Ruby wrapper for ePiX. That someone should probably be me. Plus, it’ll probably give me some opportunity to explore the C side of Ruby, which would be cool. So maybe I’ve got (yet another) project now :-P

¹ There is, as noted on the ePiX page, a Python wrapper called pyepix

Strings are cool little things. They let us do text in our programs, and what’s a program without text? What’re strings? Well, maybe they’re arrays of characters, or maybe they’re relatively lightweight objects. Or then again, maybe they contain Unicode characters and allow a ton of cool behavior. In Ruby, they tend towards being an array of characters and allowing a ton of cool behavior.

The trouble is that, most of the usual languages implement what we call ``lexicographic comparisons’’ (see the wikipedia article on lexicographic ordering) which, while usually good enough (and often faster), can be a problem when you have strings with numbers in them.

So let’s see how we can modify the Ruby String class to use natural ordering (rather than lexicographic ordering) in strings with numbers.