epistemologic

Amit Rathore’s blog about software development and project management

Archive for the 'code' Category


Easy external DSLs for Java applications

Posted by Amit Rathore on April 27, 2007

Or JRuby for fun and profit

I’ve been developing software for some time now, and have recently found myself applying ideas from various esoteric areas of computer-science to every day tasks of building common-place applications (often these concepts are quite old, indeed some were thought of in 1958).

One powerful idea that I’ve been playing with recently is that of embedding a DSL (domain specific language) into your basic application framework - and writing most of the features of the application in that DSL.

This is simply an implementation of the concept of raising the level of abstraction. The point, of course, being that when writing code in a DSL implemented in such a fashion, one can express ideas in terms of high-level abstractions that represent actual concepts from the problem domain. In other words, it is like using a programming language that has primitives rooted in the domain.

A lot of people have been writing about this kind of software design - and most implement these ideas in a dynamic language of their choice. How does one go about doing the same in a language like Java? That is what this article is about. And I cheat in my answer. Consider the following design stack -

Creating DSLs in JRuby

I propose that you only implement basic and absolutely required pieces of functionality in Java - the things that rely on, say, external systems that expose a Java interface, or some EJB-type resource, or some other reason that requires the use of Java. The functionality you develop here is then exposed through an interface to the layers above. You can also add APIs for other support services you might need.

The layer above is a bunch of JRuby code that behaves as a facade to the Java API underneath. This leaves you with a Ruby API to that underlying Java (and other whatever, really!) stuff - and makes it possible to code against that functionality in pure Ruby. The JRuby interpreter runs as part of the deployable and simply executes all that Ruby code transparently. As far as your Ruby code is concerned, it doesn’t even care that some of the calls are internally implemented in Java. Sweet!

We can stop here. At this point, we are in a position to write the rest of our application in a nice dynamic language like Ruby. For some people, a nice fluent interface in Ruby suffices - and keeps all developers happy. This is depicted on the top-left part of the diagram.

However, we can go one step further, and implement a DSL in Ruby that raises the level of abstraction even more - as referred to earlier. So on top of the Ruby layer, you’d implement a set of classes that allow you to write code in simple domain-like terms, which then get translated into a form executable by the Ruby interpreter. This is shown in the top right part of the diagram. Ultimately, potentially any one (developers, QA or business analysts) could express their intent in something that looked very much like English.

So where to write what?

How much to put in your Java layer depends on the situation - some people (like me) prefer to write as little as possible in such a static language. Others like the static typing and the associated tool support, and prefer to put more code here. When merely shooting for a little bit of dynamism through the DSL engine in the layers above, most of the code could be written in Java, and a fluent API in the dynamic language could be enough. When shooting for rapid feature turn-around and a lot more flexibility, most of the code could be in the DSL or in the external dynamic language.

The answer to this question really depends on things like the requirements, team structure, skill-sets, and other such situational factors.

OK, so where’s the code?

My intention with this post was to stay at a high level - and talk of how one could structure an application to make it possible to embed a scripting engine into it, and to give an overview of the possibilities this creates. In subsequent posts, I will talk about how actual DSLs can be created, tested, and also how a team might be structured around it.

Posted in DSL, code, java, jruby, languages, meta, multi-paradigm, ruby | No Comments »

The joys of large-screen monitors

Posted by Amit Rathore on April 16, 2007

In my ideal world, I’d have two 30″ Apple Cinema Displays, but my less than ideal world ain’t so bad either. My souped-up 24″ iMac serves me well for my day to day work, quite well indeed.

I’m positive that my productivity gains are large - I always have emacs open with at least 4 frames, or eclipse with several views open without anything important having to stay annoyingly minimized. I also have a browser open with lots of tabs, a bunch of terminals open with iTerm, and a bunch of other what-nots, and managing all this is easy. This multiple desktop manager makes it even easier. Finally, if all those windows distract you, use Think!

Anyway, if you want a quick and relatively cheap way (in the long run) to become more productive, get a large screen monitor. Or three.

Posted in code, tech, tools | No Comments »

From freedom languages to Java (and back again?)

Posted by Amit Rathore on April 8, 2007

Recently, I started working with Java again. I had little choice in the matter, really, since its for an upcoming product in the mobile application development tools space, and I’m focusing on the Java Micro Edition area. I’ll have more to say on this skunkworks initiative another time. (Watch this space, and all that).

I’ve been using mostly other languages in the recent past, Ruby, a little Python, Common Lisp, a little Haskell. But mostly Ruby. And it seems that having stayed Java-free for about two years has made me really rusty. That apart, this time around Java started out feeling annoying, and morphed into being mostly amusing. In an annoying way. The question I constantly have to tell myself to refrain from asking (out loud, and to the world in general) is – “Why can’t the bloody runtime figure this out for itself? Why do I have to type this extra (vestigial) code?”

In any case, working on the new Java Micro Edition platform again is nice – reminds me of a project I did at college - and of simpler times…

Posted in code, java, languages, micro java, mobility | 5 Comments »

Perfect vs. Shipped

Posted by Amit Rathore on March 31, 2007

I overheard an amusing comment in my team-room the other day, I think it might have been Kris Kemper who said it - “Anyone who knows Ruby On Rails has a half-done personal project that’s going nowhere”. How true. I have at-least three.

The thing is, in my mind I’m always envisioning these grand cathedrals, and even when I do start work on any one of them, I never seem to quite finish them. Or I don’t complete everything properly (or quite enough to be production-ready), and the application is never quite done.

I think it has to do with a lack of focus. I find myself thrashing between the hundreds of things that interest me, and I end up with a ton of unfinished work. I’m very much into lean software methods, and I know that all I’m doing by operating this way is creating a lot of inventory. I seem to be able to use lean and other workflow management techniques at work, but in the world of my personal projects, I seem to be at a loss.

Sometimes, it has to do with trying to get everything perfect. After all, since it is a personal project, I feel like I don’t have a delivery dead-line, so I can take the time to get it right. Which leads me down the rabbit-hole of perfection and cathedral building, with no real end. Cause there probably ain’t anything called perfection.

When consulting for our various clients, I’ve a clear idea in my mind about the compromises and trade-offs needed between design, architecture, refactoring, and delivery. And I aggressively do whatever might be needed to prod the folks along (be they developers, or product-owners) to get the thing done and into production. After all, there’s always another iteration coming up, and there’s always a next release.

So why the heck can’t I seem to do the same thing when I’m working on a nights-and-weekends project?

Posted in architecture, code, design, learning, process | 3 Comments »

Ruby, managing global variables, and dynamic scope

Posted by Amit Rathore on March 25, 2007

Everyone knows that global variables are bad. However, they are quite unavoidable. Java’s System.out is an example.

Globals, sometimes offer a certain kind of flexibility. They offer a way to tweak the behavior of the entire (or a subset of) the system. For instance, one can redirect System.out to a different stream (into a file, say) and capture all the messages a program spits out.

This kind of stuff works nicely. Except when someone else goes and changes the same variable to something else in another part of the code, and you’ve no idea where.

What is needed, is something like optional dynamic scope, so that the globals can be used when needed, but can be managed better. After all, from the above example, what seems to be needed is a way for a piece of code to say - for my purposes, and for all code that runs when I’m called, I want the value of this global(s) to be _something_, and when I return, these globals should be reset.

This can be done manually, by saving the existing value of a global before setting it to something else, and then resetting it back when the code block completes running. Perl and Common Lisp have had a mechanism to do this type of stuff for a long time, built into the language.

Here’s a hacky (and probably naive) way to implement this in Ruby, to illustrate how this might work -


module Let
def let(bindings, &block)
old_bindings = capture_existing_bindings_for(bindings)
block.call
rehydrate_old_bindings_with(old_bindings)
end
def capture_existing_bindings_for(bindings)
old_bindings = { }
bindings.each do |k, v|
old_bindings[k] = eval “@”+k.to_s
create_binding k, v
end
return old_bindings
end
def create_binding(var_name, value)
instance_eval “@#{var_name}=value”
end
def rehydrate_old_bindings_with(old_bindings)
old_bindings.each do |k, v|
create_binding k, v
end
end
end

And the way you would use this, would look something like this -


require ‘let_module’
include Let
@num_var = 1
@char_var = ‘a’
class Car
attr_reader :name
def initialize(name)
@name = name
end
end
@obj_var = Car.new(”hyundai”)
def do_something
puts “num_var is ” + @num_var.to_s + “, char_var is ‘” + @char_var.to_s + “‘, obj_var is ” + @obj_var.name
puts “returning”
end
do_something
puts “changing num_var to 2, char_var to b, obj_var to ‘kia’”
let :num_var => 2, :char_var => ‘b’, :obj_var => Car.new(”kia”) do
do_something
puts “changing num_var to 3, char_var to c, obj_var to ‘toyota’”
let :num_var => 3, :char_var => ‘c’, :obj_var => Car.new(”toyota”) do
do_something
end
do_something
end
do_something

And when run, would produce this -

num_var is 1, char_var is ‘a’, obj_var is hyundai
returning
changing num_var to 2, char_var to b, obj_var to ‘kia’
num_var is 2, char_var is ‘b’, obj_var is kia
returning
changing num_var to 3, char_var to c, obj_var to ‘toyota’
num_var is 3, char_var is ‘c’, obj_var is toyota
returning
num_var is 2, char_var is ‘b’, obj_var is kia
returning
num_var is 1, char_var is ‘a’, obj_var is hyundai
returning

This could be one way to control unruly global variables in Ruby.

Posted in code, languages, ruby | No Comments »

Java Micro Edition development - annoying emulator error

Posted by Amit Rathore on March 21, 2007

After a long time, I recently started playing with the Java Micro Edition again. Many years ago, I had downloaded and installed the Wireless Toolkit from Sun’s website (then in beta), and had hacked together common mobile games – snake, hangman, and the like.

So, when I downloaded the toolkit this time (v2.5 now), it was annoying to find that I couldn’t even seem to run a basic midlet without the emulator barfing at start up time, with an inexplicable ‘Uncaught exception java/lang/ArrayIndexOutOfBoundsException’ – no line numbers, nothing. The emulator screen wouldn’t list the midlet name either, so clicking on the soft button would simply print the same exception message again.

Google was of limited help. More annoying.

Finally, I just played around with different configurations during launching the midlet, and when running it in “class” mode (you have to specify the midlet class), it seems to work.

So there’s a work-around for you.

Posted in code, java, micro java, mobility | 1 Comment »

CruiseControl.rb - Continuous integration for ruby projects

Posted by Amit Rathore on March 18, 2007

cruisecontrol.rb

I downloaded and installed CruiseControl.rb today - from the ThoughtWorks website. Well, I suppose ‘install’ is not quite the right word as it comprised entirely of running a couple of commands, and took all of 30 seconds.

It works beautifully, right out of the box! The example on the website didn’t have any reference to the situation where you connect to your subversion server over ssh, so when I went ahead and tried it, it succeeded and then gave me the following message -

IMPORTANT!!! - It looks like you are connecting to your repository with an svn+ssh connection. For cruise to build this project, you need to have set up authentication caching for ssh, see this article
http://subversion.tigris.org/faq.html#ssh-auth-cache

What a pleasant surprise! I like software that was designed with users in mind. The information above for setting up ssh authentication works like a charm, btw.

Posted in ThoughtWorks, code, config management, rails, ruby | No Comments »