avatarharuki zaemon

Here Come The Minions

By

Well, just as Jon (and others) predicted: M$ developers are apparently beginning the move to Rails. That’s just Marvy!

I had taken comfort in the fact that .Net had disuaded a large proportion of developers from taking up Java and had hoped (nay prayed) that it would continue to keep them amused for some years to come but alas, the secret is out. Clearly the appeal of a language that gives every developer the ability to create a train wreck faster than ever before is too much resist.

I wonder how long it will take for M$ to get a patent on Ruby (and/or Rails for that matter). It seems like the only sensible thing to do ;-)

Patching Rails

By

Last night I was writing some database migration scripts and I wanted to add a not-null column to a table. The migration stuff is so cool that I was able to write something like this:

class AddExternalIdToListings < ActiveRecord::Migrationdef self.upadd_column :listings, :external_id, :string, :limit => 10, :null => trueadd_index :listings, [:external_id], :unique => trueListing.reset_column_informationListing.find(:all).each do |l|l.external_id = l.idl.save!endchange_column :listings, :external_id, :string, :limit => 10, :null => falseenddef self.downremove_column :listings, :external_idendend

This script first adds the new column allowing nulls (:null => true) then creates a unique index on it, updates each record to give the new column a value and finally modifies the column to make it not null (:null => false).

All well and good except for one thing: it didn’t seem to modify the column as expected. Looking at the source code for the PostgreSQL adapter, I could see that the code change_column() has (at least) two bugs. (Ok, strictly speaking one bug and one omission.) The first bug means that it never actually executes the intended statement. The second (the omission) means that even if the statement were executed, most of the specified options (in this case the :null => false) would have been completely ignored.

Enter the wonder of Ruby and extended/modifying classes on the fly.

Disclaimer: I’m no Ruby nor Rails expert. I’m sure there’s a “better” way to do this so if anyone wants to take this code and submit it as a proper patch, then please, please, please go for it. For my needs, this does the job nicely.

Rails allows you to add functionality via Plugins. In this case, I decided to make a “patches” plugin that will allow me to easily override or extend rails to get around any bugs (or omissions) that I encounter in my travels.

So I ended up with two files. The first vendor/plugins/patches/init.rb is executed by rails. In my case it contains only one line:

require 'postgresql_adapter_patches'

This simply loads the second file (vendor/plugins/patches/lib/postgresql_adapter_patches.rb) containing the actual code that performs all the black-magic (although it’s actually fairly straight-forward):

module ActiveRecordmodule ConnectionAdaptersclass PostgreSQLAdapterdef change_column(table_name, column_name, type, options = {})native_type = native_database_types[type]sql_commands = ["ALTER TABLE #{table_name} ALTER #{column_name} TYPE #{type_to_sql(type, options[:limit])}"]if options[:default]sql_commands &lt;&lt; "ALTER TABLE #{table_name} ALTER #{column_name} SET DEFAULT '#{options[:default]}'"endif options[:null] == falsesql_commands &lt;&lt; "ALTER TABLE #{table_name} ALTER #{column_name} SET NOT NULL"endsql_commands.each { |cmd| execute(cmd) }endendendend

In essence, all it really does is override the definition of the change_column() method in the ActiveRecord::ConnectionAdapters::PostgreSQLAdapter class. In my case, I just copied the code from add_column() and modified it to suit my needs. Of course this is a blatant violation of the DRY Principle but hey, shoot me :-).

All in all I’m impressed by how trivial the whole processs turned out to be and has made me think about writing some actual plugins; I’ll leave it to the experts to fix it for good ;-).

The Ruby Way(tm)

By

I can’t help but be amused at the number of times I see the term “The Ruby Way” (or similar) used as a euphemism for “Better than {Java,C#,Python,Perl,etc.}” It seems to be one of those terms (like “Un-Australian” and “Un-American”) that can be used to support or attack anything based largely on personal preference.

Case in point: The discussion and ensuing ruckus over Humane Interfaces. What seemed (to me at least) to be an interesting talk on the subject rapidly (as seems to happen all too frequently) into a “mine’s better than your’s” sledging match.

Unfortunately, Fowler did begin his discussion with “Hanging around the ruby crowd…” and followed that up with “…compare the list components in Java and Ruby” which amounts to pouring gasoline on a bbq. However, what almost everyone fails to see (or possibly I fail to see that they see) is that the concept has almost nothing to do with the underlying language and far more to do with the people (surprise surprise).

Java is full of Swiss-Army classes as is Ruby. Ruby seems to have some very intelligent and articulate pracitioners as does Java. In many ways, Ruby (like Perl) seems to almost encourage bad habits in those less versed in The Ways™. Java OTOH attempts to prevent these same problems and yet creates a whole slew of others.

Disclosure: I like Ruby, alot! but I don’t hate Java as a consequence. In fact I find that besides some really nice language features that I really like, I don’t find that I think that much differently in either. Then again, I’ve never liked Struts, I’ve put up with Hibernate and left the J2EE stack along time ago. Alas, ActiveRecord is not much better (yet). It lacks many things that I’ve come to appreciate in ORM tools but, in its defense, it’s still relatively early days and what is there is relatively clean (from the point of view of one using the library) but take a look at the code and tell me there aint a whole lotta spaghetti in there!

Most people (probably myself included) don’t get software development, don’t get OO, don’t get “it” in general. So let’s not get sucked into thinking that somehow the language is to blame. Sure it has an influence but honestly now, horses for courses: People think differently, taste differently and smell differently. Get over it!

Maybe look at yourself first and ask the question “Do I get what they intended?” If you think the answer is yes, then ask again. If the answer is still yes, then how about taking aim at the people involved in creating the frameworks next. The underlying language is a very soft target.

First come up with a definition for “good” and then prove to me there is a direct correlation with the language.

Dojo or Prototype or ...?

By

I’m about to start adding “funky” Look & Feel stuff to my Rails app and I was wondering what the general consensus (if there even is such a thing) is on JavaScript libraries.

I really don’t care so much about the ease or otherwise of making XMLHttpRequest calls; this is the least of my worries – it’s trivial to do manually. What I’m more interested in are things such as Drah & Drop, Accordians, Select-as-you-type, and other more general DHTML layout stuff.

Rails itself ships with prototype+scriptaculous which I’m lead to believe are quite good. My mate Andy on the other-hand has played a bit with Dojo and likes that too.

Anyone care to share their own experiences?

Don't Give Razor-Blades to Children

By

I’ve no idea who first coined this phrase but I heard it from Steve.

This was to be solely about Rails schema migration but it turned into a partial rant (surprise surprise) about playing with Ruby and Rails. Never fear, the migration bits are still here; they’re just at the end instead :)

Developing in Rails as a one- or two-man-band is very rewarding but I’d like to see how it scales to many developers and more importantly, to developers of radically different levels of experience. As you probably gathered from my previous post, my prognosis on this last point isn’t particularly flattering.

I like convention over configuration so long as the conventions don’t get in my way; and so far they haven’t. I think the idea of “flexibility” in software is highly overrated. The whole J2EE stack is a perfect example of bloat in an attempt at being all things to all people.

Don’t get me wrong, I love Java. I will always like it. It does pretty much everything I could want and do feel very productive with it – especially when compared with the pile of steaming turd that is Flash/Flex – but I have to admit that I do like The Ruby Way ™. I must have been a Smalltalk wanna-be in a previous life. It’s not for all things nor for all people but it might just be for me on the kinds of projects I enjoy doing.

So far I’ve found Ruby/Rails to be easy to test; that it facilitates adding new behaviour VERY quickly; and that the teeny bits of SQL I do need every now and then aren’t painful in the slightest. I love partials; caching; declarative relationships; validation; acts_as_xxx; components; etc.

I don’t like fact that there doesn’t seem to be a way for components to have relationships to domain objects – for example my address component needs a State which is an active record object. Tool support is pre-historic when compared with Java. I use TextMate on the Mac which is pretty darn good and there is RadRails of course but to be honest, right now – although the road-map looks very promising– it isn’t actually much better than TextMate except for debugging.

Anyway, the upshot of that little rant is to say that whilst I’m still splashing around in the kiddies pool, the water still feels good and is tempting me to want to try swimming in deeper water.

So anyway, back to the topic I originally had in my head.

If anyone has been playing with rails then at some point they’ll want to have a play with data/schema migration. I used it tonight and it worked as advertised.

In short, you create a number of files named 001_xxx, 002_xxx, etc. Rails then creates a table (schema_info) that contains the current database schema version. When you run a migrate, it (rails) will execute the scripts necessary to bring you from whatever version you are currently at (may be 0) to the latest version (by default) or a nominated version (using VERSION=#). You can even downgrade by specifying a previous version.

Besides migrations based on version numbers it essentially supports a DB independent schema description with the ability to escape to SQL if need be (like for those pesky little FK constraints that no one wants to talk about but should be locked-up for doing without). Honestly the “DB independence” thing isn’t the biggest concern for me in the world but it is nice. It would be even nicer if rails extended the concept to include foreign key constraints (the model has declarative relationships anyway!).

You can also use your rich domain model to play with the new schema in the migration script too! So, for example, you can add reference data or munge the existing records to suit the new schema. Again you can even execute raw SQL if need be!

If you’re interesting in how this really works, I can recommending reading thisand maybe thisand possibly thisand the RDOC can be found here.

The only issues I’ve had are that transaction management within the migration is a little dubious: I can’t seem to find a way to execute a batch of DML – as opposed to DDL– in a single transaction. Rather, it seems to commit each statement. The upshot of this is that it’s possible to end up with a database in a weird state where some of the statements executed but the schema version hasn’t been incremented. Thankfully you do get an error message so you know something screwed up and you can manually increment the version number and then have rails downgrade for you.

This only happened to me once and then only in development so it’s not a huge issue but one to be mindful of.

So, my new shiny toy is still shiny but I’m not about to give up my day job just yet. I still haven’t heard enough people bitching about it to make me feel comfortable that there is enough understanding of the technology in the main. I am however doing a real-life project using it and so far so good.

Ruby on Rails: 100,000 morons can't be wrong

By

So I have to admit that not only am I a cardpod-carrying member of the apple cult, but lately I’ve been dabbling in a bit of voodoRuby-on-Rails as well and so-far, me likey. I think it’s one of those tools that people will either get or not. If they do, it’ll be fantastic; if not…

Rather than give you my personal take on this, I thought I’d take a slightly different approach and get in touch with one of my inner-morons for a more balanced perspective.

Ahem…

I’d like to start by saying outright that I think RoR will be a good fit for most large corporate development shops. I can see it delivering 20x, 30x maybe even 50x improvements in efficiency however I do see some short-comings, probably due to it’s relative immaturity when compared with Java.

If you look at most of the projects that are using Rails and Ruby at the moment, the code-base consists of dozens, maybe hundreds or possibly even a few thousand lines-of-code at most; Certainly nothing that compares to the size of projects we are used to working on which are in the order of tens if not hundreds-of-thousands of lines-of-code. But fear not, we have a plan to ensure it’s readiness for enterprise use.

We have two choices: develop applications and components on an as-needs basis; or try to build some common infrastructure that all projects can use.

The first option sounds dangerous as it will no doubt lead to everyone doing it slightly differently which in turn leads to lots of unnecessary duplication of effort. So as part of the next project, we plan to produce a framework (Ruts?) that will sit on top of RoR upon which all the teams can build. This way we will have better management and control over the infrastructure.

We’ll start by checking the source code for Ruby and Rails into our repository so we can patch them whenever we need to. This means we don’t have to wait for patches to become available in production versions. It also has the added benefit that when the API’s change our code won’t need to be re-factored as a consequence. Isn’t open-source great!

Next we’ll address configuration. There really needs to be a way to place all the configuration in XML files. XML is, after all, THE standard; we’ve been using XML successfully in Java for years and everyone understand it. We’ll start with database connection details, then move on to other areas. One area of particular interest will be database schema generation. At the moment Rails only supports coding the SQL directly. Unfortunately this doesn’t allow us to write database agnostic DDL; enter XML. If we create an XML-based language for defining the schema, we can then generate the SQL for each desired database; heck we can also generate the appropriate Rails model classes as well including relationships, etc.

We’ll also need clustering – every enterprise application needs clustering. To this end we’ll extend rails – we have the source – to support transparent clustering by sending session state to a master controller server that will then send it to all the nodes in the cluster. This will require serialisation and class version management which ruby already has built-in.

We see other improvements in efficiency in terms of testing. We find that due to the very slow turn-around time of Java web applications, our developers spend a great deal of their time writing tests. Rails on-the-other-hand has such a quick development cycle time that we can dispense with much of the automated testing in favour of manual testing.

Having said that, we have noticed that each time the database schema or configuration changes we have to stop and start the server so we will also include an extension to Rails that looks for changes in the configuration and automatically refreshes rails. Again, once implemented in the framework, each project will benefit.

Another limitation in Rails is the MVC implementation. Again, it’s pretty good but it could still be improved. We’ve known through years of experience now that trying to put all that code into one controller class just doesn’t work. Instead we will create command objects, wired together using XML and a generic AbstractController that will read the configuration file and work out what to do. This will be much simpler and we envisage huge time savings as a result.

Also the active-record stuff might be a good starting-point but it will need to be enhanced a bit for real enterpise applications. For a start, what it needs are DAO’s, one for each table in the database. Again a few classes in this respect would do wonders for productivity. We might even write some code that could generate DAO’s from the schema XML configuration discussed earlier.

Come to think of it, if we had some kind of container, then it could manage all this for us and more including transaction management, dependency injection based off an XML file, etc.

We’ve also been looking at the query language. It’s pretty good but it’s not very rich and it’s basically just SQL injected into your source. What Rails really needs is some kind of Object Query Language along the lines of hibernate. In fact, because hibernate is open-source, we might want to consider replacing active-record with a hibernate re-write (Rhibernate?)

So, as you can see, with a few little tweaks here and there, Ruby-on-Rails might just be what we need to get our enterprise development teams moving towards Web 2.0. We just need to work out how to get Rational Rose and ClearQuest integrated to generate all the code for us and we’re set to go.

Thank-God for Wireless

By

When I arrived home I realised I didn’t have my keys with me and my brother had (selfishly I might add) gone out somewhere. But, thanks to the wonders of modern technology here I am, sitting on the steps of my apartment building, chatting on IM, checking my email, reading RSS feeds and of course, authoring a blog entry.

What else would a geek do under the circumstances I ask?! ;-)

Mocking my Visitors

By

I mentioned in a comment earlier this week that I like Builders as they allow me to separate out the ickyness involved with construction from my nice pristine objects. Besides anything else, it allows me to layer on functionality: first implement the domain objects, assembled by hand for testing purposes; then create another layer – the builder – that will automate the construction process.

Of course being the good little TDD weenie that I aspire to be, at some point I want to test that the builders are generating the correct structure.

IMHO, the utterly evil-broken-and-wrong approach is to expose all the properties on all the nodes in the graph – I use the terms node and graph generically here to refer to objects related in some fashion – for reasons I’ve harped on about more than enough.

Another approach – that maintains encapsulation – is to implement equals() for all the nodes in the graph. The idea for testing then is to create the expected structure by hand (just as I had already been doing) then use the builder to create another and assert that the two are identical. I have actually used this approach before and while it worked just fine, it never really felt Good™. I’m not sure why; just an intuitive ookyness.

More recently though I tried a different approach: using a visitor. Again the approach was similar: constructed the expected structure by hand; then use the builder to make another; and finally assert that the two are identical. This time however, the idea was to traverse the expected structure and match, node-for-node, with the actual. The neat thing about this approach though was that because my visitor class was an interface, it was trivial to use EasyMock to do all the grunt-work for me. (EasyMock also allows mocking classes however I still prefer interfaces.)

The idea is to create a mock visitor using EasyMock and pass that to the accept() method of the structure I had created by hand to set-up the expectation. Once that was done, I could then simply pass the same mock to the accept() method of the structure constructed by the builder:

public void testBuilderMakesIdenticalStructureToOneBuiltByHand() {
    // Create the two structures
    Node createdByHand = createByHand();
    Node createdByBuilder = createByBuilder();

    // Visit the one created by hand to set-up the expectations
    NodeVisitor visitor = EasyMock.createStrictMock(NodeVisitor.class);
    createdByHand.accept(visitor);
    EasyMock.replay(visitor);

    // Visit the one created by the builder to verify
    createdByBuilder.accept(visitor);
    EasyMock.verify(visitor);
}

private Node createByHand() {...}

private Node createByBuilder {...}

Note: I’m using the latest version of EasyMock that supporst JDK 1.5 generics however I’m not (nor will I ever be) using static imports as suggested in the documentation!

This time, it felt Good™. I could use the same visitor for testing, reporting and persistence, all without the need to break encapsulation.

Now while I’m really not keen on igniting a religious flame-war over mock objects in general nor mock object libraries in particular, the fact that EasyMock works against the real interfaces – as opposed to using string descriptions ala JMock– was a huge advantage in this case.

Sufferin' Sukertash

By

Wouldn’t you know it! A week after The Book leaves the warehouse, I find a mistake in the very first figure! I’ll never criticise another book EVER again. Ok, I’ll criticise the book but not the author(s).

Thankfully there’s an errata page; not that I’ve ever visited one for a book that I’ve bought mind you but still, it’s somewhat comforting to know.

What’s particularly amusing is that the first error submitted was by me, a co-author LOL.

Constraining Design in Search of Elegance

By

Rather than play with the latest shiny new framework, language, etc. my vice is continually trying new and/or whacky – for me at least– programming/design techniques. To be fair, I don’t tend to thrust these upon unsuspecting clients as the new way of doing things. Rather, I’ll start a new pet project of some kind and try to push the paradigm as far as possible and see where it – or I – break down.

Most of the time these “techniques” manifest themselves as a set of constraints or rules for coding; something akin to a manual Checkstyle or PMD for design rather than coding conventions. So just like constraining method lengths and Cyclomatic complexity help shape a design by forcing me to actually think about what I’m trying to achieve, I like to play with other types of constraints.

For example, James and I had a go at 100% TDD for a Swing application many, many moons ago. Again not so much because we think 100% TDD is necessarily a good (or bad) thing but more in attempt to push the idea as far as possible, just to see how it and we would react under pressure so to speak. The results were actually very interesting and made me want to find someone prepared to pay me money to build a rich-client application (Not using Eclipse RCP!)

After I started doing some Objective-C some months back, I was forced to deal with the fact that there was no such thing as a private method – everything in Objective-C is effectively public. I then started to think about what it might be like to apply the same thing to my Java code; what if I was forced to make every method public? How would that affect my design.

Interestingly it had a largely positive effect: I started making smaller classes with well defined behaviour that made sense to be public. In a way, I was forced to make myclass behaviour more cohesive. The problem was of course that, as with anything that is approached in such a strict and unforgiving manner, there are times when it just makes more sense to have a private method that can be re-used or more often, helps to make the code more readable.

So for the most part, I was happy with the outcome: assuming behaviour is public yet not wishing to expose all of that behaviour forces me to compose large classes from smaller ones thereby hiding “private” implementation detail in public methods on other, re-usable, classes.

More recently I decided to try a couple of other things out on a project. These were:

  • No if’s;
  • No casting to expose “conditional” behaviour; and
  • No getters & setters – i.e. tell don’t ask.

Nothing special here really, but I wanted to see how far I could push the ideas and what effect that had on my design and productivity.

The first – no if’s– is relatively simple to address through the use of polymorphism and Maps as jump-vector tables; techniques most people probably use anyway.

The second – No casting to expose “conditional” behaviour – is a little harder. To completely eradicate. Firstly, I was using Java 5 with “generics” to remove the need to cast items in collections – although if you’re not careful, the code can get quite messy with all the “devils horns” – however, the real problem comes when you have a group of classes all related via an interface where some of the implementations provide certain behaviour and others don’t. This was most noticeable when implementing anything that resembled a Composite Pattern.

Enter the Courtesy Implementation. In every case where I ended up needing to implement a method that didn’t “make sense” it would have been a programmatic error to have called the method on an instance of that particular class anyway so I simply threw an UnsupportedOperationException. At this point I wished that would happen by default; that by implementing an interface you could somehow say you weren’t going to support certain methods. A pretty stupid thing to want really, given I’m working in a strictly-typed language.

And finally, tell don’t ask. The code – comprising 50 main classes and slightly fewer test classes (tsk tsk) – has zero (0) getters and setters. Admittedly I wasn’t implementing a CRUD application so that made things easier but there were times when I thought I would need a getter but managed to get around that need quite elegantly (IMHO) through diligent use of simple call-backs (no real closures in Java unfortunately); more complex Visitors; implementing Comparable; etc. In other words, lots of interfaces.

One thing that did arise though was the constant fight against cyclic-dependencies. One example where this is particularly obvious is with visitor. The “standard” way to write a visitor is something along the lines of:

public interface Visitor {public void visitX(X x);public void visitY(Y y);}public class X {public void accept(Visitor visitor) {...}}public class Y {public void accept(Visitor visitor) {...}}

The problem with this is that the Visitor depends on X and Y yet the classes X and Y both depend on Visitor: cyclic dependence.

Interestingly, the “usual” way to implement the visitor would probably look something like this:

public class PrintingVisitor implements Visitor {public void visitX(X x) {out.println("X:" + x.getName());}public void visitY(Y y) {out.println("Y: " + y.getTotal());}}

But recall that I had imposed the constraint of no getters so instead re-worked it like this:

public interface Visitor {public void visitX(String name);public void visitY(int total);}public class PrintingVisitor implements Visitor {public void visitX(String name) {out.println("X:" + name);}public void visitY(int total) {out.println("Y: " + total);}}

Like anything, this is open to abuse, but there are no longer any cyclic dependencies and the only time the guts of X and Y are exposed is when calling on the visitor.

The example just shown is very simple and won’t work in all cases of course but it does highlight how a bit of extra thinking can lead to interesting, and hopefully richer and more useful, designs; the constraints I had imposed seemed to force me to think more about the behaviour and less about the data. For some of you freaks who find that very easy to do I’m very happy, but for mere mortals such as myself, having a few rules-of-thumb to know when I’m being “dumb” makes life that much easier.

Another really interesting thing for me in all of this is that statically-typed languages such as Java force me to make all my interfaces explicit. That is, I need to create physical interfaces so as to remove the cyclic-dependencies between concrete classes. However, with languages such as Ruby, Smalltalk etc, the interfaces are implicit. In a sense, Ruby and Smalltalk allow me to define interfaces at the method level; a much smaller level of granularity than is practical with Java. When I asked a old smalltalker friend of mine about how he would have dealt with cyclic-dependencies, he replied “we never worried about it; if the object responded to a message that’s all that mattered.” I repeated this answer to another non-smalltalk friend of mine to which he mused “and they probably created a lot of spaghetti!”

So, while many people are clamouring for more-and-more functionality from their programming language, API’s etc. I think sometimes I’d actually prefer less; so long as long as it’s the right set of course ;-)

Domain Specific Languages: Objective-C, Ruby and Java (and Groovy)

By

I’m forever trying to “improve” my coding and design skills; I say “improve” because there is always the risk that I’m making changes for change sake. One thing I really try hard to do is remove any notion of getting/setting properties of objects and instead focusing on behaviour.

Now I’ve always tried hard to do this but it’s a skill that definitely takes some time and constant practice. TDD certainly has made my life easier by giving me some tools for this but more recently I’ve really been making an effort to try and “design” my classes in a way that creates Domain Specific Languages (DSL). DSLs enable you to write code that is hopefully more readable and understandable and therefore easier to write, debug and maintain. (At least that’s the ide in principle anyway.)

I use a variety of languages in my day-to-day work and I’ve found that the effort required in creating a DSL to be vastly different depending on the language. Of the few languages I’ve actually used in anger (Smalltalk unfortunately not being one of them) Objective-C really does provide a nice syntax for creating DSLs (once you get your head around the square brackets).

For example, take the age-old problem of transferring money from one account to another. In Objective-C, assuming we have an Account class with a transfer() method, we can write something like this:

id source = ...;id destination = ...;[source transfer:20.00 to:destination]

_ Using floats for currency is generally a bad idea but it’ll do for illustrative purposes here :-)_*

Notice the use of named parameters to really help convey the intent. This is actually an optional feature – you can still use positional arguments if you like – but one I use exclusively.

The transfer() method might look like this:

-(void)transfer:(float)amount to:(id)destination {[self debit:amount];[destination credit:amount];}

Again, ignoring the unfamiliar method declaration (you’ll just have to trust me when I tell you that you do get used to the language and even love it), it’s all pretty nice and readable.

Essentially, when calling the method, the identifier that preceeds a colon serves as the name of each argument – ie as used by the caller– with the method name itself serving as the name of the first argument and to for the second.

Once inside the method, the identifier after the colon serves as the name of the argument to be used: amount and destination.

All up, Objective-C is very concise and allows for the creation of fairly nice DSLs without much effort at all. In fact from what I can tell, most Objective-C code turns out to be more-or-less DSL-like; it’s typical to see methods calls that look like:

[report printTo:printer withPagination:YES]

The next example I whipped up uses Ruby. Now, I have to admit that I have all of about 3 days of Ruby experience so if you can come up with a better way please, please, please let me know. So, caveats aside, here is the same example in my bestest Ruby, again starting with the usage:

source = ...destination = ...source.transfer :amount=>20.00, :to=>destination

This uses a ruby hash – an associative array like a HashMap or Hashtable in Java. You usually need to wrap the hash definition in curly-braces but this can be omitted when the hash is used as the last – or only – parameter.

Now for the method itself:

def transfer paramsamount = params[:amount]self.debit amountparams[:to].credit amountend

Pretty good really but I still have a preference for the Objective-C use of named parameters. I did read in Programming in Ruby that named parameters was to be a feature of Ruby at some point but hasn’t yet made it. I also read somewhere recently that Ruby 1.9 will have a slightly simpler calling syntax so the invocation will look like this:

source.transfer amount:20.00, to:destination

The only Ruby-based DSL I know of is Rake but again my experience with Ruby is somewhat limited.

And finally Java, IMHO the ugliest of the bunch. To achieve something similar in Java seems to me at least (and again, somebody prove me wrong puhlease!) that named parameters with an even remotely useful syntax requires a combination of inner-classes and method chaining. So, to achieve a calling syntax like this:

Account source = ...;Account destination = ...;source.transfer(20.00).to(destination);

Requires something at least as complicated as this:

public class Account {...public Transfer transfer(float amount) {return new Transfer(amount);}public class Transfer {private final float amount;Transfer(float amount) {this.amount = amount;}public void to(Account destination) {Account.this.debit(amount);destination.credit(amount);}}}

The best example of a Java-based DSL that I can think of would probably be JMock.

And finally, by popular demand, a Groovy example. Groovy currently supports named parameters for calling methods that accept a Map so the calling syntax is a lot like Objective-C:

def source = ...def destination = ...source.transfer(amount:20.00, to:destination)```

The transfer() method itself then becomes something like:

void transfer(params) {def amount = params.amountthis.debit(amount)params.to.credit(amount)}

Which looks unsurprsingly like Ruby. Alas, I have no real-world example of a Groovy-based DSL to show you.

The Computing Disease

By

My iPod has been getting a real workout lately. I’ve been getting into podcasts and audible books. I’ve never seem to make the time to read paper books anymore and when I do I always manage to fall asleep after a few paragraphs so listening to them instead works well out particularly for me.

The current book is The Pleasure of Finding Things Out by my all-time favourite physicist (yes I have a favourite), Richard P. Feynman. I’ve always liked Feynman, mainly because his approach to life and learning seems to fit with my ideal – not necessarily reflected in reality but I do try.

Over the years I’ve read a number of his books, papers and lectures etc. and he always seems to have such a great outlook on life, learning, love, you name it. IMHO, a man with his head screwed on just right. I especially like his lectures on physics and his thoughts on computing. He has a way of making difficult material accessible to the likes of yours-truly.

Among many other things, Feynman states that knowlegde without understanding is pretty much a waste of time; the idea that just being able to perform some function or know the name of something without undertsanding what you are doing or the nature of that something, is not only pointless but inefficient and makes you largely ineffective. A subject that is very close to my heart also.

Yesterday I was listening to one of his talks on his time at Los Alamos on the Manhattan Project. He was talking about how they developed sophisticated – even by today’s standards – algorithms for utilising many computers – adding and multiplying machines – in parallell. The problem was that although they had ordered a number of IBM machines, it would be sometime before the machines would arrive and even then they woudl need to be assembled. In the meantime they decided to start writing and debugging their programs. To do this, they enlisted the help of a group of women to act as the adders and multipliers – like a typing pool only performing calculations instead. Amusingly, because of the way the algorithms worked and because of the state of technology at that time, the women managed to process the data as fast as the machines could. The only problem was that the women got tired and needed sleep, food, etc.

Anyway, in all this, Feynman makes a great quote which tickled my fancy:

There is a computer disease that anybody who works with computers knows about. It’s a very serious disease and it interferes completely with the work. The trouble with computers is that you ‘play’ with them! - Richard P. Feynman

Of course we all prefer to call it “innovation” ;-) but at least it’s nice to see that the phenomenon isn’t a recent one – apparently even the great Von Neumann was afflicted.

ActionScript: JavaScript in Flashy Pants?

By

One of the jobs I’m doing at the moment involves Flex – and consequently Flash – for the front-end and Java at the back-end, most of which involves writing ActionScript.

If you haven’t used ActionScript before, you’d be forgiven for thinking you were writing JavaScript. Well, in fact you are writing JavaScript with a few changes, not necessarily for the better IMHO – If you read the documentation you’ll discover that ActionScript is indeed based on ECMA Script, the same specification that was retro-fitted to JavaScript.

From what I can tell, ActionScript 1.x was pretty much exactly JavaScript. Version 2 on the other-hand adds some syntactic sugar to the language; no doubt an attempt to make a prototype-based language appear more like a class-based language in the hope of attracting all the Java developers. I’ll get into these additions in a bit but in any event, I find it highly amusing when Macromedia proclaim that version 1 was somehow a functional language and that version 2 is now a fully-blown O-O language.

(As an aside, I interviewed some potential developers the other day who said they loved ActionScript but thought JavaScript was a language for doing hack-work. I can only assume that opinion comes from having only used JavaScript for handling onXXX events in a browser rather than any objective comparison of the langauges themselves.)

So, on to some of the more notable changes to the language starting with type-safety. JavaScript is weakly typed. This is a topic of biblical proportions so I’ll leave alone the merits or otherwise of weak-typing suffice to say that I like it. In their infinite wisdom, Macromedia decided that what was needed was a bit of strong (or strict) typing. This is enforced by the compiler with a combination of type declaration after variable and parameter names:

var foo **: Number**;

Unfortunately this type-safety is limited to compile-time checking – nothing happens at runtime, much like Java’s generics. Not so much of a problem I guess – I didn’t want the strong typing in the first place – but amusing nonetheless.

So the next question is, how do you know what functions are available for a given type? In JavaScript these are essentially defined at runtime by adding behavior to a prototype. Well why not add some more syntax to the language?

**class** MyClass {**private** var num : Number;**public** MyClass(num : Number) {this.num = num;}public getNum() : Number {return this.num;}}

Ok, so that’s probably a little easier for most people to understand than:

MyClass = function(num) {this.num = num;};MyClass.prototype.getNum = function() {return this.num;};

But I actually find the “new” way actually involves a lot more typing than the good-old-fashioned way – which once you’re used to is easy to read anyway – and hides the fact that it is still a prototype-based language and NOT a class-based one. (I also quite like the way prototype declares “classes” but I haven’t found the time to start doing it that way just yet.)

You can also declare property accessors just like in VB/C#/etc:

class MyClass {private var num : Number;...public **get** num : Number {return this.num;}public **set** num(num : Number) : Void {this.num = num;}}

Again, great if you like that kind of thing; I’m still not convinced I do.

The other thing that gets people is the scoping rules. JavaScript has some pretty funky scoping rules which once you’re used to and understand work just fine. Again, because ActionScript looks like Java, developers don’t realise the importance of understanding the scoping rules.

ActionScript also introduces another new keyword: dynamic. This can be used when defining a class and indicates to the compiler that it should NOT do strong type checking when invoking methods and accessing properties of the class – either from within or from outside the class. Again, I find this a highly amusing construct as I can always defeat the type checking the old-fashioned way anyhow: myObj["doSomething"](15);. Yes, I agree, that’s a bit of malicious code but what I’d prefer is an option to turn on/off strict typing at a project level and not on a per-class basis.

Interestingly, someone recently pointed me at an open source compiler for ActionScript. I wonder if I could just download the code, remove the strict type checking and be done with it ;-). Oh and there’s also a unit testing toolkit as well.

All in all, I quite like using ActionScript. I’ve only played around a bit with Flash/Flex bindings but they seem quite nice too. I actually think it would be pretty easy to build a Cocoa – JavaBeans the way they should have worked – like framework (eek there’s the word!) which I thoroughly enjoy using at the moment.

But when it comes down to it, It has been my experience – and no doubt the experience of others in the JavaScript/Ruby/Smalltalk/Objective-C world – that I can achieve a lot more in fewer lines of readable code without all the syntactic sugar and strong typing. (The caveat being that I’m also a big fan of automated testing.) Moreover, understanding that JavaScript uses prototypes opens up a whole new world of possibilities that further increase my productivity – a fact that became apparent to the attendees of a mini presentation I gave on this subject just recently.

My Biggest Peeves With JavaScript

By

There’s really not a lot to dislike about JavaScript; It’s object oriented – in a way Java can only dream of; weak-typing coupled with dynamic property objects make mocking and testing a breeze; the list goes on. But there are two things about the language that continue to irritate me: Exceptions; and undefined/null. Ok, so I guess that’s three things but the last two are really in the same category.

First up, undefined/null. Let me start by saying that I love the fact that these are actually objects – go null object pattern– but the fact that they silently gobble up any calls made to them is less than helpful. Even less helpful is the fact that I can’t override this behaviour. Unlike every other object in the language, these two don’t seem to have a prototype I can mess with. At least in Objective-C/Smalltalk you have the option of finding out when messages are sent to null objects or to objects that don’t understand them. Thankfully, testing catches most of these problems but where it can’t, I resort to my tried and tested method: runtime assertions. Which leads me to my second peeve.

Exceptions. Well at least JavaScript has them I guess, even if they are called Errors. Sure I can throw them, I can catch them, I can put code in a finally block but I can’t get any information about them. I use runtime assertions all the time in Java, Objective-C and even JavaScript to catch things I haven’t managed to test for or more importantly, things I can’t necessarily predict. Whenever an assertion fails, an exception is thrown which usually dumps a stack trace giving me everything – well almost everything – I need to track down the source of the problem. Unfortunately in all web browsers I use regularly – Safari and Firefox – all I seem to get is the message "Error" printed to the JavaScript console. Great! So I know there is a problem but I don’t know where, nor importantly why? This usually leads me to the JavaScript debugger – probably the best thing that ever happened to the language. Not that I mind using the debugger but a stack-trace is extremely useful!

Managing Sensitive Data on Mac OS X

By

One of the clients I’m working for at the moment mandates – quite rightly so – that any data taken offsite must be encrypted. Mac OS X provides two ways to achieve this: FileVault; and Encrypted Disk Images. (If you want to know how to encrypt emails, see this article.)

FileVault (System Preferences>Security>Turn On FileVault…) is kinda cool: It allows you to encrypt your entire home directory. This might be handy if you’re super paranoid but I’m not; neither do I want the overhead of having everything I write to disk encrypted.

Encrypted Disk Images on the other hand are super cool for this kind of thing. If you’re familiar with Mac OSX then you’ve no doubt used plain disk images before. They’re the .dmg files that are used for distributing most of the software you install. The neat thing about them is that you can mount a disk image and use it just like any other disk on your machine. On top of this, you can encyrpt them so that unless you have the password, no one can peek at the data.

To create a blank disk image:

  • Open Applications>Utilities>Disk Utility
  • Select File>New>Blank Disk Image…

To create an encypted disk image:

  • Open Applications>Utilities>Disk Utility
  • Select File>New>Disk Image From Folder…
  • Choose the folder you wish to use as the source of your disk image; and
  • Press Image

In either case:

  • Enter a filename and location and choose an initial size – disk images dynamically resize so don’t worry too much about this
  • Select AES-128 (recommended) for Encryption; and * Press Create

You’ll then be prompted for a password with which to encrypt – and decrypt – the file. You’re also given the opportunity to save the password in your keychain. This just means you won’t have to remember the password when mounting it on your own machine – If you move the file to another machine or send it to someone else, a password must be entered manually.

Now anytime someone tries to mount the disk image, they’ll be prompted for a password; if they don’t have the password the data is protected, even if they try to read it using another tool.

Once mounted, you can use it as you would any other drive: as a mounted image in Finder; or under /Volumes/ using the filesystem.

MT 3.2 Atom Feed Template Problem

By

I noticed that since I upgraded to MT 3.2 my atom feed – the main one since the switch – wasn’t being displayed correctly in Safari’s RSS Reader. The culprit: a slight problem with the content-type in the template for atom.xml.

To correct the problem, find where it says &lt;content type="html" ... and change "html" to "text/html" and all should be fine again.

The index.xml template works just fine though I’ve yet to bring either the comments.xml or index.rdf up-to-date. The former is just laziness – I need to remember how I converted the original index.html template; The latter is because MT seem to have dropped support for RSS formats <2.0. Neither of these is really an issue as they worked before and continue to work now.

FWIW, I’m considering removing index.rdf sometime soon anyway as I’m pretty sure almost every RSS reader now supports at least RSS 2.0 and most-likely Atom as well.`

Updated 17 October 2005

Seems there are all sorts of problems with the template. I ran it through a feed validator service and I’m frankly staggered anyone can actually read my blog. It seems the content type can be left as “html” after all but I needed to change a whole-lotta other stuff to get it to pass. Interestingly, Safari now sometimes manages to read the whole feed just fine. Go figure? Luckily I recently switched to using PulpFictionLite as my news reader. Safari just doesn’t cut it I’m afraid. Anyway, it’s just another example of what can happen when I try playing with things about which I understand very little. Sigh.

Multiple Mac (Tiger) Logins for Testing

By

I do all my development on my mac powerbook which, up until today, has had only one account: mine. But this morning, as we were trying to solve the last of the MT issues, I needed another login with which to quickly try something out.

It seem as though there was something peculiar about my login that was causing some of the problems so, I open Accounts and created a test user. So far nothing special about his – I’m sure you create test accounts all the time– however it’s always annoyed me that you have to logout to switch users. I mean really, this is supposed to be unix right?.

Tiger (OS X 10.4) has a nifty “Fast User Switching” option which allows you to switch between users while leaving all the applications running. I had heard about this feature some time ago and thought to myself “phe! what do I care?” but I’d never thought about it in the context of testing.

To enable fast user switching, open “Accounts” in “System Preferences” and and click “Login Options”. Tick the box titled “Enable fast user switching” (it’s down the bottom). You should then see a list of accounts in the top-right of the menu-bar.

The great thing about this for me is that I can quickly blow away the account and re-create it; or have multiple accounts all logged in to my apps at once, all from the one machine. Of course the fact that I need to get down to manual testing says more than anything but alas, in this case, I didn’t have much choice. Besides, as James has berated me for in the past: Just because you have automated tests, doesn’t mean you can avoid manual testing as well.

On a side note, I also love SSH as it allowed me to install a public-key for the MT support guy to login to my shell account without needing me to create new users – which I can’t do anyway because it’s not my server :)

Update (2 September 2005)

I noticed today that Redstone Software have a new version of OSXvnc that supports this, allowing you to view (and control) the other logins without even switching! It’s a free download; as is Chicken of the VNC – A VNC client – which you’ll also need.

All Your Keystrokes Are Belong To Us

By

I stumbled upon this paper while doing my weekly browse through articles on CleverCS. To quote from the abstract:

… a novel attack taking as input a 10-minute sound recordingof a user typing English text using a keyboard, and then recovering up to 96% of typed characters…

They even run the recovered text through a spell-checker which successfully corrected a mistake in the text as it was originally typed lol.

Pretty cool idea although I figure if you can sneak a microphone into a building – say by sending someone a bunch of flowers or a promotional desk-lamp, etc. – you can probably just as easily “upgrade” someone’s “faulty” keyboard and record keystrokes that way instead.

MovableType Weirdness Again

By

Some of you may have noticed some decidedly odd behaviour with the blog the past couple of days: you couldn’t post comments; and I couldn’t post new entries. Somehow – I’t’s still a mystery – things just stopped working. The suspicion I have is that there was some problem with the Berkeley DB files after a server upgrade but I can’t be sure.

For the most part, MT behaves itself pretty well – to-date I’ve hardly had any problems – but when I do have a problem it usually requires quite a bit of effort to work out what went wrong and fix it (if possible).

So anyways, after unloading, reloading, repairing, upgrading MovableType and performing all manner of other unix witchcraft – most of it performed at 3am – things are finally back up and running again. The next step will be to migrate from Berkeley DB to Postgres in the next day or two so there may be a few more minor interruptions a long the way.

The upshot of all this is of course that I’m now running on the latest (and hopefully greatest) version of Movable Type. Having said that, blogging ain’t my profession – god save you all – so I’m not sure that an upgrade of MT actually buys me much except some more long nights attempting to work out why things stopped working.

Everything seems to be in or-der but if you notice any more weirdness please let me know, otherwise I’ll get back to eating my orange sher-bert

Update (1 September 2005)

Ahh yes, I knew it was too good to be true. Robert kindly informs me that comments are still busted: you can read them just not post them. After a little investigation, it looks like there is some problem with the new version of SCode. It worked for me because I’m authenticated on my own blog but it doesn’t seem to work for anyone who isn’t authenticated. Sheesh! Maybe I need to write a suite of tests for my own blog!?

Thankfully, the solution is pretty simple. Thanks to the author of the plugin who responded to my forum posting: The file SCode.pm contains the “$app->{requires_login} = 1;”. This should probably read: “$app->{requires_login} = 0;”.

Update (2 September 2005)

All converted to PGSQL now thanks to the truly awesome support people at MovableType. They ironed out the last little issues with upgrading and now I’m off Berkely DB. Hopefully this now means no more file corruptions.

Attack of the Killer GPUs

By

After reading about the latest PlayStation, XBox, GameCube, etc. I was struck by how much raw processing power these machines have and how they manage to deliver such massively parallel computing at relatively low prices. For example, according to an article I read recently in Popular Science, the latest PlayStation sports nine dual-core processors, Rambus XDR RAM (apparently supporting data rates of 25.6 GB/sec) and a Rambus IO chip that supposedly moves data around at 76.8 GB/sec! All for what, a couple of hundred dollars?

Of course these machines sell in the millions and you pay through the nose for the games themselves but even still.

Then this morning, my brother forwarded me a link to an interesting article on Nvidia:

…in a recent contest to build the world’s fastest database server, the winner was a university professor who ported SQL software to run on an Nvidia GPU…

I can’t vouch for the facts of said article but if that quote is anything to go by, maybe all that wasted (oops I mean un-tapped) processing power might get some interesting use.