Feeds:
Posts
Comments

Archive for July, 2005

Character encoding malfunctions are topical for me of late. So if I were the kind of geek to publicly express personal world views within the confines of a bumper sticker, you might see my ride decked out with one of these bad boys.

Thanks to Joel on Software for this gem.

Read Full Post »

Jobster Blog Makeover

Looks like blog makeovers are all the rage at Jobster. Hot on the heels of my site update, the Jobster Blog just got gussied up, thanks to the scrappiness of Joe Goldberg (one of our webdevs) and Carol Chapman and Matt Dawsey (our graphic designers). The three column look they employed is really sharp, especially “above the fold”. I personally think the blog entries start to look a little cramped and lonely as you scroll down the rest of the page, but I also wear plaid and corduroy together, so who am I to talk?

Read Full Post »

Kitchen Remodel

Awhile ago I promised a post about our kitchen remodel. Now that I’ve redeisgned the site and setup a Flickr-enabled photo gallery, I finally took the time to set up an album of all of our kitchen remodel photos. They’re not sorted through yet, there’s been more progress than where the album currently leaves off, and you’ll find plenty of red-eye to go around. But at least they’re in chronological order. If you love out-of-focus shots of water-damaged drywall, you are in for a treat!

I would have even more photos to sift through, if we could only find our camera. Unfortunately, it looks like our digital camera has been … misplaced. Hopefully it’s hiding somewhere in our house. I did go out tonight to pick up a memory stick for our digital video camera, which apparently can take stills. So I’ll try to get up an album of more recent photos by this weekend. Stay tuned.

Read Full Post »

I took a little time today to tidy up the site a little bit. Most noticeable, I think, is the new theme. I’ve been meaning to use this image for some time as the thematic inspiration for this site. I took it in Vienna, as part of Cheryl and my bike trip from Vienna to Prague in October 2003. I couldn’t even tell you anymore where this fountain is, but it just absolutely took my breath away. I’m pretty pleased with how well that image works as a site header.

The theme itself is based off of Desert Theme, created by evil.bert. I chose it mostly because I thought the color scheme best suited the new header image. While I realize color schemes are easy to modify for most any scheme, I’m a pretty poor web designer, and the less CSS I have to customize, the better. Speaking of CSS, I’m still not completely satisfied with the overall layout, especially in IE, where the sidebar gets pushed to the bottom of the page when viewing the site with the ‘www.’ prefix. But I think it’s a pretty good start, and I’m sure with some help from my buddy zalm (who is, as you can probably tell, a pretty talented web designer), things will slowly start to gel over the next few weeks.

The other major new site update is the addition of the Flickr-based Photo Gallery. It is based off the Flickr Gallery Plugin (unfortunately, this site seems to be down at the moment). Unlike my previous gallery, this new photo gallery is integrated directly into my blog layout. It basically displays all of my photosets on my flickr account, and has a suite of really nice features that make it a more-than-adequate replacement for my old photo gallery. Now I just need to create more photosets for folks to peruse.

To celebrate all these site updates, I’ve made the ‘mockhaug’ blog the default content for the houseofhaug website. I’ve even registered the domain mockhaug.com, which redirects to this blog as well. Now, maybe with a more respectable-looking website, I’ll be inclined to actually write more.

But don’t count on it.

Read Full Post »

Much to my chagrin, a non-trivial amount of my development work involves dealing with the JavaMail API. It’s pretty easily the worst part of my job. As my friend Rich Unger once said

[JavaMail is] a classic example of an API that was designed to make it easy on the API writer instead of the API user.

All of the most annoying bugs I’ve had to deal with have been because of some awful subtlety of using the JavaMail API. This frustration was greatly aggravated by mixing in two more of life’s abominations: Hotmail and Internet Explorer. We had a bug with our application such that mail sent to a Hotmail account would display “garbage” characters when viewed in IE. I took a screenshot, because everyone loves visuals, but for the link-imparied, an otherwise plain-text ascii email would contain characters like the following:



This particular sequence of characters represents the byte-order mark (BOM) for the document. Of course, the BOM is supposed to be invisible, but that doesn’t stop Hotmail and IE from outing it to the world.

What made this bug particularly frustrating was that it was specific to Hotmail and IE. The same message sent to a GMail address would have the exact same content, but would display as expected in IE. Similarly, the Hotmail message viewed in a more reasonable browser would also get rendered correctly. Of course, one could “force” IE and Hotmail into compliance by explicitly setting the encoding to UTF-8 (don’t forget to turn off “Auto-select”!), but that’s hardly something I can expect from end-users.

This particular bug wasn’t necessarily limited to our application. If I created a plain-text message in outlook and added extended characters, the same behavior would result: Firefox would display it fine, GMail would display it fine, but Hotmail+IE would blow up.

So, there wasn’t much we could do if the message indeed had extended characters. Part of the bug, though, was that the messages we were sending didn’t have any extended characters, but JavaMail still insisted on sticking the BOM in there. If I told JavaMail to encode the body of the message as “us-ascii” instead of “UTF-8”, the plain-text would show up fine, unless of course there were extended characters.

So, to avoid this Hotmail+IE bug, I essentially wanted to tell JavaMail to encode in UTF-8 if there were extended characters, but in US-ASCII otherwise. I was contemplating writing a “boolean hasExtendCharacters(String)” method, until I decided to do some last-ditch spelunking in the JavaMail source code.

It turns out, if you don’t specify an encoding via the actual method calls, but rather rely on System properties (either file.encoding or mail.mime.charset) to specify the default encoding, JavaMail will do the right thing.

So, instead of adding text to our messages like this:


MimeMesssage message = getMessage();
// this will *always* encode the text as UTF-8, forcing a BOM at the beginning
// and causing much grief to any Hotmail recipients using IE
message.setText("Hello, world!", "UTF-8");

it needs to be done like so:


MimeMesssage message = getMessage();
// the message will default to US-ASCII, unless there are extended characters
message.setText("Hello, world!");

Ugh. I personally find relying on system properties to define the behavior of a library to be a real shortcoming of an API, especially one as complex as JavaMail. System properties are hard to document in a public manner, and many times one cannot rely on the ability to alter system properties (such as a webapp being deployed into a servlet container). If you find yourself in such a circumstance, I suggest checking to make sure you actually are sending text with extended characters before explicitly setting an encoding on your plaintext messages. You never know what kind of crappy mail clients your recipients will be using…

Read Full Post »

I found out today that Openwave laid off its remaining Seattle-based mobile apps team (and quite possibly many more) yesterday, a year to the day after I started at Jobster. This is the team I left for Jobster, and things were pretty bad then. Since that time, the Seattle office has seen a fairly steady attrition rate, with much of the top talent leaving for better opportunities. What’s amazing about this is that the folks being laid off are some of the smartest, hardest-working individuals in that office. But maybe this is expected; a smart developer will leave Openwave, but a smarter one figures out how to get a severence package out of the ordeal.

As you can probably tell, I have few fond memories of the work I did at Openwave; this is the company that essentially put me in intensive care with double-lung pneumonia a few years back. I won’t go into much detail here, but my boss has a couple posts on his blog that give some insight into the conditions there. But at Openwave I worked alongside world class developers and under incredibly smart managers, and I’ll cherish those relationships for the rest of my life. These layoffs essentially mark the end of the former Avogadro team within Openwave. If this isn’t f*ckedcompany-worthy, I don’t know what is.

Read Full Post »

This post is an overview of my overall impression of JavaOne 2005, and is intended to be my last post on the subject. I realize it’s a tad late, but I’ve been meaning to get this post written for a few days now. However, since my arrival back to Seattle last Friday, I’ve been swamped by my kitchen remodel project (more on that later). But I have a few moments to spare, and if I don’t write it now, I never will…

“Simplify” was the word at this year’s JavaOne. Sun announced at the very first general session that they desire to see Java’s population of 4.5 million developers more than double over the next few years. Their strategies in achieving this goal seems are legion, but the overarching theme was very clear: Java should be more accessible for all developers. And they had several fronts in this effort, including revised marketing, streamlined enterprise development, configuration through metadata, and enhanced tool support (there’s likely many more such fronts, but I could only attend so many sessions!).

This “simplicity” approach is evident even in its marketing. Sun has once again changed the Java naming conventions for its futurereleases. Gone are the days of J2*E and ‘dot’ versions (1.3, 1.4.2, etc). The next enterprise edition will be known as “Java EE 5”, rather than “J2EE 5.0”. And version 6 will see this convention used across all editions: Java SE 6, Java ME 6, and Java EE 6. Apparently, they figured out that the ‘2’ had little meaning to most folks, and that an emphasis on the ‘Java’ was preferred. However, despite this broad announcement, most of the presentations I went to throughout the week continued to intermix “J2EE 5.0” with “Java EE 5” in the presentations. Time will tell if the current 4.5 million are so willing to adopt this new nomenclature. Hell, I still refer to “Czechoslovakia” and “Constantinople” in my daily conversations, so Sun may have a bit of a hill to climb on this one.

The drive to simpliciation was also clearly evident in all of the server-side talks I attended. The explosive growth of Spring and Hibernate over the past year or two seems to have put the fear of Rod into Sun, as the EJB 3 spec will be vastly simplified over previous versions. New features include annotations, dependency injection, and even some light AOP with their Interceptor mechanism. This effort has even inspired the JBoss guys to start writing articles comparing EJB3 development with Spring, apparently trying to lure back the disenfranchised. It’s pretty obvious they’re feeling the pressure, and I’m not sure the “standardized” label that EJB3 will surely continue to flaunt will be able to slow down Spring’s growth, especially since Spring can be used anywhere EJB3 can, and in many places it can’t.

Speaking of annotations, they were everywhere at JavaOne! Not only have they infiltrated every nook and cranny of EJB3, they’re the new black for Java persistence, as well. This metadata mechanism isn’t just for runtime, either; annotations are also the officially blessed approach for automatic code generation. There was a “virtual apt track” at JavaOne, with 5 or so sessions devoted to this handy little tool. Apt can be used to generate source code, documentation, or configuration from annotations in the original source code, and has obvious XDoclet-like applications (and, of course, these are being referred to as “aptlets”). Check out the rapt project for a growing set of novel uses of this tool.

All these new features and utilities aren’t going to be worth the effort if the development tools can’t keep pace. Sun put on a good show making sure folks knew that their NetBeans IDE would be keeping pace. Demos of current and unreleased NetBeans builds were shown in several general sessions, and there were countless technical and BOF sessions dedicated to its legions of features. I find NetBeans “reemergence” fascinating. It was made open-source 5 years ago to much fanfare, but was pretty quiet on the marketing front since then. It seems to be far more aggressive of late, which I think is pretty much directly attributable to the amount of mindshare Eclipse has grabbed over the past couple years. On Thursday I had lunch with Rich Unger, a college friend and NetBeans developer, and we had an interesting conversation about NetBean’s visibility. He told me at last year’s JavaOne, NetBeans didn’t even have a presence in Sun’s pavillion. This year, it was one of the most oft-visited of Sun’s booths. Sun is clearly threatened by IBM and its efforts to promote Eclipse as the Java IDE of choice, and it made sure to use JavaOne to showcase all the new efforts around NetBeans every chance it got. As Rich points out, we now have a real horserace on the free Java IDE market, and this competition can only mean good things for Java developers.

Clearly, Sun has seen the signs. The emergence and rapid growth of lightweight development frameworks has resulted in an increasing exodus of developers away from the standardized, yet cumbersome, EJB architecture. And with the release of Java 5 a year ago, the Java language is bigger and more complex than ever. The libraries have grown, the syntax has expanded, and the applicability of Java as a platform choice is broader than ever. Given that Sun wants Java at the fingertips of twice as many developers as are using it today, it’s no surprise that they’re focusing on simplifying the development effort across the board, even as the language continues to expand. JavaOne proved to be the perfect venue for Sun to put these efforts on display in front of its most important customers: Java developers. More straightforward marketing, a slimmed-down EJB spec, easier configuration, and better tools are all part of Sun’s strategy for making the experience of developing for the Java platform a more pleasant one. I, for one, am looking forward to being a Java developer over the next few years, and hope these efforts prove to be as promising as they appeared last week.

Read Full Post »