Web Application Data Access Patterns: Keith Donald

Well, after a short hiatus of getting back to "real" work, I'm going to attempt to squeeze in another Spring Experience 2007 entry. This particular session was my first of Friday morning. I've always enjoyed Keith Donald as a speaker, having first heard him at TheServerSide.com's Java In Action conference in 2005, and again during his Java University session at JavaOne 2007.

Keith began with a discussion of why we need patterns. In his opinion, patterns simply provide a way of thinking about a particular approach to a problem. One could liken them to blueprints. They typically have a name, a description of the problem being solved, a description of the solution approach, and finally a selection of implementation guidelines and considerations. Pretty nice summation.

The particular patterns that Keith planned to discuss surrounded the different data access patterns typically found in web applications.

Keith began by discussing the "Unit of Work" pattern, which he defined as a unit of interaction with a shared resource that executes independently of other units. These interactions exhibit ACID properties, and a database transaction provides a typical example. In the context of an ORM such as Hibernate, a Unit of Work tracks changes to the object graph during a transaction and then synchronizes those changes with the database when the transaction is complete. Keith followed this discussion with an implementation example from his "Reward Network" sample application.

Keith followed this discussion with two of what I'll call "subpatterns" of the Unit of Work pattern: Pessimistic and Optimistic Locking. With pessimistic locking, you prevent other units from accessing your data during a given unit of work, and then release the "lock" as soon as possible. This locking is performed to prevent a race condition, resulting in an inconsistent state in your model. Keith briefly illustrated implementation of pessimistic locking with Hibernate.

It's always interesting when someone asks a slightly off-topic question which ends up in a take home gem of information. At this point, someone asked if the implementations that Keith was showing showcased Spring's Hibernate support. To this Keith surprised me by answering (and I paraphrase), "Hibernate's native API's are much more mature and powerful now, so we recommend you use those rather than Spring's Hibernate API wrapper. Why add another dependency?" He then proceeded to recommend Rossen Stoyanchev's Saturday morning session on "Working with Hibernate in a Spring 2.5 Environment" (blog entry to come later!). One of the better quotes of the conference came during this aside as well:

Whenever you can eliminate a dependency, you should.
- Keith Donald

Well, back to the presentation. Keith then moved into a discussion of Optimistic Locking. Here, within a business transaction that executes across a series of system transactions, you use optimistic locking to prevent corruption of shared data. An examples is where several users can edit account information concurrently, but the frequency of concurrent access is fairly low. Data integrity is still at risk, so you use optimistic locking to handle those infrequent cases. Keith them demonstrated the use of Hibernate versioning to implement optimistic locking.

Keith next moved into a discussion of the controversial "Open Session in View" pattern. This is a specialized technical pattern where by the Hibernate session is kept open for the duration of a given web request. It is generally used as a "quick fix" to prevent lazy loading exceptions in the view tier. This is generally considered a bad thing, as you end up with a great deal of "N+1 Select" situations while rendering the view, resulting in way too much SQL executed against the database. Typically, the need to use this pattern reveals a flaw in the design of your model or queries. For example, since you generally know how far in the object graph you'll need to go for a specific view, you should load those relationships eagerly for that use case. You may also consider whether or not a given object association is appropriate to begin with.

The final major pattern that Keith discussed was the "Conversational Persistence Context" pattern that is present in the upcoming Spring Web Flow 2.0 release. It is essentially a more flexible variation of the Open Session in View pattern, where by you can have an open session spanning multiple requests during a long-running user interaction context, or "conversation." To be perfectly honest, I still don't quite "get" this pattern beyond that, probably because I don't know much about Web Flow or it's cousins (e.g. Seam, Web Beans JSR-299).

Keith closed with a very brief description of Master Detail, where you show an overview of objects in a collection and then allow drilling down into object details, and Paging, where you allow users to easily browse through a list of items of interest. I raised a point of contention with Keith at this point. His example implementation showed delegation of the paging concern to the DAO layer, rather than implementing that concern in the View layer. When I asked him where he thought it belonged, he thought it was obvious that it belonged in the DAO layer. I then let on that we had this debate in our team and decided the the concern belonged in the View layer. Why should I run the same query multiple times just to page through the data? Why not load the entire data set and then let the View tier decide how to page through it? Keith gracefully acknowledged my point.

All in all, this was a great session, if for no other reason than it reminded me of some best practices in this area and let me in on the little secret about using native Hibernate API's rather than Spring's Hibernate template. Nice job, Keith.

Goodbye Spring Experience 2007!

Well it had to end eventually. As you can see, I'm hopelessly behind on my blog entries, having only made it through my first day of sessions. I've still got several more I intend to cover (I probably won't do the last two as I started blanking out - I think my brain was pretty much melted by this afternoon). Look for those entries in the coming days. Many thanks go out to No Fluff Just Stuff and SpringSource for putting on an awesome conference!

There were several things I really liked about this conference that I believe set it apart from most of the conferences that I have attended.

  1. The technical content was top-notch - Spring topics from the developers themselves. There were also quite a few architecture/design sessions that were also superb.
  2. The session length, at 90 minutes, provided ample time to cover each topic pretty well in-depth. The session scope cooperated with this, as most of the speakers didn't try to do too broad of subjects for the time allotted.
  3. It was a smaller conference, at a little over 500 developers. This meant you weren't trying to weave through crowds to get in queues for packed out sessions like at JavaOne. Much less stressful.
  4. The atmosphere was just plain fun. Everyone was laid back. I mean, how many conferences give you a bobblehead doll on the first night! I now issue a call out to Sun that we must have a James Gosling bobblehead doll issued to every attendee at JavaOne 2008!
  5. The food was top notch - every meal was provided, buffet-style (no boxes!!!). I ate way too much.
  6. The location was great. You can't beat a front-on view of the Atlantic Ocean from the conference center balcony during session breaks.
  7. SWAG! Let's see what all I collected: a computer bag, a binder with all of the slides, two t-shirts, a hat, sunglasses, a beach towel, a Frisbee, a NFJS Anthology, a bobblehead doll, a Spring Source toolkit (two screwdrivers and a measuring tape - you'd have to see it)...what's more, Jay Zimmerman distributed the left-over swag after the conference closed. I picked up two more computer bags full of swag and two conference binders to give away at the January and February Memphis JUG meetings!
Once again, thanks for a great conference. It was easily the best all-around that I've attended.

The State of the Art in Dependency Injection: Rod Johnson

This was a truly fascinating talk. If you ever wanted to learn the entire history and landscape of dependency injection (DI), this was your opportunity. I really didn't realize how deep of a topic DI really is.

According to Rod, DI had its beginnings in 2002, in the Interface 21 Framework that was born from his seminal work, Expert One-on-One J2EE Design and Development. In the beginning, DI was done solely through setter injection (SI), with external metadata (usually in XML). 2003 gave us Spring 0.9, which had the same DI model, but added FactoryBeans for indirection and proxy-based AOP (enabling among other things, declarative transaction management). With Spring, DI was always just one enabler of a complete enterprise solution. Contrast that with PicoContainer, also arriving on the scene in 2003, which was an ultra-lightweight DI-only container. PicoContainer brought us several innovations, including constructor injection, automatic resolution by type, and an attempt to dispense with external configuration.

Rod then discussed the Pros and Cons of Constructor Injection (CI). On the Pro side, we see that CI is great for immutable objects, can be used with existing code, enforces that the necessary dependencies are provided at object construction, and allows developers to dispense with methods like afterPropertiesSet(). On the Con side, there are no default arguments in Java, which forces us to ALWAYS provide all of the necessary dependencies, constructor overriding can be somewhat messy, and constructor argument names are not usually available through reflection, which forces us to depend on argument order for dependency resolution.

Spring 1.0, which arrived in late 2003, incorporated some of PicoContainer's innovation: CI, "Autowiring" by type and by name, as well as the ability to mix CI and SI. Here Rod reflected on Spring's pragmatic philosophy, whereby they are more than willing to incorporate the good ideas that others had first.

Spring 1.1 brought us method injection, a unique Spring feature, which solved the problem of long-lived managed objects which depend on short-lived objects. It also brought us Factory Methods. You now had the ability to create objects through invoking static factory methods or instance methods on other beans.

With the finalization of the EJB 3.0 standard in May 2006, several new ideas became available in the world of DI: annotation-based DI, annotations for callback methods (e.g. @PostConstruct), scanning for annotations without any external configuration needed for a deployment unit, and field injection (FI). These EJB standard brought with it a new philosophy - that annotations are a superior model and that externalization should be a second-class citizen. The Pros of this standard? One big one - no configuration is necessary for simple cases. The Cons? Rod listed several: resources could only be injected from JNDI, no CI, limited control over object lifecycle, unsuitability for fine-grained object graphs, effectively usable ONLY with annotations, as the XML configuration option is so verbose, and it isn't just DI - it brings along with it enforcement of many obsolete EJB concepts (such as bean instance pooling).

Spring 2.0 arrived in late 2005 with its own share of innovations: integration with AspectJ, the ability to inject anything with an AspectJ aspect via @Configurable, namespaces to provide an XML-based DSL for external configuration, the @Required annotation, and pluggable scopes to manage the object lifecycle. About that same time, JBoss Seam introduced many strange ideas (that I didn't quite grasp from Rod's explanation): bijection, outjection, and subversion of control.

Some additional players on the field include Spring Java Config, which is a DSL for configuration in Java, Google Guice 1.0, and the JSR-299 Web Beans spec, which Rod described as "blogware" in that there is currently no available implementation.

Finally we got to Spring 2.5, released last month. Rod didn't have his slides printed or available on the web (argh!), so about this time my hand was really hurting from taking furious notes, and I simply gave up. Fortunately, most of what Rod covered was redundant from some of the other sessions, so I'll have or will blog about it later. About the only thing I really don't have good notes on is Spring Java Config, which he discussed pretty extensively. If you want to learn more about it, check out http://www.springframework.org/javaconfig.

Ajax Integration Guide for 2008: Jeremy Grelle

This talk looked really exciting going in. Jeremy is a member of the Spring Web Products team and the lead of Spring Faces, as well as a member of the JSF 2.0 Expert Group. He describes himself as the resident Ajax freak at SpringSource. Jeremy began by discussing the current Ajax landscape, highlighting what he believes are the important features a successful framework must deliver, and then identifying the frameworks he considers to be the cream of the crop. No surprises here on the list: Prototype/Scriptaculous, jQuery, YUI, Ext, and Dojo. He then gave a brief high-level overview of each framework - I really didn't learn anything new here, as I've been following these frameworks for quite awhile. He mentioned the commonality that all of these frameworks are about more than asynchronous client-server communication - they're about improving your client-side code and user experience. See Dion's May 2007 comment that Ajax "was never about the acronym - it's about building killer websites." What is good about all of these frameworks is that you can use all of them in an unobtrusive manner and progressively enhance your UI. This gives you the ability to only Ajaxify what you need and also get graceful degradation.

In the second portion of his talk, Jeremy talked about connecting to Spring. I was really hoping that the "goods" would be delivered here. He started by mentioning DWR, which I think is a really nice framework. It merited 2 slides and no demo (even though there was a slide mentioning a demo). I don't think Jeremy really cares for it or GWT, as he sort of lumped them together and didn't mention them again. I do appreciate his point that neither really allows you to harvest any existing controlling infrastructure that we may have built using Spring MVC or another framework.

Jeremy then moved into what he considers the better way to do it, which is the progressive enhancement I mentioned above. He took the existing Spring Booking MVC + Web Flow example application and ajaxified portions of it. He did this using an interesting combination of Apache Tiles, some Javascript "pseudo-AOP" he lifted from the SpringFaces project, and a bit of Dojo. It seemed to work really well, but it wasn't immediately clear how this type of technology was going to be made available to us as developers. He said something along the lines of "you don't have to be using JSF to use this Javascript, so we probably need to change the name to something else." I hope they figure out soon so I can get my hands on it. :-)

He closed by briefly discussing REST's place in the future of Spring Web. The ideal scenario, according to Jeremy, is that we will be able to request different representations of the same resource. For example, we could request HTML for full page display or partial DOM updates, and JSON for intelligent widgets like the Dojo table.

It looks like a lot of exciting things will happen in 2008. I hope I don't have to wait too long.

What's New in Spring 2.5? : Juergen Hoeller

This was my second talk of TSE 2007. I have to admit I chose it by process of elimination - none of the second session talks particularly jumped out and grabbed me like Chris Richardson's talk.

Juergen is the project lead for the Spring Framework, so he was the obvious choice to give this talk. Juergen split it up into three sections:

  1. Platforms
  2. Annotation Configuration
  3. AspectJ Support
To break down part one as quickly as possible, Spring supports virtually EVERYTHING. You get JDK 1.4 all the way to Java 6, including all of the new API's in Java 6. It fully supports Java EE 5 while remaining backward compatible all the way to J2EE 1.3. You can now deploy a Spring ApplicationContext as a RAR file, and you also get full JCA 1.5 support (if you want to know what that means, don't ask me :-)). Quite notable was the fact that they have worked with IBM to support WebSphere's proprietary transaction manager. Also interesting was Spring's continuing strong support for OSGi as an alternative enterprise runtime.

The annotation configuration part of the talk was quite fascinating. I'm something of an annotations junkie - I have to be careful about that. At any rate, it was so good that I was interested enough to attend Juergen and Mark Fisher's later talk that was completely dedicated to the subject. I'll leave the details for my entry on that talk.

The final portion, on AspectJ support, was equally fascinating. The first new feature was the ability to advise specific beans by name rather than by type using AspectJ. This was made even sweeter by the fact that you can use pattern matching in your definition. Very exciting was the ability to do AspectJ load-time weaving, meaning you can use the power of AspectJ at runtime without involving the AspectJ compiler. Unfortunately, this isn't available across all appservers. I didn't get a chance to ask and comfirm, but it seems that JBoss (our primary appserver) does not support this. GlassFish, Weblogic, OC4J, and Tomcat were all mentioned as being able to handle it.

The most interesting part of this talk for me was the ability to annotate a class as @Configurable, and then do dependency injection on it even thought it isn't managed by Spring. You could do this in Spring 2.0, but you had to use the AspectJ compiler. Now, with load-time weaving, you can do this at runtime! I really could have used this recently when I wanted to inject a single dependency into a class that was really overkill to manage as a Spring bean. Since I'm using Spring 2.5 in this project, I can go back and try this feature. Exciting!

Pair Programming with the Official Rod Johnson Bobblehead

As you can see, Rod really likes my Spring MVC configuration. :-)

Improving Application Design with a Rich Domain Model: Chris Richardson

This was my very first session of the conference. I've really been looking forward to it. I became pretty excited about object-oriented programming when I first really learned it in my computer simulation course at Ole Miss. In that course we built discrete event simulation programs using collaborating Java threads. Each thread implemented an object from the domain model representing a particular simulation problem. Once I got into the "working world," I found that the architecture described by Rod Johnson as the "J2EE stove pipe" had made my OO skills essentially unusable in the projects on which I was required to work on a day-to-day basis. My recent experiences developing in a more POJO-based style, particularly with JPA/Hibernate, have allowed me to get closer to my preferred OO-style, but the business logic still lived in the service-tier. My domain model was still essentially "anemic" to borrow from Martin Fowler.

When I read the description for this session I was elated! Finally I could see that someone was building real enterprise applications using object-oriented techniques! I've never quite been able to articulate what I felt was wrong with the way we're building applications in my group. I was fortunate enough to have breakfast with Chris Richardson prior to the session, and he said that addressing my inability to articulate those problems was one of the goals of his talk. Awesome! On to the session...

Chris began with a tour through his object-based programming experience, beginning in LISP, followed by C++ and then Java. Around 1999 he got into EJB programming, and described his experience as "Applications were still built from objects, but those objects were very different..." Basically the EJB paradigm caused us to abandon object-oriented programming in favor of procedural programming. Why? Well, for all of the pros surrounding EJB, it made writing object-oriented code difficult, and in some cases, impossible. The EJB/procedural style works very well for simple business logic, but it doesn't scale well as business logic becomes more complex. The result is a few monolithic transactional classes containing hundreds to thousands of lines of code embedded in very long methods. Hence, the legacy of EJB (and I quote):

  • Java is an object-oriented language, AND...
  • Object-oriented design is a better way to tackle complexity, YET...
  • Many complex enterprise Java applications are written in a procedural style
Chris then moved on to discuss the rich domain model pattern, which is really nothing new at all. It's just good OO design. Most of your classes (or entities) correspond to real world concepts, and the business logic is spread amongst them. Classes are true objects: they contain state and behavior. The goal is to push as much business logic as possible down into the domain objects, which is exactly where it belongs. What do you get? Better maintainability, better testability, better reusability, and a better shared understanding of your domain. Not only that, but your code is quantifiably simpler! Who doesn't want that? The main drawback to this is that you have to have good OO design skills to make it happen - which is exactly what the EJB programming model has made scarce.

Chris followed this up by discussing the building blocks of domain models, concepts he derived from Eric Evans' book Domain Driven Design. In a nutshell, they are Entities, Value Objects, Aggregates, Services, Factories, and Repositories - the reader can get the book to find out what these are. Interesting notes for me include the fact that Repositories are nearly equivalent to DAO's, especially the way I typically implement them. The concept of a Service is far different from what I'm used to. I "grew up" writing services according to the EJB Session Bean/Facade model, where essentially all of your business logic resides in service methods. Chris defined a service as a class implementing only logic that cannot be put in a single entity. They are actually quite thin!

Next came the discussion of frameworks and their role. In short, frameworks act as an enabler to rich domain models when used properly. Your domain model should be implemented purely as Plain Old Java Objects (POJO's) in that they don't implement any infrastructure interfaces or call infrastructure API's. The jury is still out on annotations - Chris argues that they still violate the POJO concept, I'm not so sure. You then wire your model together using dependency injection, handle crosscutting concerns (transaction management, security, logging, etc.) with Aspect-Oriented Programming (AOP), and use object/relational mapping (ORM) for persistence. What you often run into as obstacles are that many of these frameworks, particularly web and ORM frameworks, force you to introduce "smells" into your code for the framework to use them. Examples include requirements for public default constructors and JavaBean-style setters.

Chris closed with an awesome discussion of common code smells and the refactorings used to eliminate them. I was most interested in Feature Envy, which is where you have methods that are far too interested in data belonging to other classes. This is very common in session facades, and the healing factor is to push that logic down into the appropriate domain classes. Another interesting smell was Primitive Obsession, where code uses built-in types (such as String and Integer) instead of application classes to represent state. The refactoring in this case is to introduce Value Objects, which are immutable, validated objects representing domain concepts (e.g. a shipping address).

Chris closed with the charge to begin refactoring our procedural designs into a rich domain model on MONDAY! Oh, how I can't wait to begin. Good job Chris!

Enterprise Java and the Changing of the Guard

Greetings from The Spring Experience 2007 in Hollywood, FL. So far this has been a great conference - I'm currently waiting for my third session of the day to start. As much as I enjoy all of the hype and eye candy at JavaOne, I really get a lot more out of these smaller conferences as you're not running around stressed out trying to weave through thousands of geeks as you move from session to session (or more accurately, from session to queue!).

I wanted to post a few insights that I gained from Rod Johnson's keynote last night (the title of this entry). The basis for Rod's presentation was a Gartner report entitled "Trends in Platform Middleware: Disruption Is in Sight." To summarize, there are many converging forces in the enterprise Java space that are causing or will probably cause a great deal of disruption in the way we develop enterprise Java applications. These forces include our collective experience with application servers, the rediscovery of object-oriented or POJO-based programming, open source innovation, non-Java challengers (.NET, RoR), the rise of SOA, and Rich Internet Applications. Rod sees a big movement from the "old guard," which he described as the "J2EE Stovepipe Architecture" which was based primarily around the idea of distributed objects, to a world in which many of the highest volume Java applications don't even use a Java EE application server. An interesting point was the stagnation in job requirements for the big name application servers coupled with the BZ Research statistic that 64% of Java application developers are using Tomcat for production deployment. Yet another force for disruption is the emergence of OSGi, which allows developers to modularize applications and provides facilities for versioned components, fine-grained redeployment, and library conflict resolution - all features that Java EE currently does not and perhaps cannot address. Open source provides yet more disruption, as developers have become participants in rather than spectators of the development of Java enterprise solutions. Innovation is now primarily coming from the open source world. All of this culminated in the rather telegraphed conclusion that Rod (and also the Gartner report apparently) believes that Spring is uniquely positioned to provide the best value for ongoing Enterprise Java development in the face of the current trends. Of course, what would you expect him to say? :-)

I do tend to agree with him. The pace at which Spring is innovating and addressing the Java enterprise pain points far outpaces the pace of the JCP. It just takes too long to design specs by committee. One of the more wise things that Spring does is to learn from and in most cases accommodate the changing landscape of Java EE and integrate the best features directly into the framework. I for one am glad to be developing applications with Spring, as it makes it very easy to do the things I want to do and write quality code that isn't directly dependent on an infrastructure framework. Generally, it stays out of my way.

More to come on the sessions I've attended thus far.


Here's my vote for Java 6 on Mac OS X Leopard!


Ajax Construction Kit: Building Plug-and-Play Ajax Applications

My first book review for Javalobby was published today!

Please support me in the 2007 Walk to Cure Diabetes

This year, I'll be taking part in JDRF's Walk to Cure Diabetes, along with one-half million other walkers across the country, as we try to reach our goal of raising $90 million.

Type 1, or juvenile, diabetes, is a devastating disease that affects millions of people - a large and growing percentage of them children. One of them is my oldest daughter, Abby, who is three years old.

Since Abby's diagnosis, she's had her fingers pricked over 800 times already. She's received more than 200 shots in her arms, legs, and tummy. Over the course of her life, she'll continue to receive daily insulin injections and finger pricks. She must take insulin to stay alive. We must constantly monitor her glucose levels to ward off complications such as blindness, kidney failure, and stroke. Abby must maintain strict control of her diet every day (even on birthdays and holidays), check her blood sugar at least 6 times a day, and take insulin at least twice a day.

There is some good news, though. For the first time, scientists are predicting that we CAN expect to see a cure well within our lifetime! This is exactly what we're wishing for, so we've formed a team called "Wishing With Abby," and we'd love to have your help.

Please visit my Walk Web page if you would like to donate online or see how close I am to
reaching my personal goal:


Follow this link to make a donation:


Welcome to Matt's Mac Paradise

I've been wanting to post a picture of my new work setup for awhile, but I wanted to wait until I finished getting setup over at 160 Shadyac Avenue. Just for fun, I thought I'd go VMWare Fusion crazy and boot up every virtual machine I've got - you're actually looking at 7 OS's booted concurrently between two machines. To the left I've got my 15" MacBook Pro (2.2 GHz Intel Core 2 Duo processor, 4 GB 667 MHz DDR2 SDRAM) running Mac OS 10.4, Windows XP, and Ubuntu. To the right I've got my Mac Pro tower (2 x 2 GHz Dual-Core Intel Xeon processors, 5 GB 66 MHz DDR2 FB-DIMM RAM) driving the dual 19" Dell LCD's, running Mac OS 10.4, Windows XP, Ubuntu, and Solaris Express. Whew - that was a mouthful. Thanks to Matt Raible for blogging about the Griffin Technologies iCurve laptop stand - I picked up its successor, the Elevator, for my MacBook Pro. I've got pictures from my past desktops over the years - I need to dig them up and show the procession of developer technology here. It's been quite a ride from my first system as a junior developer six plus years ago.
Posted by Picasa

Haven't had much time to blog lately....

....because we've been packing to move on top of all of our regular projects. St. Jude has nicely renovated a new building for us, so we developers are moving. This is where I'm headed on Monday:

I'm both loving it and a little sad - I've been sitting in my desk for nearly my entire career as a software developer. I just know I'm going to park in the garage and come downstairs one morning to find my office gone. :-)

STJUDE-SRM 1.0 Released

From http://sourceforge.net/forum/forum.php?forum_id=719803:

On July 27, 2007, STJUDE-SRM 1.0 was released.

STJUDE-SRM is a laboratory management system designed to support shared resource facility (or core lab) activities. It was designed and developed by the Hartwell Center for Bioinformatics and Biotechnology at St. Jude Children's Research Hospital.

Shared resources supported include DNA synthesis, Peptide synthesis, DNA sequencing, Functional Genomics (spotted microarray laboratory), and Affymetrix (commercial microarrays) laboratories. STJUDE-SRM was also designed so that it is sufficiently modular and scalable to support other laboratory activities as needed. It could conceivably support all facilities on a campus or at a research organization and provide a single portal for investigators to access these resources, retrieve data, receive invoices for services, and generate reports.

Currently available is a build of STJUDE-SRM which is certified for JBoss 4.2.0.GA running on J2SE 5.0. Builds for JBoss 4.0.5.GA and BEA Weblogic Server 8.1 are forthcoming.

STJUDE-SRM 1.0 can be downloaded here: http://sourceforge.net/project/showfiles.php?group_id=197795

Please report all bugs you find in the STJUDE-SRM bug tracker: http://sourceforge.net/tracker/?group_id=197795&atid=962898

This is a VERY satisfying announcement for me, as I have spent the better part of the last six years working on this project. I was so excited when I learned we would be releasing it to the open source community. Enjoy!

For more information on STJUDE-SRM, please visit: http://stjude-srm.sourceforge.net.

My Professional Development Goals for 2007-2008

I posted earlier on my desire to become a better programmer. Well, I've since put together a plan of action for the next twelve months. I've based some of these goals on suggestions from The Pragmatic Programmer by Andy Hunt and Dave Thomas.

  1. Learn Groovy and Grails

    Andy and Dave suggest learning a new language every year. I had already informally started learning Groovy and Grails after JavaOne 2007. Since I already have a head start on this one, Groovy will be my language for the next year (I'm learning Grails mainly because of my web development background - it will provide me more opportunity to apply my Groovy knowledge). This should be an easy way to get started on the goal of a new language each year since my Java knowledge should transfer easily.

  2. Release HallKeeper v1.0 as part of #1

    Several years ago I started an open source project called HallKeeper. HallKeeper is planned to be a web-based management system for university residence halls. Life got in the way of this project so it lay dormant for a few years. I've recently revived it as sort of a "lab" in which to learn Groovy and Grails, and hopefully have a little fun along the way.

  3. Read and LEARN the following books:

    • The Definitive Guide to Grails - Rocher
    • The Pragmatic Programmer - Hunt, Thomas
    • Computer Algorithms: Introduction to Design & Analysis - Baase, Van Gelder
    • Concepts of Programming Languages: Sebesta
    • Groovy in Action - Konig

    When I say LEARN, I mean I don't just want to do a cursory read of these. I want to really engage the concepts presented in each and apply them to my day-to-day work. I already have a head start reading the first two books. The third and fourth books are actually textbooks from my undergraduate education. I could really use a refresher on these concepts, and I think I'm a much more serious student now as a professional than I was when I was actually a student.

  4. Review two books for the JavaLobby/DZone book review team

    I joined this team several months ago and was actually assigned to review two books - again, life got in the way (if you have any small children, you'll understand). Things have settled down a bit now and I've asked to rejoin. Hopefully I'll be able to crank out some reviews this time and learn something in the process.

  5. Pass the Sun Certified Programmer for the Java 2 Platform, Standard Edition 5.0 Exam

    I want to do this mainly to give myself an excuse to go back over the fundamentals of Java, as well as learn the new features that 5.0 brought to the table in detail (generics, annotations, etc.). I have still basically been living in a Java 1.4 world as I'd say roughly 85% of my daily work is on an application that is still bound to that JDK. So, passing this is mainly just a reason to study, and it is a nice edition to the resume as well.

  6. Write one Java/software development blog article per week

    This would be numero uno! I've always stressed about the frequency of my blog writing - I've felt compelled to write every single day, and I usually end up writing a one paragraph synopsis of some other guy's blog entry. Not exactly something that will attract many readers. I'll still post those on a more frequent basis as they keep the content flowing, but I also want to write at least one in-depth article per week to give people something to look forward to. One way I'll do this is to blog about the books I'm reading. The Pragmatic Programmer provides challenges and/or exercises at the end of each chapter - great seeds for entries.

  7. Attend JavaOne 2008 or similar conference

    This one depends on the boss - hopefully I'll get to travel again this year. I'd love to go back to JavaOne - I learned a lot, and big geek shows always motivate me to go back and introduce new technology to the group, as well as get more involved in the community. I always feel a surge in my professional development in the 2-3 month period following my attending a conference.

  8. Start a Memphis/Mid-South Area Java User Group

    We don't have a JUG in this area and I really think that we could benefit from one. My company has a large number of Java developers, and I know that several others in the area, including FedEx and Autozone do as well. This would be a great way to get some of the good speakers from the conferences I've attended to speak locally, and it may even serve to get us on the map with some of the smaller shows like NFJS. Sun and others really seem to take an interest in supporting JUGS, so I look forward to see what happens. I've started a Google Group for the newborn JUG, and I'll be blogging more in the future about it.

On Agile: Why You Won't Fix It Later

Ryan Cooper writes a brilliant essay on why quick fixes today turn into tomorrow's code rot. I believe every word of this article. Unfortunately, I'm all too often my own worst enemy when it comes to implementing these ideas. Thanks for the reminder, Ryan!

On Agile: Why You Won't Fix It Later

Graeme Rocher's Blog: 5 More Misconceptions About Grails

Graeme Rocher, founder of the Grails project, answers five more misconceptions about Groovy/Grails vs. Ruby/Rails. I've grown to be quite fond of both of these languages/frameworks; however, given the amount of investment I've placed into learning and applying Spring and Hibernate to the applications I've developed over the past two years, I have to say that Grails just makes sense for me as the next step toward becoming more "dynamic" in my approach to development projects.

Graeme Rocher's Blog: 5 More Misconceptions About Grails

Help me become a better programmer!

I have decided to embark upon a quest to become a better programmer. I would really like to improve my understanding of the computer science that underlies my day-to-day tasks, particularly as it relates to programming language design as well as algorithm design and complexity analysis. I would also like to improve my analytical and problem solving skills. I've found that I'm really good at learning new technologies and quickly bringing them to bear on web application development problems, but take me out of that problem space and I get nervous rather quickly.

Who has ideas about the best way to go about this? Please comment!

How to implement form-level validation in JSF

Recently I was faced with the challenge of implementing form-level (or page-level) validation in a JSF-based application. What I mean by form-level validation is the need to evaluate a subset of a form's fields as a unit, rather than simply validating each field in isolation. An example of this type of validation can be found on a user registration form where one has to select a password in one text field, and then retype the same password in another text field for confirmation. Validating that these two text fields contain the same password is an example of form level validation.

In my case, I had two date selector components on my form, one for a start date/time and one for an end date/time for an event that was being scheduled. The rule I needed to validate was that the end date/time was later than the start date/time.

There are a few ways to implement validation like this, including but not limited to:

  1. Build a custom component that renders selectors for both the start and end date/time, then validate as a unit. This actually is field-level validation and doesn't truly address the form-level problem.

  2. Implement a validator method on a managed bean that will evaluate the data submitted for multiple components.

I'll address the second method in this HOWTO.

First, you'll need to bind at least n-1 of the components that you want to validate to properties on your managed bean. The simplest way is to declare properties of type UIInput:

private UIInput startDateComponent;

public UIInput getStartDateComponent() {
return startDateComponent;

public void setStartDateComponent(UIInput startDateComponent) {
this.startDateComponent = startDateComponent;

and do the actual binding in the JSP:

<t:inputDate id="eventStart" value="#{orderForm.sampleInfo.requestedStartTime}"
ampm="true" binding="#{dateValidationForm.startDateComponent}"/>

Next, you'll implement the validation method, which can have any name you like, but must share the same signature as this example:

public void validateEndDate(FacesContext context, UIComponent toValidate, Object value) {
Date endDate = (Date) value;
Date startDate = (Date) getStartDateComponent().getLocalValue();

if (startDate == null) {
context.addMessage(getStartDateComponent().getClientId(context),new FacesMessage("Please specify a valid date and time."));
throw new ValidatorException(new FacesMessage());

long endTime = endDate.getTime();
long startTime = startDate.getTime();

if (startTime >= endTime) {
throw new ValidatorException(new FacesMessage("Event end must be later than event start."));

And finally, you'll bind the validation method to the last component in your subset of components that need to be validated together:

<t:inputDate id="eventEnd" value="#{orderForm.sampleInfo.requestedEndTime}" type="both" popupCalendar="true" ampm="true" validator="#{dateValidationForm.validateEndDate}"/>

To understand why I say n-1 components, think of the way the validation phase occurs in JSF. Data is bound to the components in the order that they occur in the JSF component tree, which just so happens to be the order in which they appear in the JSP source. Looking at the validateEndDate method, you'll see that I only reference the startDateComponent from the binding, but I reference the endDate as the Object value reference that was passed into the method. This is why you only need to bind n-1 components, because you get the nth component from the method signature.

If you want to be more uniform and bind all of the components, you could create an extra dummy hidden value component and bind the validator method to it. You could then bind all of the components to your managed bean and access them all from the bindings rather than accessing one from the method signature.

The validateEndDate method itself is rather simple. First you access the data by getting the local value of each component (again, the endDate value is not accessed in this way - in fact, it hasn't been bound yet because it must be validated first, and that's what's happening in this method!). You then apply the business rule. You'll see that first I look to see if the startDate is null. I'm not sure why this is possible, but if the startDate was not submitting a good value on the FIRST submit, the local value was null. So, I catch that here. I add an error message to the startDateComponent and throw a ValidatorException. If the business rule is violated, throw a ValidatorException. (I'm also using the addError method provided by AppFuse to work w/ its message framework as well, but that is not necessary w/ all JSF apps).

Now, for the final problem I encountered. In Weblogic server, which we're still using for the time being, if your session cannot be serialized then it deletes your entire session. Obviously this can cause major problems in any web app. To deal with this, ANY SESSION SCOPED MANAGED BEAN must be fully serializable, meaning it and any objects referenced in its state. Herein lies the problem for JSF. Instances of UIComponent (an ancestor of UIInput) are not serializable, so if we bind our components to UIInput fields on a session-scoped managed bean (the bean backing this form is an Order Form/Shopping Cart style bean), it will not be serializable and Weblogic will kick out your session.

To deal with this problem, realize that there is no reason that you can only have one managed bean backing a form. In fact, you can reference as many managed beans as you need. Since validation is done for each request, there is no need to manage any state there across multiple requests like we need to do with a shopping cart. So, why not declare an additional managed bean that is REQUEST SCOPED, and then put the bindings and validation method there. That is exactly what I did. Here is the entire bean:

public class DateValidationForm extends BasePage {

private UIInput startDateComponent;

public UIInput getStartDateComponent() {
return startDateComponent;

public void setStartDateComponent(UIInput startDateComponent) {
this.startDateComponent = startDateComponent;

public void validateEndDate(FacesContext context, UIComponent toValidate, Object value) {
Date endDate = (Date) value;
Date startDate = (Date) getStartDateComponent().getLocalValue();

if (startDate == null) {
context.addMessage(getStartDateComponent().getClientId(context),new FacesMessage("Please specify a valid date and time."));
throw new ValidatorException(new FacesMessage());

long endTime = endDate.getTime();
long startTime = startDate.getTime();

if (startTime >= endTime) {
throw new ValidatorException(new FacesMessage("Event end must be later than event start."));

and the declaration in faces-config.xml:


The added bonus is that you can reuse this bean across all forms where you need this behavior. My application happens to have 2 additional forms where I would have repeated this logic, so I just reference this bean there.


The Grove Coffee House Rocks!

It's Friday night, and what am I doing but coding. My wife's night out is spent at the scrapbook store working on her latest layouts - mine is at my new favorite coffee shop, working on open source. I discovered this place on a date with Wendy a couple of months ago. The nice thing about it is the distinctly Christian atmosphere. A good friend of mine and I meet here on Friday mornings for accountability. Well, since they hand out free wireless internet, I thought I'd drop by for my night out as well. Good coding atmosphere - I have a nice corner with a plugin for my laptop, so I'm good to go. Check this place out if you're in DeSoto County, MS or the Memphis metro area anytime soon - http://grovecoffeehouse.com.


I recently migrated all of my Java/Development related posts from http://www.analienandastranger.com. I want to make this a PRIMARILY Java/Development-related blog. When I was splitting my efforts between Christianity and Software Development, I was quickly getting burned out and not writing anything. If you want to read any of my old devotional posts, I will be keeping the other blog alive for awhile. Since the hosting is being provided to me free (as well as the domain), I will in good conscience need to shut it down eventually. I just feel that using Blogger gives me greater visibility - I do want people to actually read this stuff, ya know? :-)

And then it was over...

I really enjoyed "The Toy Show" this morning. James Gosling went through a flurry of different demos from around the "cool" Java world. I was especially impressed with Project Wonderland (http://lg3d-wonderland.dev.java.net/), a virtual workplace environment, and with the real-time robotics demos. Unfortunately I was so sucked in that I didn't get any good photos.

If anything you could call this my day on the back end. I attended four sessions, two of which were focused on that.

- Comparing the Developer Experience of Java EE 5.0, Ruby on Rails, and Grails: Lessons Learned from Developing One Application
- Implementing Java EE Applications Using Enterprise JavaBeans (EJB) 3 Technology: Real-World Tips, Tricks, and New Design Patterns
- The Top 10 Ways to Botch Enterprise Java Technology-Based Application Scalability and Reliability
- Exploting JRuby: Building Domain-Specific Languages for the Java Virtual Machine

I scheduled the first session because I thought it was be a good way to tie together all that I had learned about Grails and Rails and then compare it to my existing Java EE knowledge. As it turns out, the speaker believed that given tool support, the development experience wasn't all that different between the three. He then gave some performance comparisons, but I wasn't all that sure the analysis was very sound. Java EE came out way on top. I hadn't heard that it outperformed the others by quite as much as he showed. He made a rather dubious statement when he said that Grails and Rails weren't protected by standards. Groovy is a JSR and Grails just sits on top of it. If that isn't standard protection, then what is?

The EJB tips, tricks, and patterns session was quite nice. I learned a few nuances of the platform. The patterns part was the best. They first went through some of the design patterns from the EJB 2.x days and identified which ones were obsolete and which ones were still useful. They then provided several new design patterns. Unfortunately the slides for this talk were not yet available and I just don't feel like combing through my handwritten notes. Definitely check this one out online when it is posted.

Cameron Purdy's "Top 10" talk was both humorous and thought-provoking. I'll never do justice to it. Check it out when the video comes available.

The final session of the conference for me addressed a burning question I had in my mind since Monday - what in the world is a DSL? I heard it thrown around in the Grails and Ruby talks at Java University, but nobody ever defined the acronym. Domain Specific Language - that what it is! I mainly attended this talk because I thought there might be applications for DSL's in our work at St. Jude. A DSL is a custom language designed for a specific purpose. Ruby's Rake language for instrumenting application builds is an example. Rob Harrop gave an impressive demo of how he built two DSL's, one providing a simpler API for JMX, and another for corporate action entitlement calculations. While I can't think of a direct application for DSL's yet, I'm not tossing out the possibility.

JavaOne was a great conference for me. If I didn't hate to leave my family for this long, I'd love to attend every year. It's definitely drinking from a fire hydrant.

Thursday was slow...

for me, not for JavaOne. Of course I was a good little programmer and used the schedule builder to sign up for all of my sessions. I edited them a bit after the first two keynotes. Even then, I had one lone session scheduled for Thursday morning (that wasn't really directly applicable to my work, it just looked interesting), and then two sessions in the afternoon, the first starting at 4:10. I decided to skip out on the morning session and do a little shopping at Pier 39. The highlight was a "Bucket of Boat Trash" and clam chowder at the Bubba Gump Shrimp Company. And yes, we Ole Miss Rebels are represented as far out as the end of Pier 39:

The two sessions that I attended were:

- RubyTooling: State of the Art
- Using Ajax with POJC (Plain Old JavaServer Faces Components)

I attended the first session simply to get a little more detail on all of the hype surrounding Ruby tooling support in NetBeans 6. What I got was even more than I bargained for. The project leaders actually walked us through not only the features that were available, but how they were implemented. I had never really thought about the problems with providing code completion and refactoring with a dynamically-typed language. It was really cool to see the thought process that went into their solutions. I'd love to hear a similar discussion from the JetBrains guys, as the Ruby support in IntelliJ IDEA is quite good as well.

For me the second session was the best of the conference for me up until that point, and arguably it still is after attending Friday's sessions. Craig McClanahan, of Struts fame, was the main speaker and was joined by his colleagues Matthew Bohm and Jayashri Visvanathan. What made this session so good for me was that they presented a problem - "How can I add Ajax behaviors to my JavaServer™ Faces technology based application, without throwing away my investment in existing component libraries?" - and then provided three different solutions to that problem - low, medium, and high level.

The low level consisted of simply using the HTML event pass-through attributes that are implemented by most standard JSF components (onClick, onBlur, etc.). One could use an existing JavaScript framework such as Dojo to send an XMLHttpRequest and then map that request to a Servlet or JSF handler using a technology such as Shale Remoting. The response could be sent back as JSON data which could then be transformed into the desired UI update.

The medium level consisted of actually extending existing JSF components and adding the desired Ajax behavior. Due to time constraints they didn't cover this solution in detail, but they did provide a link to a detailed discussion in the Java BluePrints catalog: https://blueprints.dev.java.net/bpcatalog/ee5/ajax/extendingRenderFunctionality.html

The high level solutions addressed the following needs (copied directly from the slides):

● Partial page submit—gather up a particular set of
input element values, and send them to a bit of server
side business logic
● Partial page refresh—the business logic needs to
refresh the content of one or more subtrees of the
client side DOM
● Synchronization—the benefits of synchronizing the
server side state
● Don’t repeat yourself (DRY)—reuse existing
components and renderers for partial page updates

To address these issues, the speakers highlighted two add-on frameworks:

● Ajax4JSF (http://labs.jboss.com/portal/jbossajax4jsf)
● Dynamic Faces (https://jsf-extensions.dev.java.net/)

I was quite impressed with both of these frameworks. One of my colleagues is currently implementing Ajax behavior in a Facelets-based application using Ajax4JSF and he is quite happy with it. Dynamic Faces looked really awesome, especially its tooling support in NetBeans (actually I'm quite impressed with the overall JSF support in NetBeans - I'll definitely be adding it to my tool belt). The highlight of the presentation was Matt's video of him building an entire currency trading application in 28 minutes - except it was "fast-played" to finish in 3 1/2 minutes and set to techno music. Matt wowed us with his dancing abilities while we watched true RAD. The crowd went wild!

Wednesday was AJAX Day

Not officially, but nearly every session I attended had something to do with AJAX:

- Creating Amazing Web Interfaces with Ajax
- jMaki: Web 2.0 App Building Made Easy
- Fast, Beautiful, Easy: Pick Three - Building Web User Interfaces in the Java Programming Language with Google Web Toolkit
- Killer JavaScript Technology Frameworks for Java Platform Developers: An Exploration of Prototype, Script.aculo.us, and Rico

I have to say that I was rather impressed by what I saw.

The first talk was by Ben and Dion, the Ajaxian guys. It was an appropriate way to start, as they gave a quick history overview of Ajax. One nice point they made was that Ajax really isn't about the acronym - it never was - it's about building killer websites. Who cares what the actual technology behind it is. They discussed a couple of what they seemed to consider the better frameworks available - Dojo and ExtJS. They then explored some amazing up and coming features, including offline support and 2D client side graphics manipulation.

I was rather impressed with jMaki - in short it is a wrapper around many of the popular JavaScript frameworks available (Dojo, Yahoo UI, Script.aculo.us, Spry, Google), and makes them accessible to Java, PHP, and Ruby. It has excellent tool support in NetBeans and Eclipse. It provides protection from changes in the API's of all of these projects - you can mix and match frameworks and only be concerned about one API - jMaki's. It does the work of linking all of the widgets together and communicating amongst them and with the server side.

The GWT talk was easily my favorite of the day. I'm extremely impressed with what these guys have done. I hadn't had much opportunity to look at GWT until now, and I really wish I had. I was initially skeptical about writing an entire application in Java and letting it generate HTML and JavaScript. I guess these guys knew that, because they're development philosophy addresses my concerns quite nicely:

To radically improve the web experience for
users by enabling developers to use existing
Java tools to build no-compromise AJAX for
any modern browser

From what I can see, they deliver on their mission. They've optimized their code for speed and for browser specificity (e.g. from what I understand, if your client is using Firefox, you get Firefox optimized JavaScript, same for IE, etc.). You can use all of your favorite IDE features to build the code, including the debugger. I really want to try to make use of this toolkit in the near future.

The final talk was less informative for me, but only because I had experience with most of the technologies already. The killer part of this was how the speaker extended existing JSF components and added Script.aculo.us effects. It really made his version of Yahoo maps shine.

Ajax isn't going anywhere but up. I just left yet another Ajax/JSF session, which for me was the best session of the conference so far. In a later entry I'll tell you why.

It seems to be the year of the dynamic/scripting language

It has been a whirlwind of a day. I've been to two keynotes (close to 5 hours of information there) and one technical session. Couple that information with what I heard at Java University yesterday, and you find many common themes. One that keeps coming up is the emerging trend of making other languages, particularly dynamic/scripting languages, first-class citizens on the JVM.

According to Wikipedia, "Dynamic programming language is a term used broadly in computer science to describe a class of high level programming languages that execute at runtime many common behaviors that other languages might perform during compilation, if at all. These behaviors could include extension of the program, by adding new code, or by extending objects and definitions, or by modifying the type system, all during program execution. These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them." This definition seems to fit quite nicely with what I've heard the last two days. A couple of dynamic languages I've heard A LOT about are Groovy and Ruby.

Yes, Ruby and its most popular framework, Ruby on Rails, have survived the initial hype. They are here to stay. Not only that, they seem poised to make a serious impact on the way we will do web application development over the next several years. Sun made a HUGE splash when they decided to hire the core developers of JRuby, the project which in its current pre-1.0 release already runs 98% of Ruby on Rails as a first-class citizen on the JVM. Not only that, you can now create a WAR file from a Ruby on Rails application and deploy it to any Java application server! I'll write more on this in another entry as I attended a full technical session on it.

If you're too uncomfortable getting away from Java, why not try Groovy? After all, it is a JSR (241). All of Java syntax is legal in Groovy, plus a lot more. Groovy is a dynamic scripting language like Ruby and also compiles to bytecode, making it a first-class citizen on the JVM. It has its own MVC framework, Grails (formerly Groovy on Rails), which is a direct competitor to Ruby on Rails. I've already written on Groovy and Grails in an earlier entry.

I plan to attend some additional sessions focused on these dynamic languages, as it seems they will be really important in the years to come.

Java University: Rapid Web Site Development with Groovy and Grails

I'm currently sitting in this session - Graeme Rocher is the presenter. He is the creator of Grails, which is Groovy's answer to the Ruby on Rails like development experience. He's currently doing Q&A, so I thought I'd take the opportunity to write a short entry. So far this session is awesome! Graeme is a great presenter and has had the perfect balance of slides and live coding. Unfortunately they ran out of slides before I got to the presentation (more on the sometimes laughable logistics at JavaOne later), so I'm having trouble remember details to write about (they've promised to email me the slides). The first part of the session was an introduction to Groovy, Java's "scripting" language. I had NO IDEA just how cool and powerful Groovy was. I am especially impressed with its MetaClass concept, whereby you can override almost every behavior of the Java language that you can imagine - method calling, operator overloading, etc. Imagine being able to do AOP type things without using AOP. Not only that, it has all of my favorite pet features like "everything is an object," closures, dynamic lists, etc. It's an OOP nuts dream. I'll write more later.

Java University: Developing Enterprise Applications with the Spring Framework

This was the first session that I attended at Java University. You could take either a full-day course or two half-day courses - I elected to do the latter. Keith Donald, project lead for Spring WebFlow, presented. I have quite a bit of Spring experience already through AppFuse, but I was hoping to get a more complete view of Spring as most of what I have learned is from tinkering with existing systems. Keith promised that we'd build a system from the ground up, so it sounded like I'd get what I bargained for.

And build from the ground up we did. I'd say we were almost halfway through the entire session before we even TOUCHED Spring. Up until that point all we had done was do test driven development on all of the business entities and logic. It was very interesting to me that Keith's coding methodology is quite different from what I typically find myself doing. He implemented almost all of the business logic of the application without any regard to the eventual supporting technologies (i.e. ORM frameworks, web frameworks, etc.). It seems like I almost always bind my application to a set of technologies (say Hibernate/Spring/JSF) before I ever write a line of business logic. What did he get from this? Well, his application had fully implemented and tested business logic that would work with nearly any of the available supporting frameworks. Good stuff.

Another thing that was interesting to me is his disdain for packaging classes according to application layer. I can't think of an application that I've built recently where the DAO's weren't in a dao package, the "Manager's" weren't in a manger/service package, and the web classes weren't in a web package. Keith totally changed all of this. Our two main entities in this application were account and restaurant. Anything that had to do with an account (be it a DAO, service bean, web form, etc.) went in the account package. The same went for the restaurant package. I'm not sure if I like this or not, but he seemed convinced of the value.

Overall it was a good session. He incorporated A LOT of live coding, and almost all of it was done from scracth - he had very little pre-made skeleton code. The drawback to that was that he only made it through 6 of the 8 sections of his slides. I wish he had backed down on one or the other.

Siam Thai Restaurant Doesn't Disappoint

I ended up at the restaurant across the street from the one pictured in my last entry. I found out from reading the reviews that it was the original, and then opened an additional location across the street. Strange, huh? At any rate, the Chicken Satay was definitely a 5-star dish for me. Even better than Bhan Thai back home in Memphis. I followed that up w/ the Thai Fried Rice w/ Beef. Also awesome. I will probably eat here again during the week.

Greetings from San Francisco!

This is the view from my quaint little hotel room at the Hotel Nikko in downtown San Francisco, California. I arrived here after a long morning of travel. First ~4 hours of flight from Memphis, TN to San Francisco International, followed by traversing the airport maze to find the BART (Bay Area Rapid Transit) train station. Once I found the right station, it was another 15 minutes of waiting on a train followed by a 40 minute train ride. Almost home? Not quite. As I ride the escalator out of the subway, I realize just what a country boy I am. There are literally hundreds of people crawling around on the streets, and here I am, toting a large rolling suitcase, a laptop, and a backpack, and looking totally clueless! Where is my hotel? I was definitely a prime target for predators just looking to make a quick buck. Within seconds I heard, "Where you looking to go? I've got a map." I quickly responds with "I've got it, thanks." Of course, I didn't have it. But I didn't have 20 bucks for the guy either! Not a few more steps up the sidewalk I'm confronted by Indian monks wanting to share their religion with me. I did have a nice conversation with this guy and got him to take one of my pocket Gospels of John (thank you Pocket Testament League!). Finally a nice family pointed me in the right direction. I figured out that if you look like you're on a mission and you know what you're doing, people don't come up to you, so I put on my best serious face and headed for the Hotel Nikko. Now here I am, and from my window I've got a nice view of the pool area which is surrounded by an interesting looking rock garden:

I also can see what looks like a potentially good Thai restaurant on the corner:

The reviews on Google Maps look promising!

On a final note for this entry, I desperately miss my family. Our goodbye at Memphis International was tear-filled, especially by Wendy. I haven't been this far away from them in a LOOOOONG time. In fact, Abby was only about 10 months old the last time I went on a business trip without them. Isabella and Ali Kate weren't even conceived yet! I managed to get a web camera for the trip, so I'm going to send them a video message every day. Check your email sweetheart! I love you all SO MUCH!


I plan to start posting here on Saturday, May 5, 2007. Look for photos, videos, and session synopses, as well as miscellaneous banter about JavaOne 2007 in San Francisco, CA!