..It is only yourself that bends

2006-06-30T07:17:00.000-07:00

Crossing over

A lot of different approaches are turning up for what just started out as D/XHTML and AJAX. I've been watching over the last year and more and more 'grid bag' layouts are making they're way to the front. This, of course, leads to basically being able to write webapps like one would do on a fat app. A lot of people are excited about this.

I just finished watching a TIBCO AJAX demo. These guys seem to have a really good solution. If you're a corporate developer. Corporate developers were a term I first heard when working with the BEA sales team on Weblogic 8 (I think). These were the guys that would need to crank out an app after they're done with their usual spreadsheet duties or whatever mundane office task they were in charge of (I'm not making this up).

So after even just one minute of watching the TIBCO demo I was immediately reminded of that enterprise mindset. A gazillion features and a sales pitch. In the end, after the cash has changed hands, the developer starts reading through a mound of manuals (mostly online to curb costs, so they're even harder to read) just to get a simple SOAP zip code demo working (btw, SOAP is anything but simple).

The point of this exercise seems to be all about the sale of the possibilities to do anything with a toolkit - looking for a problem to solve in other words. In the enterprise, this is usually an ok thing just because of the layers of people and departments. Some people prefer that and are comfortable in that role and that's good for them.

HTTP is a pretty light protocol. It's not perfect, but it's survived because it's easy and doesn't get in the way a lot. If you've ever worked with SOAP, you'd know that it's not lightweight or necessairly easy. It tries to accomplish a lot (and does), but at the expense of complexity. I recently worked with a client on implementing a service that uses Microsoft's MapPoint to find nearby addresses. Since they're using Java, I decide on using Axis to generate my stubs and provide the magic layer. When the stubs were done, there were over 150 classes that Axis generated and some classes were thousands of lines long. When the Axis libraries were not compatible with the app server the service was to be deployed on, I gave up and coded everything by hand. Brittle, but it worked.

I know a lot of people use SOAP but I have to ask is it totally necessary? Do we need these big complex systems just to do simple things? Should I use some new whiz bang tool to generate some JS grid bag layout, or use the D/XHTML/CSS standard that already exists and augment it with JS?

Working in the Internet business sector vs. consumer, there's always the driving force to offer more complexity vs. simplicity. It's a given that in business, more is better. Doesn't make for a better product, but when someone asks "ooh, and what about this?", you can pretty much, yah, we got that. Regardless if it'll ever be used or not; the kitchen sink and the kitchen.

When the business world catches up with the technologies that first surfaced in the consumer space, things change. Over the last few months I've noticed more and more 'Business 2.0' terms appearing in reviews, on blogs, and even major web sites. It's definitely coming for sure and with it the need for complexity and layers. Looking back at the TIBCO demo, they pride themselves in creating an entire layer - that handles everything you can think over - on top of the browser. Never mind that events in JS, form widgets, XMLHttpRequest, etc... already exist in IE and FF. I suppose that's besides the point as there's nothing to sell in just browsers. But in another abstraction layer, there is.

And ultimately that's how I view a lot of the new tech coming out on the client side. I saw it firsthand with BEA and their relentless pusing of gigantic EJB servers when all some clients really needed was maybe a small interactive site (Microsoft is guilty of this as you still had to buy into their whole stack). Comes down to the whiz bang sales pitch. AJAX apps are not hard to do. All they require is a real focus on what problem you want to solve. The pieces are already there in standardized form - D/XHTML, CSS, XML, etc... Many simple toolkits already exist to assist in this and in a lot of cases, no JS is even required and coding with 'frameworks' like Rails or Django makes Web 2.0 apps really easy. And even fun. Imagine that in the enterprise shop.

So my final point is this: watch out for the sales pitch. If it's too good to be true and does everything under the sun and you buy into it, then you probably have a lot of long hours trying to make an ant hill out of a mountain.

2006-05-31T07:46:00.000-07:00

Gotta love this stuff.

Introducing Protowidget. This is the real beginning of the web widget set for Rails based on the prototype js lib. Yah, yah, I know, G, Y!, and others have their free toolkits out already, but they either work best w/java or you have to work with them on more of a client scripting level, which in my view == waste of time.

When I first used Rails RJS the whole web toolkit thing started really making sense. Now with this, it's not going to be long before someone integrates Protowidget + Scriptaculous + RJS. Wanna develop a rich non-flash web app in the shortest amount of time? This will soon be the way to do it.

2006-05-11T08:14:00.000-07:00

Suffer through

I was reading this article over at Developerworks and it only took a few seconds before a subliminal sigh bubbled up in my thoughts. Why? Because any web 2.0 type apps done in Java, to me, are a dead end.

This isn't to say Java is not useful, it definitely is. I make my day to day using it also provides me with a source for articles to write. But the more and more I use it for various projects, the more and more I feel like I don't really want to use it anymore.

I wouldn't dream of doing an Ajax based app with it ever again. Some things you are born to do and some things you aren't. I feel strongly that if you want to save time and be productive, then there is no framework nor is there any productive way to do Ajax in a Java webapp. Doesn't matter if you have the latest Eclipse plugin - it's just not meant for that. For instance, compare these two examples to just get started with some Ajax libs on your page:

JSP
----
<script type="text/javascript" src="/prototype.js"> </script>
<script type="text/javascript" src="/scriptaculous.js">
</script>

Rails
------
<%= javascript_include_tag 'prototype','scriptaculous' %>

This is just the beginning. I haven't even started comparing tags (JSTL) which to me are not only a waste of productivity, but I really question their efficiency. Ever look a a compiled JSP to servlet? Depending on the implementation your original JSP could balloon to 2 to 4 times the size once compiled into servlet source.

With all this Java/JSP/web development, I feel like I've learned the hard way and I'm realizing more and more that as Java web development has matured, it's becoming an enormous effort managing expectations and patience. I feel like unless you have some great, tested, well architected frameworks in-house (which no one seems to) that developing web apps in Java is a total waste of time.

Say I want to create a quick demo to maintain a list of simple categories, I would do the following

in Rails:
-----------
* (This assumes a db is installed and user permissions are set correctly) tell Rails the user and db I want to use
* Create a migration that defines 1 column in the categories table: name
* Create a controller and model using one command line
* Modify my controller and tell it to use scaffolding support (two words)
* Hit my controller, start adding categories

The framework du jour (JSP/JSTL, Spring, Hibernate):
------------------------------------------------------------------
* Get Hibernate configured for a connection (which needs to be made available via some containter such as Jboss or Tomcat via JNDI)
* Generate a mapping for the categories table and explicitly define a primary key (Rails migrations already did this for me and my schema is already versioned)
* Configure Spring to use Hibernate (XML configs)
* Create my Category bean and add it to Hibernate and Spring.
* Create a controller in Spring, add it to the bean def and also make sure the URL mapping and whatever else needs to be in the Spring xml file.
* Don't forget to configure web.xml to use the Spring dispatcher servlet
* Create JSPs to do CRUD functions on the Category list (I won't even go into JSTL here)
* Matter of fact, make sure the controller supports the CRUD ops too
* Compile
* Deploy
* Add categories

I guarantee the above in J2EE will take 5-10x longer than the Rails steps. This also assumes you already have Ruby/Rails installed as well as Java/J2EE container and the necessary dependencies. You'll probably also see a factor of 10 or more in LOC, which doesn't matter, but does. It not only matters in time to type every single letter (if you have special macros and shortcuts in Eclipse or whatever Java IDE you use, this can be shortened, but then again, so it can also be for your Rails env, just watch the screencasts on the Rails site and you'll see this) but also when you have to go back and update/fix the code.

For me, it's actually fun to build in Ruby and Rails because I can get immediate results and it's so much simpler (usually) than the equivalent operation in Java. I'm not saddled by the feeling of dread when I have to make a change, especially a significant one. Plus, I really like simple, direct, and terse code. Maybe it's because after programming for so long, there's not need to type out a gazillion things to get something going. Of course, perl takes this to the extreme in a pretty ugly way, but still, I'd much rather do something like

for each people do |person|
puts p.name
end

vs.
Iterator iterator = people.iterator(); while( iterator.hasNext() ){ Person person = (Person)iterator.next(); System.out.println( person.getName() ); }
Granted, I'm using pre-Java 5 collection iteration and I could have done a few more shortcuts in the code, but the idea is still there: it just takes too long to do most things in Java.

For most people and companies, this is not a problem though and now that Java is widely accepted in the enterprise, no one will get fired for using it. However, Ruby and Rails will gain more and more momentum in the coming years a make more and more inroads into the corporate environment and also in the pro services sector because they can be highly productive tools. I don't believe one will overtake the other though. There'll be room for both but I do think that the organizations that can leverage both tools in a highly productive manner will gain an advantage over their competitors.

2006-04-03T10:50:00.000-07:00

Pay no mind....

Welcome to the world of pointless idiological (of all things) l33t programming language warring over the web via blogs. Here's a taste: http://www.loudthinking.com/arc/000569.html

One of the reasons I really dig Ruby/Rails is that it delivers. However, who wants to be associated with people who are constantly putting down other languages and development environments and at the same time chest thumping that theirs (of course) is the best and is the one size fits all? Exactly - no one.

Java is really great for some things and Ruby is great for others. I think people need to deploy more and stop whining about 'oh well, will it scale?'. That's such a pointless argument in my opinion. Most scripting languages will scale to hundreds of thousands and even millions of daily users at this point of the web and technology (including hardware) maturity. If your site is not scaling when you've passed this point, then I think you should be pretty happy and can then take things to the next level.

I think DHH and Gosling should realize that a tool kit is exactly that and for some things some tools work better. Get over it guys!

2006-02-23T06:21:00.000-08:00

Why Java is still not there for Ajax functionality.

After using Rails for a few months I still haven't found a fast and easy way to accomplish similar Ajax tricks and functionality in Java. Some of the framework extensions I have uncovered still have way too much config or the framework itself is a bit (in my opinion) convoluted.

For instance, take a look at this IntelliJ screencast and see how they recommend using Ajax. It's much different than the equivalent Rails code. Java is not a terse language. There can be tools and shortcuts that help cut this down, but it's a spell-it-out toolbox. Ruby and Rails on the other hand, feel much more concise and adhere more to convention vs. configuration.

Clearnova has an example of their Ajax controls, which is where, in my opinion, corporate J2EE app development is heading. Watching this video one is reminded of app development 5+ years ago in a Windows-only shop.

In my opinion, J2EE was more suited for (I'm gonna say it) Web 1.0. It's improved and since then and grown, but when things change, the only way to go w/J2EE is to add on, not re-do. Rails has had the advantage of starting from the group up when new ideas and approaches sprouted, so Ajax was not an afterthought. And JS templates in Rails will keep it ahead of the rest of the pack for Web 2.0 development for some time. Until the next paradigm comes along.

This isn't bashing J2EE. In fact, it reinforces its position which is corporate and business applications. For business web apps, Java is king. Clients will still pay good rates for contractors and as long as you're not doing a Ajax app, most Java web frameworks will suffice. Java is the new you-won't-get-fired-for-using-it development tool. It's a safe bet and companies know this.

Ruby and Rails still have a few years in this respect. My prediction will be that Ruby/Rails won't overtake the business web development market Java now commands - that's not its target. Instead, it will be used mostly by small (and maybe some medium to large) shops who want to get something out the door in the fastest amount of time with the fewest amount of resources. This is what Ruby/Rails (in my opinion) excels at.

So, recap; Ajax in J2EE, still hard, but corporate adoption will increase and hopefully the tools and approaches will get better. Ajax in Ruby/Rails, easy, but will stay more on small sites for the time being.

2006-01-16T11:38:00.000-08:00

Ruby's main method
------------------------

If you're coming from the Java or C world then you're used to the main(args) method. Ruby does not have this and is also picky about where code is placed in a source class. Take this class for example:

test.rb
--------
class Test
end

Simple enough. Defines a Test class that doesn't do anything. Now say you want to add a method that does something, but you want to have the class call itself. This approach does not work:

class Test

# Create a new me and call
t = Test.new
t.test_it

def test_it
puts "We're testing."
end
end

The above would result in the following error:

uninitialized constant Test (NameError)

Coming from Java/C, we'd be scratching our heads about now since everything looks fine and we're used to defining a main method at the top of the class. Ruby doesn't like this and the proper way is listed below.

class Test

def test_it
puts "We're testing."
end

# Create a new me and call
t = Test.new
t.test_it

end

Haven't found it specifically mentioned yet in any docs or books, but apparently any main type of code in a class file must be at the bottom. And now you know.

2006-01-06T10:47:00.000-08:00

Allowing empty fields in Rails dates

I had a situation where I was writing a section that allows a user to create a particular content item. On this screen I had two fields, start and end date. I used the Rails datetime_select (they were time sensitive) to achieve this. But no where was it mentioned how to allow for blank dates as these were not required fields and I didn't want a user to submit the values, which were filled in as todays date.

This issue was not very clear at first when reading thru the ActionView::Helpers::DateHelper api docs. But then I just tried the include_blank option like so:

<%=datetime_select 'content', 'start_date', :include_blank => true %>

So, it works.

2005-12-15T13:59:00.000-08:00

Kitchen sink update

The good news: everything works, including RJS Templates.
The bad news: it was kinda a pain to get straightened out.

Steps (OS X specific)

Go here to setup readline and ruby (I recommend using 1.8.3)
Go here for the rest of the setup
For postgres, check this link.

I know this has been gone over a million times before, but for some reason no one site works perfectly. Anyway, the following list works:

readline 5.0
Ruby 1.8.3
Gems .8.10
Postgres 8.1 (from Darwinports)
ruby postgres C library not postgres-pr
Rails 1.0
RJS Templates (to be included in Rails 1.1)

2005-12-15T12:11:00.000-08:00

RJS Templates update

So, turns out if you have Darwinports version of Ruby installed, all kinds of whacky things can happen. Solution: uninstall them. Argh. In my case that means all of Ruby, lighttpd (which I highly recommend over Apache and Webrick), fcgi, gems - the whole ball of wax.

Since I installed Postgres thru Darwinports, I'm gonna leave that and actually, since Darwinports installs in /opt, it makes it a little easier to have different versions of different apps running side by side.

You may be asking yourself 'is RJS Templates really worth all this trouble?!' and the short answer is: absolutely! Try them out and you'll see what I mean.

2005-12-15T09:52:00.000-08:00

Rails development on OS X + RJS Templates == frown

So I wanted to start using the new RJS Templates (which are really kick ass) available to Rails developers via this link. After upgrading to Rails 1.0, I followed the instructions and got this message:


orion:~/projects/workarea/biolexis/trunk/rails jason$ script/plugin discover
/opt/local/lib/ruby/1.8/net/protocols.rb:38:in `new': SSL_CTX_new:: library has no ciphers (OpenSSL::SSL::SSLError)
      from /opt/local/lib/ruby/1.8/net/protocols.rb:38:in `initialize'
      from /opt/local/lib/ruby/1.8/net/http.rb:430:in `open'
      from /opt/local/lib/ruby/1.8/net/http.rb:430:in `do_start'
      from /opt/local/lib/ruby/1.8/net/http.rb:419:in `start'
      from /opt/local/lib/ruby/1.8/net/http.rb:324:in `start'
      from /opt/local/lib/ruby/1.8/open-uri.rb:544:in `proxy_open'
      from /opt/local/lib/ruby/1.8/open-uri.rb:525:in `direct_open'
      from /opt/local/lib/ruby/1.8/open-uri.rb:169:in `open_loop'
       ... 12 levels...
      from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:21:in `require__'
      from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:21:in `require'
      from /opt/local/lib/ruby/gems/1.8/gems/activesupport-1.2.5/lib/active_support/dependencies.rb:214:in `require'
      from script/plugin:3

Worked fine on Fedora Core 3 (imagine that!) but definitely no love on Tiger via Darwinports. Sigh. These are the sorta things I hate dealing with. Tracking down this sorta car crash was interesting about 8 years ago. However now, it's a nuisance. And why does the whole Rails plugin thing require SSL anyway!?

Doing a little digging here and there thru various lists I find out that it's a known issue with OpenSSL .9.8 and (of course!) there's no fix yet. This is the dark side of open source and anyone that's had to deal with building Linux or various other free libs has run into these sorta issues before. I'm not saying corporate products are any better, but this is definitely a show stopper for me - if I want to use RJS, which.... I do.

So now the big questions remains: go down the rabbit hole only to probably end up exasperated, beaten, and conquered or forget RJS for now and do without it? And the latter leads to this question: develop a typical, nifty Rails app, or develop a cool, ooh and aah Rails app that'll impress the masses. Oh, the quandary..

2005-11-30T08:31:00.000-08:00

STI it is.

So my last post regarding CTI did not work. There were still other issues below just updating and loading (which I sorta suspected). So I ported a development db over to a new STI layout. All seems well, however, it would still have been nicer to keep the CTI stuff as I now have about 33 cols in my content table - this is exactly what I wanted to avoid.

The upside is queries are easier and faster; no join. Plus, it is more straight forward to just deal with the table as there's no other type table and no child tables. So in those regards, things have simplified, which is what Rails tries to do.

The upside to all this is that it has made me re-think some of my db structure. I started off reading these two books:

The Data Model Resource Book Vol 1 and Vol 2. Of course the author loves his design and from a dba perspective, it's normalized to the farthest reaches of the galaxy. One thing I struggled with from the beginning was the sheer complexity of my schema. Everything was fully normalized and I've always had to take more time to code to adjust to that. I kept telling myself "Well, that's what a programmer does - hides the complexity from the user. It's most important to do it right, whatever the costs". Now I'm not too sure about that.

I've spent a year working on sections of the app that, now, don't seem to make much sense. Or, at least from a design perspective. And now I'm in between the clash of two worlds: the J2EE and Ruby/Rails. At this point, I'm leaning towards R/R.

Why?

I've spent the last 9 years working on Java apps. I ditched scripting years ago because I got tired of the dynamicity of it. Always checking for this type, that type, etc. I liked Java because it was strongly typed and I liked the OO concepts; OO Perl wasn't really around then. And that was good for then and even the next five years after. But now, I'm done with all that. Done with verbose syntax, config files (ugh!), and five billion frameworks all with their own filthy memory leaks.

Building a web app in Java has become a monumental undertaking nowadays. The proper way is to have a dba, bean coder, jsp coder and html/layout/design person. Plus, you should be able to plug in any server at any level, so therefore, it's required that you master all aspects of said server(s) at said level of the stack. But really, who buys Oracle and then switches to MySQL? And if you do, then you must have solid reasons and porting shouldn't be too hard. So more and more I don't buy the whole switchable server argument. Seems like it's all theory and drive for a independent vendor market.

One thing I like about the Mac over Linux is that I don't have 5 billion options; I have some, but limited options. And those options seem pretty well thought out. So instead of 10 window managers on Linux, I have one on OS X. Granted, OS X wm doesn't do some things I really liked, especially focus follows mouse, but on the most part it does 95% of everything I want (with a few add on's). Plus it's fast, looks excellent and is stable! Linux can't promise the same. The problem is the same with Windows; too much junk for junk.

I feel Java is victim of the same sorta thing; too much junk. Everyone has a project on it. Some will say this makes for a richer community but I say only if the projects are of excellent quality (the quality, in my opinion, is highly debatable too). That all said, here's the point that everything teeters on for me: complexity. J2EE, to me, is too complex nowadays and that, in my mind, leads to lower quality. R/R on the other hand had tried to simplify things and in their case (because of excellent design on 98% of the pieces) has led to higher quality.

So now that I've reimplemented a decent chunk of my app in Rails (of course it did take 1/5th of the time, but that also has to do with the fact it's always faster to re-implement the second time around), I'm passed the whole web stack and on to the db. I think because Rails includes the whole stack (they understand that a lot of the time the code and dba are one in the same) it's forced me (for good or bad) to re-think my data layer.

Five years ago, it was sorta fringe to go Java and Tomcat with x framework - I know cuz I worked at a consulting company where I pushed these very issues. But nowadays, things are moving faster (this same argument could be used in 2000 as well) and there are more and more companies and groups competing and developing in the same space as you or I are in now. For my development it's all about getting something out there with the least amount of resources. For me, this is one person and about 10-12 hours a day (of course this works as I basically have little social life, something that I've accepted on a temporary basis). To do this in Java? Forget it. I've already tried that using the newest and coolest projects. Even those seem to take too long. For me now, Rails seems to be more and more the answer.

The future.

First, the Java codebase for our app is frozen as of this week. No more new changes will be made except for the transition of our current feature set to encompass free users; basically you can register and search for companies for free now. This will run in Java until Feb 1. That date will be the cut over to the Ruby/Rails code base. Development of R/R will be finished by Jan 1. and the rest of Jan will consist of qa and optimization. After Feb 1, we will start to roll out new modules every few months, something I wanted to do originally. By this time next year, we should be at where we wanted to be this time this year.

Is this delay all the fault of J2EE? No, probably not. But for me, J2EE has not simplified anything for me and it has definitely lengthened the development process. I'll still (if I have to) continue to consult using Java for the next project or two but all in all, I don't see wanting to work with it much anymore. 9 years is a long time to keep doing one thing and to keep using the same tool is a hard thing to do. It's possible we might find things for Java in the future of our product but for now, it's all about maximizing productivity. As days wear on and more tests are done I see less Java in our app and more R/R.

2005-11-23T17:43:00.000-08:00

CTI Round Two.

After days of trial and error, search after search, and even reading some of the source code, I think I might have figured out (for now) my cti issue. And behold, the nightmare:

class ContentJob < ActiveRecord::Base 
 set_table_name    "content_job" 
 set_primary_key   "content_id" 
 belongs_to        :content,  :dependent => true,
                   :foreign_key => "id"

def after_destroy
 if self.id != nil : content.destroy end
end

def before_save
 if self.id == nil : self.id=content.id end
end

end

The after_destroy and before_save methods are the saving grace. Very simple too. However, I just wished this was mentioned somewhere. But, this is the way of some things I suppose. One thing that was neat is this line:

if self.id == nil : self.id=content.id end

We're basically saying if the ContentJob object's id is null, then assign it to the Content object's id. I was tailing the test log output and I noticed that just referencing the content.id of an unsaved object in this manner will save it. Pretty slick. It's stuff like this that I'm starting to appreciate with Rails and Ruby. A lot of implicit behavior and as long as I know what I'm doing, I like that.

In my tests doing an update on the top level ContentJob object seemed to propagate fine to the linked Content object. The above methods handle all create, update, and delete actions. It's kinda neat in its simplicity really. We'll see how it fares when more things get hooked up down the road but for now, it's safe to say (hopefully) that I can turn this page.

I think there becomes a point in a programmers life when you think "don't bug me with the details, get it done, and get out of my way". It's like after you've compiled the Linux kernel 50 times; after a while it's just like, screw it, gimmie the stock kernel with all the modules plugged in, I don't care anymore. Not to sound so 90's but, been there, done that - times 20.

2005-11-22T08:56:00.000-08:00

STI (Single Table Inheritance) vs. CTI (CLSTI / Class Table Inheritance)

One of the things I'm still a little miffed about is Rails lack of support for CTI. While fully appreciative of the effort of the Rails group, I think (and I know I've mentioned this before) this will significantly slow down future J2EE adopters.

Why I like CTI

Take this example:


Content
+-------------+
| id          |
| title       |
| description |
| date_added  |
+-------------+

Event
+-------------+
| content_id  |
| start_date  |
| end_date    |
+-------------+

Job
+-------------+
| content_id  |
| location    |
| job_code    |
| contact     |
+-------------+

Now it's easy to see that event and job have primary and foreign key to content.id. Their table's also extend content and provide their own attributes which can be modified without affecting the original content table. Plus, new content types can be added on by just adding a new table and extending the content table. For me, this is a sensible design.

Why I don't like STI

While STI is good for some things, I don't think it's good for the above. Here's the Rails recommended way for the above problem:

Content
+-------------+
| id          |
| type        |
| title       |
| description |
| date_added  |
| content_id  |
| start_date  |
| end_date    |
| content_id  |
| location    |
| job_code    |
| contact     |
+-------------+

One of the reasons the Rails guys will tell you this is good is because there are no joins. And this is absolutely true. I'm all for fast db access, but if you coded everything from a speed perspective, then we'd all be using C or assembly. The reason we don't use those languages - or at least, assembly - is because it's way too hard to debug and maintain. And this is why I don't like STI for everything.

The more successful our company becomes, the more types of content we'll have. The Rails guys suggest that I just assign a different type and add the columns and be done with it. However, I feel this is a little too generic and there is no time or thought given to how this will affect things later down the road. I've been there too where you have an Orders table with 40+ columns; no thanks. Any seasoned DBA would look at that and then just shake their heads.

And this is what really surprises me; Rails is a very nice framework, but for some time I couldn't figure out why they would leave CTI out. But then after using it for a bit I see why - because there are no big projects using Rails yet. Sure, the 37signals guys have churned out all their Basecamp related apps and they're very good. But I haven't seen anything big else outside of that using Rails. The Rails guys seem very focused on their niche: small blog or CMS apps. They declare all the time that Java/J2EE is on it's knees and Rails is about the deliver the final blow. But this is ridiculous. Like any small group, it's easy to have big hopes and aspirations and think that because your solution is gaining momentum, it's the best and therefore destined to take the crown. I don't see Rails doing that anytime soon.

A few things lacking that Rails needs in order for J2EE people to really start taking it seriously:

Transactions that span multiple models without have to nest them as is done now
CTI - a must have, otherwise, the dba will laugh at you and send you on your way. Plus it makes good design sense!
Clustered sessions - I know this exists, but it's still a little obscure; make it easier

If I had the above, I'd be set. I know the Rails guys want me to do it their way and I really appreciate that. Seriously. But sooner or later, they're gonna have to realize that in order to attract more than just blog and shopping cart projects you're going to have to offer a little more. The good news is this will probably happen. The bad? When? implement CTI at some point and someone will probably offer some higher level support in the stack to provide transactions across many models, etc. Someone will probably But when? These seem pretty important issues to me - too important to be left out of a 1.0 release.

In the mean time, I suppose I'll have to adjust my data layer to fit with Rails requirements of STI. *Sigh*. The mailing list guys suggested that I hack on CTI in the source but really, if you're still learning a new language and framework, what's the chances of that happening? Yah, zero. Plus, I don't want to hack on the source, I just want it to work!

The Rails guys have enticed me but please, help me switch for good! Provide me with the tools that most Java/J2EE guys use and expect, not hollow blog entries of why Rails rules over Java. While they've have done some good work getting me to think of other approaches and design issues, having to abandon CTI in order to use Rails does not sit well with me. I suppose, thought, I'll just soldier on and see what happens.

2005-11-19T10:35:00.000-08:00

Hibernate for Java SE

My second article is up. Enjoy.

2005-11-13T16:34:00.000-08:00

Hmm, I thought, if anything, line count would go down.

Today's totals as of 4:35 pm, PTD:

XML totals:
-----------
12754 total

Java totals:
-----------
111096 total

JSP totals:
-----------
16141 total

What gives? I couldn't have coded approx. 30k lines of code in a few weeks (hey, even I'm not that good, plus I somewhat have a life). In fact, I just cut out, at least, a few hundred lines and some old deprecated classes. Bummer, I was really hoping to see how things have 'improved' since setting forth on my cleansing mission.

AHA! So, there was an error when I was reading the totals. Since my web/ dir (where my JSPs) are kept are located at the same level as my src/ dir, my count script was picking up JSP .java source files. Heh! So, here's the real count:

XML totals:
-----------
3133 total

Java totals:
-----------
61903 total

JSP totals:
-----------
16141 total

That's more like it. Which makes me wonder if my first count was right...? Nice to see I've lopped off at least 10k lines of code, which is completely possible. I've been refactoring alot and have just started. I estimate I'll be down to around 30k when done.

In other news, my new O'Reilly ONJava article about using Hibernate outside your web container is close to a final draft. Should be out sometime in Dec '05/Jan '06.

2005-11-07T11:41:00.000-08:00

Emacs CVS 11-05-2005 almost works...

Actually it does work, I now have a shiny native Tiger x86 build. Aaaah the speed and stability. This coupled with Josh Aas's x86 Camino builds have made my development month. However, no joy in sharing my Emacs build as I get an error when I try to make a distributable package:

gcc -c -fpascal-strings -fno-common -DMAC_OSX -I../mac/src -DHAVE_CONFIG_H -I. -I../src -I/Users/jason/projects/emacs/emacs/mac/../lib-src -I/Users/jason/projects/emacs/emacs/mac/../lib-src/../src -fpascal-strings -fno-common -DMAC_OSX -I../mac/src -g -O2 /Users/jason/projects/emacs/emacs/mac/../lib-src/pop.c
gcc -fpascal-strings -fno-common -DMAC_OSX -I../mac/src -DHAVE_CONFIG_H -I. -I../src -I/Users/jason/projects/emacs/emacs/mac/../lib-src -I/Users/jason/projects/emacs/emacs/mac/../lib-src/../src -g -O2 movemail.o pop.o getopt.o getopt1.o -o movemail
i686-apple-darwin8-gcc-4.0.1: getopt.o: No such file or directory
i686-apple-darwin8-gcc-4.0.1: getopt1.o: No such file or directory
make[1]: *** [movemail] Error 1
make: *** [lib-src] Error 2
Make failed... Aborting make-package.

Boo, frown, etc.. Well, at least I got psql compiled natively. That only leaves Adiumx and Desktop Manager in PPC mode.

2005-10-25T08:44:00.000-07:00

One week later..

So it's back to the old horse. Things are getting busy so no migration today - or probably for the rest of the week.

A Rails, er, complaint.

I still plan, at some point, to get a Rails version running. However, the one thing I noticed is a little inflexibility when dealing with a migration. It seems the Rails gang and the guys the wrote the Rails agile development book have a bit of a, er, myopic view.

For instance, I have an example where I have three types of content in our system: news, jobs, and events. In our db I used the Class Table Inheritance pattern, which is widely known, proven, and implemented. In Hibernate, this is easily done via your mapping file and has been supported for some time. However, Rails doesn't seem to support this and when I asked the list, even after I said I cannot change my table definitions at all, I got a few replies asking me to use Single Table Inheritance. ????

I didn't want to voice my frustration to the list but I really couldn't understand what part of the 'I cannot change my tables' sentence they didn't understand. This led me to two realizations:

1. People, obviously, didn't listen or carefully read my post.
2. There is little interest - for now - in getting people to migrate.

Let's expand on number two. If you read the Rails agile development book and go through their 20 min videos, etc, it all seems like a good simple way to do things. And coming from that perspective, I believe they're spot on.

However it seems to me that since Java is the biggest web development language and is apparently, susceptible to attack now, you would make migration from it as easy as possible. Give people a reason or many reasons to migrate. I'm not saying some GUI tool or migration scripts, etc... - just a little more infrastructure to support it. I'm not talking about complicated infrastructure either - like supporting EJB or craziness like that - just common basics; stuff that people use in real web apps. I'm convinced one of these things is CTI and I know a lot of people are already using it with Hibernate.

Another thing I noticed in the Rails camp is the drive to do it their way. I suppose this is standard across all software projects and I know they have their vision and that's cool with me. However, when dealing with migrations you'll be hard pressed to find many that will throw their legacy stuff away and start from scratch using new methodologies. So you either try to accomidate and work with them (which the majority of people on the Rails list do pretty well) or they just won't move.

The future.

My last stab at Rails was in early spring of this year and the coffin nail for me at that time was that the Postgres support was flaky at best. This time around, that has all been fixed and for me that's a really good thing. Now, the requirements are bubbling up through the framework and the connection/driver is no longer the issue, but instead, a part of the stack itself is. This is natural as it shows that the framework is maturing and moving forward.

But I feel it still has a ways to go if you want to migrate from a J2EE web app. Not only is the CTI, I feel, a critical issue, but the whole ActiveRecord relationships can be a bit confusing. The Rails agile development book has a few chapters on AR and all the Rails framework classes have good API docs, but it's still a little confusing trying to figure out what points to where points to where.

A few times on the list some people pointed out that CTI was not a priority and that anyone is free to submit their patches to fix it. However, since most people using Rails have drank that kool-aid, they probably have no need to use CTI, which leaves it a dangling ultra-low priority in their project. And the guys (like me) that really need it are still trying to just switch gears and catch up to Ruby and the framework itself. So, it would probably be weeks or even months before a n00b could really dive into AR and start mucking with things.

But who knows, maybe someone will magically patch it soon. It will be interesting to see how many times the CTI issue comes up in the future and who it prevents from migrating. All in all, I think all the above issues are an opportunity for the Rails team to solve some interesting problems in a new way. Above all Rails seems to favor simplicity over complexity, hiding the complexity behind the curtail - in much the same way I feel a Mac does. All in all though, it's still not there yet for our migration. Maybe sometime soon..

2005-10-22T09:56:00.000-07:00

The reality begins to creep in.

It's funny, there's a big difference between all the hype of watching the Rails 20 min videos and actually getting things to work. Overall, I'm somwhat pleased with the conversion attempt. However, it's definitely not that easy and I can see why it's taken me so long to develop the Java site.

Menu tabs

For instance, we have a tabbed (typical) menu system that renders parent tabs and child sections based on a user's security role/level.

a Person has Roles | Tabs have Modules which group Controllers and set access Roles

At the top, this seem somewhat reasonable. A Person has one or more Roles. A typical model. And every visitor - whether they're authenticated or not - has a Role. Therefore, I'm abe to define a set of Tabs which will only render based on particular Roles. In order for the tabs to render a useful link, it must be connected to a ModuleResource, which belongs to a Module. That ModuleResource is usually a Controller, but could be many things if need be.

Tag render speak: I see a 'public role', so let's get all the Modules and their resources for that Role. I'll then ask each ModuleResource for its Controller, ControllerMethod, and ControllerParams values and render them accordingly.

This was something I figured out at the beginning of the year, got it to work, and then moved on. It's funny, however, to re-implement it in a different language using a different framework. With Rails, you definitely feel closer to the metal, like JSPs sans the custom tags. Even though Rails does have tag helpers, they just don't feel as abstracted as JSP tags do. While I haven't gottent the menu tabs to work 100%, I have made a small dent.

Models

Another doozy if you're coming from the Java world. Somwhere in the past 8 or so years, it was considered bad to have your Model (which we'll say, wraps a table called User) passed all the way from the db level, through the controller, and then rendered straight out on a JSP. This represented tight coupling and if something changed on either the front (JSP) or the back (db), then the argument was it will break.

I found over the past year, I started getting rid of form beans (as Struts likes to call them or Commands in Spring) and just dragging my Model from the back to the front and vice-versa. Plus, componentization makes sense to me; I should be able to use a User object as part of a form or page along with an Address object and have them both validate, relate, and persist correctly. This is DRY in Rails-speak. So for me, it's become more and more of a time issue and not an academic one (although I do want to feel that I have done things with some corectness). It seems that Rails aligns more closely with the time argument than the academic. In fact, it's encouraged, if not required, that you wrap a table in a Model and then pass that to the front. Tight coupling. No facades, wrappers, or anything else.

What's the alternative though? In Struts (last I used it was 2004), this happend the following way:

* User requests a Book via an id via an ActionForm or a plain GET url
* Request coms into an Action (Dispatch, etc...) and if an ActionForm, validation fires and either succeeds or fails, or if a GET, you check manually
* Then you (the developer) have to get that Book id, and either pass it to your Service or to your Dao
* The DAO looks up the value in the appropriate table and constructs a new Book object based on the row it finds
* The Action then either adds this to the Session or Request and the internals forward to the proper view
* The view then renders the appropriate values as part of a form or as just text on the screen

The Rails way (as I've so far grep'd):

* User requests a book via a form or GET url
* The Controller directly calls the Model usually via something like Book.find(id)
* The Model has its own validation rules and will either succeed or fail
* The Controller then either catches the exception and errors correctly or forwards to the correct view
* The view then renders the Model or error

Approximate Struts objects used in this: JSP, Form Bean, Action, Service, Dao
Approximate Rails objects used in this: View, Controller, Model

For a more complex flow, Rails also allows for Helpers to be used.

This is a rough and not perfect approximation. However, I think it does demonstrate the different philosophies behind the two. Neither is correct or incorrect. However, one will take longer to code than the other.

Conversion

Again, the 20 min Rails videos are great, but I feel like they are not a real world demonstration for a full blown app migration. The videos are all mostly done with clean use cases; build a blog, build a recipe list, build a list, or build a CMS. Nothing is yet out there to migrate a Java app. I think it's totally doable. In fact, you can probably convert any web app to any other language you want. When I worked in NYC, the big thing for my Java job out there was porting their money making Perl app over to Java. Took them over a year to do and in the end, through the bumps, it worked. So porting/conversion is totally possible. But it's the details that are easy to forget about. Things that work now on one system will probably need tweaking on another.

Rails like objects and tables like so: Book object -> books table. For a join table you might have something like so:

users -> users_roles <- roles

but your tables might be named like:

user -> user_roles <- role_types

Luckily Rails does provide the option to name the table your Model corresponds to as well as the foreign key names that your realtionships use. However, it is still a bit of thinking to go from Hibernate mappings to Rails ActiveRecord mappings. The upside is the Rails mappings are much more terse as another philosophy of Rails is to hide a lot of the magic so you don't have to deal with it. I like this for sure, but like anything, coming up to speed with a black box and a different approach can be a taxing experience.

All in all, I'm having fun with the Rails stuff. It'll be interesting to see how long it takes me to get the home page working with the user login. I predict, another week.

2005-10-21T08:51:00.000-07:00

Welcome to the fold.

Hmm. So first off, I'm not a 'blogger'. I tried this in NYC years ago for about a year and just found it to be forum for complaining to my friends. Of course, I'm sure that's only because it was what I made of it, but regardless, I closed that shop down.

Now however, I find myself returning for the same initial reason: to somewhat document my adventures in web development. I think this time around there will be no complaining about the day to day news or political missteps and instead focus on where I'm and where I want to go in regards to programming.

The past.

Two plus years ago I sat in an apartment in NYC sorta lost, trying to figure out 'the next step'. I had just left, possibly, the most horrible Java position I'd ever seen in my life; the team I worked with were nice, but the VP of Technology was the absolute worst. Never in my life had I felt someone had it so wrong. (Of course, at that time I didn't have all the answers either.) Needless to say, I left that position and literally hit the streets of NYC trying to figure out what to do.

For about a year I hashed out ideas with a friend and we finally settled on the industry we both love and know: lifesciences. In the fall/winter of 2003 I put finger to keyboard and started hacking away. My idea - from a technology standpoint - was not to use a full J2EE stack and thusly a complicated app server but instead to use 'lighter' tools and mix and match. Servers like Weblogic or WebSphere were enterprise powerhouses, but at the same time, they were bloated, complicated, and I didn't like where the interfaces were going. So I stuck with the usual, Tomcat.

The present.

Yesterday I did a LOC count on my project:

Java	86472 total
JSP	15986 total
XML	12952 total

As Hurley on Lost would say: dude, that's a lot of code.
115,410 lines of code and config to be exact. This code is used with the following frameworks - or maybe a better way to put it is; this code is made possible by the following frameworks:

Spring
Hibernate
Struts/Tiles (only the Tiles bit)

And sprinkled with a smidgen of:

ActiveMQ
Jakarta Commons
Ant
CGLib (from Hibernate)
Quartz (for cron stuff)
Rome (for RSS feed parsing)
And a few other misc. libs..

Two years and 115k lines of code from one person... That's about 55k lines a year, 4.5k a month, 1125 a week, and 150 a day - roughly speaking.

Where is all this going?!

Exactly. I believe the meaning of life is learning. If we stop learning, we become rigid, stuck in the past, ignorant, and unwilling to accept the future. I know what you're thinking already; this has something to do with Java development (and if you didn't think that, well, then you can't read my mind). Yah, I think so. And where am I going? Python? Php? E-gad, back to scripting?! I think so.

I've done Java/J2EE for over 8 years now. I was part of the team that built one of the biggest travel portals on the net. I've worked with Terabyte databases. Helped code a software project management system that enabled teams to work on a project all over the world, all hours of the day. I've implemented scalable, load balanced, HA systems. Done web service endpoints until I'm blue in the face. And it's been interesting. Not always fun, maybe not always necessary, sometimes (definitely) over architected. But it's always been interesting.

Enter ROR.

Or Ruby on Rails for short. If you visit the Rails site, you'll see some great videos on how you can build a blog or CMS in 20 minutes or less. Wow, looks great. All the changes on the fly, no compiling, no re-starting [insert favorite app server here] the server every 20 mins due to memory leaks. Just edit, save, reload. Edit, save, reload.
Of course, there are no videos on how to migrate your complex J2EE app over, which I don't see as a fault of nor a responsibliity of the Rails guys. But it would be nice! Of course, there's probably a simple reason for this: because it's not something you can do in a 20 min video. Nor in a 20 hour video.

The Rails folks love to talk about LOC. And I tend to agree with them; less code = less time spent and more time playing. Does this mean that you'll have a clean kick ass Rails app if you try migrating your big Java project after watching one of those 20 min. videos? Mmmm, probably not. Frankly, that's the position I'm in: trying to see if it's possible to migrate a real-world, working, money making, production app. Not a quick blog or CMS via Rails Scaffold (which I find interesting none the less), but a real enterprise app. No script. No practice. No fricking idea.

It's going to take some getting used to, like any new language. All my commands, services, and wrappers in Java are kinda gone in Rails. It's just, really, pure MVC with a sprinkle of helpers. I think I'll probably be able to migrate and come out with a Frankenstein mix of the Rails way and the Java way. Which, I suppose, should be interesting.

So that's what this whole blog is about - the journey. From one philosophy to the other. We'll see where it goes.

Do not try and bend the spoon, that's impossible. Instead ... only try to realize the truth.
What truth?
There is no spoon.
There is no spoon?
Then you'll see that it is not the spoon that bends, it is only yourself.