techno.blog("Dion")

The Pragmatic Programmers wrote a great book in Programming Ruby.

They just released a second edition which is up to date with Ruby 1.8.2, and has an extra 250 pages (Ruby keeps getting bigger and better!)

The second edition of the PickAxe book! A tutorial, language reference, and library reference all in one book. Chapters on web programming, unit testing, extending Ruby, and packaging your code. New in this edition: six new tutorial chapters, documentation on all standard libraries, updated reference for built-in classes and modules. More than 250 pages of new or significantly updated material. Covers the latest Ruby (1.8).

Read more

There has been a lot said about Struts. Most of what I hear is:

• It sucks! My pet framework is much better
• It is great! Although I have never used anything else
• It is good enough

I have heard the “it is good enough” a lot recently. This especially seems to come up when developers are on project where the requirement is to use Struts. “My boss told I had too”. “It is a corporate standard”.

I especially feel sorry when someone who writes a popular framework is forced to use it ;)

For a lot of people, they have grabbed this reality, and have chosen to make the most of it. This results in work such as Cobbie’s, in which has has adapters which allow him to use actions which work in WebWork 2, right in Struts. Add to this a nice testing framework, and other items (e.g. use SiteMesh rather than Tiles, using Spring, etc) and then it has you wondering. Is Struts that bad?

I think it is definitely usable. I mean people are coming up with good solid applications using Struts. However, I am not sure why I would choose it on a new project (other than for political reasons, or due to the staff [a group of Struts experts]).

I am lucky enough to be working on project where we got to choose the web framework. We can use Tapestry or WebWork and noone has cared. What a pleasure?

What is the future for Struts? I think it is destined to take a U-turn, or it will die in legacy. What is the U-turn? Make it work as that framework on top of JSF, which makes JSF usable ;)

I like the 80’s band Erasure, but not when it shows up in Java Generics.

I know that there is a battle:

backwards compatibility vs. no damn casts + give me info via the bytecode + I don’t want someone to sneak in via other means to do what they want

For some reason backwards compatibility seems to always win with Java.

I know it is important, but sometimes you want to move on and evolve. I think we have reached that point, and Sun should move to Java 3 SE/EE/ME (or maybe Java 5000 or something!).

The aim of backwards compatibility isn’t even working unless you are under certain conditions.

Come on. Let’s free the Sun engineers from their “hmm, but how can we keep backwards compatibility” jail. Let them fly. Let them evole the language for the next level. Please!

Large companies have to go through insane testing before they go from jdk 1.3 to 1.4 to 1.5 (or probably more are just on 1.3). So, let them deal with it (or choose to stay at 1.3 for legacy, and Java 5000 for new projects :)

I was speaking about JDO 2 and Groovy at No Fluff Just Stuff in Salt Lake City.

It was a comedy of errors getting there (short story: stupid of me to rely on my cell phone alarm, and driving too fast… ending up with a cop!), but when I did, I was surprised to see as much AO content as there was.

I also was interested to see how full the sessions were. You could learn about basic AOP, AspectJ, AO Refactoring, and Applied AOP (a.k.a. more than Logging examples). Good stuff!

JSR 250: Common Annotations for the Java Platform is out there, and you can request to join the expert group.

The scope is hard to work out:

This JSR will develop annotations for common semantic concepts in the J2SE and J2EE platforms that apply across a variety of individual technologies.

What does this mean?

I agree with the desire to standardize on annotations. That is needed, else we will have a million annotations for the same thing (we need the equiv of java.lang.* and java.package.* and ….).

However, I worry that we will have a group making decisions that should be deferred. Again, this group could be an unbrella group for others which come up with more specialised topics… which yet shouldn’t be in their own specs.

For example, OR mapping can be shared between JDO and EJB (although I would prefer that there was ONE transparent persistence spec… but I won’t go there ;).

I would rather see a small spec/group formed for this. Then we get to the next point, which is what would we want to annotate here.

I agree with some of the JDO expert group that want to restrict annotations to the model (@Persistent, @Inverse), and we don’t clutter it with deployment info (@Table(Name=”FOO”)).

And if I see raw SQL in the annotations. Ewww!

I had the pleasure of being asked to write a foreward for Ted Neward’s new book Effective Enterprise Java.

I have never written a foreward, so it was kinda fun to think about. What do you actually write in a foreward? I had to take a peek at a couple of examples, and then just said down and said the truth on what I thought about the book.

So, rather than post what I think about the book here…. I can copy and paste from my first book foreward!

Effective Enterprise Java Foreward

Designing and implementing large scale enterprise systems is hard. Building Effective Enterprise Java deployments is even harder. I have seen this on a daily basis in two roles. Firstly, when consulting on enterprise projects, you see the real world issues that developers are facing. Developing for the enterprise is a very different beast when compared to build smaller, standalone applications. You just have to consider issues that you can safely ignore in the other world. As soon as you have to share data between multiple users you start down the enterprise path. What is the best solution for allowing concurrency to this data? How coherent and correct does it have to be? How can we scale up from 2, to 50, to 1000 clients? These are all significant questions, and I don

Closures are so great. And anonymous inner classes are NOT “Good Enough”.

However, some people don’t grok closures and think that they are “just function pointers / method objects / …”

Martin Fowler has written a nice simple piece which gets across the major points:

So the first crucial point about closures is that they are a block of code plus the bindings to the environment they came from. This is the formal thing that sets closures apart from function pointers, anonymous inner classes and similar techniques.

The second difference is less of a defined formal difference, but is just as important, if not more so in practice. Languages that support closures allow you to define them with very little syntax. While this might not seem an important point, I believe it’s crucial – it’s the key to make it natural to use them frequently. Look at Lisp, Smalltalk, or Ruby code and you’ll see closures all over the place – much more frequently used than the similar structures in other languages. The ability to bind to local variables is part of that, but I think the biggest reason is that the notation to use them is simple and clear.

I would be a very happy man if closures came into Java as a first class citizen, like other languages :)

When you flip through Dr. Dobbs you may run across the green Google Labs Aptitude Test.

I wonder if the like of Cedric, Adam Bosworth, Josh Block, and Neal Gafter applied in this way? :)

Some of the questions are hilarious:

• Solve this cryptic equation: WWWDOT – GOOGLE = DOTCOM
• Write a haiku describing possible methods for predicting search traffic smoothly

• 1
  11
  21
  1211
  111221
  

  What is the next line?

• What’s broken with Unix? How would you fix it?
• This space left intentionally blank. Please fill it with something that improves upon emptiness
• On an infinite, two-dimensional, rectangular lattic of 1-ohm resistors, what is the resistance between two nodes that are a knight’s move away?
• In your opinion, what is the most beautiful math equation ever derived?

A fun place to work?

We definitely don’t seem to talk too much about build systems, which is something that all software developers have to deal with.

I am working on a project at the moment that really needs a nice modular design. The goal is to have a central driver build file, which passes on sub builds to submissions which match a given interface.

In the Java world, we could have a nice interface, submissions would just implement that interface, and a Factory would be able to instantiate them and delegate over.

However, if you are working with something like Ant how can you get this done?

With Ant 1.6 we have more tools available:

• Using “subant”:
  

  <target name="build">
  <subant target="build">
  <fileset dir=".">
  <file name="${subA}/build.xml"/>
  <file name="${subB}/build.xml"/>
  ...
  </fileset>
  </subant>
  </target>
  

• Macro’s:
  

  <macrodef name="deploy">
  <attribute name="descriptor"/>
  <attribute name="destfile"/>
  <attribute name="infiles"/>
  <sequential>
  <jar destfile="@{destfile}"
  webxml="@{descriptor}">
  <lib refid="support-libraries"/>
  <lib file="${jar.name}"/>
  <fileset dir="@{infiles}"/>
  </jar>
  </sequential>
  </macrodef>
  

• Import: The new import task allows us to seperate out our build.xml files nicely (nicer than using XML entities!)

Groovy

Everything seems like a hack though. Maybe it would be nicer to use Groovy+Ant:

ant = new AntBuilder()

// lets just call one task
ant.echo("hello")

// here"s an example of a block of Ant inside GroovyMarkup
ant.sequential {
echo("inside sequential")
myDir = "target/AntTest/"
mkdir(dir:myDir)
copy(todir:myDir) {
fileset(dir:"src/test") {
include(name:"**/*.groovy")
}
}
echo("done")
}

If we use Groovy, then we can create a nice object model, with interfaces, and abstract methods which “do the default thing”. Then a new module would just extend the base and override anything that it needs.

Have you run into any nice clean solutions with Ant itself? Or something else?

Apache has had to come out with a Position Regarding Sender ID:

I have explained to Microsoft that their license is expressly
incompatible with the warranty of provenance in the Academic Free
License and the Open Software License:

“Licensor warrants that the copyright in and to the Original Work
and the patent rights granted herein by Licensor are owned by the
Licensor or are sublicensed to You under the terms of this License
with the permission of the contributor(s) of those copyrights and
patent rights.” (AFL/OSL S7)

These licenses are mine-fields. The layers must love it ;)