Saturday, 24 February 2007

Why use J2EE (aka JavaEE) instead of Rails

First off, I love Ruby. However, I'm not a Ruby evangelist. To be a "proper" evangelist you must preach the technology all the time even if it is a square peg in a round hole. Listen to this guy:

Why even use J2EE at all, why not use Rails? Well a sometimes you don't have a choice...

Why use Ruby instead of Java

  • It is in style - Java is no longer "cool" enough to get your next book deal and present trendy talks
  • It is easier - Java APIs tend to be designed with the locator to the factory of locators to the factory designed by committee of complexity lovers
  • It is interpreted - it is often just easier to write scripted code faster which is why JSP is more successful than OO-Java (irony intended)
  • Your system is relatively simple
  • dynamic typing

Why use full-on JavaEE

  • You aren't using MySQL - HA. Nothing supports connectivity to the number of databases nearly as fully as Java.
  • You need proper concurrency control - What if two users edit the same data at once? What if 1000s of users read the same data at once? What if one edits that data while 1000 read it?
  • Imperative transaction management sucks
  • You need services or APIs not provided to or by Ruby
  • You don't think the place you're deploying this to will install C compilers on their production AIX boxes (necessary to install most Ruby libs because they're light wrappers around C code

Frankly I love Ruby but Rails is a toy. If you're writing grandmother's address book and pessimistic locking for everything is okay, and occasional undetected data loss isn't that big of a deal -- it doesn't matter what you use. Time to develop is critical but often more critical is cost to maintain. Ruby's deployment semantics are a pain here.

However, I grow increasingly dissatisfied with Java as a language. Its not the syntax so much as the goofy committee-designed APIs. Yet I increasingly LOVE the JavaVM. Open source, FAST, parallel GC, JITs, multi-platform! Gotta love that (even if the classloader architecture blows just a little bit). Projects like JRuby and support for scripting in the JDK make me increasingly encouraged that we DON'T have to choose. We can have Ruby with a non-sucky deployment environment (we use JRuby for testing already). We can use unpopular databases with Ruby. We can get better transaction management, JMS services, etc. We might even one day call non-bizarre Ruby libs from Java (a guy can dream) rather than their bizarrely designed Java alternatives with no performance penalty and even a modest gain.

Posted by acoliver at 1:01 AM in Tech tips

Google EDU Tech Talk videos are a goldmine

First off, most talks are useless. Second off, all talks are selling something. Whether it be "support my JSR or at least don't fight it" or "Use Ruby and oh by the way hire my consulting firm". I've no problem with this so long as we get something out of it. I found Bile Blogger's JavaOne post funny. You know who gave 99% of the most blatantly product talks or just flat out uselessly boring talks at JavaOne? I'll give you a hint. 3 letters and starts with an S. sssshhh.. It was Sun. I hear it has gotten better, the last time I went was the year IBM pulled out.

Third off, frequent readers know that I am suspicious of google while using google image, video, and search like a lamb to the slaughter. I do however run CustomizeGoogle plugin for Firefox so that I can at least fool myself into thinking I have a little privacy (even if I know I'm fooling myself). However, I have to say that many of the Google Tech talks on Google Videos are truly good. Some are even practical! Consequently, it looks like my spinal fluid sapping theory may have been wrong. Although, it is possible that they had their spinal fluid replaced with a usable substitute.

I thought the surviving poisonous people talk was good (esp for a "soft" talk). Surprising because Brian Fitzpatrick kind of rubs me the wrong way.

The closures talk was also very good. I liked part of the MySQL talk although the first guy is a bit dogmatic on some things (like stored procs) that don't take into account *TOTAL system performance* in favor of simple database performance. Secondly, the advice on using business keys as opposed to surrogate keys is simply wrong more often than not. Real world business keys are flawed, suck and change too often. Even "naturally perfect" ones have "oh but"s. Good example.. Think (US) Social Security Number + Birthdate is a good key? Forget the legal issues, its a bad idea. First, dates are always fun ;-). Secondly, not everyone ACTUALLY has an SSN and BTW, people LIE about their SSN. You still need the old record for the identity thief even if you need mine too. Sure you can do dumb tricks like 000 prefixes or slightly too long SSNs...but boy oh boy. You don't even want me to get started on various product IDs, order numbers, shipping numbers, etc. ;-) The talk was a bit too basic for me but I got other kinds of information out of it ;-).

Anyhow I highly recommend checking it out. BTW, if you like my general tech tip posts (sprinkled only occassionally with these softer posts) then note that they do not come across on the main blog.buni.org page or feeds. You have to subscribe separately to this category.

Posted by acoliver at 1:00 AM in Tech tips
« February »
SunMonTueWedThuFriSat
    123
45678910
11121314151617
18192021222324
25262728