Real Programmers are nerds
A few years ago I joked with a friend that she should be in marketing because she had never read Lord of the Rings. I was joking as she's actually a pretty accomplished architect and developer, but it's been in the back of my mind for a while. When I was a youth, all the good programmers I knew were 2600-buying, RPG-playing (pen and paper, Nintendo, pc and mud), David Eddings-reading, Star Trek quoting nerds. These aren't your new fashionable nerds who go to the gym and know how to remove DRM from iTunes songs. These were real "afraid of girls" kind of nerds. The kind of guys who would come in over a week-end and re-write the entire app so it would be cooler (of course this is still the late 80s and early 90s so I'm not talking real programmers).

So as a youth I always equated technical prowess with nerdiness. Here's a very basic chart (showing elvish before the movies came out, so it was much, much worse). I got to grow up around pc shops when they were run by super nerds who built their own boxes out of computer shopper and let you borrow civ1.

But as I entered the work force, I started coming across programmers who were doing it for the money, not because it seemed so cool in an Arthur C. Clarke or William Gibson book. Now there are more competent programmers who wouldn't know Star Wars from Star Trek and don't remember Legos back when they were really cool and castle walls came in 50 pieces not one.

I guess this trend is a good thing. If you've ever tried to discuss design or functional testing with someone who hasn't bathed in 3 days and responds in Klingon you know how unpleasant it can be. I still think that someone who loves programming will outperform someone who just is in it for the money, but I guess you can now love programming and not be a nerd.
  Technical reading
There's a lot of info every day and every week and keeping up with it all is a challenge. For newsfeeds there's sites like, and even if you want to keep up with the latest big name tech or apple product. But it's harder and harder to get valuable content that makes tough tech decisions easier.

I tend to read a lot of magazines and journals as they are printed on paper and I can read them while I'm offline. The good thing about IT journals is that if you qualify, many are free. Here's a list of magazines that I read frequently:

This is a sample of what is out there. If you read most of these you will keep abreast of new products, services and technologies. They won't take the place of online feeds, but paper still has a few advantages.
  J2EE application scalability
OK, so imagine you're about to buy some new J2EE application. It could be really complex and run on a full J2EE server with EJBs and JMS and XA transactions, or it could be a simple servlet engine that can run in resin or something. But whatever it comes, there comes a time when someone asks "How many users can it support per processor?" or "What is the average response time under load?"

The potential vendor can hand you a white paper like this one from SAP or this one from IBM. It will be great and list out what processors they use, amount of ram, how many users and the response time charted for various loads. If they do this then read it and size your hardware and software purchases appropriately for your new application.

However, if they, like many J2EE app vendors, say something like "Well, we have some internal numbers but nothing specific." or "We have some rough statistics, but our app is really, really fast." then run away and don't buy the product. These are code words for "We've never tested our app under load. It will probably crash under 5 users and cost you hundreds of thousands to debug and repair. Not to mention millions of huge, wasted 8 processor sun boxen."

Of course, I'm being a little facetious, but I've seen this many times. A few years ago I was looking at an app where they assured us that the app had been load tested and benchmarked. That the app ran clustered great and could support thousands of users on cheap hardware. This sounded promising so I asked to see the reports. They said they would email them right over. It's now two years later and I haven't seen any reports. Thankfully, we didn't buy the app.

Note- It looks like Oracle made a failed bid to buy MySql. Their justification was that at least when their database was getting eroded by open source, it would be their open source. This rationale also applied to the (still undenied) rumors of the JBoss buyout.
  What if Oracle really buys JBoss?
So the whole world is buzzing that Oracle could buy JBoss. JBoss is not commenting, and oracle is mum too. We won't know until Oracle coughs up the cash and Fleury becomes an Oracle VP.

What I'm interested in is what will happen to JBoss, and to Oracle Application Server (OAS). A could years ago, Oracle had a particularly horrific app server (called OAS as well). They bought OrionServer's source, renamed it OC4J and released a much better Oracle internet Application Server (Oracle iAS) using OC4J as its J2EE core. With 10g they still use OC4J and have made tons of changes (and reverted to the "OAS" name). If you look at OC4J it's really nice and simple. Pure java, the install is an unzip/jar, and it runs everywhere you have a JRE. OAS, however, is sort of a big, bulky app server. It has lots of features and it much more complicated than just simple OC4J.

Currently JBoss is pretty cool and easy to use. My fear is that Oracle will replace OC4J in their app server with JBoss guts. So basically Oracle would sort of complicate up JBoss and make it harder to use.

Not to mention my fear that Oracle would cease development of the open source JBoss and only develop for their required support versions. But I think this would kill their reputation. And that would hurt in their push to compete with IBM and Sun as "open source" friendly companies.

But then acquiring JBoss could just be an effort to get any market share for their app server, which is getting butchered by WebSphere, WebLogic and JBoss.

I'm surprised that Microsoft isn't trying to buy JBoss so they can directly compete with the app server market with an app server that runs J2EE and .Net.

Oh yeah, happy valentine's day all you nerds and nerd-wives. It's a scam, but of all the scams around, not the worst.
  Debugging Java Threads
Back in my consulting days, I worked with a lot of guys who interviewed a lot. Once day this guy was telling of how he aced four rounds of interviewing to finally lose out because he knew nothing about Java threads.

It's possible to have a lucrative career in Java without ever dealing with threads. As long as you know how to use static and instance variables, the Java and J2EE APIs are pretty safe. But when you do have threading problems, it's a skill that you'll need to learn.

One way I experienced this wasn't in writing multi-Threaded apps, but in using third party frameworks and toolkits in my j2ee apps. Since everything goes into the ear, I'm redeploying to make changes. When I redeploy, the app server stops the application and then restarts it. Some thread based apps don't like being stopped properly. And of course it's a pain to track down the offending threads. So my app servers wouldn't shut down properly because of dangling threads.

A co-worker of mine recommended the very blandly named "StackTrace" tool from "Troubleshooting Tools For JavaTM" (no doubt named by the same team that came up with "Microsoft Office"). This tool is pretty useful for getting the thread dump of existing java processes. It's not OS, but you can get a free eval and can run it directly from their web site using their web start link.

After firing up this tool, it became pretty clear who the offending threads were and it was easy to patch them up. My particular problem was caused because the application was launching its own threads and setting them as non-daemon. This means the the jvm would wait for them to finish before exiting out. Usually, in a j2ee app, all launched threads (if you really must) should be set as daemon so if an admin tries to shut down the app server process, everything closes down cleanly.
  What are the SOA service categories?
The whole world jumped on SOA last year (or maybe it was 2004, AJAX was the ur-buzzword last year). But, it seems fairly evident that SOA is here to stay and is really useful.

I like a product by NextAxiom that lets you build and run web services very quickly.

But it's turning out that creating web services is harder than describing them to non-technical (or even technical) staff. Non-technicals hear "service" and kind of think of phone service or water service, or maybe an amorphous blob of code somewhere. Technicals hear "service" and think of OOP and components.

There's the common definition of a service as a "remotely invokable, discoverable function with validating inputs and outputs". Which is pretty vague. There are SOAP interfaces, but SOAP can come over HTTP, SMTP, JMS, anything really. But the benefit of services sort of sinks in the first time a service is reused from across the world with only a few minutes of looking it up and adding it to your flow/service.

At that point, businessies and techies spark up and want to use services.

That convoluted introduction brings me to my point: how can you categorize services? There is a pretty common term: "business service"- which is a coarse grained, well defined service that represents a business process. Business services aren't just CRUD, they represent the process from a business standpoint and the underlying technology is completely transparent.

But then what do you call those prevalent CRUD services that aren't pretty but get the job done? They are still valid, have a WSDL file out there somewhere and can be called over any protocols by any service consumers. But what do you call them? I'm at a loss because the distinction is important to service developers. Business services are perfect and can go into the UDDI (or whatever registry you favor), but these other ones are getting the job done but might have nasty interfaces that you don't really want your trading partners to know about.

So, any suggestions?
Technical and personal notes from Brian Lee, technologist/enterprise architect/software developer/soa guy.

February 2005 / March 2005 / April 2005 / May 2005 / June 2005 / July 2005 / August 2005 / September 2005 / October 2005 / November 2005 / December 2005 / January 2006 / February 2006 / March 2006 / April 2006 / May 2006 / June 2006 / August 2006 / September 2006 / October 2006 / November 2006 / December 2006 / January 2007 / May 2007 / June 2007 / August 2007 / September 2007 / October 2007 / April 2008 / July 2008 / January 2009 / May 2009 / June 2009 /
My Photo
Name: Brian Lee
Location: Atlanta, Georgia, United States


Powered by Blogger