Mar 31

Perl Deja Vu with new Groovy Syntax

Groovy, Tech 4 Comments »

One of the nice things about playing with Groovy is that I get some deja vu now and then, back to my Perl and Python days.

For instance, Jeremy Rayner showed us that a Classic Groovy trick is here in JSR Groovy:

Rather than the boring, repetitive:

Point p = new Point(2,5)

you can now do

Point p = [2,5]

This is because groovy will try to do a coercion of a List into the right type needed for the assignment.

It uses the list to choose the appropriate constructor, then invokes it for you. neat.

This then has the effect in most places, such as setters (e.g. for a property of type Point)

foo.point = [2,5]

and in named parameters

bar.setPointLimits(upper:[7,9], lower:[2,4])

And the really interesting stuff (to me) is that the empty list is coerced into the default constructor.

Date today = []
println "the time at the moment is $today"

is equivalent to

Date today = new Date()

I am not sure how much of a fan I am of taking the list syntax ([ ]) and making it have sideeffects, especially [] == empty constructor, but it does remind me of a pattern that was used a lot in the Perl days.

We used to fake named params by passing in Hashes, or references to Hashes a la:

do_foo(a => “hi”, b => 32)

So, I would love to see some syntax to enable me to pass named params in a simple syntax.

Something like:

Point p = [x:1, y:2]

foo.point = [x:1, y:2]

Of if you don’t want to hijack the syntax, you can do with a suggestion from John Rose:

Date d = (77, Calendar.JUNE, 28)

or:

Date d = (year:77, month:Calendar.JUNE, day:28)

Basically we are getting rid of the implicit new Foo(), and making an assumption from the type that we set. This is funny, as we have been getting rid of the implicit type all along (and potentially even in C# 3.0 [and therefore Java 7? :)]):

d = new Date(77, Calendar.JUNE, 28)

There are different cases. One for when you are passing in new objects to methods, and the other when you are creating a new object. Also there are the sideeffects of “I want to tell you this type”. Worth exploring… not sure how I feel about it all yet!

Mar 31

IoC: One of those things you need to try, to get it

Lightweight Containers, Tech 7 Comments »

Everyone is chiming in on Cedric’s post claiming that he doesn’t get IoC.

I sometimes feel that the IoC crowd expects to explain IoC and have people say *a ha!*, and suddenly stand back with halo’s as they see the amazing benefits.

In reality, I always find IoC to be one of those ideas which seems simple, almost TOO simple, and hard to REALLY get.

The only way to get it in my opinion is to live it.

There are a lot of technologies like this. You can’t really understand what it does to YOU the programmer, until you do some work with it. E.g., using a real ORM, playing with Ruby/Lisp/Haskell, etc etc.

IoC, to me, gives me a way to help me write clean code. Nice units to test easily, forcing me to design to interfaces (which I tried to do before hand anyway, and which Cedric does (which is another reason why it doesn’t seem like a big deal sometimes).

I never want to see a lookup("foo"). As soon as I do I get the jibblies. What if foo isn’t there? What exceptions do I need to handle with foo?

So, for me, IoC is both a big deal, and a small deal. I don’t really think about it anymore. It is just part of the system, part of the pattern of writing code. It is used to help test, be agile, and all the cliches.

But, you won’t ‘get it’ until you just do some serious work using it… and then you won’t even think “oh I get it”, you will just be doing it.

Mar 31

Del.icio.usly De.lirio.us

Tech 5 Comments »

There has been a lot of hubub around the new social bookmarking kid on the block: de.lirio.us.

As Jon Udell has said the responses have been either:

Good! del.icio.us is closed-source, the world needs an open-source social bookmarking service.

Bad! Geez, what a lame ripoff!

I actually thought both of these at the same time. I didn’t see any features which would make me take the time to move all of my bookmarks over (and if de.lirio.us wants to get serious then it should create an import mechanism from del.icio.us).

de.lirio.us has a chance to make it IF:

  • Del.icio.us stagnates
  • Del.icio.us starts getting weird due to the investment that Joshua Schachter has taken. However, the investment could really help del.icio.us grow now it has full time backing
  • Since de.lirio.us is open source, if they build a community which adds a lot of features that people are crying out for (e.g. private bookmarks)

In some ways (in famous SAT format):

de.lirio.us is to del.icio.us

as:

Nutch is to Google

I still use Google rather than Nutch (right now), but it is nice to know that Nutch is around in case Google starts to change to “Be Evil” ;)

Mar 30

John Carmack finds Mobile Java

Java, Mobile, Tech 2 Comments »

John Carmack, the creator of Doom to Quake to Doom 3, and plenty others… has found the pleasure that is Mobile Java. It is really quite interesting to listen in to such a low level guy, as he learns the issues that are inherent in the Java platform.

He starts off quite positively:

I wrote a couple java programs several years ago, and I was left with a generally favorable impression of the language. I dug out my old

Mar 30

Sun to opensource Java Enterprise System

Java, Tech No Comments »

So, it seems like Sun is starting to go the whole hog wrt OpenSource. The latest is that we hear Sun Plans To Make Java Enterprise System Open-Source.

Although their product hasn’t made a large push in the industry, the JES is certainly a full stack, including real world functionality like LDAP (as Rickard mentions).

I think it is cool that Sun is putting this all out there (and they need too), but I do wonder where they will make any money. I don’t think the future is SPARC.

Mar 30

Pragmatic Studio

Tech No Comments »

I am trying to plan to be in Denver for the new Pragmatic Studio event, which is in Seatle and Reston also.

Dave Thomas and Mike Clark are some of my favourite speakers, and I am lucky that I get to sneak in to their talks on the No Fluff Just Stuff tour.

I always learn a lot from them, even if I think I know a lot about the particular topic.

So, if you are looking for a fun couple of days, check out the new studio event. I will see you there!

Mar 30

Code Reading

Tech 11 Comments »

Code Reading

I got turned onto the book Code Reading based on the foreward by Dave Thomas.

He is spot on to the fact that we learn traditional Computer Science in a weird way.

In the classes that I had at uni, we were always asked too:

Write a program which uses Bubble Sort to do X…. Then compare with a Quick Sort version.

Each time, we got to start from scratch and write code for the task.

I don’t know if things have changed recently (I am sure it is different in some good schools), but we never had to do the task that you end up doing most of the time:

Maintenance: Starting from the given application, fix 5 of the 10 bugs located in this JIRA instance. Then, add the following 2 features into the application.

Now THAT would be more realistic and useful. Part of this process requires that we are good at reading code. However, as the book states, we never get taught HOW to read peoples code.

With the advent of opensource, we now even have the luxury of being able to look at good and bad code. It is all out there. Rather than having someone come talk at a Java User Group, wouldn’t it be nice to have a group get together to analyze some code? Each time someone could be the CM (Code Master) and have looked through for choice design decisions.

This all comes down to my entry: Read The Source, Luke

Mar 30

Duo Pizza Teams

Tech 1 Comment »

I was just reminded by a new friend about Jeff Bezos, and his quote regarding software teams:

“If your team needs more than two pizzas to feed, it is too big”

I have recently worked on some projects which contained small lean, mean teams, and it has been a pleasure.

I had one particular day pairing with a collegue which was of the most productive ones in a long time. It just clicked!

Mar 30

Don’t quite get Yahoo! 360

Tech 3 Comments »

I was invited to Yahoo! 360, so went over and setup an account.

It is interesting to see the merging of features, but I don’t really get how I would actually use it.

I am not going to use their blog now. I am not going to go through the pain of inviting everyone to the social network yet.

I do think that in the future it may be more compelling. There is a chance for them to merge this with My Yahoo! It would be tempting if I had ONE place to go too:

  • View news / rss feeds
  • Create new blogs (which get put up here automatically)
  • Comment on any forum/blog
  • Merge social networking with other services like LinkedIn
  • One stop shop to view email, address book, etc

They could do it. This version isn’t quite there for me though…

Mar 29

Spring, EJB 3, and the future

Lightweight Containers 54 Comments »

I am often asked whether Spring will be a flash in the pan, and everyone will move to EJB 3. There are definitely a set of customers who want to do the standards thing… and I have already talked about a path for those folks.

Then I saw the following from Juergen, via Keith Donald, which shows the point of view of the Spring guys:

Spring and EJB3

On the surface it may seem that EJB 3.0 (in particular session beans) covers the same area as Spring’s Lightweight Container. However, when you look closer, you’ll notice some important differences with regards to the two, both in terms of focus and capabilities.

Dependency Injection

EJB3 provides dependency injection for JNDI objects. All referenced objects need to be managed by the application server in JNDI. This is only appropriate for coarse-grained facades, as there is no value in letting the application server manage every single internal object of your application. Essentially, EJB3’s dependency injection capabilities are targeted at making JNDI lookups more convenient, but do not go beyond that.

In contrast to the above, Spring is designed for managing fine-grained application objects in a local fashion, without making the application server aware of each and every object. You can link in objects from JNDI if you need to, but most of your application objects are not (nor should be) managed by the server. Furthermore, Spring supports prototypes, constructor injection, factory methods, simple property values, value placeholders (variable configuration properties sourceable from external locations), control over bean lifecycle (lazy-init, disposal, pooling), and bean autowiring.

The most important difference is that Spring can seamlessly manage application objects in any environment, while EJB3 just allows you to run them in an EJB container. In a test environment or standalone environment, the best you can do with EJB3 is instantiate the session beans yourself. With Spring, you’ll just select a different context implementation, typically sourced from the same XML bean definitions. This means you can reuse configuration metadata across environments with minimal hassel.

Other Capabilities

Beyond those basic IoC capabilities, Spring offers full support for proxy-based AOP with prebuilt and custom interceptors, while EJB3 offers its fixed set of interceptors (transaction, security). Furthermore, Spring’s declarative transactions are backed by various transaction strategies (DataSource/JDBC, Hibernate, JTA, JOTM), working outside of J2EE too. There’s also support for a wide variety of data access strategies (JDO, OJB, JDBC, all using a consistent programming model, while EJB3 just integrates a single strategy). If you haven’t guessed by now, Spring’s mantra is, “it’s all about choice”.

We’ve not even touched Spring’s web support yet, which range from basic web application context support to its own web MVC and web flow framework and prebuilt Struts/JSF integrations, all able to seamlessly reference middle tier beans. There’s also support for lightweight remoting with various strategies (Hessian, HTTP Invoker, Burlap, JAX-RPC, JMX) using a common service export facility, rather than the (unknown?) set of protocols that a particular EJB server implementation may offer.

Spring in an EJB3 Scenario

In many respects, Spring and EJB 3.0 complement each other more than they compete. Like it currently does for EJB 2.x, Spring will be able to link in EJB3 session beans seamlessly (local or remote), and will provide internal contexts for EJB3 session and message-driven bean implementations (holding a Spring bean factory within an EJB).

In such an EJB3 scenario, Spring manages the application objects in the web tier (no matter which web MVC framework is being used), accessing coarse-grainded EJB facades when necessary, and potentially also finer-grained objects behind those facades (for example, business logic strategies and DAOs, using JDBC, JDO, Hibernate, etc). Spring still acts as the glue for the entire application, just now with EJB3 session beans thrown into the mix.

Beyond EJB3 session beans, Spring will also support the new persistence API defined by JSR-220 (formerly known as EJB3 entity beans), as a further O/R mapping strategy, in addition to the current support for Hibernate, JDO, OJB, and iBATIS SQL Maps. Note: this will be completely
independent from the rest of EJB3–you could easily manage your entire middle tier with Spring, using a JSR-220 persistence implementation in standalone.

EJB3 in a Spring Scenario

I hope the above answers why it still adds value to use Spring in an EJB3 scenario. Of course, we can also turn the question around: What value is added by EJB3 session beans to a Spring scenario? (JSR-220 persistence is a different matter: It’s an alternative to Hibernate and JDO, not to Spring.)

In principle, Spring covers all capabilities of EJB3 session beans today, offering more flexible and more sophisticated management and deployment options. The main benefit with modelling components as EJBs is that you’re able to export remote services through your J2EE server (to support load balancing and failover).

For purely local needs, there appears no compelling reason to choose EJB3 session beans over Spring-managed POJOs, except for one specific
scenario: You might want to deploy some of your components in a separate class loader within an EAR, making them accessible to multiple web applications. In such a case, using local EJBs as facades makes sense, possibly with fine-grained networks of Spring-managed application objects behind them.

Juergen Hoeller, co-lead, The Spring Framework