Java Hair

A lot of people ask us where the name Vgo Software comes from. (That’s pronounced Vee-Go Software in case you were wondering.)  Since I’m in Greece this week with a client and I haven’t posted anything in a while, I thought I would expound upon where our name came from.

Back in the day, we were just a consulting company. At that time I had come up with a prototype for what eventually became our Rev product. I remember writing an e-mail to my business partner about this prototype. While writing the e-mail I realized that I did not have a name for the project and started to think about what I would call it.

Earlier that day I had talked to a consultant that was working for us and who was a friend of mine. He told me that he had been experiencing bouts of dizziness earlier in the week and didn’t know what was causing it. After suffering for a couple of days without it getting any better he went to the doctor to see what the problem was. As it turned out, the doctor told him he either had a cancerous tumor in his ear or he had Vertigo.

Thinking about what to name the software, which was a code generator, I thought “Vertigo!” what a perfect name! It generates code so fast it will give you Vertigo. Well, I put that in the e-mail as the name of the prototype and the name stuck for a while but at some point before we actually released it somebody did a name search and determined that the name Vertigo was actually being used by another software company for another product.

About a week later we held our monthly staff meeting where we gather everyone from wherever they may be, talk about current company events, and have beer and pizza. We decided it would be a good time to come up with a new name (esp. after the beer part). After everyone throwing out various names for about an hour, we finally settled on a mutilated version of Vertigo, Vgo.

Well, Vgo eventually became our code generator, Rev, and the product built on top of that which was once referred to as Vgo4Oracle became Evo (anybody notice a pattern emerging?). Both products were part of the “Vgo Software Suite” of products and we eventually just started using the name of the software itself as the name of the company.

So, I get this all the time “Why should I convert my perfectly good Forms?”. The answer is you should if you have a good reason to. If you don’t, by all means stay there (until, of course, one day Oracle decides you will not have Forms at all anymore; around 1213 or so, and then you’ll need to do something). I see TON’s of blog’s about the topic. Mostly these entries are on Oracle-centric sites and are not, perhaps, as objective as they could be. So, here’s my opinion on the matter (as I find myself to be a relatively objective person).

Wait, before beginning, I need to pull out a blog-shaped soap box.

These efforts aren’t “conversions”. This isn’t a translation exercise. Meaning, if you think you can change from one computing architecture to a completely different one by pushing a button, you’re nuts. It’s just not realistic. From the outset of Vgo Software (and prior to that, NEOS) we used the word “evolution” or “modernize”. To reach a stage of evolution, you have to work at it to reach the full potential of the modernized state (whoa… I’m feeling a little Zen here).

Think about this, Oracle DBA’s out there: when you upgraded from v7 to v8 of the database, did you use consider the cool new features like partitions, a better cost-based optimizer (though, in my ex-DBA opinions, still not great then) or materialized views (I’m publishing my age here)? If you did, did you get all that stuff by upgrading? NO. You had to reconsider your applications using the DB and what impact that the changes would have on them. 

I shouldn’t mention that your manager wouldn’t give you time to implement any of the good stuff as I’m sure that wasn’t/isn’t common at all.

So, back to Forms and Java.  The people that should want to convert would be those folks who want to integrate applications in a standard way.  They want to move towards service orientation and can see integration across application silo’s.  These folks may want to move away from Oracle as an application solution and move toward open-source, allowing them to use a wide community of development resources.  Of course, Oracle has been making great strides as we can attest to. 

But why is Forms evolution hard?  It’s hard because there is alot to do to create a solid JEE app.  In a code translation (of which there are a large number), an engine maps each construct to a “Java equivalent” which may, or may not, be proprietary to the translator.  What you do in those cases is create at least 2 different source files (possibly 10 times more) for every Forms program unit, trigger, etc. creating a huge mess.  Maybe it works, most likely it will not, but then your stuck with 1 million source files and no way to maintain them.

We put in a lot of effort to try to allow people to clean up and consolidate code in forms applications (we’re the only one’s who do that, BTW) and even build customized classes from existing forms components.  Our last release allows you to do this across different forms applications, creating true enterprise-class applications and services.

There is also discussion about modernizing Forms apps by putting all of the PL/SQL in the form into the database (perhaps the re-surgence of mainframe computing is making it into the distributed database market).  This approach was taken by forward thinking companies in the mid-to-late ’90’s by taking core business rules out of their forms and wrapping them in CRUD procedures in Oracle to thin out the front end.  A good approach back in the client/server days.  In fact, I did that myself with a large annuities application.  But now you have application servers that run real Java; why would you want to isolate your business logic in a single database?  What about sharing that logic with other apps (yes, I know you can do that to some degree in Oracle)?  What about exposure as a web service from different platforms?  And how many PL/SQL programmers can be found to manage really large apps that stuff all of their logic in a database?  In my opinion, fattening the database isn’t a viable architectural solution in this day and age.  If you want to thin-out your front end, that’s great, just don’t dump all of it in the database. 

So, I’ve written this over a vast amount of time, being a poor blogger (Rob may suspend my blogging privileges after this release).  Maybe it’s insightful to you; therapeutic to me.

As you probably saw in Ernt’s earlier post, we exhibited at ODTUG Kaleidoscope this year. It was our first year at the show, but I don’t think it will be our last. To me the show was more valuable than Oracle Open World which we’ve exhibited at for the past 3 years. It may be that as a vendor, exhibiting at OOW is a necessity, but as a developer, exhibiting at the ODTUG show was much better.

What was most encouraging was being able to demo our products to a wide range of people who understood what we were talking about and what our products are trying to achieve. I believe that anyone who believes in code generation as a viable “enhancement’ to custom development should take a look at Rev and see what it can do. I was encouraged to speak to one person who said that he believed we are getting to the point where everything can be done by code generation. I certainly believe that any software project that persists data to a database can benefit from code generation.

Enough about Rev. We had the chance to demo Evo to a number of folks who had some great insight and advice. To me, that was what made the conference such a success. The ability to be able to network with such a great community of people who really want to see a product that can do things right was encouraging.

I had long wanted to speak with Wilfred van der Deijl about his solution to the ADF/Forms integration problem and get his impression on Forms to ADF conversions. At this conference I had the chance to do that. Even though I missed his presentation (the time had changed and I didn’t check the board), he was kind enough to stop by the booth and show it to us personally. It’s a great solution for a problem that we have been asked about many times. If you are into Forms or ADF developement, you should definitely check out his blog. It was nice to see from his blog that he believes we are on the right path.

Peter Ebell over at AMIS in the Netherlands stopped by. If you are into hardcore ADF development, checkout the AMIS blog where Peter is a contributor. Anyway, he stopped by to get a demo of our Forms conversions and hopefully will post his thoughts about it. We talked a lot about Forms Conversions, JHeadstart, and even Whirlyball.

I, unfortunately, did not have the time to attend any of the sessions I wanted to. In each case, when the time for one of those sessions rolled around I was engaged in a product demo or an interesting discussion with one of the attendees. I suppose it’s better to network at these things than sit in on sessions all day, but a nice mix would have been appreciated.

It was a great show and we all had a good time. Though I am not a NASCAR fan in particular, I did get to Daytona USA as guest of Oracle’s at the ODTUG party they held there, and though I was less than impressed, when I stopped by the following day as we were leaving Daytona and got a chance to check out the grandstands with some cars on the track, it was very cool. I don’t think I’ll be watching any NASCAR races on the tube at home, but if I get the chance to attend a race in person, I think I’ll take it. Just the sound of those engines as the cars go screaming by is quite impressive. Not quite as impressive as Evo or Rev, but impressive nonetheless