My biggest concern at first was that all that time waiting had cooled my desire to the point where I wouldn’t be really excited about having the iPhone. Fortunately, that turned out to not be the case and I proceeded to spend Saturday afternoon and much of Sunday just playing around with the iPhone. I downloaded a few apps (and discovered that typing my Apple Store password is an interesting challenge on the iPhone keyboard), used said apps, surfed the web, and so on. All in all, the iPhone held up very well to my initial expectations.

After the initial “ZOMG WOW!!” phase wore off (mostly), my iPhone and I settled into a more normal user-gadget relationship. The biggest and most immediate change was the reduction of the number of things in my pockets. I used to carry both my old cell phone and my iPod in my pocket, which ran the danger of one scratching the other in addition to space issues. The iPhone was therefore a nice reduction in things crammed into my pockets, and is in very little danger of scratching itself. The one interesting side-effect of replacing my iPod with my iPhone is that I’ve gone back to listening to the radio when I’m driving (most of the time). This is mostly because I’m worried that the FM adaptor I was using with my iPod is partly responsible for its degraded battery capacity, and not anything specifically wrong with the iPod feature of the iPhone. I have an old cassette adaptor I will be trying once I find it.

As far as being a phone goes, the iPhone works great. I haven’t had any problems with dropped calls (though I don’t make a huge number of calls in the first place). The form factor is quite nice, and I haven’t had any issues with being heard that I know of, which was a concern (due to the non-flip nature of the iPhone, the mic is further from my mouth than it was on my Razr). Most of the problems I have had have been my own fault. The one thing that is an issue is the volume of the speakerphone isn’t enough to carry more than a foot or so. This makes hearing people calling into our daily standups a bit difficult. I did a bit of experimenting, and it seemed that going into speakerphone mode bypasses the headset jack, so plugging a speaker into that jack for increased volume doesn’t look to be an option either. While this is a daily nuisance, knowing about it ahead of time certainly wouldn’t have stopped me from getting the iPhone.

Battery life on the phone is decent. I’m currently charging it every other night (my uncle, who does a fair bit more calling on his iPhone, said he charges his every night). I could probably get more out of the battery, but that would involve having less fun with the phone, so every other night will have to do. =)

I’ve downloaded around a dozen apps for the iPhone now, ranging from from free to cheap (no $999.99 purchases here). The download and upgrade process goes quite smoothly. My only early complaint was that upgraded apps moved to the end of the app list, though the 2.1 update seems to have fixed that issue. I also had an issue where none of the apps would start, which took multiple syncs to fix (removing and then readding the apps to the phone). Most of the apps I’ve downloaded have been of the leisure/entertainment sort, which in conjunction with airplane mode has given me things to do on plane flights. I’ve been trying a few productivity apps, with the idea of making the iPhone a well-rounded PDA.

Overall, I have been extremely pleased with my iPhone it fills the role of phone quite well, and does enough other things that I don’t feel the need to try and add more devices to my pockets. I would definitely recommend the iPhone to anyone who’s looking for a device that can fill a multitude of roles without sacrificing being a phone.

I’ll say up front that I haven’t spent a lot of time working with EJBs. Most of what I’d done prior to this was modifying existing EJBs. The creation and deployment of EJBs was handled by other developers (all of whom had moved on by the time this project began). So I had some learning to do.

Our EJB modules pre-date 3.0 with its annotations, which meant lots of XML wrangling for me. The first thing that came up was that the ejb-jar.xml files were missing local EJB reference definitions. I don’t know if JBoss is more permissive than Glassfish or what, but the JNDI lookup in Glassfish failed without the ejb-local-ref elements. I didn’t discover the verifier tool until later on in the migration, so all the missing local references were found by deploying the EJB apps and uncovering them as I tested the system.

A related problem was also that the string constants used to reference the EJBs were often incorrect. I found this especially odd because we were using XDoclet to dynamically generate the EJB interfaces at compile time, and you think it would have gotten it correct. At any rate, I removed the compile-time generation, checked the interfaces into SVN and went on my way (they don’t really change enough to require compile-time generation).

The other big problem was doing the JNDI lookups for the EJBs. Fortunately, perhaps 80% of our JNDI lookups were handled by a single utility class, and it was easy enough to clean up that single class. The remaining JNDI lookups were scattered throughout the client and server code. And in pretty much every case, the initial context factory was passed to the InitialContext as a constant string (referencing the JBoss context factory, naturally) instead of letting that value be found in the environment. While I don’t expect us to change app servers all that often, letting the environment define as much as it can is certainly better than having lookups fail because they’re statically looking for the wrong classes.

Ultimately, I’d say most of our problems stemmed from an assumption that the app server would never change, or relying on vendor-specific behaviors (no doubt fed by the previous assumption). There are still a few places where we’re doing questionable things (several EJBs read configuration information from files, for example) but I have plans to take care of those.

First, a bit of background. We’ve recently started swapping our backend over to a service-oriented architecture based on RESTful services. All of our recent development has been involved in the creation of new RESTful services, but we still have a lot of legacy code that happens to take the form of EJBs and RPC-based web services. Faced with the need to either upgrade JBoss or switch to Glassfish, we chose the latter (which will probably make a fine post in the future). This meant we had to make changes to all three service types to get them all working in the new app server.

I’m going to start with the RESTful service migration, mostly because they were far and away the easiest part of the migration. So easy, in fact, that there were only two major issues I ran into.

The first came about because we were prepending numbers on the names of our web application archives. This was done for ordering reasons, and in JBoss, the number was ignored for determining things like context root. Glassfish, on the other hand, uses the entire war name. So while the services were working, and deploying correctly, you needed to have the correct number in the URL when accessing the service. Rather than change all the services to include numbers in the URL, I went looking for another solution. Thanks to the java.net forums (which I found to be an excellent resource throughout the project) I discovered that you could set the context root in the sun-web.xml file of the web app (which then sprung into existence for all our services).

A fairly obvious solution, to be sure, but less so when you’re learning.

The second was finding a deployment solution for our JDBC resources (this, of course, covered more than just the RESTful services, as the EJBs also used them, but this was the first area I hit the problem in). Adding and configuring resources via the Glassfish admin console is very easy, and I had no trouble setting up the resources, but navigating a web console isn’t the most friendly method for a more automated install process. The java.net forums once again proved their worth, leading me to the solution. In this case, the solution is the add-resources command that is part of the command line administration tool.

This solution was doubly nice because we already had XML files for defining our resources in JBoss, and the formats were similar enough that creating the new files was mostly a matter of XML wrangling. This solution also nicely covered other resources, such as the few queues and topics we use for communication.

With those two things taken care of the RESTful services happily took up residence in Glassfish. And with the RESTful services out of the way, it was time to tackle the EJBs.

The basic line of my thinking started with the following: I like the idea of a blog, I just haven’t been very good at the execution of a blog. As I thought about it from there, the reasons why I wasn’t very good at writing the blog became apparent.

One reason is best illustrated with an example. I have been sitting on a post about my Costa Rica trip for over a week now. I haven’t published it because I’ve been waiting to get the pictures developed and uploaded to Flickr. My original plan was to make this post after the Costa Rica post was published. But because the Costa Rica post was basically stuck in the unpublished state, this post wasn’t happening either. Normally, the post that’s blocking me from writing anything is all in my head and so nothing ever gets written. This sort of behavior has sentenced many previous post ideas to death.

But the biggest reason is that what I want this blog to be has changed. I’m not really interested in trying to document the things that go on in my life, which is basically what I’d thought of as this blog’s purpose. After thinking things through, I decided it was better to do something else with this blog, something I’d be more interested in writing about. After all, I still like the idea of a blog, and the blog software and domain were already set up, so it seemed a shame to let it languish or to remove it.

And so, I’m making this post to announce that this blog is now going to be a place for me to talk about technology. A pretty open-ended topic, to be sure. But with this change I can cover a lot of ground that I’m actually interested in writing about. For example, there are interesting technological decisions and happenings going on at my job, which are cool and I’d love to share (though obviously there’s some detail that must be omitted). And I can talk about gadgets and such, because I really dig that sort of stuff.

That’s not to say that I will never make non-technology related posts. There’s still cool stuff I occasionally do that I do want to share, like my Costa Rican adventure. And it will likely be better and more interesting than what I was trying to do anyway, because it will be fun and cool stuff that I’ll want to spend time writing about. If you really want to skip out on the tech blather, feel free to point your browsers to this page or your RSS readers to this feed.

Oh, if anyone has a better category name than “Non-Tech”, I’m all ears.

I’ve contacted the monitor manufacturer to see if there’s anything they might be able to tell me or do to fix it. In the meantime, I’ve pulled out my old 17″ CRT monitor and am using that. And having used the LCD monitor for so long, going back to the CRT shows me exactly what I gained by going LCD. Oh well, the silver lining may be that I finally get to satiate that widescreen LCD monitor desire that my MacBook Pro instilled in me.