Java Industry News
Things Can Only Get Better
Things Can Only Get Better
By: Alan Williamson
Feb. 1, 2001 12:00 AM
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!
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 server.
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!
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.
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.
Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week