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

I haven’t been able to work on Quill too much lately, in part because I lost my stylus somewhere along the way (new one should be forthcoming today, actually) and in part because my day job involves Rails at the moment, so that’s the world my mind has been in. What I have been working on is my awesome_fields plugin and a new plugin, headerize. Actually, the `work’ I have done on these has been extracting some stuff that I commonly do in my Rails projects into plugins. There’s very little that is technically new code from me there, though the headerize plugin is well spec’ed-out.

Anyway, so awesome_fields has received a LinedBuilder for creating better marked-up forms with less effort, and headerize was created to facilitate putting all your stylesheets and scripts in one place (typically the document head) while still being able to include them from the view. That way, the stylesheet that needs to be included by the _form partial is included there, so that it is spatially near to the place where it is used, while the actual markup for it goes in the head, where it belongs. So I’ll hit these two separately…

Read the rest of this entry

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…

Read the rest of this entry

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.

Read the rest of this entry

In lieu of introduction

I have recently started working in Eclipse, helping build an IDE on top of the standard runtime. This involves me learning an awful lot about the eclipse architecture (though I am far from an expert), and as I've worked on things, I've discovered that the otherwise excellent Eclipse documentation sometimes fails to mention small but vital things that lead me to waste, say, an entire afternoon on solving a trivial problem.

I am therefore going to start a series of posts relating to the WTP project (and whatever else I work on next), and other aspects of eclipse as things move along.

The amazing vanishing facet

Facets are a way to specify some default behavior in a Web Tools Platform (WTP) project that can be added and removed at will by the user. Because of their modular nature, you can use them to create finely grained wizards, either by letting the user select the facets they want through the standard facet selection wizard, or by defining the facets in the background and using them to abastract the design of the wizard you present to your client. The tutorial linked to above is quite good, but if, like me, you like to start playing in your own project rather than follow along in the provided tutorial project, some things might trip you up.

Here's the problem. In Section 2, the tutorial shows you how to define a facet using the org.eclipse.wtp.common.project.facet.core.facets extension point. This works fine in the example plugin; notice, however, that when you fire up the "New Project" wizard in the running instance of the FormGen plugin and select the Dynamic Web Tools project as indicated, the "Target Runtime" field specifies "". This is important: if a target runtime is spefied, your facet will not appear as an option when you click "Next." This is because facets must explicitly support a given runtime (or any runtime) to be added to a project that includes it. What does this mean? If you specify a runtime (or if, like me, your project has one defined by default), your facet will not show up, even though it is properly defined. So, in short:

If your facet is not showing up where you expect it to, make sure that either a. your facet is configured to run on the specified runtime or b. the project you're trying to set up does not have an associated runtime.

Of course, since facets are associated with WTP projects, they almost always will need to support at least one runtime. However, it helps to know about the runtime dependency ahead of time as a sanity check: if the facet is not showing up, try not specifying a runtime in the project wizard and see if the facet then appears---you can worry about adding the runtime dependencies later. Defining runtime support is covered in Section 9 of the turorial, where the dependency of facets on runtimes is explained in detail as well. But if you got lazy and came here first instead, I hope this helped.

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.

Read the rest of this entry

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 :)

Read the rest of this entry

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.

Read the rest of this entry

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.

Read the rest of this entry

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!

Read the rest of this entry

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.

Read the rest of this entry

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.

Read the rest of this entry

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.

Read the rest of this entry

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.

Read the rest of this entry