Requirements

I usually ask candidates for Software Engineer positions the following questions about their project work:

How do you know when you are done?
How do you know when you have succeeded?

Server as a Text Pump

So a server gets requests from the network and these come as text. A server gives a response and these are formulated as text. The text is formatted to give it a structure. And, if you use the right formats you get to call your server an XML-RPC server, or a SOAP server, or flavor of the week. Isn't all this just the Unix Philosophy taken to the web and hammered on with an XML hammer?

And, this is the point where I start wondering why the heck so many freakin'' book get written about this. SOA should be the easiest thing in the world. Unix programs have been parsing and spewing forth text for ever why does it suddenly become so much more difficult once you put objects into the mix?

It's the frameworks. Many of these XML frameworks don't make life simpler, they make it more complex. If you're trying to do SOAP or any XML-RPC work in a Java Application Server I encourage you to look at JBoss' EJB3 product. It looks to me like EJB3 in general will save a lot of grief for SOAP-y programmers and the JBossWS API is the first implementation of this that I've found usable.

When I tried some of the WebService tricks on the Sun Application server that comes with NetBeans I sprained a nerve cluster. When I tried the same on Glassfish I lost a lobe. With JBossWS I was so shocked at how easily my EJB3 service went together I couldn't believe it. I've made EJB3 + JBossWS my default development stack for Web Services.

No job shortage here?

We've been interviewing candidates for an open Software Engineering position for the last year. It averages about one interview a month and so far we can't find qualified candidates. Some of the more frustrating candidates interview well but when you get to technical questions you can't get the feeling that they themselves are comfortable with the technical subject matter. At least once someone passed technical, got hired, and had to be "let go" because it soon became apparent that they had "studied" for the interview but had no practical experience... And had lied on their resume.

I'm really puzzled by the fresh faced BSCS who has never taken data structures. I asked him which university he attended and I have to say that if this is the quality of education at that name-brand university I'll take my employer's business elsewhere. I would expect that BSCS students would either learn theory or learn practical skills to an appreciable degree.

Where are all the qualified candidates that were complaining about jobs going to India? Could you tell me where they are? I can't find them.

Bit Plumber

It seems that most of my life is spent either waiting for, calling new, or building data transfers. I spend my Monday morning reviewing logs from the previous weekend's data transfers, I start a refresh of my development environment's database, and I work through last week's progress on the web services I created. This weeks project is to design a custom export of data from one database to an XML format and back into a different database. So much of this is repetitive and so much of it is the same from week to week I have to wonder if there isn't a group of tools to automate these tasks.

Let me introduce you to the wonderful world of ETL tools. These are tools that Extract, Transform, and Load data. In short they have the potential to replace an entire stack of SOA tools that currently are written painstakingly entity by entity by your talented Web Service programmers. They do all their by work by pragmatically by-passing the entire ORM process (that then demands you to Serialize the Objects to get XML) and skip directly to the XML.

I expect to see more applications built around these ideas as SOA catches on more. Why can't an ETL be used to generate Ajax messages or SOAP calls? After all aren't many SOAP calls and Ajax calls just loading up data from a database and transforming it into the right message format?

Velocity versus JSP

I've spent the last few weeks in a new larval stage again. This time I've the been studying the alphabet soup that surrounds web portlets and the JSR168 spec. I'm not talking about learning to make portlets... that's easy... I'm talking about the best way to make portlets.

The fastest way to get working with portlets is to start by creating JSP pages and balling them up into portlets. You end up with function fast. But, if you plan on doing that, why not just go with a PHP based site? About all that JSP will get you in this case would be some props at cocktail parties where you can get an easy 'wow' by tossing around the word Java a few times.

We want MVC and we want to enforce it. So I've decided on velocity for page design. With velocity I can give page designers the ability to work with active page content and remove the possibility that some slack-jaw might muck up my code-base by slapping in some ill concieved SQL. It also means that view policy is utterly divorced from controller mechanisms.

Programs that write programs

A new generation of software has begun to emerge. These are tools that take UML diagrams and transform them into code. Humans have been creating software now for nearly a generation. This wisdom has begun to distill itself into "Design Patterns" and into a higher order of meta-thinking about systems design.

The idea behind UML to Code tools is simple enough and the progression follows a path something like this:

In the bad old days you had to toggle in programs one bit at a time. Then there were switch boards allowing bytes at a time to be toggled in. Programming involved all sorts of unrelated skills such as knowing how to toggle in code from 3x5 cards. There were no languages beyond binary.

Later the binary got covered over in a veneer of language that could be assembled into binary. Life was better. When higher order languages were introduced that could translate formulas into assembler and then binary there was some resistance. Surely, there was no way that these compilers could produce binary that was as good as the binary created by a talented human programmer? In time this argument was forgotten and the age of Programming Languages dawned on the planet.

After thrashing around for a while on how to best represent programmer thought in programmer language some defacto paradigms started to evolve as the ways that various classifications of human minds work began to be understood. In time we began to see common problem solving patterns. These patterns eventually began to see formalized expression in an implementation independent way.

Just as assembler was more expressive than binary, the programming language more expressive than assembler, wouldn't this meta formalization be even more expressive? And, shouldn't it be possible, once they were formalized, to transform these diagrams into programming language representations that would find their way all the way down to binary?

This is the early dawning of that next phase of software developments evolution. We have had some faltering starts at it. Several commercial products have tried to add a "visual" component to their development tools but these miss the power of the meta-language called UML. Just as it took time for the first compilers to get "good enough" to over come the argument that no "code generator" could do as well as a human programmer, these tools face that problem too.

In time they hold great promise of freeing the programmer from unnecessary minutiae allowing them to build bigger bolder castles in the air.

Things you never want to hear...

... your doctor say:

What the heck is that?

I didn't even know that was possible.

oops.

Oh well.

I'm thinking Arby's!