As I write, it's the day after Boxing Day. I was supposed to have this written yesterday, but to tell the truth I just couldn't find my muse...so today will have to do. As I wake up this morning I see in horror the latest on a madman who let loose with a firearm on his work colleagues. Sadly, nothing terribly new in that fact for a nation that's so proud of its right to bear arms. However, this particular instance had it occurring within an Internet consultancy company. This industry is no longer as safe as the career officer once promised.
Over this festive period we've been fed the usual nonsense on television. This year, however, I've been avidly glued to a documentary series chronicling the American West and how it was "won," and I use the word won in the loosest sense. In our schools we aren't taught that much American history; we stick to castles with kings and queens lopping each other's heads off. This series has whet my appetite enough to dig for more information. I have a lot of unanswered questions. So if anyone knows any URLs of reliable historical reference, please e-mail them to me.
Enough talking about the past and more about the future. This column, after all, is Industry Watch, as opposed to Industry Watch of Yore!
I've never been a great fan of JSP (JavaServer
Pages) and what have you. But everywhere I look it seems that all
the major application server vendors are throwing a serious amount
of development and marketing behind this (and I will probably upset
some JSP purists here) god-awful technology. I just can't see the
allure of a technology that gives so much power to those that should
never be entrusted with a calculator, let alone a "Webplication."
Sure, the concept seems interesting enough, providing the ability to
embed Java code within an HTML page. Sounds great on paper. However,
ask anyone who's had to support someone else's JSP abortion, and you
get a different perspective on the whole JSP debate. It's a support
Now it would be wrong of me to dismiss JSP completely without giving it a proper hearing. The custom tag API in which it was introduced is indeed a great piece of technology and one that should
be exploited a lot more. While I'm interested in seeing where this one is heading, I'm not at all convinced it should be anywhere near JSP. Doesn't fit as far as I'm concerned. A custom tag library is probably closer to that of the servlet API as opposed to the JSP interface. The purists will argue that a JSP page is just a servlet.
Technically, I can't argue with them on that score. However, JSP is yet another layer slowing down the page-rendering process, where a layer need not exist.
The reason I say custom tags are closer to the servlet API is simple: the servlet API has had this facility from day one, with the Server-Side-Includes (SSI) facility. So why reinvent the wheel?
With SSI we had the ability to completely hide our inner workings from those who might meddle. We simply presented them with a simple interface. An interface they were used to using. An interface
that wasn't foreign to them. A - dare I say it? - tag!
JSP, I believe, blurs the border between presentation and business logic a little too much. It allows those who know nothing about the business logic to fiddle, and those who haven't an artistic
bone in their bodies to meddle. A very ugly scene can ensue. I find it wonderful that Java is so accepted now. It's refreshing to arrive on a client's site and find their server already Java enabled. Sadly, this wasn't the case four years ago. Not only did you have to install your own software when you arrived, but also that of the JVM, the servlet engine, and sometimes even the Web
Early on at n-ary we set about developing our own HTML tag templating system. We quickly discovered how useless it was to write Java servlets for each client project. The Java servlet is indeed a
clumsy technology when all is said and done, and in the majority of cases developers are creating more work for themselves than they're supposedly solving.
To this end we designed a complete templating system that runs on top of the Java servlet API. Our tags were extensive and very versatile and, thanks to Java, ran on all servlet-enabled platforms.
Over the next three years our system, which we called tagservlet, was under constant development with testing in the field.
This time last year we were about to release it free to the world. However, as we looked around in this very busy marketplace, we pulled back and thought, The world doesn't need yet another HTML
template system thrust upon it.
What a difference a year can make.
We studied the alternatives closely and decided we would adapt our tag system to fit alongside that of another. The one that resembled our tag structure and that our clients would moan about was
CFML from Allaire. ColdFusion, they would say, "Great tag system, but slow as hell." We spent a month or so looking in depth at this system and decided to change our tagservlet to what is now known as tagFusion.
The tag switchover didn't take as long as we first envisioned, with the majority of time devoted to developing the expression library that CFML boasted. We launched our new and improved tagFusion to our clients in beta form in the summer of 2000.
It was received very well, outperforming the ColdFusion server in the area of six to 10 times for some pages. We went through a series of rigorous tests and ironed out the majority of the wrinkles.
We started shipping CFML solutions to our clients, creating the necessary custom tags that their particular requirement warranted. We were no longer a Java software company, but a solutions
company. It was a spooky changeover for us.
Would you believe we had to downsize our Java team? We had to made some of our Java team redundant simply because we didn't have the work to support them. We had created a tool that was so successful for our consultancy firm that it changed the focus of our entire business.
We then began hiring other skill sets to support the emerging market that tagFusion opened up for us. Not only are we now able to take on existing Java projects, but we can deliver them faster with a standard that our clients feel safe with without compromising the openness and deployment features of running under a J2EE environment.
One of the first pieces of advice given to me when I set out to build a company was not to be scared to change direction. I've seen many large corporations changing direction and moving into areas they're not customarily known for. Take HP, IBM, Sun, and even Microsoft as a few examples. But I had just never imagined n-ary being anything other than a pure Java company. But here we are,
starting 2001 as a new company that doesn't focus its energy entirely on Java.
We effectively coded ourselves out of a job. But I'm not sad. I'm excited at the opportunities our vision has brought and will continue to bring. We haven't completely left Java behind, though. We
have a supporting team for tagFusion, and I can still be found cursing and swearing at CodeWarrior!
Technology is quite wild in the parts of our lives it manages to reach. My son was born recently, and within four hours of that event, thanks to a digital camera and a Web site, I had all of our
family and friends witnessing the new addition to the clan, irrespective of their distance. It's now nearly a month since Cormac introduced himself to the world, and already I have more photographs of him than my parents have of me in my entire child life. Add to that the number of RealVideo clips I've made of him. I have to sit back and marvel at the ability to do all this. What really impresses me is how little it cost to produce this technical diary.
With WAP just beginning to make an appearance, I have to wonder what tools will be at Cormac's disposal when he goes to document the new life of his first child. Once we have that figured
out, we have to start coding for those tools. What ingenious ways can we find to pull as much functionality out of this hardware with just software? This is what excites me about this time we live in. We're young enough to remember what it was like in predigital days to appreciate the move to 1's and 0's.
To us the change is far more dramatic. My son will never know the wonders of a vinyl record or understand the complexity of the classic Space Invaders. I can't even imagine what the game of his day will be. I just hope I'm about to witness some of it and, more important, together with him, make some of it happen.
I do a lot of reading - mainly current affairs-type stuff. One of the chaps I follow is one Jesse Berst of ZDNet fame. Jesse, a bit like myself, isn't scared to court a little controversy once in a
while, and I admire anyone who does that sort of thing. Takes a lot of guts to throw one's body over the barbed wire. Jesse produces a daily e-mail editorial that's highly informative and sometimes quite entertaining. However, on one such occasion Jesse was twittering about wireless and what have you, and wrote a sentence I thought I had heard somewhere before. On my weekly back review of Wall Street Journals I found the phrase again. Printed two days before Jesse's article. Coincidence? I don't know. You decide.
But rest assured about reading this column: it may on occasion be drivel, but at least it's original drivel!
And on that note, see you in the March issue of JDJ.
Alan Williamson is CEO of the first pure Java company in the UK, n-ary (consultancy) ltd, a Java solutions company specializing in delivering real-world applications with real-world Java. Alan has authored two Java servlet books and contributed to the servlet API.