According to Kurzweil your IT systems will be twice as powerful in 3 years. By 2013 or so we should be able to model a human brain in entirety on the world's most powerful machines. In time that power will hopefully trickle down to you and me. If you are like me, you write software, how are you going to use all that power? How are you going to produce all those features people need so rapidly?
If you've read my blog at all you'll know I'll tout the advance of the DSL and the dynamic language. I see these technologies on the JVM at a key inflection point between backwards compatibility and increased efficacy. They are transitional technologies at a key period in technological history.
The win in DSL, dynamic languages, and frameworks is always how succinctly you can get to your core thought or core idea. I don't really care about the ORM, the Ajax, the email most of the time. Most of the time there is a core idea I'm trying to work out.
In 24 months I need to be in the place where I can effectively divide the problems in front of me down into their key ideas. Keep the competing paradigms apart from each other. And then combine them at the right moments of confluence with a minimum of dissonance.
Get to the core thought, the core idea, ignore as much minutiae as possible, get the problem solved. Keep the idea clean. Keep the core thought from being tangled in a mess of details that have nothing to do with the answer you are after.
Advances in the way we create software will be key to the advance of the technologies of the future. If you are writing software today you will have to be prepared to leap a mighty chasm approaching us at break neck speed. That chasm will be paradoxically caused the increase of computational power available to us.
The problem of "traditional" programming that it is very procedural which can feel plodding at times. It takes forever to say anything meaningful. Yet before long we will have the ability to command computational power that could out strip our ability to speak into these systems with these sometimes unnecessarily verbose languages.
Consider that (in the video linked above) Kurzweil says that a scant 30 million bytes describes the whole of the human brain. The reason 30 million bytes could possibly hold the whole design for the human brain is that the brain's design is fractal and self organizing. A uniform underlying design is repeated with variation to create a whole. This is a similar goal to what we have in DRY (Don't Repeat Yourself) code that means we express an idea and leverage that idea again and again.
In the case of our brains, that assembled whole adapts to inputs to form intelligent variation leading to astounding complexity and abilities. The subtle variation introduced by input creates the mote of a soul... or at the very least all the personality traits we recognize as a living person. If only we could write software that could reorganize itself like that.
Functional programming, rules engines, and dynamic languages promise to free us from those mind-killing details that we don't really care about anymore as application developers. But they don't really address the need to create adaptive systems or systems that are able to span across computational mediums.
I predict that there will have to be new programming languages that run in new ways that allow for fractal designs like the human brain. I happen to think these still need to be languages because they are still conversations between a creator and the created system. I dream about these systems acting like holograms or fractals in their nature.
If you cut a hologram in half you get two identical but smaller and fuzzier holograms. If you look at one part of a fractal you see the whole. I think human designed software can have the same quality. The idea isn't new I've heard the opposite idea called "dirt" and perhaps that's a good word but in my mind these form knots ... asymmetric distributions of thought where one idea unrelated to another must intersect in incongruent ways. Perhaps "dirt" is the antithesis of "fractal" or "crystal" design.
I say "fractal" or "crystal" because "modular" isn't strong enough. You can make modules all day long but if they don't allow for cleanly intersecting concerns then you don't haven't done much more than take a messy room and shovel it's contents into random boxes. You haven't actually organized things you've just cut down on the size of the mess you have to sift through.
Good code focuses on one concern at a time and tries to ignore details that are incidental. It should be that in daily programming activities we can use tools like AOP and DSL to focus on the foremost thought ignoring details of execution. Good code is reusable because it encapsulates one concern in a way that is clean enough and simple enough to be easily lifted out and reused.
That's good stuff because if you're like me you really get paid for some high level thought and some high level idea and not the millions of tiny details you have to move through to get there.
2007-12-27
2007-12-26
Code Size and the Cognitive Gordian Knot
The size of a code base is not the worst enemy of code.
My personal experiences with code bases large and small have given me the insight to realize that size of code is a terrible enemy but not our worst enemy. Our worst enemy is stupidity. Well, not out right stupidity but what I call the cognitive Gordian knot.
The larger a code base is the more material there is to create a knot. The smaller, the less material there is to create a mess with. So there is beauty in the small. I have been arguing for the decomposition of large projects into small reusable code units for most of my career.
Yet, I've seen examples at Coding Horror and The Daily WTF that show in a scant few lines some of the most impressive inability to think I have ever seen. These examples are not necessarily what we would consider mind numbingly, guffawingly, powerfully brutish idiocy but subtle brain warping WTF? These are the thought-knots we can't untie like that knot of legend the Gordian knot.
During my time over seas I have worked on code bases whose ages were measured in decades and sizes estimated in rough fractions of millions of lines. Code bases of this size are surely incomprehensible but the best can have inner structure that can be navigated and internal API that can be understood. The reader of this kind of code doesn't need to know what exactly each call does but only understand the local code and some specific libraries to work on it.
And then later in my career... oh the irony... I maintained a code base of a scant few hundred thousand lines of code whose internal structure shifted upon itself every few lines. Every few hundred lines a new API, a new convention, a re-written API, a half-refactor, a violation of another API. And so on the insanity folded over and over upon itself like a Lewis Caroll narrative without any beautiful onomatopoeia. All of it written by the same person over the course of five years.
Instead of a crystalline structure found in those majestic and old code bases whose patterns fold and unfold like a fractal thus leading the maintainer to an understanding of the whole from only a part... this newer... this smaller... this uglier code base contained no song and no resonance that my mind could fix upon. Instead it was a tangle of swamp weed coated in a toxic sludge that defied understanding and like "Alexander the great and the Gordian knot" I saw no other answer to my problems other than to cut it asunder. Bust it up, break it apart, make it small again.
No, I know better, size is not what kills code. It is the Gordian knot of superficial complexity that kills code. Instead of a crystalline pattern or an enforced internal structure the code is allowed to grow untamed. The key to long life in code is pulling out and separating concerns into libraries and frameworks.
You could argue this tactic constitutes removing some code from the main code base and creating small supporting projects that fit together to create a whole. You'd be right. That's what it is. That is what I mean by saying fractal, crystalline, or internally disciplined. The supporting libraries may be internal to the project but they may constitute sub-projects they divide and conquer the problems and keep the material from building to the point that it can accidentally tie itself in a knot.
You could achieve this using MVC, Services, or libraries. I've seen Domain Driven Designs and Spring annotations to enforce SoC that would work well. You could say this is how Linux and GNU work together to create a full operating system. You could say that is code reuse and proper object orientation. You could say this the weapon we have in the mix-in and dynamic language.
Whatever you call it. It makes code easier to understand because it has a logical structure and what I call a resonance or song. It means you can see part of a code base, understand it, and ignore the other concerns to focus on your particular problem.
If you can dive into one section of code and comprehend it without having to comprehend the whole thing then I say you have a good code base no matter how big or how small it is. The goal is to keep the knotty beast at bay for as long as possible using every trick we have.
My personal experiences with code bases large and small have given me the insight to realize that size of code is a terrible enemy but not our worst enemy. Our worst enemy is stupidity. Well, not out right stupidity but what I call the cognitive Gordian knot.
The larger a code base is the more material there is to create a knot. The smaller, the less material there is to create a mess with. So there is beauty in the small. I have been arguing for the decomposition of large projects into small reusable code units for most of my career.
Yet, I've seen examples at Coding Horror and The Daily WTF that show in a scant few lines some of the most impressive inability to think I have ever seen. These examples are not necessarily what we would consider mind numbingly, guffawingly, powerfully brutish idiocy but subtle brain warping WTF? These are the thought-knots we can't untie like that knot of legend the Gordian knot.
During my time over seas I have worked on code bases whose ages were measured in decades and sizes estimated in rough fractions of millions of lines. Code bases of this size are surely incomprehensible but the best can have inner structure that can be navigated and internal API that can be understood. The reader of this kind of code doesn't need to know what exactly each call does but only understand the local code and some specific libraries to work on it.
And then later in my career... oh the irony... I maintained a code base of a scant few hundred thousand lines of code whose internal structure shifted upon itself every few lines. Every few hundred lines a new API, a new convention, a re-written API, a half-refactor, a violation of another API. And so on the insanity folded over and over upon itself like a Lewis Caroll narrative without any beautiful onomatopoeia. All of it written by the same person over the course of five years.
Instead of a crystalline structure found in those majestic and old code bases whose patterns fold and unfold like a fractal thus leading the maintainer to an understanding of the whole from only a part... this newer... this smaller... this uglier code base contained no song and no resonance that my mind could fix upon. Instead it was a tangle of swamp weed coated in a toxic sludge that defied understanding and like "Alexander the great and the Gordian knot" I saw no other answer to my problems other than to cut it asunder. Bust it up, break it apart, make it small again.
No, I know better, size is not what kills code. It is the Gordian knot of superficial complexity that kills code. Instead of a crystalline pattern or an enforced internal structure the code is allowed to grow untamed. The key to long life in code is pulling out and separating concerns into libraries and frameworks.
You could argue this tactic constitutes removing some code from the main code base and creating small supporting projects that fit together to create a whole. You'd be right. That's what it is. That is what I mean by saying fractal, crystalline, or internally disciplined. The supporting libraries may be internal to the project but they may constitute sub-projects they divide and conquer the problems and keep the material from building to the point that it can accidentally tie itself in a knot.
You could achieve this using MVC, Services, or libraries. I've seen Domain Driven Designs and Spring annotations to enforce SoC that would work well. You could say this is how Linux and GNU work together to create a full operating system. You could say that is code reuse and proper object orientation. You could say this the weapon we have in the mix-in and dynamic language.
Whatever you call it. It makes code easier to understand because it has a logical structure and what I call a resonance or song. It means you can see part of a code base, understand it, and ignore the other concerns to focus on your particular problem.
If you can dive into one section of code and comprehend it without having to comprehend the whole thing then I say you have a good code base no matter how big or how small it is. The goal is to keep the knotty beast at bay for as long as possible using every trick we have.
2007-12-19
Fun with Groovy and the Reflection API
Here's the scenario: You've got dates in the format "MM/dd/yyyy" to be parsed and turned into a real Date object. You would parse the date like so:
And you have hundreds of collections of Java and Groovy objects that your library could be potentially mapping from hashes that look something like this:
You could write a switch statement for each of these... or you could go and ask the class defintions for what the types of foo.id and foo.started are. But if you do this:
... that println will print "null" because the started object is set to null. So how do I know if "started" is a date or not? I need to know the type on the other side of the "started" member. It would be nice to have a reverse mapping I could use... so I wrote this:
... now you can ask the type of a field like so ...
... to get the type of the field on the class you are working with... in a loop you would...
Presuming you knew that all the values of "val" were strings and all the members in "Foo" had constructors that could handle a string argument intelligently. I cache up the type map else where so that the real production classOf doesn't build a new type map on each pass.
But now I can map from arbitrary strings into real objects and back without having to specify a "mapping" for each object.
public Date format(String str) {
def format = new SimpleDateFormat( "MM/dd/yyyy" )
return format.parse(str)
}
public String format(Date date) {
def format = new SimpleDateFormat( "MM/dd/yyyy" )
return format.format(date)
}
And you have hundreds of collections of Java and Groovy objects that your library could be potentially mapping from hashes that look something like this:
["foo":[ "id" : "5", "started":"12/11/2007", "name":"bob" ]]
You could write a switch statement for each of these... or you could go and ask the class defintions for what the types of foo.id and foo.started are. But if you do this:
class Foo {
Long id
Date started
String name
}
def foo = new Foo()
println foo.started.getClass()
... that println will print "null" because the started object is set to null. So how do I know if "started" is a date or not? I need to know the type on the other side of the "started" member. It would be nice to have a reverse mapping I could use... so I wrote this:
def getTypeMap(Class clazz) {
def typeMap = [:]
def members = clazz.getDeclaredFields()
members.each( {
m ->
typeMap[m.getName()] = m.getType()
} )
return typeMap
}
... now you can ask the type of a field like so ...
def classOf(Class clazz, field) {
def typeMap = getTypeMap(clazz)
if(typeMap.containsKey(field)) {
return typeMap[field]
}
else {
return null
}
}
... to get the type of the field on the class you are working with... in a loop you would...
def params = ["id":"5","started":"12/11/2007","name":"bob"]
def foo = new Foo()
params.each({ key,val ->
def clazz = classOf(foo.getClass(),key)
if(clazz && clazz != Date.class) {
foo[key] = clazz.newInstance(val)
}
else if(clazz) {
foo[key] = (Date) format(val)
}
})
Presuming you knew that all the values of "val" were strings and all the members in "Foo" had constructors that could handle a string argument intelligently. I cache up the type map else where so that the real production classOf doesn't build a new type map on each pass.
But now I can map from arbitrary strings into real objects and back without having to specify a "mapping" for each object.
Seven Sins of Bad Groovy Programming
Jörg Staudemeyer has posted on the groovy-user forum at nabble a list of seven sins committed in groovy and why they are bad. A good read for anyone new to groovy.
2007-12-18
Single Sign On with JBoss Portal and Active Directory
No one has asked for it but I've begun work on a SSO project when I'm between official projects. I discovered the power of Acegi and CAS. I have an install of the JBoss portal as well and that requires its own set up too... however it is looking like we are going to use Joomla instead.
I began with understanding how to talk to an ldap server (in my case Active Directory). Once I understood how to query LDAP I began searching around using my groovy scripts to find the object classes, and specific names I would need inside my CAS configuration.
I then followed this tutorial for CAS to authenticate the users:
Next I built in the CAS client into JBoss portal using this wiki page's instructions:
Finding the specific settings were hard. In particular I had to muck about with the ldap_identity-config.xml deep inside our jboss-portal.sar file... it turns out our AD setup is somewhat "special" and needed some extra care beyond what is in this page:
I have no idea how I would have figured out how to do that kind of configuration without that wiki page.
Once I managed to stitch together both sets of instructions I could have my users authenticate via CAS and then the portal would query roles on its own against Active Directory.
Next I'll investigate how to bring Groovy and Grails into this mix. I'll have a project for delivery in March that will need to hook into this SSO system... and likely subsequent projects to link into the CAS system using PHP and Perl.
I began with understanding how to talk to an ldap server (in my case Active Directory). Once I understood how to query LDAP I began searching around using my groovy scripts to find the object classes, and specific names I would need inside my CAS configuration.
I then followed this tutorial for CAS to authenticate the users:
Next I built in the CAS client into JBoss portal using this wiki page's instructions:
Finding the specific settings were hard. In particular I had to muck about with the ldap_identity-config.xml deep inside our jboss-portal.sar file... it turns out our AD setup is somewhat "special" and needed some extra care beyond what is in this page:
I have no idea how I would have figured out how to do that kind of configuration without that wiki page.
Once I managed to stitch together both sets of instructions I could have my users authenticate via CAS and then the portal would query roles on its own against Active Directory.
Next I'll investigate how to bring Groovy and Grails into this mix. I'll have a project for delivery in March that will need to hook into this SSO system... and likely subsequent projects to link into the CAS system using PHP and Perl.
2007-12-12
BPM is mostly wrong
In response to:
The Seven Fallacies of BPM
Mentioned in "The World is Flat" book Business Process Modeling systems were supposed to deliver businesses with a glorious future in which Business Analysts could model processes without the need for a programmer's intervention.
The problem is that the modeling process itself is core to application development and utterly central and important to a properly functioning application. You would no more have a Doctor design your house than you would a Business Analyst design a Database or Application. The Doctor is concerned with much different sets of concerns than an Architect is. The Doctor is concerned about wheel chair access and ventilation while the Architect is concerned with whether the building will stand up to a storm or earthquake.
While both a Doctor and Architect could collaborate to create a house you would not have a Doctor build a house unassisted. If you did you would be inviting disaster. And, you would be offended if I suggested that you take dietary advice from an Architect. That would be absurd.
It is true that many small projects are released without the help of a specialist. I'm certain many buildings are built without an Architect... and many diseases are overcome without a Doctor. But, you should ask yourself what your project is? Are you trying to produce a professional product or are you just "hacking around" looking to make something that works? Do you want to create "professional" systems or just "hobby" systems. Are you producing a reliable car or are you creating a dune buggy in your back yard?
If you can honestly answer that the project you are producing is a "buggy" then by all means forgo the professional assistance ... but don't kid yourself... that's not a Toyota you've got.
The Seven Fallacies of BPM
Mentioned in "The World is Flat" book Business Process Modeling systems were supposed to deliver businesses with a glorious future in which Business Analysts could model processes without the need for a programmer's intervention.
The problem is that the modeling process itself is core to application development and utterly central and important to a properly functioning application. You would no more have a Doctor design your house than you would a Business Analyst design a Database or Application. The Doctor is concerned with much different sets of concerns than an Architect is. The Doctor is concerned about wheel chair access and ventilation while the Architect is concerned with whether the building will stand up to a storm or earthquake.
While both a Doctor and Architect could collaborate to create a house you would not have a Doctor build a house unassisted. If you did you would be inviting disaster. And, you would be offended if I suggested that you take dietary advice from an Architect. That would be absurd.
It is true that many small projects are released without the help of a specialist. I'm certain many buildings are built without an Architect... and many diseases are overcome without a Doctor. But, you should ask yourself what your project is? Are you trying to produce a professional product or are you just "hacking around" looking to make something that works? Do you want to create "professional" systems or just "hobby" systems. Are you producing a reliable car or are you creating a dune buggy in your back yard?
If you can honestly answer that the project you are producing is a "buggy" then by all means forgo the professional assistance ... but don't kid yourself... that's not a Toyota you've got.
2007-12-08
Learning the Eclipse RCP
While I'm learning grails I'm also learning the Eclipse RCP. I'm hoping to merge the two efforts at some point.
2007-12-07
telecomputational
Heard in conversation just now:
It's the dawn of a new era.
You have a telecomputational device don't you?
--Billy Howell
It's the dawn of a new era.
Grails 1.0-RC2 sprites and stogies
So, I've run on over to check out the Grails 1.0-RC2 release and see if all my favorite bugs were fixed. They were! And there were birds chirruping and rainbows and a unicorn ... and a sprite lit a fresh stogy for me and one for Bender. Then I tried to do something a little unusual. Should I? Dare I? Yes.
I tried to do a one-to-many mapping where the "one" side was a Groovy domain class and the many side was a JPA annotated class (You know an EJB3 entity bean). And it failed. Oh, the misery and woe! Well, okay it's not quite that bad.
So the lesson learned children? Don't do drugs, stay in school, use JPA or use GORM, be careful using both. I have filed this bug hoping that next time the stogy is a fine cuban cigar: GRAILS-1983. Bender likes fine cigars.
I tried to do a one-to-many mapping where the "one" side was a Groovy domain class and the many side was a JPA annotated class (You know an EJB3 entity bean). And it failed. Oh, the misery and woe! Well, okay it's not quite that bad.
So the lesson learned children? Don't do drugs, stay in school, use JPA or use GORM, be careful using both. I have filed this bug hoping that next time the stogy is a fine cuban cigar: GRAILS-1983. Bender likes fine cigars.
2007-11-30
Groovy Grails GORM and its flaws
NOTE: This problem was fixed in the Grails 1.0 release making GORM the most amazing Object Relational Mapper ever created by mortals.
I am beginning to understand the limitations in Grails better. I would say the "honey moon" phase is drawing to a close now and I can effectively evaluate the tool in light of some of its limitations. One such limitation is GRAILS-1308 which is slated for fix on the Grails 1.1 release... yes the Grails 1.1 release... NOT the up coming Grails 1.0 release. It turns out that this is a significant problem.
The problem in a nutshell is that if you have:
... and that EmployeeBean can be the one from this tutorial or even a straight Groovy domain object... and you try todo this:
The employees will simply not make it into the database... more over GORM won't even bother setting up anything to associate the two classes... ick.
What I end up doing is either:
I haven't tested going to all JPA classes yet, but I wonder if that wouldn't work.
I had not even noticed that I was working around this problem because I just naturally saw that things weren't working for me the way I wanted to I tried to figure out what the tool could do... and then I'd do that. Ideally you shouldn't have to do that at all. But, this is reality and we have to ship our projects on the platforms in front of us.
Even with its flaws Grails is still much better at many tasks than any other Java related product I have access to. Seeing flaws like this one and the poor support for SOAP clients in Groovy/Grails make me evaluate where I'll use Grails until version 1.1 comes out. The answer for me is Grails will be my front end system and I'll learn how to do Spring-JNDI bridging or Spring-RMI remoting to tie in more mature EJB3 technologies for the complex tasks.
In other words, Grails becomes more View than Controller for me. It becomes a powerful front-controller system for UI and web-applications. That's a good niche to fill... especially if I can learn to tie in a SessionBean from plain old Java land.
Oh yeah, and I'm sorely disappointed in the Searchable plugin too. It simply doesn't work on newer Grails versions. I might use a standalone WAR with very old Grails in it just to get the searchable feature... or I might wait fitfully for that wonderful plugin to deliver on its promises.
EDIT
Looks like the searchable plugin development has stopped dead in its tracks. Oh well. I guess it will be a while.
EDIT 2
I guess we can look forward to this bug being fixed in Grails 1.0! This just shows how amazingly responsive Graeme Rocher and his team are. Think of how many utterly disappointing software releases we've seen in the last few years. The Grails 1.0 release could really count as a breath of fresh air. I know getting this kind of response from a development team surely is for me. It bodes well for the future of Grails.
I can live without a plugin for a while if it means I get a sterling framework for it to plugin to.
I am beginning to understand the limitations in Grails better. I would say the "honey moon" phase is drawing to a close now and I can effectively evaluate the tool in light of some of its limitations. One such limitation is GRAILS-1308 which is slated for fix on the Grails 1.1 release... yes the Grails 1.1 release... NOT the up coming Grails 1.0 release. It turns out that this is a significant problem.
The problem in a nutshell is that if you have:
class Company {
Long id
Long version
String name
static hasMany [employees: EmployeeBean]
}
... and that EmployeeBean can be the one from this tutorial or even a straight Groovy domain object... and you try todo this:
def people = EmployeeBean.list()
people.each({ e ->
company.addToEmployees(e)
})
company.save()
The employees will simply not make it into the database... more over GORM won't even bother setting up anything to associate the two classes... ick.
What I end up doing is either:
- edit EmployeeBean so it "belongsTo" the company
- create a "bridging" object like "Contract"
I haven't tested going to all JPA classes yet, but I wonder if that wouldn't work.
I had not even noticed that I was working around this problem because I just naturally saw that things weren't working for me the way I wanted to I tried to figure out what the tool could do... and then I'd do that. Ideally you shouldn't have to do that at all. But, this is reality and we have to ship our projects on the platforms in front of us.
Even with its flaws Grails is still much better at many tasks than any other Java related product I have access to. Seeing flaws like this one and the poor support for SOAP clients in Groovy/Grails make me evaluate where I'll use Grails until version 1.1 comes out. The answer for me is Grails will be my front end system and I'll learn how to do Spring-JNDI bridging or Spring-RMI remoting to tie in more mature EJB3 technologies for the complex tasks.
In other words, Grails becomes more View than Controller for me. It becomes a powerful front-controller system for UI and web-applications. That's a good niche to fill... especially if I can learn to tie in a SessionBean from plain old Java land.
Oh yeah, and I'm sorely disappointed in the Searchable plugin too. It simply doesn't work on newer Grails versions. I might use a standalone WAR with very old Grails in it just to get the searchable feature... or I might wait fitfully for that wonderful plugin to deliver on its promises.
EDIT
Looks like the searchable plugin development has stopped dead in its tracks. Oh well. I guess it will be a while.
EDIT 2
I guess we can look forward to this bug being fixed in Grails 1.0! This just shows how amazingly responsive Graeme Rocher and his team are. Think of how many utterly disappointing software releases we've seen in the last few years. The Grails 1.0 release could really count as a breath of fresh air. I know getting this kind of response from a development team surely is for me. It bodes well for the future of Grails.
I can live without a plugin for a while if it means I get a sterling framework for it to plugin to.
2007-11-29
Working Grails and JPA... troubleshooting
I've been working with Grails and the JPA. In eclipse I use the Hibernate3 reverse engineer tool. To make that work I use a hibernate.cfg.xml file that I place in my project's top level folder and a hibernate.reveng.xml file also in the top level folder. I then ask the tool to create EJB3 annotated POJOs and drop them into my grails project.
Previously, I had been deleting the hibernate.cfg.xml and hibernate.reveng.xml files out of the project but yesterday I forgot to do that. What happens if you leave these extra files in your project is that none of the JPA objects get mapped and are therefore invisible to your GORM.
It turns out GORM is reading the top level hibernate.cfg.xml file so why would it see those classes? I never mapped the EJB3 entity beans in the hibernate.cfg.xml I was using for reverse engineer. So, no surprise. There won't be an error either because there were no hibernate errors. The GORM was working perfectly well against the hibernate.cfg.xml in the top level directory.
Now you might wonder why I have two different hibernate.cfg.xml files? Well, the answer is that I need different configurations for the running environment and for the reverse engineer environment. That might be peculiar for me.
Is this a bug? No, not really. It was very hard to diagnose because of the lack of output. Even turning all the logs wide open produced no problems. It wasn't until I went through the project and reverted it to an old version then added one change at a time to it that I noticed the problem was related to the extra hibernate file. At least I know to watch for that now.
Previously, I had been deleting the hibernate.cfg.xml and hibernate.reveng.xml files out of the project but yesterday I forgot to do that. What happens if you leave these extra files in your project is that none of the JPA objects get mapped and are therefore invisible to your GORM.
It turns out GORM is reading the top level hibernate.cfg.xml file so why would it see those classes? I never mapped the EJB3 entity beans in the hibernate.cfg.xml I was using for reverse engineer. So, no surprise. There won't be an error either because there were no hibernate errors. The GORM was working perfectly well against the hibernate.cfg.xml in the top level directory.
Now you might wonder why I have two different hibernate.cfg.xml files? Well, the answer is that I need different configurations for the running environment and for the reverse engineer environment. That might be peculiar for me.
Is this a bug? No, not really. It was very hard to diagnose because of the lack of output. Even turning all the logs wide open produced no problems. It wasn't until I went through the project and reverted it to an old version then added one change at a time to it that I noticed the problem was related to the extra hibernate file. At least I know to watch for that now.
2007-11-27
Grails Datasource, legacy database, and you
Any one out there trying to work with Groovy, Grails, and legacy databases?
Well, I am and I thought I'd share with you my final dataSource configuration. I'm using a legacy database that drove an Apache + mod_perl web site that had a MySQL 3.x database. The Groovy/Grails project I'm working on will interact with that data (right now as a read-only service) and here's the final dataSource definition I ended up using for our first beta.
The LAMP stack was upgraded to use MySQL 5 recently so we can set up our new projects using the setting dialect= org.hibernate.dialect.MySQLInnoDBDialect which will give us the ability to use actual foreign key relationships. That's a big deal if you are a LAMP developer. I suppose that in short order I will be a Grails, Linux, Apache, MySQL developer... a GLAM developer... ah... no... lets not call it that.
BTW: I deploy to a JBoss Application server in production which manages the DataSources in a legacy-ds.xml file under /usr/local/jboss/server/default/deploy that's why my production dataSource uses the jndi lookup.
Well, I am and I thought I'd share with you my final dataSource configuration. I'm using a legacy database that drove an Apache + mod_perl web site that had a MySQL 3.x database. The Groovy/Grails project I'm working on will interact with that data (right now as a read-only service) and here's the final dataSource definition I ended up using for our first beta.
import org.codehaus.groovy.grails.orm.hibernate.cfg.GrailsAnnotationConfiguration
/**
* This project is driven off of Legacy data.
* Use update to prevent wiping old tables...
* much of the data is accessed using JPA classes generated by
* the Hibernate3 reverse engineer tool.
********************************************************************/
dataSource {
configClass = GrailsAnnotationConfiguration.class
dbCreate = "update"
dialect= org.hibernate.dialect.MySQLMyISAMDialect // or perhaps MySQL5Dialect
pooled = false
}
environments {
development {
dataSource {
driverClassName = "com.mysql.jdbc.Driver"
url = "jdbc:mysql://localhost:3306/legacy?zeroDateTimeBehavior=convertToNull"
username = "legacy"
password = "legacy"
}
}
test {
dataSource {
driverClassName = "com.mysql.jdbc.Driver"
url = "jdbc:mysql://localhost:3306/legacy?zeroDateTimeBehavior=convertToNull"
username = "legacy"
password = "legacy"
}
}
production {
dataSource {
jndiName = "java:/LegacyDS"
}
}
}
The LAMP stack was upgraded to use MySQL 5 recently so we can set up our new projects using the setting dialect= org.hibernate.dialect.MySQLInnoDBDialect which will give us the ability to use actual foreign key relationships. That's a big deal if you are a LAMP developer. I suppose that in short order I will be a Grails, Linux, Apache, MySQL developer... a GLAM developer... ah... no... lets not call it that.
BTW: I deploy to a JBoss Application server in production which manages the DataSources in a legacy-ds.xml file under /usr/local/jboss/server/default/deploy that's why my production dataSource uses the jndi lookup.
2007-11-26
Alpha Geeks: say w00t!
2 Types of programmers
Yet, we work for and produce software for use by casual programmers and non-programmers. And as Sussman's post points out we had best not forget it. That means you. If you are reading my blog chances are an alpha geek (or just horribly lost).
What's the point of all the pretty shiny objects if we can't get people to use the pretty shiny objects?
... what many would call "alpha" programmers — the leaders, trailblazers, trendsetters, the kind of folks that places like Google and Fog Creek software are obsessed with hiring. These folks were the first ones to install Linux at home in the 90's; the people who write lisp compilers and learn Haskell on weekends "just for fun"; they actively participate in open source projects; they're always aware of the latest, coolest new trends in programming and tools.
Yet, we work for and produce software for use by casual programmers and non-programmers. And as Sussman's post points out we had best not forget it. That means you. If you are reading my blog chances are an alpha geek (or just horribly lost).
What's the point of all the pretty shiny objects if we can't get people to use the pretty shiny objects?
2007-11-21
Interoperability is the key to success
I just read the We have lost control post by Reg Braithwaite that's been making the rounds of the blog-o-sphere. Basically, modern IT departments compete directly with the internet. We have to. It's the 21st century. That's because...
It means that our end users have used the internet and if our programs don't measure up they know it. You can't hide it! They know! Braithwaite tells us this lovely story about working on a CRM for his mum:
In other words if you ship a CRM today that can't interoperate with a phone system... or your phone system can't interoperate with a CRM... your in house CRM will not measure up to the internet based competition... Skype.
And is the user wrong to expect a Skype-like experience? Should the IT department tell them to go suck an egg? I don't think that will fly.
Long story short modern IT departments will have to provide in-house mash-ups of services to be able to provide an end user experience that can compete with the wild and wooly internet.
BTW: I now believe that the Grails Searchable Plugin will change my life. Even though I haven't used it yet. Because I can see how full text search wins and how that plugin can single handedly enable search for all my projects. Yes... the computing world is about to change... again. Hold on for the barrel roll.
Our users are being exposed to applications we don’t control. And it messes things up.
It means that our end users have used the internet and if our programs don't measure up they know it. You can't hide it! They know! Braithwaite tells us this lovely story about working on a CRM for his mum:
For example, my Mother uses Skype to talk to her friends. She thinks it’s normal to see all of your voice mail messages in a list on the screen. If I tried to give her a CRM application for managing contacts, the very first question she would ask would be, “Why can’t I listen to all of the voice mails from that contact in the application?”
Do you think she would have patience for my explanation that the company’s phone systems are complex and proprietary and that we can’t install Asterix just for her? She would grab me by the ear and drag me to my desk to get cracking on it!
In other words if you ship a CRM today that can't interoperate with a phone system... or your phone system can't interoperate with a CRM... your in house CRM will not measure up to the internet based competition... Skype.
And is the user wrong to expect a Skype-like experience? Should the IT department tell them to go suck an egg? I don't think that will fly.
Long story short modern IT departments will have to provide in-house mash-ups of services to be able to provide an end user experience that can compete with the wild and wooly internet.
BTW: I now believe that the Grails Searchable Plugin will change my life. Even though I haven't used it yet. Because I can see how full text search wins and how that plugin can single handedly enable search for all my projects. Yes... the computing world is about to change... again. Hold on for the barrel roll.
2007-11-20
helloLDAP.groovy
Here's a short script that I wrote just to test working with an ActiveDirectory server. It's a short hack of a script that you can use to just test settings and the like. Thanks to this script I know I've found the right settings to work with our Microsoft ActiveDirectory server through Java. I could even use this groovy code to set up a Spring Bean service.
#!/usr/bin/env groovy
import java.util.Hashtable
import javax.naming.*
import javax.naming.event.*
import javax.naming.directory.*
def ou = " System and Service Accounts"
// here, we're just reading in some parameters...
def stdin = new BufferedReader(
new InputStreamReader(System.in)
)
print "username: " // your username to access LDAP... not a real user
String username = stdin.readLine()
print "password: " // the password for that account...
String passwd = stdin.readLine()
// next we set up an environment for LDAP
Hashtable env = new Hashtable()
env.put(
Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.ldap.LdapCtxFactory"
)
env.put(
Context.SECURITY_AUTHENTICATION,
"EXTERNAL"
)
/* // if only I had SSL working... *sigh* oh well...
env.put(
Context.SECURITY_PROTOCOL,
"ssl"
) //*/
// You'll want to put your server's name or IP here:
env.put(
Context.PROVIDER_URL,
"ldap://activedirectoryhost.mycompany.com:636/"
)
// Here, you'll want to set up your company's parameters for OU and DC...
env.put(
Context.SECURITY_PRINCIPAL,
"CN=" + username + ",OU=" + ou + ",DC=mycompany,DC=com"
) // username
env.put(
Context.SECURITY_CREDENTIALS,
passwd
) // and password
// Now we'll try and connect...
try {
def ctx = new InitialDirContext(env)
def attr = ctx.getAttributes("")
def srchInfo = new SearchControls()
// you'll want to use your own search base
def searchBase= "OU=company,DC=mycompany,DC=com"
// this is the magic search string sauce:
def searchFilter = "(&(objectClass=person))"
// we strong type the next var because it is
// used in a Java API that needs String[]
String[] objAttribs=[
"givenName",
"cn",
"sn",
"mail",
"mailNickname",
"userPrincipalName",
"displayName",
"manager",
"department",
"memberOf"
]
srchInfo.setSearchScope(SearchControls.SUBTREE_SCOPE)
srchInfo.setReturningAttributes(objAttribs)
// Now we get the results and loop through them...
NamingEnumeration dirObjects = ctx.search(searchBase,searchFilter,srchInfo)
def nodirObjects = 0
while (dirObjects != null && dirObjects.hasMoreElements()) {
def dirObject = dirObjects.next()
println("'" + dirObject.getName() + "':")
def attrs = dirObject.getAttributes()
for(name in objAttribs) {
println "\t * " + attrs.get(name)
}
nodirObjects++
}
ctx.close()
println("Number of entries identified: " + nodirObjects)
} catch (Exception e) {
println "Exception: " + e
}
2007-11-17
Grails Searchable Plugin... wow.
Words fail me Searchable plugin for Grails... wow. I'm speechless... I'm... wow. I just don't know what to say... wow.
Is anybody using this yet? I'm going to have to plug this into my very next project... wow.
Is anybody using this yet? I'm going to have to plug this into my very next project... wow.
2007-11-16
Magical MySQL URL parameters Save my Groovy Code
I've been working with legacy databases in MySQL and basically forbidden from using hibernate by a bug I had with all zero dates of the format '0000-00-00' which is perfectly legal in MySQL but completely disallowed in JDBC.
Stack trace for this problem contains:
The answer? Apparently there is a hidden setting to use...
That little flag on the URL is absolutely magical and now I can map my Grails objects onto a legacy database. Isn't life grand?
Stack trace for this problem contains:
SQL Exception: Value '0000-00-00' can not be represented as java.sql.Date
The answer? Apparently there is a hidden setting to use...
dataSource {
driverClassName = "com.mysql.jdbc.Driver"
dialect= org.hibernate.dialect.MySQLMyISAMDialect
url = "jdbc:mysql://localhost:3306/legacy?zeroDateTimeBehavior=convertToNull"
username = "legacyUser"
password = "legacyPassword"
}
That little flag on the URL is absolutely magical and now I can map my Grails objects onto a legacy database. Isn't life grand?
Groovy Class tricks
jwagon sent me these mind bending groovy class manipulations in a chat today:
Or how about....
#!/usr/bin/env groovy
class AA {
def msg
AA(something){ msg = something }
}
def c = { a, b ->
def x =a.newInstance(b)
println x.msg
}
c(AA, "foo")
Or how about....
#!/usr/bin/env groovy
def m = java.lang.String
def n = m.newInstance("foo")
println n
2007-11-15
The Fallacies of Distributed Computing
I'm working a SOAP heavy project right now so I thought I'd look up the 8 Fallacies of Distributed Computing. These are 8 assumptions people often make in designing network based systems such as a SOA or ESB that simply aren't true.
The following is NOT true:
1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn't change.
6. There is one administrator.
7. Transport cost is zero.
8. The network is homogeneous.
Designs should allow for the network to drop in and out, run slowly, take a while to move data around, change with out notice, or deal with multiple operating systems, langauges, or data representations. How often to we just think about the 'best case' scenario and fail to build in allowances for problems?
The following is NOT true:
1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn't change.
6. There is one administrator.
7. Transport cost is zero.
8. The network is homogeneous.
Designs should allow for the network to drop in and out, run slowly, take a while to move data around, change with out notice, or deal with multiple operating systems, langauges, or data representations. How often to we just think about the 'best case' scenario and fail to build in allowances for problems?
2007-11-14
Groovy Grails and the JPA
If you are using Grails 0.6 or later chances are the tutorials you've found for making EJB3 persistence annotated POJOs work with Grails don't match up exactly. If you're like me, probably need to be made aware of a few differences in configuration. They aren't big... but the little differences could trip you up.
First note my version of myApp/grails-app/conf/DataSource.groovy
Is not the same. Just because configClass = GrailsAnnotationConfiguration.class is set and your IDE says the class is found in this context doesn't mean that it's working for you... that import above still has to happen...
Next, I have added a file under "grails-app/conf/hibernate/hibernate.cfg.xml" and this part goes pretty much like the tutorials from last year... you register each class here one at a time. I need to research this one but I think grails mixes in this hibernate.cfg.xml with another one at run time so just stick to registering your classes. I tried to get fancy here and it didn't work out too well. My working hibernate.cfg.xml looks something like this:
You'll need your Java files to be in "src/java" and annotated up. I will be trying to make a shared JAR file full of only the shared domain objects for the various projects that need them. I don't know how well this is going to work but my idea is to create one set of JPA annotated EJB3 Entity classes and put them in a JAR and share them between various Spring applications. I don't know if that's a good idea or not...
Finally, you'll need to get the compiled class files for these annotated POJOs into "web-app/WEB-INF/classes" that means you need to do a "grails run-app" or similar first so that the Java files get compiled into classes and dropped into the "web-app/WEB-INF/classes" directory.
Once that is done you can run the "grails generate-all" command on your Java classes.
If you're interested in working through the EJB3 examples I have posted ejb3_grails.zip which uses this tutorial by Jason Rudolph but also uses Grails version 1.0_RC1 and the Groovy Eclipse Plugin.
EDIT: in version 1.0 and higher recent experience shows that if you set the Eclipse Groovy plugin to output to bin and set the build path of the Java compiler to output to project/bin class resolution will work fine for the IDE. When Grails itself goes to run the application or build the WAR file, the right class files will make it into "WEB-INF/classes" since Grails uses a separate class cache anyhow. It seems the reason I advised to output Groovy and Java classes to "web-app/WEB-INF/classes" is no longer true.
First note my version of myApp/grails-app/conf/DataSource.groovy
import org.codehaus.groovy.grails.orm.hibernate.cfg.GrailsAnnotationConfiguration
dataSource {
configClass = GrailsAnnotationConfiguration.class
pooled = true
dbCreate = "create-drop"
driverClassName = "com.mysql.jdbc.Driver"
dialect= org.hibernate.dialect.MySQLInnoDBDialect
url = "jdbc:mysql://localhost:3306/grails"
username = "grails"
password = "grails"
}
Is not the same. Just because configClass = GrailsAnnotationConfiguration.class is set and your IDE says the class is found in this context doesn't mean that it's working for you... that import above still has to happen...
Next, I have added a file under "grails-app/conf/hibernate/hibernate.cfg.xml" and this part goes pretty much like the tutorials from last year... you register each class here one at a time. I need to research this one but I think grails mixes in this hibernate.cfg.xml with another one at run time so just stick to registering your classes. I tried to get fancy here and it didn't work out too well. My working hibernate.cfg.xml looks something like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-configuration SYSTEM
"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
<session-factory>
<mapping package="com.mycompany.shared.domain" />
<mapping class="com.mycompany.shared.domain.Subject" />
</session-factory>
</hibernate-configuration>
You'll need your Java files to be in "src/java" and annotated up. I will be trying to make a shared JAR file full of only the shared domain objects for the various projects that need them. I don't know how well this is going to work but my idea is to create one set of JPA annotated EJB3 Entity classes and put them in a JAR and share them between various Spring applications. I don't know if that's a good idea or not...
Finally, you'll need to get the compiled class files for these annotated POJOs into "web-app/WEB-INF/classes" that means you need to do a "grails run-app" or similar first so that the Java files get compiled into classes and dropped into the "web-app/WEB-INF/classes" directory.
Once that is done you can run the "grails generate-all" command on your Java classes.
If you're interested in working through the EJB3 examples I have posted ejb3_grails.zip which uses this tutorial by Jason Rudolph but also uses Grails version 1.0_RC1 and the Groovy Eclipse Plugin.
EDIT: in version 1.0 and higher recent experience shows that if you set the Eclipse Groovy plugin to output to bin and set the build path of the Java compiler to output to project/bin class resolution will work fine for the IDE. When Grails itself goes to run the application or build the WAR file, the right class files will make it into "WEB-INF/classes" since Grails uses a separate class cache anyhow. It seems the reason I advised to output Groovy and Java classes to "web-app/WEB-INF/classes" is no longer true.
2007-11-13
Groovy Grails documentation online...
As the much anticipated 1.0 release of Grails approaches, the first release of the official Grails 1.0_RC1 documentation has been released.
2007-11-11
3D Linux Desktop
I use a 3D Linux desktop to do my work in. I have a dual monitor setup at work and a nice high-resolution single monitor (shown) at home. The 3D desktop doesn't just give my work a nice sheen of eye-candy it also gives me valuable feedback on the health and status of my OS.For one thing a busy application gets dimmer and gray in my desktop. So if my browser is busy it doesn't just stop responding to my clicks, I'll know its working hard well before that... I'll see it dim and go gray. If something really bad happens it will burst into flames. A moving application wobbles as it refreshes itself making the move feel substantial.
The 3D cube is a more natural way to deal with multiple desktops. I've been using 4 desktops in KDE for about a decade. But, it was easy to get lost on the desktops since they had no real spatial relationship to each other. This same feature has been ported to Windows and OSX so I'm sure many people are now enjoying multiple desktops. As far as I know these are UI changes that appeared on Linux first.
If you haven't seen Beryl yet you should. I think Beryl and Compiz could revitalize Linux on the desktop.
The humor of Engineers
From the wikipedia entry on Portal the video game:
I wish I worked in a team that had conversations like that. Oh... wait... I do.
"at the beginning of the Portal development process, we sat down as a group to decide what philosopher or school of philosophy our game would be based on. That was followed by about fifteen minutes of silence and then someone mentioned that a lot of people like cake."
I wish I worked in a team that had conversations like that. Oh... wait... I do.
2007-11-08
Being Presidential
"Nothing in the world can take the place of persistence.
Talent will not; nothing in the world is more common than unsuccessful men with talent.
Genius will not; unrewarded genius is a proverb.
Education will not; the world is full of educated derelicts.
Persistence and determination alone are omnipotent."
-- Calvin Coolidge
2007-11-07
Grails XFire Plugin
Had a little trouble with the XFire Plugin for Grails. I found this thread of posts on
nabble which clears things up. I attached the thread to the appropriate bug. Other than that I noticed that java.util.Date Is turned into a string. To fix this I created DTO (Data Transport Object) with XMLGregorianCalendar instead. This works find for DTO but could cause a minor headache if I have to expose domain classes directly through a SOAP service. Other than that the XFire plugin handles everything I need it to so far.
XFire is apparently on the verge of getting replaced with CXF which is an Apache incubator project. I was able to work through an CXF service myself using the JSR-181 annotations (that's the Java Web Services meta data specification). Configuring CXF inside a Spring container was the usual Spring XML-er-ific mess that you run into when doing Spring work without a tool kit.
Integrating the CXF Spring config with Grails worked up until I hit a class incompatability between Groovy 1.1 and CXF somewhere down in the XML parsers. I caught just enough to see that it was a class version problem around the DATETIME type where Groovy had one version and CXF had another. That was enough for me to decide to stick with the XFire plugin. I don't want to be in the business of building my own versions of anything that I didn't write.
I figure if the XFire plugin is that simple to set up then it will probably be just that simple to "port" my services to CXF later. Grails does a pretty good job of letting you switch between DWR, Prototype, and YUI when you are working in Ajax... so why not have multiple SOAP plugins that swap out just as easily?
nabble which clears things up. I attached the thread to the appropriate bug. Other than that I noticed that java.util.Date Is turned into a string. To fix this I created DTO (Data Transport Object) with XMLGregorianCalendar instead. This works find for DTO but could cause a minor headache if I have to expose domain classes directly through a SOAP service. Other than that the XFire plugin handles everything I need it to so far.
XFire is apparently on the verge of getting replaced with CXF which is an Apache incubator project. I was able to work through an CXF service myself using the JSR-181 annotations (that's the Java Web Services meta data specification). Configuring CXF inside a Spring container was the usual Spring XML-er-ific mess that you run into when doing Spring work without a tool kit.
Integrating the CXF Spring config with Grails worked up until I hit a class incompatability between Groovy 1.1 and CXF somewhere down in the XML parsers. I caught just enough to see that it was a class version problem around the DATETIME type where Groovy had one version and CXF had another. That was enough for me to decide to stick with the XFire plugin. I don't want to be in the business of building my own versions of anything that I didn't write.
I figure if the XFire plugin is that simple to set up then it will probably be just that simple to "port" my services to CXF later. Grails does a pretty good job of letting you switch between DWR, Prototype, and YUI when you are working in Ajax... so why not have multiple SOAP plugins that swap out just as easily?
2007-10-29
One Laptop Per Child
http://www.xogiving.org/ is running a special promotion, give one, get one starting November 12th of 2007. If you purchase an XO laptop for one child, you may also purchase one for yourself. The project will allow developers to get their hands on what could become one of the most common computers on the planet.
I think David Pogue's video blog on the OLPC drives home this simple idea that is really about advancing education. Textbooks are expensive. The OLPC can act as a textbook reader even in harsh day light. The OLPC can charge off of solar panels.
Most shockingly, it exposes it's own operating system code to the end user in a unique way I've never seen. Control commands expose the Python code behind every screen. That's amazing... could this mean that there is a potential horde of newly minted Python coders on the horizon? What does that mean?
I think David Pogue's video blog on the OLPC drives home this simple idea that is really about advancing education. Textbooks are expensive. The OLPC can act as a textbook reader even in harsh day light. The OLPC can charge off of solar panels.
Most shockingly, it exposes it's own operating system code to the end user in a unique way I've never seen. Control commands expose the Python code behind every screen. That's amazing... could this mean that there is a potential horde of newly minted Python coders on the horizon? What does that mean?
2007-10-25
People you don't like...
I can't find an official quote but I once saw a televised question and answer session with Warren Buffet. When an audience member asked what it was like being one of the world's richest men.
In Warren's reply he said: "One benefit is, I don't have to deal with people I don't like." Warren then went on to explain with grandfatherly charm that his days were spent dealing with people he admired or otherwise liked because he could afford to select those people to surround him. He explained that finding good people and investing in them was one of his keys to success.
Only the most wealthy of people can seriously claim that they don't have to deal with people they don't like. For everyone else in the world dealing with people who annoy you is just a fact of life. There's no real way out. Few of us can afford to ignore or avoid our bosses, coworkers, or authority figures if we want to.
Not having to deal with people you don't like is an expensive luxury.
In Warren's reply he said: "One benefit is, I don't have to deal with people I don't like." Warren then went on to explain with grandfatherly charm that his days were spent dealing with people he admired or otherwise liked because he could afford to select those people to surround him. He explained that finding good people and investing in them was one of his keys to success.
Only the most wealthy of people can seriously claim that they don't have to deal with people they don't like. For everyone else in the world dealing with people who annoy you is just a fact of life. There's no real way out. Few of us can afford to ignore or avoid our bosses, coworkers, or authority figures if we want to.
Not having to deal with people you don't like is an expensive luxury.
2007-10-23
Some advice from a smart guy
"Any fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."Make your software small, simple, and powerful.
-- Albert Einstein
2007-10-22
Issues of Concurrency
I have a problem. I have two databases. One old one and one new one. The new one is fully normalized and the old one is not. Both databases drive their own front ends. One is a Perl front end the other is a Spring Java front end. The data between both interfaces has to stay in sync. Our DBA has elected to use triggers to keep the databases in sync.
Hibernate uses its own Version column to keep up with which version got committed to the database and when it happened. There are articles dealing with JPA, Hibernate, and Concurrency... my problem is a little different.
Here's my example of the problem.
Let's say you have a web application using an ORM engine like Hibernate. There is Entity version 1 in the database. User Alice checks out version 1. User Bob checks out version one.
Alice edits her copy of version 1 and sends it back. The ORM engine checks the object version against the database version and they match and on commit of Alice's changes the database version number is set to 2.
Bob makes changes to his copy of version 1 of the Entity and checks his version in. The ORM checks the database version and sees version 2 in the database. Version 1 is old and Bob gets an error reporting mid-air collision.
Now lets say you introduce a second database. This second database uses different Relational mappings but is itself an OLTP. Let's pretend both databases have exact copies of the data initially and an update trigger mechanism keeps the two OLTP's in sync.
If Alice checks out version 1 from the first database and the first interface and Bob checks out version 1 from the second database and the second interface. When Alice makes her change and creates first version 2 (2' or two prime) and Bob commits his changes to create second version 2 or (2'' or two double prime) the trigger from the first database to update the second will fire simultaneously as the trigger from the second.
In other words Alice's OLTP is unaware of changes made on Bob's OLTP and both changes are in route to the other's.
How should the two databases proceed?
Should last saved win? Should both databases error and roll back? Should the systems attempt to "merge" changes? Should one system be elected the "authority" for this data electing that Alice's interface and OLTP are always the right ones?
Hibernate uses its own Version column to keep up with which version got committed to the database and when it happened. There are articles dealing with JPA, Hibernate, and Concurrency... my problem is a little different.
Here's my example of the problem.
Let's say you have a web application using an ORM engine like Hibernate. There is Entity version 1 in the database. User Alice checks out version 1. User Bob checks out version one.
Alice edits her copy of version 1 and sends it back. The ORM engine checks the object version against the database version and they match and on commit of Alice's changes the database version number is set to 2.
Bob makes changes to his copy of version 1 of the Entity and checks his version in. The ORM checks the database version and sees version 2 in the database. Version 1 is old and Bob gets an error reporting mid-air collision.
Now lets say you introduce a second database. This second database uses different Relational mappings but is itself an OLTP. Let's pretend both databases have exact copies of the data initially and an update trigger mechanism keeps the two OLTP's in sync.
If Alice checks out version 1 from the first database and the first interface and Bob checks out version 1 from the second database and the second interface. When Alice makes her change and creates first version 2 (2' or two prime) and Bob commits his changes to create second version 2 or (2'' or two double prime) the trigger from the first database to update the second will fire simultaneously as the trigger from the second.
In other words Alice's OLTP is unaware of changes made on Bob's OLTP and both changes are in route to the other's.
How should the two databases proceed?
Should last saved win? Should both databases error and roll back? Should the systems attempt to "merge" changes? Should one system be elected the "authority" for this data electing that Alice's interface and OLTP are always the right ones?
2007-10-17
Linux Forgotten Root Password
Oh no, you've forgotten the root password to your laptop or other Linux desktop.
If they are set up with grub all is not lost. At the grub splash screen key in 'e' for edit. You'll now be able to edit the boot options. Select the line with the kernel on it and add the word 'single' as the last parameter. When you hit enter the edit mode will exit. Striking the 'b' for boot command will boot this configuration and your kernel will boot into the magical single user mode where you can type 'password' to change root's password without having to know what that forgotten original password was.
Now you can use the awesome power of root to change the other forgotten passwords on the system. If you think this presents a security hole and don't want to allow 'e' from the grub splash... you can secure grub with a password.
If they are set up with grub all is not lost. At the grub splash screen key in 'e' for edit. You'll now be able to edit the boot options. Select the line with the kernel on it and add the word 'single' as the last parameter. When you hit enter the edit mode will exit. Striking the 'b' for boot command will boot this configuration and your kernel will boot into the magical single user mode where you can type 'password' to change root's password without having to know what that forgotten original password was.
Now you can use the awesome power of root to change the other forgotten passwords on the system. If you think this presents a security hole and don't want to allow 'e' from the grub splash... you can secure grub with a password.
2007-10-15
Symbol System Manipulation
If thought is just the manipulation of symbols. Then computers think. If thought is more than the manipulation of symbols... then how do you know people think?
If you can't accept that the mechanical manipulations of symbol systems carried out by a computer are thought... then how can you accept that the mechanical symbol manipulations carried out by organic beings are thought?
Artificial Intelligence beats real stupidity every time.
Waxing a tad philosophical, perhaps the mechanical symbol manipulations of any system be it a human brain or a computer are the echo of thought. In the case of the computer the program is the echo of a thought left by its programmer. In the case of a brain these are the echoes of thoughts begun in the minds of others and advanced or reproduced yet again.
The idea is that thought-stuff can move between noggins and that the computer offers a similar place of purchase for the thought-stuff as a rather simple minded noggin. So thought-stuff lives in noggins. Thought-stuff can be preserved in medium like a seed of an annual plant it lays dormant on a page. Thought-stuff gets planted in a noggin and sprouts.
Living thought stuff that bears fruit as action and turns to seed is shot across the divide between noggins in speech, on paper, or as code. The result is germinated. In the case of code the germination can occur in the artificial soil of a computer.
If you can't accept that the mechanical manipulations of symbol systems carried out by a computer are thought... then how can you accept that the mechanical symbol manipulations carried out by organic beings are thought?
Artificial Intelligence beats real stupidity every time.
Waxing a tad philosophical, perhaps the mechanical symbol manipulations of any system be it a human brain or a computer are the echo of thought. In the case of the computer the program is the echo of a thought left by its programmer. In the case of a brain these are the echoes of thoughts begun in the minds of others and advanced or reproduced yet again.
The idea is that thought-stuff can move between noggins and that the computer offers a similar place of purchase for the thought-stuff as a rather simple minded noggin. So thought-stuff lives in noggins. Thought-stuff can be preserved in medium like a seed of an annual plant it lays dormant on a page. Thought-stuff gets planted in a noggin and sprouts.
Living thought stuff that bears fruit as action and turns to seed is shot across the divide between noggins in speech, on paper, or as code. The result is germinated. In the case of code the germination can occur in the artificial soil of a computer.
2007-10-12
The new Alfresco
TriLUG last night had a special presentation from principal architect Jon Cox. Jon Cox had developed software for the Interwoven product suites and is now working for Alfresco which has released a new versioning engine based on Jon's work.
The new alfresco tool's new features include Native Office integration, multiple locking models, adaptive workflow engines based on jBPM, REST style API, a new Web 2.0 front end, web portal integration, and web content management features. The big win here is the long awaited Office integration. Unfortunately, this feature is apparently very new and doesn't have good documentation around it yet.
For a programmer the most common use of versioning is in source code version management with tools such as SVN. The difference between Alfresco and SVN was described by Cox using this analogy:
Imagine you have a window pane and you are looking at the Mona Lisa. You can draw on this pane, erase it, do what ever you want and no one but you can see it. Now imagine there are three of you... Alice, Bob, and Charlie. Charlie puts a mole on Mona Lisa, Bob puts a mustache, and Alice adds a goatee. If Charlie commits (permanently saves) his mole Alice and Bob will suddenly see the mole show up underneath their window panes.
This is very different from source code control in products like SVN and CVS. In source code the developers all have their copies that they work on. When they are done they commit their changes. In SVN if Charlie has committed that mole neither Alice nor Bob will see the mole until they go to commit. When they try to commit they get an error. Alice and Bob each have to update manually and then make changes to accommodate Charlie's mole addition.
This is inappropriate behavior for managing documents. And, that is why Alfresco can be set up with either pessimistic locking (source code type locking) or optimistic locking (everyone sees each other's changes immediately).
I took away these key concepts:
Alfresco versioning composed of three layers... The official copy, the working copy, and the preview.
The official copy is like the Mona Lisa under glass, the working copy you have is like a pane of glass that you can draw on and no one can see. The preview exists behind you as a preview that you can send "links" to other people who can then look "over your shoulder". This set of concepts allows people to play "what if" scenarios with their documents and web sites.
The working copy can pass through an approval process before it reaches the official copy. You may snapshot a working copy before you send a preview and only allow a preview of the snap shot. And all this can be used to version sets of documents or websites.
Toward the end of the talk Jon entertained the long term vision that the Alfresco object-version system could be used for source code control. It would allow for the implementation of different policies on how source code could be modified and worked with... and could be used to implement radically different software work patterns then what we use now.
The new alfresco tool's new features include Native Office integration, multiple locking models, adaptive workflow engines based on jBPM, REST style API, a new Web 2.0 front end, web portal integration, and web content management features. The big win here is the long awaited Office integration. Unfortunately, this feature is apparently very new and doesn't have good documentation around it yet.
For a programmer the most common use of versioning is in source code version management with tools such as SVN. The difference between Alfresco and SVN was described by Cox using this analogy:
Imagine you have a window pane and you are looking at the Mona Lisa. You can draw on this pane, erase it, do what ever you want and no one but you can see it. Now imagine there are three of you... Alice, Bob, and Charlie. Charlie puts a mole on Mona Lisa, Bob puts a mustache, and Alice adds a goatee. If Charlie commits (permanently saves) his mole Alice and Bob will suddenly see the mole show up underneath their window panes.
This is very different from source code control in products like SVN and CVS. In source code the developers all have their copies that they work on. When they are done they commit their changes. In SVN if Charlie has committed that mole neither Alice nor Bob will see the mole until they go to commit. When they try to commit they get an error. Alice and Bob each have to update manually and then make changes to accommodate Charlie's mole addition.
This is inappropriate behavior for managing documents. And, that is why Alfresco can be set up with either pessimistic locking (source code type locking) or optimistic locking (everyone sees each other's changes immediately).
I took away these key concepts:
Alfresco versioning composed of three layers... The official copy, the working copy, and the preview.
The official copy is like the Mona Lisa under glass, the working copy you have is like a pane of glass that you can draw on and no one can see. The preview exists behind you as a preview that you can send "links" to other people who can then look "over your shoulder". This set of concepts allows people to play "what if" scenarios with their documents and web sites.
The working copy can pass through an approval process before it reaches the official copy. You may snapshot a working copy before you send a preview and only allow a preview of the snap shot. And all this can be used to version sets of documents or websites.
Toward the end of the talk Jon entertained the long term vision that the Alfresco object-version system could be used for source code control. It would allow for the implementation of different policies on how source code could be modified and worked with... and could be used to implement radically different software work patterns then what we use now.
2007-10-09
Watching ProjectZero
I just saw this ProjectZero Demo and given that this is IBM developing the tool I'll be watching the development of this project over time. It seems that Project Zero competes with Spring. Unlike Grails which builds on top of Spring, Zero appears to create a new set of conventions and competes with Spring.
SunSpot + Lego + LeJOS + Groovy
A few ideas have been rolling around in my head for the last few weeks. For one I really like the idea of the SunSpot kit and I really like the idea of LeJOS which is Java for the Lego Mind Storm robotics kits. I am slowly finding myself becoming a Groovy fanatic too.
So, I've got this crazy idea of doing a Lego + LeJOS + Groovy + Sun Spot project just to prove it can be done. I'm just entertaining the idea right now... but I think I'll need several hundred dollars in hardware to pull off a project. I hope to turn this particular idea into more than a pipe dream but once again I'm severely resource constrained.
Anyone think I can get a grant to do this stuff?
So, I've got this crazy idea of doing a Lego + LeJOS + Groovy + Sun Spot project just to prove it can be done. I'm just entertaining the idea right now... but I think I'll need several hundred dollars in hardware to pull off a project. I hope to turn this particular idea into more than a pipe dream but once again I'm severely resource constrained.
Anyone think I can get a grant to do this stuff?
2007-10-08
Code Addicts in Java Land
Some one just sent me this Billy Hollis video. Billy asks us if we are "Code Heads" and although his solution is Microsoft based, it's and entertaining talk just the same. It is why we have 1.2 billion frameworks (a slight exaggeration) in the Java code space. Developers need frameworks and developers like writing them. The problem is developers don't seem to like using the other guy's framework.
Microsoft has the benefit of being "the one" and can dictate the community's direction. Few vendors have that luxury. That's one reason why Microsoft shops have an easier time making up their minds... they have no real choice.
Java shops have a myriad of choices and can decide to go any number of routes. You could go application server specific, Java standards specific, or with an open source framework. You could choose to write in a dynamic language on the JVM or in plain old Java.
The trick is to recognize when you can leverage the framework and to actually do it. Don't write the code for the sake of writing code. Use the tools in your frameworks for what they are good at.
Microsoft has the benefit of being "the one" and can dictate the community's direction. Few vendors have that luxury. That's one reason why Microsoft shops have an easier time making up their minds... they have no real choice.
Java shops have a myriad of choices and can decide to go any number of routes. You could go application server specific, Java standards specific, or with an open source framework. You could choose to write in a dynamic language on the JVM or in plain old Java.
The trick is to recognize when you can leverage the framework and to actually do it. Don't write the code for the sake of writing code. Use the tools in your frameworks for what they are good at.
2007-10-05
GORM is a work of Art
I've been working in GORM a lot lately. And out of all the different ways I've ever had to make objects work with tables this is perhaps the most fun and straight forward.
My eyes kind of glaze over when people mention XML configurations and that seems to violate some deep down desire I have for all the things related to a thing... let's say a class Foo and its mapping and validation... to either be contained with in Foo or near by Foo. Spreading out validation and mapping between multiple objects related to Foo rubs me wrong.
GORM fixes this problem by using the Groovy language concepts to store this validation configuration inside the class definition. Which I like because my bias is nearly always toward code. The addition of code by convention means many of the pre-defined queries I would have been writing in EJB3 annotations are created when called.
It is the most pleasant way to do ORM I've ever seen.
My eyes kind of glaze over when people mention XML configurations and that seems to violate some deep down desire I have for all the things related to a thing... let's say a class Foo and its mapping and validation... to either be contained with in Foo or near by Foo. Spreading out validation and mapping between multiple objects related to Foo rubs me wrong.
GORM fixes this problem by using the Groovy language concepts to store this validation configuration inside the class definition. Which I like because my bias is nearly always toward code. The addition of code by convention means many of the pre-defined queries I would have been writing in EJB3 annotations are created when called.
It is the most pleasant way to do ORM I've ever seen.
2007-10-02
Ruby on Rails: The Java web DSL
Technical evaluations aside, the longevity of a technology has more to do with the community behind it than it does with the suitability of the product. The "Sun surprise at railsconf Europe 2007" has shed some light on what the character of the Rails community may become. Justin seriously thinks this could lead to a hybrid Java/Ruby or JRuby coming of age in the near future.
That Ruby thunder is the Groovy rumbling we heard all summer. It looks like the "official" Sun Java camp may be backing the Ruby on Rails horse. In Open Source technology it isn't always the best, most feature rich, or advanced product that wins. This is probably the revelation that Sun is working from. Ruby on Rails is popular and Java can ride that train all the way into town.
The question is now, will JRuby ride its rails over Groovy or does Groovy still have a niche.
Moving from Java to Groovy is simple since most Java syntax works in Groovy. That means you only need to add on new language features and you're writing in Groovy. A very shallow and gradual learning curve for Java people. Is that enough? Is that everything?
JRuby's claim to fame will be the ability to work with EJBs and run in an "enterprise" environment. When that hype train comes into the station many things won't matter. When RoR is a full fledged member of the Java environment Ruby becomes one more Java DSL and Rails becomes one more Java web framework.
And that's a good thing. It means Ruby on Rails and Java are not mutually exclusive. It means both sides benefit. These are critical developments to watch right now because the fall out from these will greatly influence the political landscape of web development for years to come.
If Java can successfully bring Ruby into the fold we can reverse some industry killing fatal fragmentation.
That Ruby thunder is the Groovy rumbling we heard all summer. It looks like the "official" Sun Java camp may be backing the Ruby on Rails horse. In Open Source technology it isn't always the best, most feature rich, or advanced product that wins. This is probably the revelation that Sun is working from. Ruby on Rails is popular and Java can ride that train all the way into town.
The question is now, will JRuby ride its rails over Groovy or does Groovy still have a niche.
Moving from Java to Groovy is simple since most Java syntax works in Groovy. That means you only need to add on new language features and you're writing in Groovy. A very shallow and gradual learning curve for Java people. Is that enough? Is that everything?
JRuby's claim to fame will be the ability to work with EJBs and run in an "enterprise" environment. When that hype train comes into the station many things won't matter. When RoR is a full fledged member of the Java environment Ruby becomes one more Java DSL and Rails becomes one more Java web framework.
And that's a good thing. It means Ruby on Rails and Java are not mutually exclusive. It means both sides benefit. These are critical developments to watch right now because the fall out from these will greatly influence the political landscape of web development for years to come.
If Java can successfully bring Ruby into the fold we can reverse some industry killing fatal fragmentation.
2007-10-01
Ruby on Rails: Long term view
How viable is it long term?
Working in Java you know that there is a good chance that you could work in Java up to retirement. But, the nature of that job could change drastically. There is also a good chance the next ten to twenty years of that job could be spent maintaining banking software created in the last decade.
I have a rule: "Never fall in love with technology"
The reason you should never fall in love with technology is that it changes. The rules for what technology triumphs are not wholly rooted in market share, technical sophistication, or beauty either. So it is very hard to evaluate where a technology will land in the landscape of all things digital.
The one insurance policy for a developer is to "keep moving" so that they are always on to the greener fresher pastures. But this means never developing a depth of technical knowledge in any one technology stack.
Ruby on Rails is old hat by now. It has been around for several years now and has helped legitimise the LAMP stack in the minds of many traditional developers. Because Rails enforces good design standards such as MVC and Unit testing it sits well with Software Engineering types who like to see discipline in development projects. But, how is it long term? How does it look for someone deciding to build a career on it?
Let's look at why something like Java was able to enter the "Enterprise" business space.
Java was backed by Sun and Sun was big iron. The weight of Sun lent legitimacy to the Java development stack. The marketing of Java focused on "enterprise" quality solutions that conjured images of serious engineers building serious programs to with stand serious load under serious conditions. Java was serious. Seriously.
For just how serious Java was take a look at any fine book store selling computer programming books. If there is more than one shelf of "computer programming books" then you are probably going to be staring at mostly Java or Java related books. Java is everywhere. Java is in your cell phone... and that is a potentially powerful idea.
What gives Ruby any kind of weightiness in light of all that "enterprise" goodness behind Java?
Well, for one thing, look how serious Patrick Lenz is in the photo on this page for "Build Your Own Ruby on Rails Web Applications". And, then there's Amazon who uses it and they are no slouches. The other thing to keep in mind is that when we're talking Ruby we're talking open source and that changes the rules a little. After all, what is Linux? Did it have any big iron support?
So what I might actually ask when determining the long term viability of something like Ruby on Rails is not is "Ruby on Rails" viable but: is the "Ruby on Rails Community" viable? And that is a slightly different question and much more valid today.
Java has about 1.2 billion web frameworks to choose from. (A small exaggeration) The proliferation of choice means that there is enough community behind Java to create all those frameworks. Certainly enough wasted resource and talent in the community to convince someone that they were all needed whether they were wanted or not. And there is a depth of knowledge and wisdom in those development efforts that can be leveraged.
I think this is why Java is being "Open Sourced" today. It is probably an concession by Sun that it can't win the closed source battle against open source and that if the product is to survive it is on community. A vibrant open source community. A community that is leveraged by Ruby on Rails.
Every Java talk I've been to in the last year has had some mention of Ruby on Rails. It has captured the minds of many Java devotees based on its technical beauty. I think RoR actually benefits from its _lack_ of choice. Because there are fewer ways to get things done and fewer options the RoR community is more tightly focused even if they are smaller.
The bottom line is I can't say what the long term viability is for RoR. But I plan on devoting the next few days to studying it and getting a better feel for why it has taken the fancy of certain Java devotees. Why is RoR worth "burning the ships" for and never setting foot on Java land again?
Long term viability of a product in the internet age is not tied to big iron companies with crushing infrastructure. Long term viability of a product today is tied to the community. It is a fact of the internet age. So much so that Gartner believes that open source will be unavoidable.
So I don't have a conclusion for you because I haven't spent enough time in Ruby land. I'll be taking a tour this week and I'll try and render some kind of verdict on the health of the Ruby community. If someone wants to point me in a certain direction feel free.
Working in Java you know that there is a good chance that you could work in Java up to retirement. But, the nature of that job could change drastically. There is also a good chance the next ten to twenty years of that job could be spent maintaining banking software created in the last decade.
I have a rule: "Never fall in love with technology"
The reason you should never fall in love with technology is that it changes. The rules for what technology triumphs are not wholly rooted in market share, technical sophistication, or beauty either. So it is very hard to evaluate where a technology will land in the landscape of all things digital.
The one insurance policy for a developer is to "keep moving" so that they are always on to the greener fresher pastures. But this means never developing a depth of technical knowledge in any one technology stack.
Ruby on Rails is old hat by now. It has been around for several years now and has helped legitimise the LAMP stack in the minds of many traditional developers. Because Rails enforces good design standards such as MVC and Unit testing it sits well with Software Engineering types who like to see discipline in development projects. But, how is it long term? How does it look for someone deciding to build a career on it?
Let's look at why something like Java was able to enter the "Enterprise" business space.
Java was backed by Sun and Sun was big iron. The weight of Sun lent legitimacy to the Java development stack. The marketing of Java focused on "enterprise" quality solutions that conjured images of serious engineers building serious programs to with stand serious load under serious conditions. Java was serious. Seriously.
For just how serious Java was take a look at any fine book store selling computer programming books. If there is more than one shelf of "computer programming books" then you are probably going to be staring at mostly Java or Java related books. Java is everywhere. Java is in your cell phone... and that is a potentially powerful idea.
What gives Ruby any kind of weightiness in light of all that "enterprise" goodness behind Java?
Well, for one thing, look how serious Patrick Lenz is in the photo on this page for "Build Your Own Ruby on Rails Web Applications". And, then there's Amazon who uses it and they are no slouches. The other thing to keep in mind is that when we're talking Ruby we're talking open source and that changes the rules a little. After all, what is Linux? Did it have any big iron support?
So what I might actually ask when determining the long term viability of something like Ruby on Rails is not is "Ruby on Rails" viable but: is the "Ruby on Rails Community" viable? And that is a slightly different question and much more valid today.
Java has about 1.2 billion web frameworks to choose from. (A small exaggeration) The proliferation of choice means that there is enough community behind Java to create all those frameworks. Certainly enough wasted resource and talent in the community to convince someone that they were all needed whether they were wanted or not. And there is a depth of knowledge and wisdom in those development efforts that can be leveraged.
I think this is why Java is being "Open Sourced" today. It is probably an concession by Sun that it can't win the closed source battle against open source and that if the product is to survive it is on community. A vibrant open source community. A community that is leveraged by Ruby on Rails.
Every Java talk I've been to in the last year has had some mention of Ruby on Rails. It has captured the minds of many Java devotees based on its technical beauty. I think RoR actually benefits from its _lack_ of choice. Because there are fewer ways to get things done and fewer options the RoR community is more tightly focused even if they are smaller.
The bottom line is I can't say what the long term viability is for RoR. But I plan on devoting the next few days to studying it and getting a better feel for why it has taken the fancy of certain Java devotees. Why is RoR worth "burning the ships" for and never setting foot on Java land again?
Long term viability of a product in the internet age is not tied to big iron companies with crushing infrastructure. Long term viability of a product today is tied to the community. It is a fact of the internet age. So much so that Gartner believes that open source will be unavoidable.
So I don't have a conclusion for you because I haven't spent enough time in Ruby land. I'll be taking a tour this week and I'll try and render some kind of verdict on the health of the Ruby community. If someone wants to point me in a certain direction feel free.
2007-09-26
If technology is key to your strategy...
... if technology is key to your strategy, then, when you plan your strategy include a practicing technologist. People who have dedicated their careers to studying technology will typically understand it. Those people can advise you on how technology can interact with your plans.
2007-09-19
Sipping Googleccinos
But then, while you’re sitting on your googlechair in the googleplex sipping googleccinos and feeling smuggy smug smug smug, new versions of the browsers come out that support cached, compiled JavaScript. And suddenly NewSDK is really fast. And Paul Graham gives them another 6000 boxes of instant noodles to eat, so they stay in business another three years perfecting things.- Joel On Software
Okay, that's about the funniest thing I've read in a month. Kudos Joel.
2007-09-18
TriJUG: Java FX
A term I shall coin today is YAJAPPL (Yet Another JAva Platform Programming Language.) and I'll use it to refer to Groovy, JRuby, and Java FX. Last night's TriJUG meeting was a double header on Java FX and Java 6 update 5. The big noise in Java land is over new programming languages that play on the JRE and tonight was no different.
First up, Java FX which is tagged in the press as Sun's answer to Flash. This summary doesn't do either Flash or FX justice. From what Raghavan "Rags" Srinivas showed us I'd say that the real strategic play here with Java FX is the creation of YAJAPPL (pronounced yah-juh-apple) which has a nifty concept in it called a "bind".
Java FX appears to be yet another language enamored with the associative array. Window definitions and graphical display elements are composed of associative arrays of associative arrays. What's different here is that you can bind an attribute in a display element to a value or method in another object. Demos I've seen include tying a radius to a time stepped method that causes the circle to grow or shrink.
This is a powerful concept in the long run since it means a true separation of the MVC elements and not just by virtue of enforcing this via policy. The Java FX code itself will force the separation. The graphical design tools will certainly help craft better looking Java applications in shorter time frames... but it's really that "bind" concept that's going to simplify development.
Next up was the Java 6 update 5 release and the introduction of the Java Kernel. To someone who is relatively new to the Java political landscape this looks like an update that was sorely needed and a long time in coming. From what I understand the upshot of the new release is that Java is no longer distributed monolithically. That means you download the Java Kernel and some browser plugins to start with.
The browser plugins are interesting in that they will allow scripts running on websites to detect the presence and version of Java installed in the browser the plugin is running in. Sun's goal will be to get as many browsers as possible to run these Java bootstrapping plugins so that way sites can detect Java and cause the JRE to download additional Java features as needed.
It would be very nice for Sun to consider doing something with these remote class loaders that would allow the formation of a comprehensive Java archive network that would allow the distribution of JAR files and the expression of their dependencies. The archive network could function as an open source clearing house that developers could use to get their proposed classes peer reviewed and that neophyte Java developers could use as an example of "good" Java. Projects in the network would have to under go a review process to be accepted to keep out cruft.
With the new browser plugins circulating allowing for piece-meal download of the JRE on an as needed basis it reduces the cost of the JRE from an enormous 10 MB to a merely huge 4 MB. This reduces a barrier to entry for some shops.
Ethan Nicholas mentioned that the JRE plugin was too large for Yahoo! to consider using for the Yahoo! Maps project. It didn't matter if Java was a superior development platform, had better API, or could do a better job all around. It only mattered that from a practical stand point the JRE was a heavy plugin.
Ethan's lesson to Sun is in my words: "It doesn't matter if you are better if they don't let you play."
And, this is the problem facing Java in this space. Java is on just about every cell phone out there but it doesn't matter if they don't let Java play. Java and Java FX appear to be better suited linguistically for their respective jobs than anything that Flash and ActionScript currently have but that doesn't matter if Flash has more developers, better tools, and an equal install base. Java won't even get to play.
Now, Java is open source. Open JDK is out there. But, I don't see it causing any earth quakes until around Java version 8. That quake is coming though and the people involved now will likely be the shakers.
First up, Java FX which is tagged in the press as Sun's answer to Flash. This summary doesn't do either Flash or FX justice. From what Raghavan "Rags" Srinivas showed us I'd say that the real strategic play here with Java FX is the creation of YAJAPPL (pronounced yah-juh-apple) which has a nifty concept in it called a "bind".
Java FX appears to be yet another language enamored with the associative array. Window definitions and graphical display elements are composed of associative arrays of associative arrays. What's different here is that you can bind an attribute in a display element to a value or method in another object. Demos I've seen include tying a radius to a time stepped method that causes the circle to grow or shrink.
This is a powerful concept in the long run since it means a true separation of the MVC elements and not just by virtue of enforcing this via policy. The Java FX code itself will force the separation. The graphical design tools will certainly help craft better looking Java applications in shorter time frames... but it's really that "bind" concept that's going to simplify development.
Next up was the Java 6 update 5 release and the introduction of the Java Kernel. To someone who is relatively new to the Java political landscape this looks like an update that was sorely needed and a long time in coming. From what I understand the upshot of the new release is that Java is no longer distributed monolithically. That means you download the Java Kernel and some browser plugins to start with.
The browser plugins are interesting in that they will allow scripts running on websites to detect the presence and version of Java installed in the browser the plugin is running in. Sun's goal will be to get as many browsers as possible to run these Java bootstrapping plugins so that way sites can detect Java and cause the JRE to download additional Java features as needed.
It would be very nice for Sun to consider doing something with these remote class loaders that would allow the formation of a comprehensive Java archive network that would allow the distribution of JAR files and the expression of their dependencies. The archive network could function as an open source clearing house that developers could use to get their proposed classes peer reviewed and that neophyte Java developers could use as an example of "good" Java. Projects in the network would have to under go a review process to be accepted to keep out cruft.
With the new browser plugins circulating allowing for piece-meal download of the JRE on an as needed basis it reduces the cost of the JRE from an enormous 10 MB to a merely huge 4 MB. This reduces a barrier to entry for some shops.
Ethan Nicholas mentioned that the JRE plugin was too large for Yahoo! to consider using for the Yahoo! Maps project. It didn't matter if Java was a superior development platform, had better API, or could do a better job all around. It only mattered that from a practical stand point the JRE was a heavy plugin.
Ethan's lesson to Sun is in my words: "It doesn't matter if you are better if they don't let you play."
And, this is the problem facing Java in this space. Java is on just about every cell phone out there but it doesn't matter if they don't let Java play. Java and Java FX appear to be better suited linguistically for their respective jobs than anything that Flash and ActionScript currently have but that doesn't matter if Flash has more developers, better tools, and an equal install base. Java won't even get to play.
Now, Java is open source. Open JDK is out there. But, I don't see it causing any earth quakes until around Java version 8. That quake is coming though and the people involved now will likely be the shakers.
2007-09-17
Binding JBoss
$ /usr/local/jboss/bin/run.sh -b `hostname` 1>&2>/dev/null &
Binds JBoss to `hostname` on port 8080 and ignores the standard output and standard error.
2007-09-13
Database questions...
If you were building a new project today, which database should you use?
If you are working with JBoss how do you identify the need for an XA compliant database?
If you need XA and you are on a budget which database do you use?
If you are working with JBoss how do you identify the need for an XA compliant database?
If you need XA and you are on a budget which database do you use?
2007-09-12
EJB3 security annotations
So with EJB3 declarative security annotations I can do things like this:
Which will allow me to lift the Frobnicator bean out and drop it into a JUnit tests as a POJO. The POJO can then call the methods in Frobnicator without authentication. This helps doing unit tests and getting higher code coverage. But... isn't the authentication part of what I've written? Isn't that something that needs testing?
So my predicament is how do I provide automated acceptance testing for all the permutations of roles in the system?
@DeclareRoles("ADMIN", "USER")
public class Frobnicator {
@RolesAllowed("ADMIN","USER")
public boolean checkFrobnication() { ... }
@RolesAllowed("ADMIN")
public boolean fullyFrobnicate() { ... }
}
Which will allow me to lift the Frobnicator bean out and drop it into a JUnit tests as a POJO. The POJO can then call the methods in Frobnicator without authentication. This helps doing unit tests and getting higher code coverage. But... isn't the authentication part of what I've written? Isn't that something that needs testing?
So my predicament is how do I provide automated acceptance testing for all the permutations of roles in the system?
2007-09-11
Database Vendor Political Landscape as of 2007
Oracle: Oracle the company has filed court proceedings against SAP citing that SAP has been stealing Oracle intellectual property. Oracle 11g is still closed source and proprietary. Considered the leader in RDBMS technologies and offers unique features such as XML Publisher and XML SQL Java API's that allow java developers to do ORM in Oracle proprietary ways.
Please note this is simply my opinion. Companies are presented in random order. No official recommendations are being made.
Microsoft: Owner of both Access and SQL Server products, SQL server is based on Transact-SQL which is an implementation of the ANSI SQL standard. It is favored by .NET developers because of its tight integration with the .NET Framework. SQL Server runs only on the Windows operating system and as such can only be used in production environments that are predominantly windows. Security vulnerabilities such as the "SQL slammer worm" have scared some shops away from this option as an internet application OLTP store.
IBM: acquired Informix and supports Informix along side DB2. DB2 now has an open source version. Informix and DB2 have started to share features. IBM's move to open source DB2 may indicate a shift in IBM's software development and support strategy. The acquisition of Informix may indicate a desire at IBM to freshen their database offerings. Informix is actively supported by IBM and has had a new release this year.
Sybase: Still a traditional software shop, their still closed and proprietary products based on Transact-SQL have confusing names such as OpenServer and OpenClient which typically are used in industry to indicate Open Source or at least a reviewable source code base. This is simply not the case with the Sybase products. These products are "Try and Buy" products which has absolutely nothing to do with Open Source. However, Sybase still has a strong following but their popularity is waning.
Firebird: an open source RDBMS that features ANSI SQL 2003 compliance is based on Inprise code base from Borland's now defunct InterBase database product. This project is extremely young and unproven by RDBMS standards.
MySQL AG: In addition to the unique MySQL product which has earned acclaim and scorn alike for its design, MySQL AG acquired MaxDB from SAP. MaxDB is an ANSI SQL 1992 compliant product. MySQL itself is partially ANSI SQL 1999 compliant... or rather MySQL does not comply entirely with ANSI standards but enjoys a 10 million user install base. That large install base has earned it the title of "The Open Source Database" since it has become a defacto standard for open source projects such as Ruby on Rails.
Ingres Corporation: Still enjoys a following, (judging from all the comments below to fix this post), but has not enjoyed much market attention. The survival of the product and company appears to be driven by legacy support.
PostgreSQL: Sun Microsystems provides support for Postgres which is an ORDBMS (Object-Relational Database Management System) which is an open source project based on Ingres. It has a much richer feature set than MySQL and commercial technical support available from Sun Microsystems. Among the database players it is unique for its support of multiple PL/SQL sub languages. While Postgres has not enjoyed the success that MySQL has it is used by clients such as BASF, IMDB, Skype, TiVo, USPS, Sony, VeriSign, and the US department of labor. Postgres continues to thrive but has no marketing buzz around it... it has a solid reputation in the Open Source community as a "real" database. (EDIT: Sun does not own PosgreSQL, they merely support it.)
Apache: The Derby RDBMS is actually the IBM Cloudscape database also known as the Sun Microsystems Java DB. The project has only emerged from Apache incubator status in 2004 and is relatively unproven.
The upshot
Oracle and Microsoft still are industry leaders and seem to be relatively comfortable each in their own niche. There doesn't seem to be a serious contender that could knock down either of them.
MySQL has achieved nearly total dominance and is currently the un-assailable king of the Open Source database market but this dominance is built on a non-standard and non-compliant database system that has serious issues with ACID compliance and major missing ANSI SQL features.
Several players (strangely, IBM is a small player in the open source database market niche) are challenging MySQL's dominance by open sourcing already proven, stable, and compliant databases. Serious technical contender Postgres can not seem to get a solid marketing based footing that could propel it to the front. Apache Derby and Firebird may prove to be serious competitors in five years. No other current players seriously factor in to the short term picture.
A fringe player DB4O (Database for Objects) is an interesting new technology but will not likely be a serious commercial space contender in the near future. The product is only 3 years old in production but has prominent users such as BMW, Boeing, Bosh, Intel, Ricoh, and Seagate.
2007-09-10
Engineering for the Web
"What ever happened to Web engineering?"
This just feeds my assertion that the dot-com boom was the worst thing to happen to software engineering practice in computer history. The bust was harrowing and the good and bad alike were cut down, but, the boom is what fostered the legacy of bad practice and unrealistic expectations that we have to fight today.
The new movement to introduce engineering principles back into web development shops should be unnecessary.
"The problem is, strictly separating designers from developers has resulted in a Web built by people frightfully unaware of the standards and technologies required to make it go. Most Web pages today extend well beyond the limited scope of HTML, and a good many of them bring together a "pure" programming language like Java or C++ (you know, real code with control structures and variables and stuff) with healthy chunks of JavaScript, PHP, HTML, CSS, and oh, don't forget, XML."
This just feeds my assertion that the dot-com boom was the worst thing to happen to software engineering practice in computer history. The bust was harrowing and the good and bad alike were cut down, but, the boom is what fostered the legacy of bad practice and unrealistic expectations that we have to fight today.
The new movement to introduce engineering principles back into web development shops should be unnecessary.
2007-09-08
Groovy Grails Portlet
I need to put my grails applications in a Portal. If you look at Bug 1345 over at codehaus you can see I'm not the only one. Now Spring will run in a Portlet... Grails is built on Spring... how hard could it be? I might write a portlet adapter myself.
2007-09-04
Careful, Spring will eat your lunch...
One of the best NFJS talks that I did not attend but should have was the talk by Venkat Subramaniam titled "OSGI: A Well Kept Secret." I discovered this talk on my CD a few days ago and started researching OSGi.
OSGi is indeed a well kept secret and appears to be worth looking at. Based on Venkat's presentation and research I've done on my own it looks like OSGi could very well be an answer to creating web enabled appliances. These could be hardware that through JNI and OSGi could expose themselves as services... and it appears that this could be the answer to the class loader woe I had a few months back. Not to mention sounding like it's a JINI/JMX killer... which seems to me to be the lion's share of what an Applications server is to most applicaitons.
The big deal here isn't so much OSGi and how good it is... but that Spring is (from what I see in Venkat's notes) poised to leverage OSGi in its 2.1 release. And if Spring can offer Hibernate3 and JINI/JMX replacements... and can offer SOA... and can offer all of this in an industry standard way...
... why are we using those big heavy application servers again? Clustering? It seems to me that Spring is getting ready to eat someone's lunch. Make sure it isn't yours. Red Hat, I'm looking in JBoss' direction... do you really think embeddable ejb3 will save you? Is that rye bread?
OSGi is indeed a well kept secret and appears to be worth looking at. Based on Venkat's presentation and research I've done on my own it looks like OSGi could very well be an answer to creating web enabled appliances. These could be hardware that through JNI and OSGi could expose themselves as services... and it appears that this could be the answer to the class loader woe I had a few months back. Not to mention sounding like it's a JINI/JMX killer... which seems to me to be the lion's share of what an Applications server is to most applicaitons.
The big deal here isn't so much OSGi and how good it is... but that Spring is (from what I see in Venkat's notes) poised to leverage OSGi in its 2.1 release. And if Spring can offer Hibernate3 and JINI/JMX replacements... and can offer SOA... and can offer all of this in an industry standard way...
... why are we using those big heavy application servers again? Clustering? It seems to me that Spring is getting ready to eat someone's lunch. Make sure it isn't yours. Red Hat, I'm looking in JBoss' direction... do you really think embeddable ejb3 will save you? Is that rye bread?
2007-09-01
Grails Widget list...
Take a look at this...
... which I got from the Grails site. So, if you want to use the code generators to create views for a form and want a string to have a text area as its input you can use the constraints on the object to specify text area. But wait, what other widgets can you specify?
I did a little digging in the Grails source code and came up with this list....
def constraints = {
description(widget:'textarea')
}
... which I got from the Grails site. So, if you want to use the code generators to create views for a form and want a string to have a text area as its input you can use the constraints on the object to specify text area. But wait, what other widgets can you specify?
I did a little digging in the Grails source code and came up with this list....
- textField
- hiddenField
- submitButton
- field
- textArea
- form
- actionSubmit
- actionSubmitImage
- datePicker
- renderNoSelectionOption
- timeZoneSelect
- localeSelect
- currencySelect
- select
- checkBox
- radio
2007-08-31
Pimping with Groovy
One of the great advantage to the Groovy programming language is that you can take Java libraries and extend them. The formal technical definition of this process when done in Groovy is called "Pimping".
http://groovy.codehaus.org/Pimp+my+Library+Pattern
So why do we care about Groovy?
Groovy, the programming language for pimping.
Oh yeah.
http://groovy.codehaus.org/Pimp+my+Library+Pattern
So why do we care about Groovy?
- Groovy allows you to access all the power of Java from shell scripts
- Groovy compiles to Java binary format allowing you to use Groovy from Java
- Groovy lets you pimp
Groovy, the programming language for pimping.
Oh yeah.
2007-08-30
Where do we go now?
Last year Google dropped their SOAP API and today they announced that You Tube launched a new API. That got me thinking.
This Google-hate-on-SOAP was covered at my NFJS conference, the reason cited was the strong typing issue in SOAP.
As I've written SOAP services I've found that you get tied to the POJO or DTO object that you write. This is okay if you are a small shop and you control both end points (read "me") but it becomes a problem when you have 3rd parties working with your services. The problem gets pretty bad after a half dozen versions...
What to do? Well, apparently if you ar a multi-billion dollar organisation you do this:
Google Data API
Which is the google answer to the problems in SOAP. Now if you aren't Google you could do a few different things... you could just use the GData libraries... reverse engineering your own back end for them since they don't release the server side code for this stuff... or you could do what was suggested by the ThoughtWorks consultant at NFJS... you _could_ do loosely typed SOAP services.
Huh?
A loosely typed soap service is a soap service that takes an XML document as its only parameter. That means your method names change from
to
which doesn't seem all that profound from the method signature but it does introduce a bit of pain. The pain introduced is in the necessity of implementing a strategy pattern...
Strategy Pattern
... in this case you would have a collection of parser or processing engines that would return a result document. The particulars on which result and how we get it are determined by the concrete implementation.
But even this seems a little hackish. But, take a look at this:
stone mind on rest, groovy, and other things
And, I think this sums up where my mind is headed. After spending a lot of time hacking around in the J2EE playing grounds where there are all kinds of horribly stodgy things, conflicting ideas, and just plain crazy ideas... I've come away with a couple of golden nuggets I'll share with you and where I think the technology stack will be in three years.
I don't have an affinity for Python. I don't have a particular love of plain old Java either, but I do have a yen for many tools that Java lovers have. I love their XML handling tools. I love entity manager based persistence engines.
I think Groovy is going to be a major player for shops like mine where we have a need to work with Java and other tool chains too. We need to get things done quickly but we also need to be a bit stodgy at times. Groovy means we can bring in the Java "enterprise" stack without choking on the "enterprise" part.
Grails helps a lot too. It is rapid application development, MVC, Hibernate3, and Spring in a box and you can crank out applications in it once you know what you're doing. The trouble is getting to know what you are doing if you are a PHP programmer. (which we can find... but not JSP programmers)
I think there needs to be a few more Grails books. But I'm adept at figuring things out and I can get by without a book. I'm impressed that Grails has a DWR plugin so that means the best of all possible worlds.
I am looking forward to getting things done with Java, Groovy and Grails in the next couple of months. I think Groovy will take off in the next few years and legitimize the dynamic language on the Java stack. Groovy is just variant enough off of Java to improve development cycle but close enough to Java to keep the barrier to entry low.
This Google-hate-on-SOAP was covered at my NFJS conference, the reason cited was the strong typing issue in SOAP.
As I've written SOAP services I've found that you get tied to the POJO or DTO object that you write. This is okay if you are a small shop and you control both end points (read "me") but it becomes a problem when you have 3rd parties working with your services. The problem gets pretty bad after a half dozen versions...
What to do? Well, apparently if you ar a multi-billion dollar organisation you do this:
Google Data API
Which is the google answer to the problems in SOAP. Now if you aren't Google you could do a few different things... you could just use the GData libraries... reverse engineering your own back end for them since they don't release the server side code for this stuff... or you could do what was suggested by the ThoughtWorks consultant at NFJS... you _could_ do loosely typed SOAP services.
Huh?
A loosely typed soap service is a soap service that takes an XML document as its only parameter. That means your method names change from
@WebMethod
public User getUserByComplex(ComplexObject complex)
to
@WebMethod
public XmlDocument getUser(XmlDocument xml)
which doesn't seem all that profound from the method signature but it does introduce a bit of pain. The pain introduced is in the necessity of implementing a strategy pattern...
Strategy Pattern
... in this case you would have a collection of parser or processing engines that would return a result document. The particulars on which result and how we get it are determined by the concrete implementation.
But even this seems a little hackish. But, take a look at this:
stone mind on rest, groovy, and other things
And, I think this sums up where my mind is headed. After spending a lot of time hacking around in the J2EE playing grounds where there are all kinds of horribly stodgy things, conflicting ideas, and just plain crazy ideas... I've come away with a couple of golden nuggets I'll share with you and where I think the technology stack will be in three years.
I don't have an affinity for Python. I don't have a particular love of plain old Java either, but I do have a yen for many tools that Java lovers have. I love their XML handling tools. I love entity manager based persistence engines.
I think Groovy is going to be a major player for shops like mine where we have a need to work with Java and other tool chains too. We need to get things done quickly but we also need to be a bit stodgy at times. Groovy means we can bring in the Java "enterprise" stack without choking on the "enterprise" part.
Grails helps a lot too. It is rapid application development, MVC, Hibernate3, and Spring in a box and you can crank out applications in it once you know what you're doing. The trouble is getting to know what you are doing if you are a PHP programmer. (which we can find... but not JSP programmers)
I think there needs to be a few more Grails books. But I'm adept at figuring things out and I can get by without a book. I'm impressed that Grails has a DWR plugin so that means the best of all possible worlds.
I am looking forward to getting things done with Java, Groovy and Grails in the next couple of months. I think Groovy will take off in the next few years and legitimize the dynamic language on the Java stack. Groovy is just variant enough off of Java to improve development cycle but close enough to Java to keep the barrier to entry low.
2007-08-29
Groovy Grails: Little joys
I'm working on a Groovy Grails project and I've just written a controller that takes a post from a form with only a partial representation of the object. Full representation of the object in the form is easy just do this:
The properties save to the Database without much fuss and if the data is invalid we'll toss back to the edit view with a bucket of error messages. But, what if I only wanted to update one field in my object from a form... or sub form... or Ajax call?
...take a look at this little slice of groovy:
The output looks like this:
What just happened? We mapped the values from a Map object onto the fields of an object with out knowing what the fields in the Java object were. Without introspection.
I presume this works with a POJO and if it does I'm going to go have a party tonight because I think web form processing, ETL, and a whole mess of other ORM type activities just got a helluva lot easier in Java land.
Aren't you happy?
myObj.properties = params
myObj.save()
The properties save to the Database without much fuss and if the data is invalid we'll toss back to the edit view with a bucket of error messages. But, what if I only wanted to update one field in my object from a form... or sub form... or Ajax call?
...take a look at this little slice of groovy:
public class testObj {
Long a
Long b
String c
}
def t = new testObj(a:0,b:1,c:"foo");
t.properties.each({
println it
});
def params = ['a':1,'b':2]
println "-----------"
params.keySet().each({
println it + "->" + params[it]
t[it] = params[it]
})
println "-----------"
t.properties.each({
println it
});
The output looks like this:
metaClass=groovy.lang.MetaClassImpl@157c2bd[class testObj]
class=class testObj
b=1
c=foo
a=0
-----------
a->1
b->2
-----------
metaClass=groovy.lang.MetaClassImpl@157c2bd[class testObj]
class=class testObj
b=2
c=foo
a=1
What just happened? We mapped the values from a Map object onto the fields of an object with out knowing what the fields in the Java object were. Without introspection.
I presume this works with a POJO and if it does I'm going to go have a party tonight because I think web form processing, ETL, and a whole mess of other ORM type activities just got a helluva lot easier in Java land.
Aren't you happy?
2007-08-24
Getting Fit and Groovy
Fitnesse + Groovy + Hudson
Today I'm going to talk about my Continuous Integration environment and Acceptance Testing Framework. We are using Fitnesse to write acceptance tests that run in Fit, Hudson (running ant) to create our builds, and we're writing our Fitnesse Fixtures in Groovy.
The big picture
The Fitnesse Acceptance testing suite paired with the right tools becomes an absolute authoritative documentation of all business processes implemented in the software under test. It becomes not only a tool for validating software but also a tool for quantifying formal and informal business processes. For some companies this can provide a light weight tool for business analysts to understand their business where no formal tool provided any such insight before.
References:
- Hudson - a continuous integration server that is extremely easy to set up and manage
- Fitnesse - a stand alone wiki that is a server and wiki all in one which makes life easy for neophyte administrators but harder on experienced admins and developers... yes I know they spelled fitness wrong.
- Groovy - a revolutionary new scripting language that compiles to Java byte code.
Hudson: Because continuous integration facilitates testing early and often and prevents software projects from getting into a broken state. You want to know where your problems will be early since fixing unit level bugs is easier earlier in the development cycle rather than later.
Fitnesse: Because acceptance testing should test function of the code independent of presentation of code. We sing the praise of Model View Controller separation in code... why not in test? Business users can understand spreadsheets and fitnesse tests are just wiki spreadsheets. Fixtures are just preambles to calling your re-usable API. So all business features can be encoded into the fitnesse framework leading to automated functional regression testing. That means easy business visibility to programmer's progress and an easy way to update changes in requirements.
Groovy: Because traditional Java Bean code doesn't "facilitate expressing what a program is really trying to accomplish" and that is not something you want to get bogged down by in your fixtures... fixtures are not "real" or "permanent" code! Groovy lets you crank out fixtures quickly so you can focus on the important code that going to get called by that fixture.
Some business process details
Typically what happens in software projects that age is the documentation that expresses what the business thinks the project should do becomes less and less accurate of what the software does do. This happens either because the business expresses a requirement change outside the documentation or because the regression testing system does not look at business level acceptance tests for the system as a whole.
Using continuous integration and an automated acceptance testing solution that expresses requirements in business level language means that all business cases are tested each build. The system does not "drift" from requirements. If the business changes the requirements that is expressed in a way that demonstrates how much "breakage" the change represents. This affords the business an objective way to measure the cost of the change in an unambiguous way.
The Fitnesse wiki becomes the repository for all knowledge about the business rules expressed in the software system. This documentation of a business rule is automatically validated against the system and the code either operates this way or not. There is no disparity between what the business thinks the business rule the software supports is and what the code implements as a business rule.
Making it happen
As of this writing, Hudson and Fitnesse should share the same file system to make writing your ant build scripts easier. Hudson will call the ant build script for your project, I've specified a "fitnesse" target in the script that deploys all the classes for the project into the fitnesse files directory allowing you to run fitnesse tests from the wiki on the code base.
Tasks overview
- deploy hudson.war into a servlet container... that could be Apache+Tomcat, Jetty, JBoss + Tomcat, or whatever your heart desires as long as it can deploy war files. The servlet container for hudson should not use the same port as fitnesse. Typically users want fitnesse to run on port 80.
- "deploy" fitnesse to an established and stable directory that ant and hudson can reliably access. You will set up fitnesse to either grab port 80 or catch port 80 forwarded traffic so that fitnesse is easy for your business users to get to.
- set up your ant build script to compile groovy to class files and to deploy classes into the fitnesse file system for execution by fitnesse wiki pages.
- tweaking the classpath of the fitnesse wiki pages to include the groovy embeddable jar file.
I've posted before on deploying software to Linux boxes so I won't spend any time on that issue here. I should think you can find good tutorials on how to configure Fitnesse and Hudson for your environment. Instead I'll talk about the unique features of my configuration.
The secret sauce
The ant build script has the following
<property name="fitnesse-dir" location="/usr/local/fitnesse/FitNesseRoot/files/OLA"/>
<taskdef name="groovyc"
classname="org.codehaus.groovy.ant.Groovyc"
classpathref="classpath"/>
You can add a line to a FitNesse wiki page that adds classes to the class path for the test runner. For example on our fitness server we have groovy installed (via symbolic link) under /usr/local/groovy and fitnesse installed under /usr/local/fitnesse.
Hudson runs an ant build script that has a fitnesse-dir property, a groovyc task definition, and a fitnesse target after build.
We set up Groovy tasks like this:
<taskdef name="groovy"
classname="org.codehaus.groovy.ant.Groovy"
classpathref="classpath"/>
<taskdef name="groovyc"
classname="org.codehaus.groovy.ant.Groovyc"
classpathref="classpath"/>
And build the groovy files to classes by doing this:
<groovyc destdir="${build}" srcdir="${src}" classpath="${build}">
<include name="**/*.groovy"/>
<include name="**/*.java"/>
</groovyc>
... instead of calling javac, we are using groovyc so we get java and groovy compiled side-by-side able to work with each other seamlessly.
Next, we set up the fitnesse dir property as:
<property name="fitnesse-dir" location="/usr/local/fitnesse/FitNesseRoot/files/MyProj"/>
So that later we can do this:
<target name="fitnesse" description="Set up for FitNesse tests" depends="build">
<mkdir dir="${fitnesse-dir}">
<delete file="${fitnesse-dir}/proj-fitnesse.jar">
<jar jarfile="${dist}/proj.jar" basedir="${build}">
<jar jarfile="${fitnesse-dir}/proj-fitnesse.jar">
<fileset dir="${build}">
<fileset dir="${test-dir}">
</jar>
</target>
Now on the wiki pages we set the path to include our project jar and the groovy jar...
!path /usr/local/fitnesse/FitNesseRoot/files/MyProj/myproj-fitnesse.jar:/usr/local/groovy/embeddable/groovy-all-1.1-beta-2.jar
There isn't really anything special to get Fitnesse to use Groovy fixtures. Groovy compiles to class files and Fitnesse will look on its class path for class names that match the fixture name. For example if we create a fitnesse table that looks like this:
|MyFixture |
| param1 | param2 | param3 |
| joe | | blogs |
| mary | joesephine | blogs |
Now when you run the test the page will look for MyFixture.class in your jar file. It won't care whether the class is Java or Groovy. If your fixture is a groovy class, you have provided the groovy jar to the classpath and it will just run.
Subscribe to:
Posts (Atom)