Larry Sherrill: Java and Object Orientation

Sat, 29 Jan 2005 20:36:21 GMT

During my rant on 11/11/2004, in which I was venting my frustration with web development, I made the following statement: "Struts, JSF, tapestry, velocity, JSP are all Band-Aids for a broken paradigm." I should not have included Tapestry in that list. I assumed incorrectly that it was just another framework. It is not. If you are jaded on web development, you need to try Tapestry. It makes web development fun again. I especially like the fact that it works with HTML developers, not against them. I also should not have included Velocity in my rant, as I have not worked with. I cannot say anything pro or con about it. I stand by my statements about Struts, JSF, and JSP. I do not enjoy building web apps using an alphabet soup of technologies.

Visit Tapesty!

Sun, 26 Dec 2004 19:52:56 GMT

CiLite is a continuous integration tool for Java projects. It is simple to set up and use. It uses a short Groovy script and a Quartz scheduler to periodically invoke an ant target in your build.xml. The result of the Ant invocation is mailed using Ant's inherent mail logger. Install Groovy, point to an Ant target in your build.xml, define your mail.properties (using the sample project as a model), and you're finished. Continuous integration does not need to be prohibitively complicated.

Sun, 26 Dec 2004 19:40:38 GMT

A spectre is haunting Microsoft -- the spectre of Open Source.

Software developers of all countries, unite!

Thu, 11 Nov 2004 23:16:50 GMT

Rant 1. I want information and device fusion (IDF). I want my television to show me who is at the front door. I want my stereo to read my email to me. I want my milk carton's RFID tag to tell my refrigerator which then alerts me when my milk has spoiled. I want to use my browser to see if my car's oil is dirty. I want to see/control my house while I'm on vacation. I want to control my TV by selecting a program from yahoo's TV guide. I want my bedroom lights to flash if my back door is accidentally left unlocked at 1 AM. I want to receive a text message if my basement is flooding. Reading a manual, trying to determine is bit 35 should be a one or zero (or the modern day equivalent: configuring of windows or linux) won't make it. I want to do these things without the pain of typical computer software configuration. Currently, everything I've mentioned above could be done. But not without manuals, custom programming, wires, hair-pulling, and hours of configuration pain. When will the computer industry evolve beyond requiring us to read manuals? It will require standards and it will require something beyond HTML. It will require us to expect more from a computer than either Windows or Linux currently provides. These things should be as simple as plugging in a light and turning on a switch.

This morning I bought Mozart’s Sonata in C from ITunes over the internet, and played it on my stereo using Apple’s Airport Extension. This is fusion. (Thanks, John)

This morning I used my browser to check on my bank balance. I also received an email alert that yesterday five purchases were made with my credit card. This is fusion.

This morning I received a text message that the billing system at work was healthy as of 5:15 AM. This is fusion.

This morning I used Bloglines to review 30 different blogs in a couple of minutes. This is fusion.

I want all my important information to be fused with all the devices I want. Bank balances, credit card alerts, home lighting, car engine statistics, spoiled milk warnings. And I want it with the ease of plugging in a lamp. I think we’ve hit a plateua in the computer industry and the current state of configuration bit-twiddling and HTML development pain won’t get us there. That is the subject of Rant 2.

Rant 2. In my opinion, HTML caused the internet bubble to burst. It is holding back the IDF (see above) revolution. Here is the scenario in the mid 90’s: sell venture capitalists on a web idea, develop a prototype, get some beta customers, add more features, get some real customers, add more features. The HTML development starts to bog down in a sea of complexity and alphabet soup: HTML, CSS, javascript, JSP, ASP, PHP, EJB, … Maintenance costs rise, developing the application on a page-based HTML slows to a crawl. Customers begin to leave, CEOs start to panic and increase worker hours. Developers burn out and produce even less. Companies go out of business. Recession hits.

Using Spring has awakened me to the realization that if something is painful (e.g., EJB) then it probably should be retired. Developing web apps is painful. Struts, JSF, tapestry, velocity, JSP are all Band-Aids for a broken paradigm. If you’re a developer, how many MVC frameworks have you learned trying to look for the magic solution? Compare this with the simplicity of developing a swing app in one language (Java) using a powerful refactoring browser such as Eclipse or IntelliJ. Maybe the solution is that the web should be a sea of services and the client decides on the rendering (although SOAP is currently a typically painful configuration process). Similar to the RSS readers but with interactivity and alert-setting. RSS news readers take semantic information and present it however they like. Perhaps we need Service Browsers or IDF browsers (see rant 1) with easy alert-setting capability. Just brainstorming here. Just as Spring has to potential to render EJBs obsolete, I think the that industry is ready for a new paradigm that renders the current HTML development cycle obsolete. Don’t get me wrong. Browsers and HTML provide a great level of convenience and power. But it could be so much more if development were simpler. The goal is not to myopically browse HTML sites, the goal is the fuse the information we need with our relevant devices (PCs, stereos, TVs, cell phones, PDAs).

We need to break out of our current HTML-centric development paralysis; raise our expectations; and imagine and invent a richer/easier fusion of information and devices.

Mon, 31 May 2004 04:51:13 GMT

I've encountered several milestones in the past five years that have changed the way I work. The first and most important milestone was becoming test-infected via junits.

The second milesone was finding jboss, which made using EJBs moderately tolerable and affordable. I was ready to abandon EJBs (maybe that still would not have been a bad decision). EJBs have always been an exercise in configuration minutia: endless fat books on J2ee, deployment descriptors, application.xml, ejb-jar.xml, ejb refs, et cetera ad nauseum. It does not feel like the simplest thing that could possibly work.

I think I have now stumbled across another milestone: the Spring Framework. This will definitely change and simplify the way I build applications. It is a framework designed to make j2ee easier--in many cases eliminating the need for EJBs altogether. I've only start scratching the surface but I already learned how to greatly simplify jdbc coding by using the org.springframework.jdbc.object package and by using declarative transaction management provided by Spring's AOP capabilities.

Several speakers at the recent Rocky Mountain Software Symposium stated that EJB 3.0 is being heavily influenced by the ideas in Spring (and other inversion of control containers) as well as Hibernate. EJB 3.0 will use annotated POJOs and POJIs (plain old Java interfaces).

One of the motivations for Spring is to improve testability of j2ee applications. Perhaps, stated another way, test-driven development--which can mutate design when done correctly--is exposing the current design of EJB for the mess that it is. Here is why Spring apps are more testable: 1) POJOs are easily testable outside of the j2ee container. 2) Spring encourages the use POJOs and POJIs. 3) Spring knows about your POJOs but they don't know about Spring. 4) Dependency injection provided by Spring makes it easy to mock or stub major portions of your code.

I just heard of Spring a few weeks ago. How did I miss this? I had trouble understanding what it was for at first. I wanted to like it, but I didn't know why. :> A few case studies or usage scenarios on the Spring website would help.

Just got back from the Tattered Cover in Cherry Creek. I found Rod Johnson's book Expert One-on-One J2EE Design and Development which introduced the concepts and sample code that became Spring. Yes, it's another fat book on j2ee but this one is very different.

Tue, 02 Mar 2004 03:05:18 GMT

I've written a white paper for my current job with the City and County of Denver that describes the agile practices that we are following and/or working towards. We are trying to evangelize the city.

Mon, 01 Mar 2004 05:16:52 GMT

A couple of nice quotes from Ward Cunnigham regarding test driven development (made in the Yahoo agile-testing forum under the topic Testing and "smooth pace" on 2/29/2004):

"TDD makes for a slow and plodding week, so much so that by Friday you are amazed to be done."

"Javadoc is a perfect example of something that must be kept in sync. If you've written a lot of javadoc for a function, you're not likely to push responsibilities into or out of it even if things will code out better if you do. Its ironic that so much effort is devoted to javadoc in the name of downstream maintainability when just making the program half the size does so much more."

Wed, 18 Feb 2004 05:04:45 GMT

I've been working in a four-person war room for four months now and I have a couple of random thoughts.

First, setting weekly iteration goals is very productive because it keeps the team highly focused. However, there is a potential trap. A team that uses weekly goal setting can get caught in a pattern of doing as much as they can possibly squeeze in, which after a period of time, becomes an unsustainable march. The team becomes haggard and new ideas stop flowing. My current manager encourages research time, but unfortunately, we developers have forgotten to listen to him and incorporate free research time into our weekly goal setting. The solution is to schedule or set aside R&D time in the weekly goals. Projects need the accidental discoveries that result from unstructured, chaotic research.

My second random thought is based on the second law of thermodynamics: developers, left undisturbed, will gravitate to one section of the code and stay there permanently. Also known as stove-piping, code-ownership, and going dark. Resisting this natural law of programming requires a constant counter pressure to break developers out of their comfort zones and into different areas. XP counters this by pairing. Other agile projects that are not pairing need to have an equivalent strategy to deal with this.

Wed, 10 Dec 2003 05:20:04 GMT

This week I have been experimenting with an acceptance testing technique I call semi-automatic testing. Although automated junit testing is essential for unit testing, customers need to see more than a green light for acceptance tests. For customers to accept it, they need to use it.

For semi-automatic testing, I create test cases using MS-Word and embed hyperlinks in the document to exercise JSPs (utilizing dbtags) running in JBoss as a web app (e.g., mytesthelper.war). These JSPs alter database state to setup the test data as necessary. Testers exercise the target application during the tests, but they also use the embedded hyperlinks to setup external data at key steps in the test. The tester will have a paper copy of the test for note taking and recording pass/fail status, but the Word document will also be on the screen so that the tester can click on the hyperlinks.

Here is a trivial example representing a Word document. The underlines are the hyperlinks to be invoked by the tester using ctrl-click.

Test Case: Make a payment
1. Intialize database
2. Make an account
3. Go to url http://someplace/mywebapp
4. Login using "user" and "password". Verify that ...
5. Click View Balance. Verify that the balance is 100.00
6. Make a payment
7. Click View Balance, Verify that the balance is 0.00

We develop the tests in conjunction with the customers when we can. At other times, we take our best guess, develop the tests without the customer, and then use it as a starting point for discussion when the customer returns. We may use an Instructional Designer with QC experience to help develop the tests and make them into a more polished training tool. We intend to use these test cases for customer testing/training, requirements clarification, new hire training, and for regression testing. One of the benefits of using Word is that a tester/trainee can easily print out all the test cases to review them as a whole. The current application is small so I don't know if it will scale up to a larger project. For now, however, it is simple and good enough.

Wed, 01 Oct 2003 22:23:19 GMT

A few years ago, I read a book entitled Constructing the User Interface with Statecharts by Ian Horrocks. Using those ideas, I occasionally use state charts as disposable artifacts on large projects to nail down a confusing user interface problem. Each screen becomes a state and the user actions are the events. The diagrams end up looking like the diagram of a regular expression state chart, which is appropriate, because the user actions form a language. You can glance at a state chart and visually identify confusing aspects of the user language, which will translate into user confusion. On a large project, it makes no sense to try to document the entire system with state charts. However, on a small, haiku-like, J2ME application (note to self: don’t ever say haiku-like again), the entire state chart can be drawn on one page with room to spare. State charts are very good at precisely specifying an application because of their formality.

Wed, 01 Oct 2003 02:07:54 GMT

Antenna is a set of custom ant tasks that compile, pre-verify, and package a J2ME application. It can also invoke an emulator in which to run your J2ME application. Therefore, with a double-click of an ant task in an IntelliJ window, you can do the entire build cycle and bring up a cell phone emulator with your application running in it. Nokia has a very good pdf file (Using Ant and Antenna MIDP v1.0) describing the use of antenna. This document has a more complete example than the docs from antenna and will help you get successfully started with antenna. The KToolBar from Sun and Nokia’s equivalent environment are fine for playing around with; but if you want to develop in a serious and unencumbered IntelliJ/Ant fashion, then you need ant tasks as opposed to endlessly clicking around in GUI tools.

Nokia appears to be very serious about wooing Java developers. Registering with them to download their developer kits was hassle free. There are a lot of good documents to help J2ME developers. Here is an RSS feed of their top 10 Java developer downloads. They also have several different emulators available for download.

Sun, 21 Sep 2003 04:47:28 GMT

Went to the Tattered Cover tonight and gravitated to the Computer section. I was looking for something on CruiseControl so I took a look at Kent Beck’s Test-Driven Development. I got sidetracked when a subsection in Chapter 26 entitled in "Cheap desk, Nice chair" caught my eye. In it Kent says:

"What physical setup should you use for TDD? Get a really nice chair, skimping on the rest of the furniture if necessary."..."My solution is to use cheap, ugly folding tables for my computers, but buy the best chairs I can find."

I guess Agile Development will have arrived when the Tattered Cover has a shelf for War Room design in the Interior Design section.

Sat, 20 Sep 2003 20:50:31 GMT

I’m going to be starting a new job on Nov 1, 2003. My new boss has kindly invited me to meet with his team for a discussion of how to design the new war room. In the spirit of agile projects, which reject expensive UML tools in favor of cheap whiteboards, I favor cheap 3 by 6-foot tables for each developer versus expensive monster desks. This gives each developer 18 square feet of workspace. Also, using a table instead of a desk let’s two or three developers gather around a monitor without their knees hitting desk drawers. The tables should be away from the walls so that whiteboards can be easily accessed for impromptu UML sessions and GUI sketching. The tables could be in two rows, facing each other, so that developers can look up and talk without twisting. The chairs should be where the money goes— comfortable ergonomic chairs with good wheels so that developers can easily roll over to their neighbor’s station.

The thing I’m excited about is the fact that we are having this meeting at all. In the end, my preferences will be just one set of ideas thrown in the pot. This is a good metaphor for how software should be developed: group design, the team is the architect. The design of the war room will be the team’s design, not the design of a chief architect on high. Especially for smaller teams, I don’t believe in the concept of the chief architect anymore. In the process of creating software, it is too difficult for one person to think of everything. A project suffers when it is the product of one person’s myopic point-of-view.

In my experience, a manager who not only understands what it means for a software team to be agile but also knows how to actively promote agility is very rare. I’m looking forward to being in such an environment.

Thu, 18 Sep 2003 04:13:49 GMT

BlogLines is a web-based rss new aggregator. Unlike other news aggregators, this one runs on the BlogLines server; therefore, you can access it from anywhere using a browser. It keeps track of what you've read, allows you to bookmark favorite articles, and has a notification system in the form of a tiny browser window that let's you know when there is a new article. It's clean, simple, professional, and free. It is a good example of how a web-based, server-side solution can replace the need for client-side software.

Sun, 06 Jul 2003 16:19:26 GMT

I am still working on a n-machine cache system. Each machine holds a subset of the domain (a.k.a., domain prime) and can answer queries requiring a complex object graph (we expect 2 million queries a day soon). I am using a JBoss cluster for the query machines. The problem is that the client does not know which query boxes are running, so I configure the InitialContext of the client using cluster identity rather than machine identity. Therefore, any server in the cluster that is currently running can answer the query. This brings me to my point: JBoss clustering is based on javagroups. This is an extremely cool and apparently rock-solid api that implements group functionality based on multicasting and a configurable protocol stack. One of the included sample apps extends a HashMap with a DistributableHashMap. Think transparently-distributed local memory. When an element is put into the HashMap of one VM, it shows up magically on all the other VM's HashMaps that belong to the group. JavaGroups knows when new members join or leave the group. To better understand JBoss clustering, take a look at JavaGroups. JBoss points out that JavaGroups could be swapped out for another implmentation, but for me, studying JavaGroups made the JBoss clustering stuff click.

Sat, 31 May 2003 23:06:19 GMT

Eric Dobbs introduced me to easymock a couple of weeks ago. This java library lets you incorporate mock object testing into junits. I’ve been looking for a good place to try it out and settled on a JMS-based distributed caching system that I’m writing for my current employer.

The old way to junit the onMessage method of a MessageListener requires a running JMS server, an InitialContext, a connection, a session, and a call to session.createObjectMessage to create an ObjectMessage. You then set the payload on the ObjectMessage and invoke onMessage, passing in the ObjectMessage as the parameter.

But with easymock, you simply create a mockObjectMessage, specify the payload object to be returned when message.getObject is called, and then invoke onMessage, passing in the mockObjectMessage as the parameter. No JMS server, no initial context, no session, and no connection are required. The result of this approach is a unit test that requires much less infrastructure.

Mon, 12 May 2003 02:19:59 GMT

Eric M. Burke and Brian M. Coyner have written a short article entitled Top 12 Reasons to Write Unit Tests. I especially like that they mention that it makes development faster and that it improves the design.

For me, design is improved because by the time the classes are released, they have had at least one user--the developer. I typically fiddle with the API by exercising it via unit tests until it feels right--trying to balance it from the perspective of programmer usability, good OO design, and good-enough criteria.

Unit tests make development faster, because, to use a military metaphor, once you have taken ground, you never give it up, you always move forward.

Fri, 02 May 2003 17:43:25 GMT

Just read chapter 20 of Agile Software Development by R. Martin. It explains all the metrics in the JDepend package. Don't know who inspired whom in terms of the tool versus book development, but the moral of the story is: download jdepend and read chapter 20 hand-in-hand. Your package dependencies will become more sane.

Fri, 07 Mar 2003 13:16:01 GMT

Just found a great tool called JDepend by Mike Clark at Clarkware Consulting, Inc. It analyses package dependencies. It reports efferent dependencies (this package dependsOn other packages) and afferent dependencies (other packages dependsOn this package). It also reports cyclic dependencies, which can be broken by using the dependency inversion principle (DIP).