Mats Helander has written an excellent article on how to manage your domain model with some intelligent design trade-offs. It’s a lengthy article that even manages to introduce AOP as well. If you start reading it and wonder where it’s going, just carry on reading…it is written in an evolutionary style. Nice article, Mats! UPDATE: I have written the Java equivalent of the listing in Mats’ article and attached it. The AOP part uses SpringFramework 2.5 and AspectJ.
Category Archives: Software Development
Get Cooking with JRuby on Rails
Some of the companies that I interact claim that they will never switch to Ruby on Rails (or just plain ‘ol Ruby) for that matter. But with JRuby reaching 1.0 status (and currently on 1.0.2 with 1.1b1 already released) this changes the situation somewhat. Now it is possible to develop Rails apps and run it on your Java infrastructure that make use of native JDBC connections and a whole bunch more.
Pre-requisites
Since we want to run a Ruby on Rails app on a Java application server, we need to have a Java web container such as Tomcat, Jetty or Glassfish. In my case, I’ll be dropping the app into into a Glassfish domain. I guess that this should work just fine for Tomcat as well, but I have not verified this as yet.You also need a database and I will be using MySQL. If you are going to use another database, you need to make sure that the ActiveRecord-JDBC adapter has been developed for the DB. ActiveRecord is the ORM for Rails apps. Currently, there are ActiveRecord-JDBC adaptors for HypersonicSQL, Derby, MySQL and PostgreSQL. This is true for version 0.6 of ActiveRecord-JDBC. For other adapters, you will need to specify a proper JDBC URL in your application’s database configuration file, config/database.yml. This will make a lot more sense once you finish this exercise.All of the above (except or ActiveRecord, of course) should be stock standard goodies on any self-respecting Java development box. With this place, let’s get cooking.
Install JRuby
Download the JRuby bin distribution from the JRuby downloads page. At the time of writing this, 1.1b1 has been released. I am currently using the 1.02 release. Unzip/untar the file to somewhere convenient, add an environment variable JRUBY_HOME to point to the extracted directory, and add JRUBY_HOME/bin to your path.
/> cd ~/tools /> tar xzvf jruby-bin-1.02.tar.gz
/> export JRUBY_HOME=~/tools/jruby-1.0.2
/> export PATH=$PATH:$JRUBY_HOME/bin
You can verify your JRuby installation with:
/> jruby -v
ruby 1.8.5 (2007-11-01 rev 4810) [i386-jruby1.0.2]
You will notice two versions being reported. The first tells us that the ruby implementation is version 1.8.5 and the second tells us that it is running on jruby 1.0.2 on i386 platform. If you are new to ruby, then you need to know that there are different implementations of ruby, with the definitive one called MRI (Matz’s Ruby Implementation – Matz is the original author of ruby). JRuby is an attempt at a complete port of MRI to Java, aiming to eliminate all dependencies on C libraries. This is one of the significant points about JRuby: it is pure Java.
Install RubyGems
The closest Java equivalent of RubyGems is Maven or Ant+Ivy. Gems is a library and dependency management tool for ruby. On a native ruby install, you would have to download and install RubyGems, but JRuby already has RubyGems rolled in. Take a peek at JRUBY_HOME/bin and you should see an executable file called gem. So, nothing more to do here. What the heck, let’s verify that RubyGem is working.
/> jruby -S gem -v
0.9.4
If $JRUBY_HOME/bin is first in your path, then you can try /> gem -v. The -S tells jruby to run the command that follows from $JRUBY_HOME.For the ruby folk, you should realize that JRuby has rolled in RubyGems version 0.9.4 which is as fresh as it comes.The closest Java equivalent of RubyGems that I can think of is perhaps Maven or ANT+Ivy. But RubyGems takes the prize hands-down for its absolute simplicity. Install rake and Rails below and see what I mean.
Install Rake
Rake is a really good build tool for ruby (i.e a make for ruby, hence the goofy name). Once you start writing rake build scripts, you will wonder why one earth you thought ANT is nice. Anyway, let’s install rake.
/> jruby -S gem install rake
Install Rails
Now that you’ve seen the goodness of RubyGems, install Rails and the ActiveRecord for JDBC.
/> jruby -S gem install rails -v 1.2.6 -y --no-rdoc --no-ri
/> jruby -S gem install activerecord-jdbcmysql-adapter --include-dependencies
We are deliberately installing Rails version 1.2.6. Rails 2.0.1 was released in early December 2007 and I have not taken 2.0.1 for a drive under jruby yet. So, we’ll stick to version 1.2.6 which is still great.
Get MySQL Ready
We’re heading for the home straight with all this setup and configuration nonsense. Just a couple of things to do.
- Copy the MySQL JDBC driver to
$JRUBY_HOME/lib. - Create a MySQL database called
testapp_development. Rails apps require three databases; one for development (suffixed_development), one for unit testing (suffixed _test and is wiped clean with every test run) and one for production (suffixed _production). For this exercise, we will just use the development database with full rights given to the MySQL userrootwith no pasword.
Create the Rails App
Now the fun starts! Finally!The next command will create a directory with the same name as your application. So, change to a directory that will contain your rails applications. In my case, I keep my applications in ~/projects/jruby.
/> cd ~/projects/jruby
/> jruby -S rails testapp
Now you should have a directory called testapp. Let’s see if our app works. Yes, in rails-land, the app can already be fired up!
/> cd ~/projects/jruby/testapp
/> jruby script/server
This fires up webrick, a built in http server with ruby support built in. Just point your browser to http://0.0.0.0:3000 and you should see the Rails happy page. Kill webrick by hitting CTRL+C.
Link up to your database
Edit the file config/database.yml and change it as follows. Note that the line socket: /tmp/mysql.sock must be removed.
development:
adapter: mysql
database: testapp_development
username: root
password:
and
production:
adapter: mysql
database: testapp_development
username: root
password:
YML files are files that store configuration using YAML, which is a ” is a straightforward machine parsable data serialization format designed for human readability”.Now, let us inform the Rails app that we are using ActiveRecord-JDBC. Add the following to the file config/environment.rb just before the line Rails::Initializer.run do |config|.
if RUBY_PLATFORM =~ /java/
require 'rubygems'
RAILS_CONNECTION_ADAPTERS = %w(jdbc)
end
Create a table (the Rails way)
Sure, we can write a simple SQL script to create the table we want, but for fun, let’s do it using some Rails sugar. You can keep your app running in webrick and still do the this. Just open up another command or shell, switch to your project directory and get going. This is one of the nicest bits of Rails – you can do most things without a restart of your application server.
/> jruby script/generate migration AddGadgetsTable
This should have created a file db/migrate/001_add_gadgets_table.rb. Open this file and edit it as follows.
class AddGadgetsTable < ActiveRecord::Migration
def self.up
create_table :gadgets do |table|
table.column :name, :string, :null => false
table.column :color, :string, :null => false
end
end
def self.down
drop_table :gadgets
end
end
After saving the file, run the following command to create the table. Actually, we’re migrating our existing database to version 001! Database refactoring is a definite goal of Rails. It may not be perfect, but it is certainly better than maintaining a bunch of SQL files.
/> jruby -S rake db:migrate
Even if you’ve never seen ruby before, the above is certainly readable and you can easily understand that we intend to create a table called gadgets with two columns name and color. Actually, there are more than these two columns. Have a look at the table structure and check that a primary key colum id has been added as well.
Generate Scaffolding to maintain the table
I know, I know, I know! Code generation for anything but the most trivial of code can be dramatic for newbies but real code takes a lot more effort. The point here is just to get some Rails code up and running so that we can deploy it in a Java application server. So, please bear with me.
/> jruby script/generate scaffold gadget
Fire up webrick and visit the URL http://0.0.0.0:3000/gadgets. You should see a page with an empty list of gadgets and CRUD links.
Get ready to WAR
We need a few additional rake tasks to be able to build a WAR for our Rails application. The Goldspike plugin for Rails does just that. Let’s install the Goldspike plugin.
/> jruby script/plugin install
svn://rubyforge.org/var/svn/jruby-extras/trunk/rails-integration/plugins/goldspike
All that’s required is to add the WAR dependency on the MySQL driver. What’s great about Goldspike is that we can declare Maven dependencies. Great combination: RubyGems for Ruby-land and Maven for JRuby-land! Open the file vendor/plugins/goldspike/lib/war_config.rb and add the following line to the list of # default java libraries block.
add_java_library(maven_library ('mysql', 'mysql-connector-java', '5.0.5'))
Build the WAR
Now build the WAR using rake.
/> jruby -S rake war:standalone:create
If you look in the root of your application directory, there should be a file testapp.war
Drop it into Glassfish
Start your Glassfish domain, log in to the Glassfish admin console and click the Deploy Web Application link. Browse to the testapp directory and select the testapp.war file. If the app is not enabled, then select testapp, and click Enable.
See it in action
Point your browser to http://localhost:8080/testapp. You should see the Rails happy page, and http://localhost:8080/testapp/gadgets has the CRUD for our Gadget object.As easy as pie! And just as nice!
Treading into OSGi
On my current project, the number of JavaBeans / Spring Beans is becoming a bit too much to handle. What’s becoming quite painful is that there is a significant number of combinations and dependencies between beans, and between the various web applications that we are rolling out. Simply including a few “common” JARs in multiple WAR’s is not good enough anymore.Modularity and dynamic modules has always been painful in Java, mostly due to its ridiculous class loader. But OSGi seems to offer significant improvements in this area. The possibilities of having classes “plugging” into each other, resolving versions, etc., all dynamically is terribly exciting and, at the same time, frightening.Nevertheless, I will be venturing into OSGi land and will blog my experiences and hopefully provide a some simple HOWTO’s and tutorial style posts.
The optimistic concurrency gotcha
In my current project, I have a group of about 7 budding young developers none of whom have done any significant web development. This includes hitching up to a database and using object relational mappers. The one thing that always gets first-timers is stateless nature of the web. And the first solution they come up with is session based statefulness which eventually leads to a scalability bottleneck. The ripple effect of lack of state is that you need to have optimistic concurrency at the data access level. Now most of us just assume that our OR Mapper will solve that for us. And, yes, they do offer optimistic concurrency out of the box, be it with a version column or without. But Mats Helander makes a strong point that optimistic concurrency in most (maybe all) OR Mappers actually kicks for really short durations (milliseconds). In that case, you might as well be using good old fashioned database transactions. Mats suggests that a way to solve the problem is to store original values in the view. Check out Mats’ post and you’ll see why you should be storing, at the very least, your Hibernate version column/property on your view as well.
Not everything has to be Object Oriented
For some time now I have been wondering whether we have become completely obsessed with object oriented analysis and design. Hence my step into the world of functional programming. This led me first to Haskell and also Erlang. Interestingly, Niclas Nilsson has posted a thought provoking piece on InfoQ which asks whether Erlang is the next Java. Also, check out the comment on Scala which is now on my radar as well. Maybe functional languages will be the language for Web 3.0 where semantic interoperability and semantic correctness will be prominent.
Kung Fu Coding – Bruce Lee Style
Bruce Lee would have been one awesome software developer. Even better, I would have really loved him being my coach or mentor. I came a across a site with his views on Jeet Kun Do and was astounded by the relevance to agile software development. There’s definitely something in it for everyone involved in a software development effort: from requirements gathering and problem definition, writing code and unit tests, software architecture and mentorship to attitude and values. Check out the following (anything in italics is a Bruce Lee quote) …
On Understanding the Problem or Domain
One the traps we often fall into when facing a problem domain is that of exploding the problem into spaces that we never anticipated. Often we lose track of the original problem. Users are equally guilty of digressing from the problem space. But check out Bruce Lee’s approach:
In building a statue, a sculptor doesn’t keep adding clay to his subject. Actually, he keeps chiselling away at the unessentials until the truth of its creation is revealed without obstructions. Thus, contrary to other styles, being wise in Jeet Kune-Do doesn’t mean adding more; it means to minimize, in other words to hack away the unessential. It is not daily increase but daily decrease; hack away the unessential.
The key is to remain focused, “to hack away the unessential”, so you can get to the truth – the heart of the problem. Now our stories/use cases and release plans focus directly at the core of the problem. The truth is revealed and the starting point for test driven development is cut to the bone, it’s bare. You know exactly where to start and what you are solving.
Writing Clean Code (without smells)
So we have our problems defined, we have a some cool release plans and we start some early designs. Again, complex solutions ead to complex implementations. In agile software development we always aim for simplicity. This is exactly what Bruce Lee’s Jeet Kun Do is all about.
My movements are simple, direct and non-classical. The extraordinary part of it lies in its simplicity.
and
One must be free. Instead of complexity of form, there should be simplicity of expression.
I always coach teams by saying that “If you draw it, you must build it … otherwise don’t draw anything”. The simpler the solution that is architected, the higher the chance of success at the code level, implementation level, maintenance level, all levels. Bruce Lee maintains that “I always believe that the easy way is the right way.”
Avoiding Code Bloat
So we have our bare-bones problem with a simplist solution possible, and we start coding. How often, have you meandered off to explore some cool feature that your user will just love? But it doesn’t address the problem. And test driven development trys to address that. But here’s some very sobering advice from Mr. Lee:
Don’t indulge in any unnecessary, sophisticated moves. You’ll get clobbered if you do, and in a street fight you’ll have your shirt zipped off you.
From this moment on, the imagery of having my shirt ripped off and getting clobbered is enough to keep me on the right track. At a more basic level, it is the philosophy of suppressing your ego (the “cool” recognition factor) that is so essential in reducing code bloat.
Embracing Change
You crafted your solution, you are about to go live and a new requirement sneaks in. SCOPE CREEP!!! CAN’T DO THAT!!! In Extreme Programming, you are meant to embrace change and react to it in a manner that serves the interests of all stakeholders. However, you can only react if you are flexible, if your design is simple and fluid. Bruce Lee reckons that “One should not respond to circumstance with artificial and ‘wooden’ prearrangement.” If you stick to a rigid point of view, or react rigidly with pre-conceived intent, then that essential new requirement will never see the light of day. Be fluid and react accordingly. If your design is simple and fluid, if your code is simple and fluid, you can embrace the changes.
Use of Tools and Technologies
I often come across teams where the choice of tools, technologies, languages, frameworks, etc becomes an obsession. I have seen far too many architectures where a one-framework/language/tool-will-do approach just kills off an otherwise excellent piece of work. For these situations, remember “Any technique, however worthy and desirable, becomes a disease when the mind is obsessed with it.” There is always a another way to solve a problem, or produce the same result. Don’t become obsessed with your choices. There is nothing wrong with writing core backend code in Java or C# and front end code in Ruby where a dynamic language is, maybe, a better option.Even more appropriate: “Again let me remind you Jeet Kune Do is just a name used, a boat to get one across, and once across it is to be discarded and not to be carried on one’s back.” The way I see it is that once you’ve used something, done some good, there’s no reason to be burdened by it. If your choices have served their purpose then accept that, appreciate it and move on…don’t force the same fit everytime.
Coaching Teams
So you squeezed in the new requirement and you have some happy users. You decide to build your team and be the head-geek … the ARCHITECT guy!! Now your responsibilities change, you have to guide, mentor and help the unenlightented so they too can be fluid. You impose your way on a few newbies, you tell them what patterns they should use and what algorithms where wrong choices. And you have a mutiny. Why? Because, according to Bruce Lee:
Each one of us is different and each one of us should be taught the correct form. By correct form I mean the most useful techniques the person is inclined toward. Find his ability and then develop these techniques.
I have so often made the mistake of leading people into my way of thinking, my way of coding, my way of writing and the end result is always that the work produced is never up to MY standard. But if I take Bruce’s idea of teaching the useful techniques, and letting a newbie develop their own style, their own identity which will reflect their individuality in their creations, then I have helped a person grow. There is no other way.At the same time, you have to watch for classical symptoms in your team. Check this out:
Too much horsing around with unrealistic stances and classic forms and rituals is just too artificial and mechanical, and doesn’t really prepare the student for actual combat. A guy could get clobbered while getting into this classical mess. Classical methods like these, which I consider a form of paralysis, only solidify and constrain what was once fluid. Their practitioners are merely blindly rehearsing routines and stunts that will lead nowhere.
This is serious stuff. I often refer to this as “cut ‘n paste” coding from Google search results. Blindly hacking away old code is not code reuse, it just creates a maintenance nightmare. Software developers need to understand that the patterns and techniques that they use are only relevant in particular circumstances and contexts. Even if the pattern is relevant to solving the problem, it may be a poor choice because of other architectural considerations.Another word of advice from The Legend on coaching people:
A teacher must never impose this student to fit his favourite pattern; a good teacher functions as a pointer, exposing his student’s vulnerability (and) causing him to explore both internally and finally integrating himself with his being.
Now this is some serious advice which I need to heed. We often lapse into a one-way-for-all approach to coaching. Is this not a symptom of our educational methods: the exclusion of individuality for the sake of mass education? The cookie cutter approach of modern schooling – Another Brick in the Wall, Pink Floyd style.
It’s all about attitude
I’m not even going to elaborate on this. Just read the following and let it rest with you, then start Kung Fu Coding … Bruce Lee style.
Do not be tense, just be ready, not thinking but not dreaming, not being set but being flexible. It is being “wholly” and quietly alive, aware and alert, ready for whatever may come.When one has reached maturity in the art, one will have a formless form. It is like ice dissolving in water. When one has no form, one can be all forms; when one has no style, he can fit in with any style.Finally, a Jeet Kune Do man who says Jeet Kune Do is exclusively Jeet Kune Do is simply not with it. He is still hung up on his self-closing resistance, in this case anchored down to reactionary pattern, and naturally is still bound by another modified pattern and can move within its limits. He has not digested the simple fact that truth exists outside all molds; pattern and awareness is never exclusive.
Trust Everything
Trust has popped up in so many of my conversations recently. It came up at home, at a new school that Lia will be starting next term, in the DDD course that I gave earlier in the month, in Peter Hundermark’s scrum master certification course. And I got a one line email that said this.
The entire world lives on trust. Every aspect in life moves with trust.
The more I think about situations in life that will prove this statement false, the more it seems to hold true. Even in design it holds true. Your most fundamental architectural decisions are based on trust and the implementations of that architecture work because of trust.
It’s true for code too. If you don’t trust the code on which you build or depend, then you might as well write everything yourself, and give up your place on your team.
I was thinking about the AOP with DDD tutorial that I will be giving at OOPSLA this year, and this trust thing came up. Here again, aspects and the classes into which they get woven, need a trust relationship. It may seem like a stretch to make that statement, but I think it holds true again.
So, how do you gain trust? I am not sure, but I think you have give up something first. Maybe you need to show your vulnerability first, then it becomes easier to let someone into your space. Then, perhaps, they will let you in to their space too. When ego walls are erected, then trust finds it hard to grow. By ego, I don’t mean arrogance, I mean awareness of your self that you hide from others for fear. Perhaps, it is only when you show your true interface, that the other will worry less about hidden agendas.
In code, trust lies in interfaces and types, not in implementations. It’s really about trusting the implementation that makes types worthy. When you trust the type and send it a message and it behaves as expected, then you trust it. If you request something of an abstract type and the message was received by an instance of a subclass, then you expect the subclass to behave like the abstract type. You don’t hope that it does behave consistently, you trust that it does!
Trust is tied in with ubuntu too. You can’t be part of a community nor allow yourself to be defined and shaped by the people around you, if you can’t trust them. I think ubuntu coding needs trust as one of it’s values. It’s already a value in XP, and Scrum, and families. It needs to be in teams, and organisations, and communities and nations too.
Fat is the new Thin
During a factor10 virtual coffee break, Niclas Nilsson and I had a chat about what’s going on in web app land, on the browser end of the landscape. So this is inspired by his observations and him ‘pushing’ me to write this.
Recently, I’ve seen a few people searching for the holy grail of the ubiquitous browser UI. The usual suspects appear: Silverlight, Flex, JavaFX. Then I always suggest “What’s wrong with HTML, CSS and JavaScript. You are writing a browser app, aren’t you?”. And I get this weird, one raised eyebrow look. So, in response to the one-raised-eyebrow look, here’s what I have observed. (I use the word model and fat below, maybe it’s the wrong usage, but I think you’ll get the gist.)
In the early days of browser apps, everyone was trying to write fat desktop apps in HTML. And that went horribly wrong because the programming model was different. We eventually figured out page based, disconnected apps in the browser, then someone did the AJAX thing and we had out-of-bound HTTP requests and in-place DOM updates. Another small twist in the programming model. But we had already made the transition to a new programming model and AJAX was not a radical change.
Now we have Silverlight, Flex/Air and others. They happen to run in a browser, but there’s nothing browser based about them. Yes, they all let you interact with the DOM and run some JavaScript too. But these apps might as well not be in a browser. In fact, that’s now pitched as a super great feature: your code can run inside and outside the browser. The programming model is different. No matter what the marketing folk say, I think the in-browser feature is a clever adoption scheme.
The truth is that this new thin is actually fat, FAT, FAT! It’s just fat and disconnected. That is all. My advice for those that want to go this pseudo-thin route, is to just write your app to run outside the browser. Just forget about the browser. If you want to use the browser, then go back to HTML and JavaScript. The common counter statement is that these clients get rid of browser incompatibility issues. If you really want to get rid of browser incompatibility issues, then don’t use a browser. Simple. And these confused thin clients will let you do that.
But the part that really scares me is that the fat code I have seen so far reminds me of unmaintainable VB, Delphi or PowerBuilder code. And there are other scary things too. For example, the Cairngorm framework for Flex is based on a singleton pattern, but the underlying language does not make it easy to create singletons. Imagine all the code to create a singleton just to get the framework to work. And these frameworks are not very DRY either. Somehow, it seems like a new group of developers are writing these frameworks and they have not bothered to learn from 10+ years of web UI framework lessons. The good news is that code maintenance and framework quality issues are solvable.
But the game itself has changed. It’s not a case of new rules in an old game. That’s what caused the mess in 1999 with HTML.
By this time, most people either close their eyes or raise the other eyebrow at me.
Stranger Danger in the Cloud
There will always be someone who will scream that Cloud Computing is new. And there’s someone else that will tell you it’s old-school-been-there-done-that. And there will always be some vendor that will try to sell something too.
Since we shrink in body and mind to the state of children when thrown into a new context, beware of stranger danger. It’s tempting to follow strangers for cheap candy in the cloud.
And yes, like SOA, we’ve seen and done this before. But I think it is important that we let the passage of time to gel our experiences and ideas over and over again. Why? Because contexts change with time and we can use new contexts to innovate again and again and again.
You’re allowed to think … for yourself … and decide … for yourself.
Launching the Services Support Group
“Hello. My name is Hope and I am a Service. Last week I was asked by a View to do something. I told the View that I can’t do it. So he asked the Fat Controller. The Controller sent me the same message and I just took exception. What kind of service does he think I am?”
“Hello Hope. We are glad you joined us. You are not alone. Look around the room. We’re all struggling to find our own identity. Those of us that have been around for a long time are still recovering from being forced to convert DomainObjects to DTOs. The more recent ones feel like meaningless proxies, and last week we had a guy who thought he was a Service but he was just a HelperClass.”
“It’s as if I am losing touch with reality. My own DomainObjects don’t even interact with me directly. Now processes want a piece of me too. I think I am schizophrenic. Am I now a process? A wrapper point for Transactions? I swear to you, there are days when I even think I am a stored procedure!”
“Ohhhh, noooo!”
“But I know who I am. I am a Service. I like working with DomainObjects. They need me. Somethimes they can’t do everything on their own, so I help out. I complete their world and it makes me feel like I belong in the right place. One guy even refactored me from the domain package to a services package. Can you believe that! Actually, now that I’ve said it aloud, I am not surprised that I feel more and more disoriented.”
“Disoriented? Oh boy, we really can’t help you here. You see we’re recovering from abusive Controllers and Views and when you told us the story in the beginning, we thought we could help you but you’re just a …”
“But that story is true. Apparently there was this Process on other side of this MessageBus that needed something and he asked the Fat Controller who got involved with View and then I got sent this message and …”
“WTF?!! The Process asked the Controller…”
“Yeah! You won’t understand … it’s after your time. It’s really a WebServices Controller but I hear that he also feels abused and just wants some REST. You think there’s a support group for Controllers?”
“Wait. I remember this other crowd … uhhmmmm … sorry – those weren’t Controllers, those were Presenters working with Models and Views, but I used to be confused as a Delegator and I can …”
“You’re NOT HELPING!!! I told you I am a Service! And I am confused! I want to be part of the domain again! I feel disoriented! And I …”
“And I told you that we can’t help you. The truth is that you are DOA.”
“Dead on Arrival?”
“No! DisOriented Architecture. You know … they don’t know where to put that, so it becomes a service.”
“But, but … I am a Service … <sniff>”
“YOU WERE NEVER A SERVICE! YOU’RE ONLY HOPE!!!”
f3yourmind 