~pperalta

When I was a senior in college, I wrote a Java front end for controlling X10 devices. In those days, libraries for serial port access did not exist for Java, so I used JNI to call a serial library written in C. When presenting this project to faculty and classmates, one of my presentation points was that checked exceptions were a good thing. This forced the programmer to handle operations that could go wrong instead of ignoring them. In fact, during my demo, a catch block that I had coded to handle IO problems displayed an error dialog. The checked exception forced me to handle that error even though I had never seen it before! This occurred because the demo was being held in the CS lab with lots of other machines on the power grid, whereas all of my previous testing was done at home, where there was much less interference on the line.

Lately I have seen a few blog entries discussing the checked vs. unchecked debate. The first place I can remember reading about this debate was in Expert One-on-One J2EE Design and Development a few years ago. In this book, Rod Johnson advocates the use of unchecked exceptions as the norm and checked exceptions in edge cases instead of the other way around.

Up until that point, I was still a checked exception fan, although I had some misgivings. I had two major pain points with checked exceptions:

• If a method throws a checked exception, any interface methods that it implements must also declare the exception. Often, this exception has nothing to do with the interface.
• What do you do with a checked exception if it can’t be handled where it is being thrown? If you declare that the method throws that exception, that change may have a ripple effect throughout the code base. Before JDK 1.4, wrapping an exception with another one meant loosing the stack trace unless you implemented your own exception type.

After dealing with the pain of many checked exceptions that I could do nothing about (and the boiler plate try/catch blocks that go with them), I am firmly in the unchecked-exceptions-as-normal camp. This is especially true in server side programming, where a SQLException that is nested deep in a DAO usually can’t be reasonably handled and thus has to make its way to the UI to let the user know that something went wrong. I think the reason why checked exceptions worked so well in my college project is that the UI was a thin layer over the JNI library. When working at the UI level (especially in a desktop application), it is helpful to know what can go wrong because it is easy to display an error message of some sort to handle the exception. However, most of the time applications are making deep calls into APIs which call other APIs. For non trivial applications, unchecked exceptions are the way to go.

For further reading on this topic, see this article by Bruce Eckel.

I just tried out Ruby on Rails for the first time after reading the article “Railing on AJAX” in the November 2005 edition of Software Development. I first saw RoR in action at No Fluff Just Stuff demoed by Dave Thomas. This is a framework that strictly adheres to the DRY (Don’t Repeat Yourself) principle, which means that changes in configuration are only required in one area instead of having rippling effects throughout the application. It also relies heavily on convention instead of configuration, so once you’re familiar with the setup it is quick and easy to add functionality. Scripts are provided for generating web applications, controllers within those applications, and more. It also comes with an ORM tool known as “Active Record” which is supposed to be very nice for simple CRUD operations.

This article also mentions the AJAX support provided by RoR, and it gives a simple example of how to use it. In the example, no JavaScript coding is required…the application comes with JavaScript libraries called from Ruby for performing the AJAX calls.

Ruby, RoR and AJAX have received quite a bit of press coverage lately. It will be interesting to see how they affect the industry in the coming months and years.

A few days ago this strange posting was made on the front page of TSS. It seems to me that this would be a more appropriate question on a “JDBC for Newbies” forum somewhere, not on the front page of a major news site for server side Java. Even stranger (or perhaps just scary) is that this code supposedly came from a Sun tutorial. As Keith Donald points out, using Spring’s JDBC support would go a long way toward cleaning up that code. However, one of the biggest problems that I see with the sample is that the prepared statements, result sets and connection are not closed in a finally block. In my experience with Oracle, if everything isn’t closed out explicitly, you could end up running out of cursors. Just closing the connection will return it to the pool; that won’t be enough to clean up the connection’s resources. However, using Spring JDBC would make that point moot…Spring will close everything properly for you. Notice that Keith’s example isn’t cluttered with try/catch/finally blocks!

Meet the Life Hackers, an article from the New York Times has been mentioned by Slashdot and Joel Spolsky in the past few days. It is a long article, and it covers many aspects of office and knowledge work, in particular how we interact with modern office technology. However, there is one section of the article that I found particularly interesting:

When Czerwinski walked around the Microsoft campus, she noticed that many people had attached two or three monitors to their computers. They placed their applications on different screens – the e-mail far off on the right side, a Web browser on the left and their main work project right in the middle – so that each application was “glanceable.” When the ding on their e-mail program went off, they could quickly peek over at their in-boxes to see what had arrived.

The workers swore that this arrangement made them feel calmer. But did more screen area actually help with cognition? To find out, Czerwinski’s team conducted another experiment. The researchers took 15 volunteers, sat each one in front of a regular-size 15-inch monitor and had them complete a variety of tasks designed to challenge their powers of concentration – like a Web search, some cutting and pasting and memorizing a seven-digit phone number. Then the volunteers repeated these same tasks, this time using a computer with a massive 42-inch screen, as big as a plasma TV.

The results? On the bigger screen, people completed the tasks at least 10 percent more quickly – and some as much as 44 percent more quickly. They were also more likely to remember the seven-digit number, which showed that the multitasking was clearly less taxing on their brains. Some of the volunteers were so enthralled with the huge screen that they begged to take it home. In two decades of research, Czerwinski had never seen a single tweak to a computer system so significantly improve a user’s productivity. The clearer your screen, she found, the calmer your mind.

Having lots of screen real estate has always been very important to me. In fact, when I was in college (and poor, but I’m being redundant here) I spent $600 on a 17″ CRT at a time when the average PC had a 13″ or 14″ monitor. Having a larger monitor and being able to fit more text on a single screen makes me feel much more productive, especially when coding. At work I was using a 19″ LCD for a while (since LCDs are so much easier on my eyes, but I digress) and the 1280×1024 resolution felt very constraining. Getting a 20″ monitor that does 1600×1200 felt quite liberating. Even though it is only 1″ bigger, the difference in resolution is huge.

Having multiple monitors sounds intriguing, but I’ve tried it before and I find it more distracting than productive. I prefer to just have one large monitor…that 42″ model sure sounds nice!

As Joel says, it is nice to have scientific evidence to back anecdotal feelings!

Yesterday Maria and I got back from a week in New York. We stayed at my sister’s apartment in Kew Garden Hills. We didn’t tell her ahead of time that we were going to show up, so she and her daughter were quite surprised to see us!

Unfortunately, the week that we chose to spend in NY turned out to be one of soggiest on record. Every day was overcast at best, and there were several days of non stop rain. Living in Florida, the rain is not quite so inconvenient since we all use cars to get around, and for the most part parking is plentiful wherever you go. However, pleasant weather is enjoyed much more as a pedestrian than as a driver.

Despite the weather, we did get to enjoy certain venues, one of them being a Broadway show. We picked up a pair of tickets to see Beauty and the Beast at the TKTS booth in Times Square. This was our first Broadway show and I must say that it was a very good performance. Just about everyone on stage needs to have three talents to be successful: acting, singing, and dancing. I think that each of them pulled it off very well.

We also trekked uptown to see the Cloisters at Fort Tyron Park. I really wish the weather was nicer on this day because the park is very nice, and there were some really nice gardens inside of the Cloisters as well. The Cloisters is an extension of the Metropolitan Museum of Art dedicated to medieval art. The building looks and feels like a castle, and many of the doorways consist of actual doorways of medieval buildings. The main thing that Maria wanted to see was the Unicorn Tapestries. She had been fascinated by them since childhood and was very much looking forward to seeing them. Looking at them up close, the detail that the weavers were able to achieve was amazing. Although the tapestries are huge, they have the same level of detail as paint on a canvas.

I was looking forward to seeing Massive B spin Dancehall at The City nightclub, and I was not disappointed. We showed up around 12 and the early DJs were spinning some old tunes. Their selection was excellent even if the mixing left something to be desired. An hour or so later the Massive B crew showed up and really woke up the crowd. As is the case with their mix tapes (which I have been listening to for at least 10 years) and their show on Hot 97, the selection and mixing was top notch. They also had Kiprich performing that evening, but the performance was mediocre (and the crowd let him know) so we left a little after he started. The promotional CDs that they gave away were not bad, although the songs were not as new as the literature suggested.

On Thursday evening we hung out with Dario and Frank, two guys that I went to grade school with and grew up with in the Woodside projects. Frank is doing IT, performing installations and administration for a company in NJ. Dario is buying and selling stocks on Wall Street, and also recently started a Hip Hop record label, Firewater Records. So far they have a few artists signed up and a couple of mix tapes, with more on the way.

This trip was my first experience with JetBlue. These were the best coach seats I have ever had by far. There was plenty of legroom and each seat has its own LCD TV with 20+ DirectTV channels to choose from. The trip to JFK from Orlando was very smooth and trouble free. On the way back however, after boarding the plane we sat on the tarmac for 20 to 30 minutes. It turned out that there was engine trouble and we would not be able to fly on that plane. After pulling back up to the jet way, they had us go to another gate. They pulled another jet out of the hanger and sent us on our way. Before takeoff, the flight attendant apologized for the delay and informed us that they would give us $50 off our next trip to compensate (which drew enthusiastic applause from the passengers.) And sure enough, I have the following in my inbox:

Dear Patrick,

Thank you for flying with JetBlue Airways on flight #41 from New York’s JFK on 10/14/05. We regret that we did not operate your flight as scheduled and sincerely apologize for the inconvenience that the maintenance delay may have caused you. As always, our foremost consideration in these cases is the safety of our customers.

As a gesture of apology and goodwill, we have issued each customer on your flight a $50 JetBlue electronic voucher. When you are ready to use your voucher, please call 1-800-JETBLUE with your confirmation number **** for this flight. The voucher is for you and is non-transferable; vouchers are valid for one year and cannot be used as a payment option for online bookings.

We thank you for your understanding, and look forward to a future opportunity to welcome you aboard JetBlue Airways.

Very impressive. I will certainly fly with them again in the future.