<$BlogRSDUrl$>

Saturday, January 18, 2003

My latest wireless experience 

Just bought one of the new 802.11.G Linksys Wireless Routers and a corresponding network card for my laptop.

link on Amazon

I must say - its pretty cool.

I have noticed one annoying thing though. Everytime our cordless phone rings, I lose my network connection. We have 2 Panasonic 2.4 Ghz cordless phones in the house which operate on the same radio spectrum as does the 802.11.g standard.

All in all - I'm pleased though. On my current project - it takes about 40 minutes to do a complete rebuild + execute all of the build verification tests (load the database, deploy the newly built app, run the suite of junit tests).

I've found that I can now grab the latest from the CVS repository and then kick off one of these big mama builds (with the laptop downstairs in the main kitchen area). I can do my thing downstairs while still keeping tabs on the build...

Heck, I guess I could even take the laptop to the bathroom with me now.... Hmmm....


Friday, January 17, 2003

A little known law of Physics 

A little known law of Physics (that I seem rather fond of demonstrating):

"The more insignificant you think your change is, the more likely it is to break the build."

Imagine - You've just finished integrating your latest round of major changes. Its 2:50 AM, and after 30 minutes of waiting around, you proudly note that all 287 JUnit tests have successfully passed. You commit all of your changes and are just about to call it a night, when you see a silly little error that you could easily fix. What the heck, you make the change, verify it with a few Junit tests which pertain to that package, and commit the lone remaining file. You stumble off to bed and call it a night...

Of course you're tiny little change has had unforseen consequences on some other area and you've just doomed the forthcoming build.

You'd think I'd learn after a while...


JBoss 3.0.5 is out... 

Looks like it contains quite a few bugfixes :

Release notes

We had some wierd classloader exceptions with our JAAS stuff (had to serialize/de-serialize to get around them), perhaps this will fix it.

Woo-hoo, time to upgrade...


Layering Strategies in J2EE Systems: 

I wanted to take a poll on what people thought about layering strategies for J2EE systems. On my current project, we have been following the layering strategy outlined in the EJB Design Patterns book (see excerpt from our coding standards document below).

In a nutshell, for each service based component, we partition into the following layers (there are two others related to presentation or application layer things, but these are irrelevant to this discussion).

Do you guys try to maintain insulation of your domain layer from your services layers for J2EE systems??? We've come across several instances where it makes sense for the domain layer of one component to know about the services layer of another component. In some cases, we've even run across instances where it makes sense for a domain layer of Component A to know about the services layer of Component A (or at least to know about services that end up being exposed via its service layer)

This type of scenario makes me want to give in to the dark side and collapse the domain and services layer for that component into one layer.

Maybe this discussion hinges on the definition of the domain layer. We've tried to isolate as much of our business logic in our domain layer as possible. We're building a distributed system - in many cases the business logic for one component depends on a service provided by some sibling component (therein lies the rub).

BTW - you can get around the problem of "domain layer needing service layer" in a number of ways. For example : by defining interfaces in the domain layer that are implemented by classes in the service layer and using a factory to create them, but this really makes it seem like your jumping through a lot of hoops to hide the fact that your domain layer is dependent on your services layer (and using this solution, your domain layer code is still dependent on your service layer code at runtime). In this situation, wouldn't it make more sense to just collapse the two layers...?

I feel like we've expended a lot of effort to maintain this isolation, and am wondering if we haven't made things harder than they have to be. Here's an excerpt from the coding standards document on my current project:

Directory Structure and Build Outputs

We are following the layering strategy outlined in EJB Design Patterns (Marinescu, 2002). For details on this layering strategy, see chapters 6 and 7 from this book. For a free soft copy of this book, please see the following url :

http://www.theserverside.com/books/EJBDesignPatterns/index.jsp

In short, any component can be decomposed into the following layers :

NOTE: Not all components will requires each of these layers. For example, some components may have only a domain layer, many components will not have a presentation or application layer, etc. It would be common to see components with a persistence, domain and service layer.

For literal Java translation, we will use the following directory structure for layers which are included for a component :

ComponentX


Good Coding Music... 

Picked up the latest Paul Oakenfold CD a week or so ago - Bunnka. If you like techno - you'll like Oakenfold. He's the guy who did the SwordFish soundtrack. Its good coding music....

IDEA 

I love IDEA. Its an order of magnitude better than any other IDE I've ever used, and I really think it does a good job of attacking the accidental complexity associated with software development.

Its the only IDE I've ever seen that makes the hardcore emacs or VI guys give up emacs/VI in favor of an IDE.

My favorite refactorings are : "Move/Rename", "Delegate", "Introduce Variable", "Move Members Up", etc.

I'm a real stickler for names. Often times I'll create a new class, and I don't feel good about the name I give it (but can't think of a good one at that time). It'll sit there in the back of my head and bug me until I fix it. Finally, I'll think of a more appropriate name and then go change it (this used to take some time - I'd have to search for everywhere it was used, rename it, fix the places I missed, etc). Not so with IDEA. Shift-F6, give it the new name, and move on. IDEA does the rest.

IMHO - This is an example of reducing the accidental complexity associated with software development. IDEA really helps to let you concentrate on the problem at hand (without losing your train of thought). For example - you've got CTRL-B (go to definition) and CTRL-ALT-B (goto implementations). These are REAL timesavers. Another really great feature is the CTRL-Q feature (popup Javadoc for whatever it is you have your cursor on). Again - a perfect examploe of letting you keep you train of thought (instead of having to alt-tab out to a browser, go look for the link to XYZ class, etc).

ALT-F7 (Show Usages) is also indispensible.

If you're ever trying to understand what's going on in an open source tool like JBoss or Lucene, just create an IDEA project for it and start browsing. It makes my life so much easier. Thanks Intellij ;)

Speaking of IDEA - I wrote my first plugin the other day - its a plugin that will generate a new GUID and paste it at the current cursor location. Its available on the intellij.org plugins page (which has many extremely cool plugins) :

http://www.intellij.org/twiki/bin/view/Main/GenerateGuidPlugin


A great time... 

A regular occurence in my day: I read random people's blogs and I discover some new and very cool open source tool I didn't known about previously.

I've been employed as a full-time software development professional for about 6 years now (and did non-professional for about 4 years before that).

Though this is a profound statement of the obvious : the open source movement simply rocks.

I can think back to the first several projects I worked on after grad-school (back in '96 or so), and I don't think we used a single open source tool. Back then it seemed like I used to spend so much time just writing tools, building blocks, utilities, etc (none of which were ever open sourced, but many of which seemed to find there way along with me from project to project). I've always loved building horizontal, reusable stuff (probably more so than working on vertical customer specific logic).

What a stark contrast these days. There are so many wonderful open source tools and libraries at everyone's fingertips. Man that's great!!! I love Xerces and Xalan, Ant , JUnit, HttpUnit, and CruiseControl. Lucene simply rocks. Log4j is wonderful. JBoss has become my AppServer of choice. CVS, Bugzilla, Postgresql, MySQL, the list goes on and on.

These days - you can be up and running on a project so much quicker. You pick and choose the building blocks and tools you need, and then hit the ground running - concentrating on the specific problem at hand.

What a great time to be a software developer :)


Wednesday, January 15, 2003

Moved over to blogger... 

Gonna switch my Blog to this site, FreeRoller's getting hammered lately...

This page is powered by Blogger. Isn't yours?