cwash into software

Update: A great article on OSGi popped up on Javalobby today. Check it out.

I haven’t yet written any thoughts about OSGi but it’s something that’s increasingly found its way on to my radar over the past year and a half or so. I’ve been doing a little bit of reading and research on it lately, (a quick introduction can be found via Adrian Colyer’s talks on InfoQ about it). Needless to say it’s got me excited. Really excited – to the point where I’m catching myself geeking out uncontrollably like Quagmire from Family Guy. What’s got me all giggity? (continue reading…)

Update: Sysinternals puts out some great developer friendly tools. They come in handy!
Update #2: I’ve made the switch to using Launchy over DOMercury.

Working on Windows XP is unavoidable at my job. While it’s not my favorite environment, I’ve found a decent baseline of software tools to augment the barebones OS that can get me to a place where it isn’t that bad. Note, I’m not including any tools for doing off-development related things, anything development related that is on the web or any cool plugins for any of these programs.

Here is what I need, in roughly the order I download them: (continue reading…)

Dwight D. Eisenhower said “In preparing for battle I have always found that plans are useless, but planning is indispensable.” After reading Jason Yip’s No matter how many times you say it, we still don’t need a QA on the team, I started thinking about how similar this is to the correlation between (software) quality and exploring what software quality is. In the spirit of Jason’s article, thinking about how you “get quality right” will have more positive results for the sake of quality than searching out defects. So the question stands, how do you get quality right? I’m not sure there’s a cut and dry answer, but I have a feeling it’s in the details. I know it sounds anecdotal, but quality isn’t easy. It requires a lot of effort applied constantly. It requires reward and incentive, not punishment and fear. It’s caring about small things, and shifting how your team thinks, communicates and works together. (continue reading…)

I can’t believe it’s already December! I came across 24ways last year and thought it was a neat concept: an ‘advent calendar for web geeks’ – take a look! They had a pretty good variety last year and I’m expecting some good things this year.

I’ve been doing a lot of reading lately and have been meaning to plug some of my favorite reads, and one of the things that I’ve been trying to read with an eye toward is for converting those that have been stuck on “behind-the-curve” projects to the new way of thinking and doing things. As such, and just in time for the weekend, I’ve compiled a list of my favorites with an eye to the “movers and shakers” that have driven innovation in the Enterprise Java world recently. Note that even though some of these links are specific to certain frameworks/technologies, there is a common thread throughout most of these that have a bigger focus on the best way to solve problems using Java 5/EE 5 constructs and concepts.

A book that should be on any Java developer’s shelf is Effective Java (2nd Edition). Make sure you get the second edition, for all of the Java 5 changes. This talk by Joshua should whet your appetite. (His talk on good API design is also very good.) You should also take a look at Bob Lee’s talk on Guice. Guice’s philosophy and focus on typesafety has spilled over into Web Beans (and newer versions of Seam) and its annotation based approach has heavily influenced newer Spring features. I especially like his points on type safety around the 11-minute mark. The walkthrough at the end of the talk from “old way” to “new way” is great for people who haven’t really gotten away from Factories, Delegates, and Service Locators yet.

The Guice video mentions that a common thread in modern Java frameworks is a focus on testability. Testing is a very important concept that nearly all new frameworks have embraced, but you still need know-how to be successful with testing. I’ve come across some great books recently in the automated (developer) testing arena. I’ve found the most thorough book on the topic out there is Lasse Koskela’s Test Driven. The ideas and topics discussed in the book are really language independent, and work equally well with other languages. To cut your teeth on TestNG, which the Seam documentation turned me onto, I recommend the TestNG developers’ book Next Generation Java Testing: TestNG and Advanced Concepts. Cedric Beust, also the author of EJBGen, and Hani Suleiman, author of the Bile Blog, produced a book that was a suprisingly good read. It’s packed with a lot of knowledge and some interesting takes on EE concepts. Newer versions of JUnit also include many of these features and concepts, so you’ll get the underpinnings of these concepts in this book. This video gives you a basis to TestNG’s approach.

As one of the growing number of developers who have an application in the Seam In Production page, there are a few Seam resources I have to share. Even if you don’t get into Seam, it should be on your radar because a lot of the core concepts around conversations have evolved into Web Beans, and are found other frameworks like Apache Orchestra and Spring WebFlow. Pete Muir did a Webcast that’s a great introduction to Seam 2.

Author of one of my favorite Seam blogs, Jacob Orshalick, has created a DZone RefCard for Seam 2.1 Core. It’s right off the presses, being published this week, but is a great quick-capsule review of what Seam can do for you, and nice to have on your desk if you’re writing Seam. If you need more in-depth descriptions of what’s on the RefCard, Jacob also coauthored the latest edition of the great Seam reference Seam Framework: Experience the Evolution of Java EE.
Dan Allen’s Seam in Action is another excellent resource. Of course, the awesome Seam Docs and Forums always come in handy. You should also RSS in.relation.to – the Hibernate/Seam developers’ group blog.

I know I’m leaving some great things out. What resources do you think someone who is used to J2EE should take a look at to get them “up to speed” with the state of the art?

If you’ve checked out my blogroll, you’ll notice I have a link to Basil Vandegriend’s “Professional Software Development” blog.  I like a lot of the articles he has written and to a large extent the subject matter I envision for this blog frequently crisscrosses with Basil’s.

While I was reading “The Reuse Trap In Software Design” I found myself thinking,”Me too! Me too!” like a giddy kid on the playground that’s found a new pal with a mutual interest in “pet snakes and/or tarantulas.”  As with many of the problems Basil writes about in his blog, I experienced the same problem, investigated it and found the same root causes, and came to many of the same conclusions as those outlined.  He describes the “reuse trap” as:

…[A] term I coined to describe the situation when one becomes stuck trying to design new functionality while simultaneously attempting to reuse existing code that needs some modifications.

He then goes on to describe why it’s a tough problem for n00bs and outlines a strategy he uses to get out of the trap–one that’s best described as a two-step process: copy-paste to reuse/refactoring to remove duplication.  I encourage you to read his article if you’re not familiar with the terms, or how this strategy can solve the problem described above.

My preferred technique for mitigating the problems involved isn’t copy-paste reuse/refactoring; it’s stubbing the calls to the code-to-be-reused (C2BR) that needs modification.  If I can fake out the behavior I need, it lets me focus on the nature of the dependency that exists between the two objects/components.  When I go to modify the C2BR, my inputs and outputs (or other consequences that occur as a result of a call to the C2BR) translate directly into a test that I can use to drive the changes I make to that code.  It also ensures that the coupling that exists between the objects is loose and legit.

The only thing to watch out for is that care must be taken to then remove the (small) duplication of the stubbed out inputs/outputs and actually wire the two pieces together when finished with the reused code.  I usually do that by throwing a TODO:WIRE marker in when I stub something.

I’ve found this is the approach I take more often, though I do take the copy-paste reuse/refactoring route from time to time.  This stub/rewire approach is a bit more advanced, but it’s how I envisioned solving the “reuse trap” when, as Basil puts it, “I became aware of it” and all that it entailed.

Do you ever come across this problem?  How do you get out of this “trap” or avoid being caught up in it in the first place?

Tired of messy logging logic cluttering your code with a bunch of if/else statements? Don’t let logging cramp your style! The approach Seam takes to logging makes your code pretty again (and other things). What does this mean for you? No more “code guards“!

A nice byproduct of the genius of Seam’s design is that many common problems can be solved by using EL as veritable swiss-army knife. We’ll look at this through a logging example specifically, though it’s just one of many different innovative ways of solving problems using Java5 features and EL as a general approach.

WTF is a code guard?

What goes without saying in most of the discussions regarding logging is that excessive logging can be the largest and most common performance bottleneck in code that meets its functional requirements. Thus, logging APIs introduce the idea of log levels, to ease the burden of excessive logging. Generally, log levels are a configuration setting on a per-environment basis. Development environments will typically log most dependent code at the info level, and cut that up to the debug level for custom code or when things go awry with a piece of dependent code. Testing environments typically log at info while production will often just log at the warn level.

While this is all well and good, we find that for a lot of the logging we do, we typically run across an ugly little flaw in this approach that’s produced an equally ugly hack as a work-around. Enter the code guard. From the log4j docs:

Code guards are typically used to guard code that only needs to execute in support of logging, that otherwise introduces undesirable runtime overhead in the general case (logging disabled). Examples are multiple parameters, or expressions (e.g. string + ” more”) for parameters. Use the guard methods of the form log.is<Priority>() to verify that logging should be performed, before incurring the overhead of the logging method call. Yes, the logging methods will perform the same check, but only after resolving parameters.

What’s all this business about resolving parameters? Let’s look at an example:

So, we need this cluttered if/else around only to ensure that our expressions (concats, usually) won’t get resolved unless we actually want them to. Why is there no other recourse? The answer isn’t surprising – it comes down to the way the API was designed. All log4j logging methods take a single argument — which made a lot of sense, I suppose when the powers that be first designed logging APIs. They soon realized that in order to use their API, one has to use an expression to resolve all parameters into a single argument prior to calling the method! This is why a code guard is needed.

Java5 introduces a feature that allows for varargs, and taking advantage of this can help us with our ugly little logging problem, e.g.

With this approach, our expressions won’t get resolved until after we’re in debug(), and we can let it do the dirty work inside the method. The first thing that our logging method does is check to see if its level is valid, otherwise it’ll fall out immediately. Because the concatenation happens inside the log method, we don’t need a code guard to protect us.

This is the approach that Seam takes to logging. Seam’s Log interface provides not only a solution that removes the need for code guards, it also allows you to use EL in your log messages (if you’re trying to dive into a Seam component…) – e.g.

Much better. By and large, this is the way you do logging in Seam. Because binding occurs late, you never really run into the problem where you need to even think about using something like a “code guard.” Code what you’re supposed to; not noise! This is just one of many novel ways to use EL in Seam, and why it really deserves a look as a way to write better code, faster and as a far more productive platform for Java programmers (fed up with JavaSE/EE 1.4) than Rails/Grails.

See the Web Beans Manifesto for much more on this approach.