techno.blog("Dion")

The Middleware Company and DevelopMentor have combined forces :)

I think this is a great partnership. Some partnerships that you go into don’t have the “synergy” that business folk love to talk about.

Now, TMC will have DM taking on their training (and they are excellent at that), and our communities will really benefit from the involvement of the DM employees.

Welcome DM folk! (We already had Ted on a trail basis ;) )

TSS Announcement: DevelopMentor and TMC announce Community and Education Alliance

Press Release

Collaboration of Training and Online Communities Provides Expanded Services and Content for Middleware Industry

MOUNTAIN VIEW, Calif. and TORRANCE, Calif., April 20 /PRNewswire/ –
The Middleware Company, the world’s leading knowledge network for middleware
professionals, and DevelopMentor, the leader in hands-on training for
experienced developers, today announced a community and training alliance. As
a result, The Middleware Company and DevelopMentor will combine community and
training assets to significantly boost each company’s core services while
delivering enhanced online content and technology training to the middleware
industry.
“This alliance is aimed at expanding market share for both companies and
positioning for joint growth,” said Salil Deshpande, CEO at The Middleware
Company. “Both companies benefit from increased visibility as DevelopMentor
gains The Middleware Company’s best-of-breed training assets, as well as
unprecedented, regular exposure to nearly half a million new developers and
architects via the TheServerSide Communities. The Middleware Company gains a
significant boost in membership and additional middleware content on
TheServerSide Communities, contributed by DevelopMentor. Ultimately the
entire middleware industry benefits from better training and services as a
result of our collaboration.”
The two companies, formerly competitors, will now collaborate on joint
marketing, sales, lead generation and membership activities. As part of the
alliance, The Middleware Company will exclusively host, manage and promote
DevelopMentor’s online community elements including the DevelopMentor
Resources area technical content and discuss.develop.com on TheServerSide
Communities. DevelopMentor will acquire and integrate The Middleware
Company’s training business including EJB for Architects, EJB Essentials, J2EE
Design Patterns and J2EE Essentials into its offerings. In addition,
DevelopMentor and TheServerSide Communities will collaborate to produce online
course services including course-specific discussion forums and resource areas
as well as new and unique technical content such as books, whitepapers and
sample applications.
“TheServerSide Communities will now become our community front end,
further extending DevelopMentor’s reach within the developer community. The
added functionality resulting from the migration of our community assets to
TheServerSide will benefit developers who learn from our instructors as well
as those that rely on online resources,” said Mike Abercrombie, president and
CEO at DevelopMentor. “Teaming with The Middleware Company will reinforce our
position as the premier advanced developer training firm with the most
comprehensive curriculum spanning J2EE and .NET.”

Many of us have read books which talk about maintenance effort versus the initial build effort right? For those who haven’t, the synopsis is: maintenence time = 10 or 100 times the initial development time.

Are we taking this fact into a lot of consideration?

To explain what I mean, let’s walk through a couple of scenarios:

Versicorp

Versicorp has a development team that is bleeding edge. They are on top of the blogging world and grok AOP, IoC, and Groovy. They are even enlightened enough to send their entire team to TheServerSide Symposium :).

Three plus years ago they were writing a product, and were asking themselves:

- How should we handle persistence?
- What about the presentation tier?

amoung many other questions.

At this time they concluded:

• Persistence: I don’t want to hand code JDBC! We need to use EJB and Entity Beans. That is where everyone is going, and it allows me to encapsulate my data model. A few people argued for TOPLink, but they lost out
• Presentation: I don’t want to hard code “out.println(…)” in Servlets. Let’s use JSP, and build our own controller mechanism to create a nice MVC system

They build the product and it was successful.

A year later they were onto another product and asked the same questions.

This time different conclusions were had:

• Persistence: Oh man, I can’t believe we used Entity Beans. Look at how everyone is trashing them… let’s never mention the fact that we used them in the past! Now we need to move on to transparent persistence, and JDO!
• Presentation: Our own MVC framework is OK, but it isn’t as feature rich as the other solutions out there. We really need to just go with the de facto standard Struts

They build the product and it was successful.

Another year later they get onto another product, same question.

• Persistence: JDO was nice, but we should really try Hibernate
• Presentation: Struts it too bloated. They are fighting over JavaServer Faces, Tapestry, or WebWork 2. They also want to tie in with Spring for the business services

I am sure this product will be successful too.

If we take a look at what this company now has. They have 3 products on TOTALLY DIFFERENT systems. They have kept up with technology, but have to understand many products to be able to maintain their successful products. They have a couple of choices now:

1. Migrate to latest and greatest: Do they take the first two products and rewrite them to use their latest frameworks?
2. Keep the knowledge: Keep training their support staff to understand the legacy systems?

There are sacrifices either way, and at what point does it make sense to spend time and resources on migrating old products, when they could be used on new products? Maybe the old product is ready for a new version anyway, so it can be folded in?

Protege

Protege has a development team that is equally skilled as Versicorp. They are very customer focused, and don’t all keep up on the tech to the same extent as Versicorp does… but they don’t keep their heads in the sand.

They have also written three products, yet they had different answers to the technology questions:

Product A:

• Persistence: They created their own JDBC wrapper, using a combination of the DAO and Command patterns
• Presentation: They also created their own MVC framework

Product B:

• Persistence: They continued to use their own JDBC wrapper (and tweaked it where needed)
• Presentation: They continued to use their own simple MVC framework

Product C:

• Persistence: They continued to use their own JDBC wrapper (and tweaked it where needed)
• Presentation: They continued to use their own simple MVC framework

As you can see, Protege decided to stick to their guns. Their JDBC wrapper is very simple, and they could bring anyone out of college and put them to work immediately (as long as they know SQL). They ended up spending minimal time on the frameworks themselves, and instead put in the time on the business problem at hand. It may not be sexy to be working in this manner, but can you really argue that it is wrong?

Does IoC and Transparency help us migrate now?

One trend in the industry that definitely will help us move up the stack as we build more projects is the wave of lightweight containers and transparent persistence.

The hope here is that our object model can be written in a “pure” way, and that we can then tack on persistence, and tie components together via dependency injection. I do feel that this should enable us to move up the food chain a little easier as things change around us, but it is still a little work.

Some people will want to work at Protege, and others will want to work at Versicorp, but I definitely think that there are arguments for both approaches.

What do you think?

Amazon has launched A9 a new search engine which seems to add functionality on top of Google. It has a bunch of personalization features such as showing you your history, giving you easy access to Alexa site info, click history, URL short cuts, adjustable columns, and they have the usual browser toolbar plugin.

Of course, you can search within the book ™ too :)

Interesting.

Larry Wall has come out with Apocalypse 12 which details how you will define and use OO in Perl 6.

This is great to see, especially after also being up on the discussions for Groovy on how to handle certain things (e.g. properties).

What does a Perl 6 simple class / use look like now?

class Point {
has $.x;
has $.y is rw;

method clear () { $.x = 0; $.y = 0; }
}

my $point = Point.new(x => 2, y => 3);

$a = $point.y; # okay
$point.y = 42; # okay

$b = $point.x; # okay
$point.x = -1; # illegal, default is read-only

$point.clear; # reset to 0,0

Thank god for the keywords of class (and method). Finally it doesn’t feel like OO is bolted on (even though Larry thinks it was bolted through).

It is interesting that there is no constructor, yet “my $point = Point.new(x => 2, y => 3);” still does the right thing.

And moving from “->” to “.” is nice too.

You may wonder what the “$.x” is all about. This is an interesting use… if you said “$:x” that would make it private! Sneaky huh. You can make private classes via “class :MyPrivateClass {…}”, and private methods via “method :think (Brain $self: $thought)”

Another interesting thing is the part of “roles”.

E.g.

class Dog {
is Mammal;
does Pet;
does Servant;
does Best::Friend[Man];
does Drool;
…
}

I also enjoyed seeing this Groovy/Ruby/…-ish looking code:

@thumbs.each { .twiddle }

Whatever you think of this document, anyone can see that a LOT of thought has been put into this (as is always the case with Larry), and there are many things in which we can learn from (are you reading this Groovy guys?).

Great stuff. Hopefully we will see Perl 6 in the next 5 years ;)

I spent part of the week with a company in the Video on Demand space, putting together a case study of their J2EE application. It is interesting in many ways, one of them being that has a large deployment, and they use JBoss as the application server.

What was particularly interesting was to yet again get a view of how business folks see J2EE. They wanted to see “standard” J2EE in the application. They weren’t looking for the latest and greatest (e.g. Tapestry/Spring/Hibernate layers).

Their thoughts:

“This technology is going to have to be around for a long time. J2EE will be here (and people skilled enough to code in it) 10 years from now. Will there be people who understand Spring?”

It makes you think. Does the industry standard have a large leg up in this regard, or is everything “legacy” as soon as it is out of the door anyway?

I was reading TeXML: an XML vocabulary for TeX and I had a flashback to Cameron’s blogs from last month:

Byte Code as XML

Byte code as XML got too big

XML Processing got too expensive

I don’t know about you, but I think:

<cmd name=”documentclass”>
<opt>12pt</opt>
<parm>letter</parm>
</cmd>

looks a lot more verbose than the “raw” TeX:

\documentclass[12pt]{letter}

Maybe it is just me.

I enjoyed the article Implementing the Null Object Pattern using AOP, by Dale Asberry.

It is another example of how you can take something that is “annoying” in your development, and having an elegant solution with AOP.

NullPointerException’s are such a pain. Whenever you get a NPE in your app as a developer you sit back and *sigh*. “Time for the debugger”, and you know that it could be awhile.

With a simple aspect, and the right pointcuts, we get real information about the ugly NPEs.

Jakob Nielsen, the User Interface guru, has a funny entry in his Alertbox.

Bystanders rated mobile-phone conversations as dramatically more noticeable, intrusive, and annoying than conversations conducted face-to-face. While volume was an issue, hearing only half a discussion also seemed to up the irritation factor.

It is interesting to see that the study in question is from the UK. Whenever I am back home in London it drives me a bit nuts to see all of the phones and the damn polyphonic rings. When my 7 yr old cousin has a mobile….. what the hell is going on! :)

To read about the study, and “Can We Make Mobile Phones Less Annoying?”, checkout Why Mobile Phones are Annoying.

One of the great things about groovy is that you can sneak it into your development :)

So, go on, go to a project and tweak the build.xml to add groovyc into your compile step.

1. Add the ant task definition

<taskdef name=”groovyc” classname=”org.codehaus.groovy.ant.Groovyc” classpathref=”project.class.path” />

2. Go to one of your compile tasks and add a groovyc to do its thing (as well as the javac)

<target name=”compile-tests” depends=”prepare”>
<javac srcdir=”${src.tests.dir}”
destdir=”${build.tests.dir}”
debug=”off”
deprecation=”off”
optimize=”on”
includeAntRuntime=”no”>
<classpath refid=”project.common.class.path”/>
</javac>

<groovyc srcdir=”${src.tests.dir}” destdir=”${build.tests.dir}”>
<classpath refid=”project.common.class.path”/>
</groovyc>
</target>

3. Repeat for any compile tasks that you want to make groovy

4. Now, if you fancy, make a Foo.groovy instead of a Foo.java and away you go!

As I mentioned a little already, I think Sun should take a leaf out of Microsoft’s book in one way.

Microsoft had a summit this week for their MVPs. They bring together the top minds in the Microsoft community and facilitate:

• Communication: Between Microsoft engineers and the MVPs, and between MVPs
• Learn: There is a chance for Microsoft to show off the “future” of their technology

You end up with a ton of blog entries from excited MVPs, a feedback loop to the Microsoft engineers, and a lot more. It is a great idea.

This year they showed a video that had Steve Balmer as Neo, and Bill Gates as Morpheus that was meant to be hysterical. Unfortunately they aren’t going to put it up on the web :(

Sun should do the same thing. Get the people that matter (your prophets) together for a few days and magic will happen. Then the prophets go back to the masses and share the vision.

Come on Sun. Think big!