July 16, 2009

If you read through the JFace wiki page above, though, it says that to use JFace + SWT outside of Eclipse we basically have to locate several dependencies, namely:

org.eclipse.core.commands_<version info>.jar

org.eclipse.equinox.common_<version info>.jar

org.eclipse.jface_<version info>.jar

org.eclipse.osgi_<version info>.jar

org.eclipse.ui.workbench_<version info>.jar

All of these are available in the standard installation of Eclipse IDE in the ${ECLIPSE_HOME}/plugins directory.

Now, it would be a 10 minute job to manually search for, copy and paste the actual JAR filenames and execute the Maven commands to install those into the local repository with proper group and artifact ids.

Since I’m ‘lazy’, though, instead of 10 minutes I decided to spend a couple of hours writing a Ruby script to do this all for me (I originally started to write it in bash but I realized it’d be a lot easier in Ruby).

September 19, 2007

I work with a distributed team of Ruby (on Rails) developers, and we use Subversion as our repository of choice. Just recently, I wanted to find out which files were recently changed or added to a particular directory of our project.

Doing it manually would’ve been tedious. I also wanted to do it with code so that maybe sometime in the future we might be able to script some behavior depending on the last changed date of a file or group of files in our repository.

I could’ve resorted to merely calling svn info and parsing its output, but I thought maybe this was a good excuse to sharpen my Ruby chops and figure out the Subversion Ruby bindings.Read the rest of this entry »

September 7, 2007

If you’re developing with Rails using PostgreSQL as your database back-end, you might find yourself in the same situation I was just in.

Rails, by convention, makes us think in terms of application ‘environments’: development, test and production (where I work we add “staging”). Each environment is given it’s own database (each environment can even have entirely different database servers).

During development, there’ll be times where you start populating a table with meaningful data as you develop and test. For example, you might have created a users table and added a couple of logins.

In some cases, data that’s meaningful in development can also be meaningful during staging or production. So, like me, one day you might find yourself wanting to copy some rows or an entire table from one database to another.

If I were using MySQL, I could easily do this via the SQL console. But PostgreSQL doesn’t support cross-database references (offering schemas, instead).

July 27, 2007

Ruby on Rails provides a convenient way to ensure consistent database state for all unit tests and this is accomplished through Fixtures.

In the Rails Weenie forums technoweenie presented a technique that allows us to ‘bootstrap’ our development or production database using the same underlying mechanisms.

The way it works is first we place YAML files similar to the ones we use for testing under db/bootstrap (instead of test/fixtures). Then it’s a simple matter of executing:

rake db:bootstrap:load

Fixtures and Referential Integrity

The only problem with the above technique is when your tables have foreign key constraints (as they easily could if you use ActiveRecord Migrations with my own Migrations Constraints Plug-in).

When using fixtures for unit tests, we can explicitly specify the order of the fixtures in code. For example:

fixtures :foo, :bar_references_foo

The original technique by technoweenie allows us to specify a fixture order by an environment variable:

FIXTURES="foo bar_references_foo" rake db:bootstrap:load

While it works, it requires us to specify our fixture names and their order every time – not very DRY if you ask me.

Ordered Fixtures

Sandro Paganotti on RailsOnWave.com also realized this and presented his own version of rake db:bootstrap:load that attempts to address this.

The idea is to let us number our fixtures, similar to how we number our migrations, so that they can be loaded/unloaded in proper order according to our foreign key constraints.

Except, when I looked more closely at his code, I had my reservations.

First, and most glaring, is that he sorts the fixtures array, even if it’s passed in through the FIXTURES environment variable. I think this totally defeats the purpose of explicitly specifying the fixtures that way.

Second, and relatively minor, is that he hard-codes the format of the fixture file names so they have to be 2 digit numbers followed by an underscore, then the table name.

January 8, 2007

There’s something about Ruby

What continually excites and amazes me about Ruby is how expressive it is, how extensible it is, and how elegant it is.

Because you can extend any class/object in Ruby, and because everything is an object, you can essentially refine or redefine the language and its idioms to suit your thinking or preferred way of expression.

Case in point – if you deal with collections, ranges or subclasses you will have used one of the the following expressions (Ruby in Java-esque style):