With the popularity of the iPod, the fortunes for the Mac have been looking brighter too and with that, more retailers are carrying Macs. In Calgary, BestBuy and London Drugs are recognizable chains that carry the Mac. So with that in mind, I went shopping for a game for my son for Christmas. Well it wasn't a terribly pleasant experience. While the shelves are loaded with software for Windows PCs, Mac software is far more difficult to come by. BestBuy was the worst. They had NOTHING. London Drugs faired a little better but only had a few titles like "Mac OS X Tiger". I went to these stores first because their locations are more convenient to my place of work.
But in the end I went to WestWorld Computers on Centre Street in Calgary and was greeted with a recently rennovated showroom. There was lots of hardware and software on display and some knowledgable salesmen walking around. I immediately found what I was looking for and made my purchase. My lesson? Forget the big box stores and go for the focussed reseller.
PS: iPods are very hot Christmas items. People were buying them at all three locations.
Monday, December 12, 2005
Thursday, December 08, 2005
RoR & Foos together at last
Even as my spare time dwindles with the responsibilities of hosting the family Christmas celebrations at our house this year, I still try to find the time to continue my Ruby on Rails education. In 2005 I looked at a lot of technologies but RoR is one of the first to actually have me interested enough to do more than just read a book. Let me explain...
At work we have a foosball ladder which consists of a white board and a dry erase pen. While refreshingly low tech I thought "here's a problem just waiting to be automated with software!". Okay it doesn't really need software but it's a complex enough problem for me to get my feet wet with Rails. I unabashedly looked at the ladder options already on the web and (ahem) borrowed some of their ideas. I need to store information about players, teams, the ladders themselves, matches and the games in those matches and then I can go onto bells and whistles like enabling online challenge negotiations, the ability to mark a players status, and showing player/team stats.
So already I have several tables in a PostgreSQL database with a variety of relationships between them and I'm slowly figuring out what I can do with RoR's ORM tool ActiveRecord. So far I've been pretty happy with the support for optimistic locking, one-to-one (belongs_to & has_one), one-to-many (has_many), and many-to-many (has_and_belongs_to_many) relationships, dynamic finders, and transaction support.
I especially like being able to just play around in Ruby. I can mess with the tables, add and remove columns, change names, etc and then quickly see my changes take shape in my Ruby object model by running a simple Ruby script to create some objects and save them to the database. And no requirement to compile, or generate ORM XML mapping files has me feeling quite empowered.
At work we have a foosball ladder which consists of a white board and a dry erase pen. While refreshingly low tech I thought "here's a problem just waiting to be automated with software!". Okay it doesn't really need software but it's a complex enough problem for me to get my feet wet with Rails. I unabashedly looked at the ladder options already on the web and (ahem) borrowed some of their ideas. I need to store information about players, teams, the ladders themselves, matches and the games in those matches and then I can go onto bells and whistles like enabling online challenge negotiations, the ability to mark a players status, and showing player/team stats.
So already I have several tables in a PostgreSQL database with a variety of relationships between them and I'm slowly figuring out what I can do with RoR's ORM tool ActiveRecord. So far I've been pretty happy with the support for optimistic locking, one-to-one (belongs_to & has_one), one-to-many (has_many), and many-to-many (has_and_belongs_to_many) relationships, dynamic finders, and transaction support.
I especially like being able to just play around in Ruby. I can mess with the tables, add and remove columns, change names, etc and then quickly see my changes take shape in my Ruby object model by running a simple Ruby script to create some objects and save them to the database. And no requirement to compile, or generate ORM XML mapping files has me feeling quite empowered.
Wednesday, December 07, 2005
Testing
I came in to work this morning only to listen to a QA lead and a senior developer discuss the almighty importance of tests (specifically unit tests). "They are the specifications, blah, blah, blah". But you know what I didn't hear, the importance of the actual software itself! Agile-development, test-first, test-driven, whatever-process-comes-next are all well and good but don't get so damn attached to it that you don't focus on what's really important, the software. Don't get me wrong, tests are important but they come a distant second to the system under development.
Thursday, December 01, 2005
Work's a drag
A few Pragmatic Programmer tips are:
During some informal polling among other developers I get a pretty divere set of opinions. Some agree with me (but not on the same remedies), others are apathetic, and others feel that everything is just fine. So naturally I don't feel that comfortable pulling the handbrake. I just hope there isn't a sudden stop and a loud bang associated with this ride.
I guess there's a reason they call it "work".
- Provide Options, Don't Make Lame Excuses
Instead of excuses, provide options. Don't say it can't be done; explain what can be done. - Don't Live with Broken Windows
Fix bad designs, wrong decisions, and poor code when you see them. - Be a Catalyst for Change
You can't force change on people. Instead, show them how the future might be and help them participate in creating it. - Remember the Big Picture
Don't get so engrossed in the details that you forget to check what's happening around you.
During some informal polling among other developers I get a pretty divere set of opinions. Some agree with me (but not on the same remedies), others are apathetic, and others feel that everything is just fine. So naturally I don't feel that comfortable pulling the handbrake. I just hope there isn't a sudden stop and a loud bang associated with this ride.
I guess there's a reason they call it "work".
Remarkable developers use remarkable technologies to do remarkable things.- Chad Fowler
[...]
If you don't have passion for software development you will not become a remarkable software developer, period.
Tornado Foosball

We got a new foosball table at work about a week ago, a Tornado Whirlwind. Now I can fully indulge my addiction to this fun but difficult-to-explain-to-your-wife game. The Tornado tables are very solidly built and are designed for a controlled game. So while we still have some slaptastic players whose style of play is better suited to the "speed-ball" rules, most are coming around to trying to intentionally score a goal rather than just smacking it as hard as you can and hoping something good happens.
Digital Cameras
iPhoto on the Mac was first released in January, 2002 and nearly four years later I've finally joined the party by buying the Canon PowerShot SD450 digital camera. I learned that size is a pretty big consideration when buying digital devices and generally the smaller the better. The less of a hindrance it is to take with you, the more likely you are to use it. That's certainly been my experience with my iPod shuffle. I sometimes wish I had the features and storage of the larger model but the size is perfect. The feature I like best about my new camera is its ability to rotate the image according to orientation of the camera when I'm playing back existing shots. Very cool!
Monday, November 21, 2005
Genealogy
What started out as an innocent school project for my daughter has turned into a full time project for me! What was a simple family tree has now turned into a genealogical expedition of epic proportions... well okay maybe not... But I have discovered some interesting facts:
Finally my software of choice has been a little Java application called GenealogyJ or GenJ for short. Having never touched a commercial tool that does this stuff I'm pretty impressed with GenJ. There's a nice little graphical viewer and lots of reports. The best part is that it stores all it's data in a UTF-8 encoded text file (in the standard Gedcom format) that's easily read in any text editor. That's pretty important to me so that my information will always be accessible even if GenJ should go the way of the Dodo.
For those of you who've been into this stuff for years and have some pointers, send me an e-mail or post a comment...
- my grandmother on my father's side came from Scotland
- my great Grandfather on my father's side was a candy maker in Germany
- my great grandparents on my mother's side came from England
Finally my software of choice has been a little Java application called GenealogyJ or GenJ for short. Having never touched a commercial tool that does this stuff I'm pretty impressed with GenJ. There's a nice little graphical viewer and lots of reports. The best part is that it stores all it's data in a UTF-8 encoded text file (in the standard Gedcom format) that's easily read in any text editor. That's pretty important to me so that my information will always be accessible even if GenJ should go the way of the Dodo.
For those of you who've been into this stuff for years and have some pointers, send me an e-mail or post a comment...
Wednesday, November 02, 2005
Chasing simplicity in programming
A new article on c|net discusses the new phenom "Ruby on Rails". Quotes from the article:
Like Java did a decade ago, Ruby on Rails is getting developers excited by making them more productive
The vision of Ruby on Rails, or RoR, is to combine the speed and ease-of-use of scripting language PHP with the "clean," structured approach of Java
Java Enterprise Edition software is a "complex monstrosity" that's hard to learn
Research company Burton Group recommends that corporate customers consider Ruby on Rails for new Web development projects
We took a pretty radical stand: Stored procedures and all things that make your database clever are evil
Thursday, October 27, 2005
Hibernate & Ruby

In my previous project I was using the latest and greatest version of Hibernate and was happily employing the Hibernate Eclipse plugin for writing my HQL queries before embedding them in my application. But my current project uses an older version of Hibernate (2.1.x) so the Eclipse plugin is out of the question. Fortunately I can remember back to when I used the forerunner of the Eclipse plugin, a little program that was called Hibern8IDE. It later became part of the Hibernate extension tools and was then thankfully renamed "Hibernate Console". Fortunately it's still available for download from hibernate.org.
Now the only problem is that this project also uses Spring which informs Hibernate about the XDoclet-generated mapping files at runtime in a decidedly non-hibernate fashion. What I needed was to create a good old fashioned hibernate.cfg.xml which contains references to each *.hbm.xml file. But I wanted to script the generation of this file so that I wouldn't have to manually maintain the file as the collection of *.hbm.xml changes over time. So I turned to my new friend Ruby. The top and bottom part of this script use "here docs" to generate the boiler plate static XML. But then right in the middle I got this:
`find . -name '*.hbm.xml' -print`.each { |f|
f.gsub!(/.*(com\/company.*?)\n/, '\1')
puts "<mapping resource=\"#{f}\"/>"
}
The first line executes the Unix find command, and then begins an iterator over each line of that command's results. Then within the block I use a simple regex within the String's substitution method to get the Java package and file name. Then finally I print out an XML element whose resource attribute contains the name of the *.hbm.xml file. That's a lot of stuff in only four lines of code! Ruby is very expressive. Now I must emphasize the value of a good editor to color code something like that so a person can make sense of it. I definitely recommend the RDT plugin for Eclipse.
Thursday, October 20, 2005
Right & Wrong
Back in August I commented on Microsoft's aggressive moves against Adobe. I also mentioned that Apple could also make a move with it's new Core Image technology built into OS X. But at the time I didn't think it was all that likely. Well I was right that they could but I was wrong because they did.
Apparently Apple wants a piece of that image processing market. They just introduced Aperture. And although they're going to some pains to say it's complementary to Photoshop, I think it's definitely a competitor.
Apple really is becoming quite a software powerhouse... Fortunately for most software companies, they can feel secure that the only software they produce that isn't Macintosh-only is iTunes and Quicktime. But then again once somebody (like me for example) gets a taste of Mac, all that Microsoft stuff just feels like rubbish. With all the Apple stores around the U.S. with their little built in theaters, the brand new Quad PowerMacs will show this stuff off very well.
Apparently Apple wants a piece of that image processing market. They just introduced Aperture. And although they're going to some pains to say it's complementary to Photoshop, I think it's definitely a competitor.
Apple really is becoming quite a software powerhouse... Fortunately for most software companies, they can feel secure that the only software they produce that isn't Macintosh-only is iTunes and Quicktime. But then again once somebody (like me for example) gets a taste of Mac, all that Microsoft stuff just feels like rubbish. With all the Apple stores around the U.S. with their little built in theaters, the brand new Quad PowerMacs will show this stuff off very well.
Tuesday, October 18, 2005
HD Movie Trailers
Check out the new Movie Trailers page at Apple. A fair number of them are in HD. Normally I have to scale a video several times to fit my entire screen. These trailers fill my screen without any scaling at all.
Saturday, October 15, 2005
Ruby, Ruby, Ruby, Ruby
Remember when Steve Ballmer went all schizo and jumped around like a big Gorilla shouting "developers, developers, developers, developers"? Well I think I'm starting to get infected by a similar disease. I'm not a complete raving lunatic just yet but I'm really starting to dig Ruby. ;-)
After madly writing endless lines of Java code for the past three weeks that does next to nothing (see my previous rant) I'm elated to see that there are others in the world who believe less code is better.
To demonstrate, here are the steps you can take to create a dynamically generated page with Ruby on Rails.
1. > rails ./demo
2. > cd demo
3. > mv public/index.html public/index.html.old
4. > script/generate controller people list
5. modify config/routes.rb and add the line map.connect '', :controller => 'people', :action => 'list'
6. modify app/controllers/people_controller.rb (see listing below)
7. modify app/views/people/list.rhtml (see listing below)
8. > script/server
9. browse to localhost:3000
10. voila!
A couple of important points to notice is that Rails embraces the MVC design pattern. Model and Controller classes are separate while the View is off in its own place. The view is an .rhtml file because it's basically HTML with Ruby embedded within it. While those who've been doing JSP development may scoff at the mere idea of embedding "code" within a page and believe that custom tags is the only way to go, I have to admit that after doing JSF for a few weeks I actually like this a whole lot better. Remembering that Ruby is a 'scripting' language and that Rails uses Controller classes (like "code-behind") may help people get over their prejudice. Finally here a few links I've found very valuable during the last week:
What Is Ruby on Rails
Rolling With Ruby on Rails
Rolling with Ruby on Rails, Part 2
Ruby On Rails Documentation
why's poignant guide to Ruby
Rails Academy (videos)
app/controllers/people_controller.rb
app/views/people/list.rhtml
After madly writing endless lines of Java code for the past three weeks that does next to nothing (see my previous rant) I'm elated to see that there are others in the world who believe less code is better.
To demonstrate, here are the steps you can take to create a dynamically generated page with Ruby on Rails.
1. > rails ./demo
2. > cd demo
3. > mv public/index.html public/index.html.old
4. > script/generate controller people list
5. modify config/routes.rb and add the line map.connect '', :controller => 'people', :action => 'list'
6. modify app/controllers/people_controller.rb (see listing below)
7. modify app/views/people/list.rhtml (see listing below)
8. > script/server
9. browse to localhost:3000
10. voila!
A couple of important points to notice is that Rails embraces the MVC design pattern. Model and Controller classes are separate while the View is off in its own place. The view is an .rhtml file because it's basically HTML with Ruby embedded within it. While those who've been doing JSP development may scoff at the mere idea of embedding "code" within a page and believe that custom tags is the only way to go, I have to admit that after doing JSF for a few weeks I actually like this a whole lot better. Remembering that Ruby is a 'scripting' language and that Rails uses Controller classes (like "code-behind") may help people get over their prejudice. Finally here a few links I've found very valuable during the last week:
What Is Ruby on Rails
Rolling With Ruby on Rails
Rolling with Ruby on Rails, Part 2
Ruby On Rails Documentation
why's poignant guide to Ruby
Rails Academy (videos)
app/controllers/people_controller.rb
class PeopleController < ApplicationController
def list
@names=['Yukihiro Matsumoto', 'David Heinemeier Hansson']
end
end
app/views/people/list.rhtml
<html>
<head>
<title>This is my first Ruby page</title>
<link rel="stylesheet" type="text/css"
href="stylesheets/mystyle.css" />
</head>
<body>
<h1>Ruby/Rails People List</h1>
<table>
<% @names.each do |name| %>
<tr><td><%= name %></td></tr>
<% end %>
</table>
</body>
</html>
Saturday, October 08, 2005
Ruby On Rails

I discovered a new version of the Ruby Development Tools (RDT) plugin for Eclipse yesterday. I hadn't used it in quite awhile, so I downloaded this new version, installed it and was quite pleasantly surprised. I opened an old project I had laying around and rediscovered the simplicity of Ruby. I wrote a Test::Unit subclass and ran it in the RDT test runner. Very nice. Just like running JUnit tests in Eclipse.
So I decided this is cool, lets try this Ruby on Rails thing that I keep reading about. Mac OS X Tiger comes installed with Ruby 1.8.2, the Apache web server and SQLite, so I was more than half way there to getting setup. I followed this little tutorial to install RubyGems, a packaging system for Ruby libraries and tools. After that, installing rails (i.e., "sudo gem install rails") and creating a little sample application was a breeze. My only hiccup was fixing a permissions problem with my sample app (i.e., the public, db, and logs files needed to be readable and writable by apache).
Setting up a rails app involves generating a bunch of files so I can't claim to know what's really going on under the covers, but it's a very cool thing to be able to edit data through a web UI so quickly. Rails has impressed me so far. Now I just need to build something of my own and decide for myself if all these Ruby/Rails productivity claims hold water.
Tuesday, October 04, 2005
LINQ
A friend of mine just sent me a video link to a interview with Anders Hejlsberg talking about LINQ (Language INtegrated Query). Take Java's Hibernate ORM (object relational mapping), mix in contextual type inference and then throw in homogenous query syntax (that has a close resemblance to SQL) across relational databases, XML data and in-memory objects and you get an idea of what LINQ is all about. It sounds very ambitious (and it is) but Anders does a great demo. The comments section on the board makes it sound revolutionary but if you've been playing in the ORM space for any amount of time it seems like a very natural evolutionary step. But I didn't see the "type inference" stuff coming. That's brilliant. Makes the query stuff much more powerful.
Sunday, October 02, 2005
Seam
After yesterday's rant about layers upon layers of code and XML based dependency injection I found Norman Richard's blog about a new web framework called Seam from JBoss. Apparently Gavin King, the guy who brought us Hibernate, is involved in this as well. That's a very good sign. From what I've read it looks like this might be just what I'm looking for. It's brand new and will undoubtedly have rough spots and missing functionality, but it really does seem to be headed in the right direction.
Saturday, October 01, 2005
6 days later
I've been in my new job for six days now and thought I'd post my thoughts about what I've done so far. The short answer is "not much". It's actually pretty amazing to me how little is done to prepare for a new person. And I'm not even talking about this specific company, it's a general problem. Even the most glaringly obvious things like getting ids and passwords for databases, version control systems and even permissions on file servers are almost never set up when I go to a new job. Sometimes the environment is responsive to new requests, other times... not so much.
Secondly, when being inserted into a team of people already madly coding away, nobody has the time to give you the lay of the land. So I spent at least a couple days looking a existing code to figure out what I need to do to make my code fit in with everything else. It all seems highly inefficient and a waste of my time and their money. Maybe when you consider just one developer, it may not seem like much but multiply a week of time for every new developer who walks through the door then it's easy to see a pretty big opportunity to save. Do the math with let's say 20 developers and you soon start to think "I could probably build a lot of stuff in 20 weeks".
Anyway, I did manage to build a single web page this past week. But what really impressed me was the number of files I needed to create/edit to enable this one page. I created:
In my last job, where I made the decisions about architecture and technologies, I had:
Having worked with a variety of people over the years I know there are those who believe that elegance is expressed with simplicity. Look at E=mc² for example. And then there are those who love to wallow in complexity. I love simple, efficient, elegant designs. I'm not sure I've found that here... Not yet anyway. Maybe I'll come to love it over time (my fingers are crossed).
Finally, let me comment on a couple of my statements in earlier posts:
Secondly, when being inserted into a team of people already madly coding away, nobody has the time to give you the lay of the land. So I spent at least a couple days looking a existing code to figure out what I need to do to make my code fit in with everything else. It all seems highly inefficient and a waste of my time and their money. Maybe when you consider just one developer, it may not seem like much but multiply a week of time for every new developer who walks through the door then it's easy to see a pretty big opportunity to save. Do the math with let's say 20 developers and you soon start to think "I could probably build a lot of stuff in 20 weeks".
Anyway, I did manage to build a single web page this past week. But what really impressed me was the number of files I needed to create/edit to enable this one page. I created:
- a domain object with Hibernate XDoclet annotations
- a DAO interface
- a Hibernate DAO implementation
- a DAO unit test
- a Service/Facade interface
- a Service implementation
- a Service unit test
- a JSF backing bean and a JSP page.
- an application resources properties file (despite the fact localization is not a requirement)
- two Spring XML files
- a JSF config XML file and
- added some XML to the tiles definition file.
In my last job, where I made the decisions about architecture and technologies, I had:
- XDoclet annotated domain objects (which included named queries)
- NO DAOs (I felt that the Hibernate abstraction and named queries were a sufficient data access layer)
- Service Objects (typically singletons with explicitly coded session and transaction management)
- XDoclet annotated Struts Action/Form objects + JSPs
- the typical smattering of JUnit test classes.
Having worked with a variety of people over the years I know there are those who believe that elegance is expressed with simplicity. Look at E=mc² for example. And then there are those who love to wallow in complexity. I love simple, efficient, elegant designs. I'm not sure I've found that here... Not yet anyway. Maybe I'll come to love it over time (my fingers are crossed).
Finally, let me comment on a couple of my statements in earlier posts:
- There is a simpler way to integrate Spring and JSF so that you can inject Spring configured beans into JSF managed beans. Using Spring's org.springframework.web.jsf.DelegatingVariableResolver configured within your faces config makes it all transparent. Yay! It may not be as good as using only one dependency injection framework but it's a good runner up.
- Secondly, you can integrate tiles into JSF by configuring org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl in your faces config file.
- Finally, I read Spring's documentation a little more closely and it appears you can use HibernateTemplate's execute method to call whatever Hibernate code you want. So I can now feel free to use that lovely Hibernate API all I want! ;-)
Sunday, September 25, 2005
On JSF, Struts, & Spring Part Deux
After a Saturday of messing around with Spring, JSF, & Hibernate I have a nice little application that does nothing more than retrieve an object from my local PostgreSQL database and display the value in a web page. While the end result isn't very exciting there is a whole symphony of integration going on under the covers.
Hibernate and Spring
I first created a couple business domain classes that use the latest and greatest Hibernate/EJB3 Java 5 annotations to describe how they map to database entities. This is currently supported in Hibernate 3.1 beta 3 so I didn't really expect to be able to use this stuff once I got to integrating it with Spring. I assumed I'd have to either write Hibernate mappings in XML or maybe integrate XDoclet to generate the mappings. Well to my surprise Spring has org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean!! So Spring was good to go! All I had to do was declare the sessionFactory and the transactionManager that I wanted in applicationContext.xml. I still haven't figured out a way to get it to autodiscover the annotated business model so I had to manually list the two classes but that wasn't too big of a problem.
I then moved on to creating a subclass of Spring's HibernateDaoSupport class and configuring it in applicationContext.xml where I learned about the declarative transaction management features of Spring. In this XML file I was able to wire together the DAO, the Hibernate sessionFactory, the transactionManager and indicate which DAO methods require a transaction. This simplified the code in the DAO by injecting the necessary Hibernate Session and Transactions at runtime. But this comes at the cost of using a HibernateDaoSupport method called getHibernateTemplate() whose returned object basically delegates to the injected Hibernate session and turns Hibernate exceptions into unchecked exceptions. This also has the unfortunate side effect of burying the native Hibernate API. I don't really care for that idea too much but it's a tradeoff for not having to manage session and transaction resources manually.
So I then created a little JUnit test, used the FileSystemXmlApplicationContext to start up Spring and then used the context to get the configured DAO from Spring and called a method. Everything worked as expected.
Spring and JSF
Next it came time to integrate JSF. This became a little more time consuming. First of all I needed to figure out how to initialize all the Spring stuff within a web application which in turn initializes all the Hibernate stuff. It was actually fairly simple. I only had to configure a listener in the web.xml file for org.springframework.web.context.ContextLoaderListener. Also by using context-param in web.xml I was able to tell this ContextLoaderListener instance where to find my spring applicationContext.xml files.
Secondly, JSF has its own Dependency Injection framework for configuring backing beans that have request, session or application scope and it was unclear to me how to integrate the two dependency injection frameworks i.e., If my DAO and Facade/Service classes are configured with Spring how would I go about injecting these instances into a JSF backing bean? Well as it turns out I can't. Not yet anyway. There is a little project appropriately enough named "jsf-spring" that aims to transparently aggregate these two frameworks. It's in beta. But Spring has a supporting class called FacesContextUtils which allows me to fetch an instance of WebApplicationContext (with the current FacesContext as a parameter). I can then use that Spring context object to fetch the DAO (or more typically a facade class) to do the work I need. Given all this dependency injection stuff this manual fetching of context objects and service objects seems like a very odd hack and is more like calling a singleton getInstance method. But it works and I was able to tie the business layer to the presentation layer.
Summary
So there you go, a display-only Spring/Hibernate/JSF application. It was a good lesson in making all the pieces work together. In the end I look at all this plumbing and I'm a bit surprised how simple and difficult it was to get everything going. The Spring stuff is well documented on the web and was easy to get going with Hibernate. But answers to my questions about adding JSF to the mix were a little harder to come by. I suspect the future holds a stronger integration for Spring and JSF (perhaps you can just use Spring as a replacement for the JSF injection framework) and I can see Java 5 annotations becoming more prevalent in Spring so that you don't have to write all that XML. Annotations work great for Hibernate so I don't see why they wouldn't work well for Spring too.
Hibernate and Spring
I first created a couple business domain classes that use the latest and greatest Hibernate/EJB3 Java 5 annotations to describe how they map to database entities. This is currently supported in Hibernate 3.1 beta 3 so I didn't really expect to be able to use this stuff once I got to integrating it with Spring. I assumed I'd have to either write Hibernate mappings in XML or maybe integrate XDoclet to generate the mappings. Well to my surprise Spring has org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean!! So Spring was good to go! All I had to do was declare the sessionFactory and the transactionManager that I wanted in applicationContext.xml. I still haven't figured out a way to get it to autodiscover the annotated business model so I had to manually list the two classes but that wasn't too big of a problem.
I then moved on to creating a subclass of Spring's HibernateDaoSupport class and configuring it in applicationContext.xml where I learned about the declarative transaction management features of Spring. In this XML file I was able to wire together the DAO, the Hibernate sessionFactory, the transactionManager and indicate which DAO methods require a transaction. This simplified the code in the DAO by injecting the necessary Hibernate Session and Transactions at runtime. But this comes at the cost of using a HibernateDaoSupport method called getHibernateTemplate() whose returned object basically delegates to the injected Hibernate session and turns Hibernate exceptions into unchecked exceptions. This also has the unfortunate side effect of burying the native Hibernate API. I don't really care for that idea too much but it's a tradeoff for not having to manage session and transaction resources manually.
So I then created a little JUnit test, used the FileSystemXmlApplicationContext to start up Spring and then used the context to get the configured DAO from Spring and called a method. Everything worked as expected.
Spring and JSF
Next it came time to integrate JSF. This became a little more time consuming. First of all I needed to figure out how to initialize all the Spring stuff within a web application which in turn initializes all the Hibernate stuff. It was actually fairly simple. I only had to configure a listener in the web.xml file for org.springframework.web.context.ContextLoaderListener. Also by using context-param in web.xml I was able to tell this ContextLoaderListener instance where to find my spring applicationContext.xml files.
Secondly, JSF has its own Dependency Injection framework for configuring backing beans that have request, session or application scope and it was unclear to me how to integrate the two dependency injection frameworks i.e., If my DAO and Facade/Service classes are configured with Spring how would I go about injecting these instances into a JSF backing bean? Well as it turns out I can't. Not yet anyway. There is a little project appropriately enough named "jsf-spring" that aims to transparently aggregate these two frameworks. It's in beta. But Spring has a supporting class called FacesContextUtils which allows me to fetch an instance of WebApplicationContext (with the current FacesContext as a parameter). I can then use that Spring context object to fetch the DAO (or more typically a facade class) to do the work I need. Given all this dependency injection stuff this manual fetching of context objects and service objects seems like a very odd hack and is more like calling a singleton getInstance method. But it works and I was able to tie the business layer to the presentation layer.
Summary
So there you go, a display-only Spring/Hibernate/JSF application. It was a good lesson in making all the pieces work together. In the end I look at all this plumbing and I'm a bit surprised how simple and difficult it was to get everything going. The Spring stuff is well documented on the web and was easy to get going with Hibernate. But answers to my questions about adding JSF to the mix were a little harder to come by. I suspect the future holds a stronger integration for Spring and JSF (perhaps you can just use Spring as a replacement for the JSF injection framework) and I can see Java 5 annotations becoming more prevalent in Spring so that you don't have to write all that XML. Annotations work great for Hibernate so I don't see why they wouldn't work well for Spring too.
Saturday, September 24, 2005
On JSF, Struts, & Spring
I started a new contract yesterday and got a bit of a taste of what to expect in the coming months. We're building web-based Java applications and the typical J2EE MVC, Facade, DAO, & (evil) DTO patterns are in full effect.
I'm fortunate enough to get to continue to use Hibernate for ORM which is very cool. I still think Hibernate and object relational mapping in general is a very good thing. The biggest "problem" I see is that it looks like people are opting to use the "TopLink" way of doing things by using Criteria objects instead of HQL. What are they thinking? Why anyone would choose to use a non expressive bunch of Java code to write a query is beyond me. HQL is way better and one of the reason I like Hibernate so much better than TopLink. I e-mailed my supervisor about this one and we'll see what kind of response I get.
On the web framework front, we're using JSF (MyFaces specifically) instead of the defacto standard Struts. While fundamentally I don't have anything against Java Server Faces (it does have some nice features) I have to wonder why they made the decision to use it. David Geary (co-author of the book "Core Java Server Faces") once gave a talk at our local Java User Group meeting once and said something to the effect that "JSF was a standardized Struts that IDE vendors could rally around to create JSP visual editing tools". Part of that goal was to compete with ASP.NET. Coding up JSP pages is a bit mundane and who wouldn't rather have a tool write that junk for you? Well apparently the people where I'm working made that decision! It's still all hand-coded. So now we're using a framework nobody understands and I suspect productivity is lower. Where's the logic in that?
MyFaces seems very similar to Struts so conceptually it's easy to grasp but it's the details and the peculiarities of how things work that slow you down. It also seems to be at a higher level abstraction from the lower level request/response and the HTML it generates (the theory is that you can generate something other than HTML). But I think I prefer Tapestry's idea of staying close to HTML and only injecting the dynamic content. Tapestry allows you to use any HTML editing tool and HTML is well understood. JSF on the other hand is this parallel universe of tags that look a bit like HTML but can only be edited in a text editor or a JSF visual editing tool and at the moment there doesn't seem to be any tools that play nice with the MyFaces implementation. Secondly, staying close to HTML allows you to take advantage of advances in HTML like XHTML and AJAX. JSF, like ASP.NET, gives you a component model that will likely adapt to support advances in the underlying technology but there will always be a time lag. Perhaps the other minor benefits will outweigh the losses. We'll see... Right now it looks like change for the sake of change.
They also bought into the whole Spring IoC (a.k.a., Dependency Injection) idea. At first glance this seems like a good idea. You design to interfaces in an attempt to hide implementation details. Theoretically it should enable unit testing and allow us to switch between POJOs, Web Services and EJBs with greater ease. Of course it comes at a cost of greater complexity for questionable gain. For example if you create a DAO interface and then only ever create one implementation of that interface what have you gained? And then you have all the XML gunk to wire everything together. Theoretically, a meta data approach to wiring stuff together is better but not having experienced it before I'm a bit skeptical. The fortunate part about Spring is that they seem to understand that they need to play nice in a bigger community and support all the major Java frameworks out there so integration looks to be pretty straightforward.
My feelings are a bit mixed... Sometimes I believe that the dynamic, competitive, multi-vendor Java community is more vibrant than the MS .NET community and that the variety of tools is our attempt to find the most effective method for developing software. But sometimes I believe that we're all just chasing the next trend and running around in circles and I envy the single voice (Borg like as it may be) leading MS development. Anyway, I have some things to learn and I'll withold my final judgement until I've been using JSF and Spring for awhile. Maybe there are some pleasant surprises to come.
I'm fortunate enough to get to continue to use Hibernate for ORM which is very cool. I still think Hibernate and object relational mapping in general is a very good thing. The biggest "problem" I see is that it looks like people are opting to use the "TopLink" way of doing things by using Criteria objects instead of HQL. What are they thinking? Why anyone would choose to use a non expressive bunch of Java code to write a query is beyond me. HQL is way better and one of the reason I like Hibernate so much better than TopLink. I e-mailed my supervisor about this one and we'll see what kind of response I get.
On the web framework front, we're using JSF (MyFaces specifically) instead of the defacto standard Struts. While fundamentally I don't have anything against Java Server Faces (it does have some nice features) I have to wonder why they made the decision to use it. David Geary (co-author of the book "Core Java Server Faces") once gave a talk at our local Java User Group meeting once and said something to the effect that "JSF was a standardized Struts that IDE vendors could rally around to create JSP visual editing tools". Part of that goal was to compete with ASP.NET. Coding up JSP pages is a bit mundane and who wouldn't rather have a tool write that junk for you? Well apparently the people where I'm working made that decision! It's still all hand-coded. So now we're using a framework nobody understands and I suspect productivity is lower. Where's the logic in that?
MyFaces seems very similar to Struts so conceptually it's easy to grasp but it's the details and the peculiarities of how things work that slow you down. It also seems to be at a higher level abstraction from the lower level request/response and the HTML it generates (the theory is that you can generate something other than HTML). But I think I prefer Tapestry's idea of staying close to HTML and only injecting the dynamic content. Tapestry allows you to use any HTML editing tool and HTML is well understood. JSF on the other hand is this parallel universe of tags that look a bit like HTML but can only be edited in a text editor or a JSF visual editing tool and at the moment there doesn't seem to be any tools that play nice with the MyFaces implementation. Secondly, staying close to HTML allows you to take advantage of advances in HTML like XHTML and AJAX. JSF, like ASP.NET, gives you a component model that will likely adapt to support advances in the underlying technology but there will always be a time lag. Perhaps the other minor benefits will outweigh the losses. We'll see... Right now it looks like change for the sake of change.
They also bought into the whole Spring IoC (a.k.a., Dependency Injection) idea. At first glance this seems like a good idea. You design to interfaces in an attempt to hide implementation details. Theoretically it should enable unit testing and allow us to switch between POJOs, Web Services and EJBs with greater ease. Of course it comes at a cost of greater complexity for questionable gain. For example if you create a DAO interface and then only ever create one implementation of that interface what have you gained? And then you have all the XML gunk to wire everything together. Theoretically, a meta data approach to wiring stuff together is better but not having experienced it before I'm a bit skeptical. The fortunate part about Spring is that they seem to understand that they need to play nice in a bigger community and support all the major Java frameworks out there so integration looks to be pretty straightforward.
My feelings are a bit mixed... Sometimes I believe that the dynamic, competitive, multi-vendor Java community is more vibrant than the MS .NET community and that the variety of tools is our attempt to find the most effective method for developing software. But sometimes I believe that we're all just chasing the next trend and running around in circles and I envy the single voice (Borg like as it may be) leading MS development. Anyway, I have some things to learn and I'll withold my final judgement until I've been using JSF and Spring for awhile. Maybe there are some pleasant surprises to come.
Friday, September 09, 2005
Open Surfin Safari
People seem to give Apple a lot of flak for being a proprietary software company and while it'd be ridiculous to argue the fact that Apple is to a large degree closed source, what most don't realize is that they are a very active user of and contributor to open source projects. The kernel of the OS is based on FreeBSD and the source code is available for download at Apple's OpenDarwin website. It's been like that since the first release of Mac OS X.
Secondly Apple's Webkit, their HTML engine used in the Safari web browser, is based on KHTML from KDE, the desktop environment for Linux. The source code for Webkit is also available for downloading from the OpenDarwin website. And as a matter of fact I followed the instructions in this article to get the source code from the CVS repository, compile it and run the latest code. Very cool. It's even the first (and currently the only) browser to pass the ACID2 test which tests a browser's support of web standards (try that with IE).
So yes Apple is proprietary in many respects but they understand when it makes sense to be part of the open source community.
Secondly Apple's Webkit, their HTML engine used in the Safari web browser, is based on KHTML from KDE, the desktop environment for Linux. The source code for Webkit is also available for downloading from the OpenDarwin website. And as a matter of fact I followed the instructions in this article to get the source code from the CVS repository, compile it and run the latest code. Very cool. It's even the first (and currently the only) browser to pass the ACID2 test which tests a browser's support of web standards (try that with IE).
So yes Apple is proprietary in many respects but they understand when it makes sense to be part of the open source community.
Tuesday, September 06, 2005
Lube, Rods, Scoring, oh my!
I was told by a couple of people who read my blog that it's too "boring" so I figured I'd spice it up a bit and talk about lubing your rod. All your partners will oooOOOOooo and aaaaAAAAAaaaa...
Get your mind out of the gutter...
I'm talking about foosball again! LOL. In addition to the new men on our foos table I had enough money left over from our "foos-aid" office collection to buy a can of 3-in-1 silicone spray lubricant from Canadian Tire for the foosball table rods. What a difference maintaining your uh "equipment" can do for you.
Subscribe to:
Posts (Atom)