Friday, August 26, 2005

Training and Coaching

I just found an old article that I co-wrote back in 1997 for Computing Canada. The article was really a reader's digest version of a report I wrote for an application audit (a really intensive code review after-the-fact). It was a PowerBuilder app and the article makes reference to some PB-specific technology but reading it again 8 years later I'm surprised to realize that so many of the same things apply to the way we build apps today.

Too often, I see relatively junior programmers unleashed on software development projects with little or no guidance or leadership. As a matter of fact, I've probably spent two thirds of the last year rewriting year-old software that was created by junior resources with no training and no concern for best practices. I can see why companies are lured into using resources like this. They're relatively cheap, they're pretty keen, they work long hours and they really crank it out. But if they don't know what they're doing you end up supporting the old adage "there's not enough time to fix it now, but there's always time to rewrite it later".

The biggest thing that junior software developers don't do, is separate concerns. UI, business logic and data access get all tangled into one big incoherent mess. I stress that there must be some cohesion in your domain model. Generally speaking the closer you get to the users the more your code is exposed to change. In other words, the UI is going to change. Count on it. As you go up through the layers things change less and less. By the time you get to your domain model and the relational model that allows it to be persisted, Things are very stable and any change you must make to them has serious repercussions on the rest of the app. Therefore get that stuff right. You can be forgiven for cheating a bit when you get to the UI but at least build the backend stuff as well as you can. And feel free to use some junior resources, but for crying out loud, lead them.

Luxury Foosball


I recently took up a collection to replace a couple of foosball men on our Harvard foosball table at work. If you've ever seen one of these tables you know that the original men and the replacements are pretty boring looking. So a few folks around the office had some fun photoshopping, combining the heads of people with men on a rod. Well it appears for a mere $73,000 you too can get a table with tiny little replicas of friends and family.

Monday, August 22, 2005

Target: Adobe

Microsoft is making some moves that look quite threatening to Adobe. Microsoft is building applications to replace Photoshop (PSD) , Acrobat (PDF), and now Flash (SWF). Microsoft's calling it's Adobe-killers Acrylic, Metro, and Sparkle. A little more of that embrace, extend, and extinguish we all love? Maybe.

By the way, with the new Core Graphics, Core Image, and Core Video frameworks in Apple's Mac OS X, I suspect that Apple has laid the foundation for a similar move if they think it's necessary. But Adobe got its start with Apple, and Apple in turn uses PDF everywhere in Mac OS X so I think Apple contributing to Adobe's demise is a much less likely outcome.

Monday, August 15, 2005

Interviewing

In my current position I'm the lead Java developer because I have the most experience and know as much as, and maybe even a little bit more than, the rest of the people on the team. Part of my strategy to keep my skills sharp, is the routine investigation of other languages and tools. Most recently those languages have been C# and ObjectiveC (and their related frameworks, .NET and Cocoa respectively). Apparently my boss took note of my new knowledge and a few days ago she asked me to conduct technical interviews for a "senior" Microsoft .NET developer.

I was a bit anxious about the request because I don't consider myself a .NET expert. But I approached these interviews the way I've approached all the Java developer interviews in the past. I try to cover a broad range of topics (e.g., Relational Databases, OO, Patterns, Object Relational Mapping, Unit Testing, HTML, insert programming language here , etc.) and just substituted the Java questions for C#/.NET questions. What surprised me is the quality (or the lack thereof) of the people I've interviewed. Maybe I should be looking for a .NET job? ;-)

Wednesday, August 10, 2005

EJB3 Presentation

It seems like EJB3 information is coming fast and furious now. The Server Side is hosting a new EJB3 presentation recorded at the Belgium Java Users Group. One of the speakers is an Oracle Toplink developer. It gives a very good overview of the EntityManager API that I was talking about the other day. Check it out.

Virtual Globetrotter

Google Maps has obviously inspired some people to check out the world from a whole new perspective. Check out the Eiffel Tower or the Great Pyramids. And when you're through with that go check out Sightseeing with Google Satellite Maps or Google Sightseeing. Be careful, just like the real thing, sightseeing this way can waste a lot of time.

Monday, August 08, 2005

EJB3 EntityManager

Since my first post about Entity EJBs with Hibernate, the Hibernate team put out a new beta implementation of javax.persistence.EntityManager. So I wondered what exactly it would take to jettison all the hibernate imports from my class. Well it turned out to be pretty simple. First I substituted the hibernate.cfg.xml file for a META-INF/persistence.xml file that looks like this:

<entity-manager>
<name>manager1</name>
<properties>
<property
name="hibernate.connection.driver_class"
value="org.postgresql.Driver"/>
<property
name="hibernate.connection.url"
value="jdbc:postgresql://127.0.0.1:5432/myDatabase"/>
<property
name="hibernate.connection.username"
value="darcy"/>
<property
name="hibernate.connection.password"
value="darcy"/>
<property
name="hibernate.dialect"
value="org.hibernate.dialect.PostgreSQLDialect"/>
</properties>
</entity-manager>

The interesting thing about this is that it autodiscovers the annotated classes. No longer do I have to individually list each persistent class. Secondly, I changed my main method to look like this:

public static void main(String[] args) {
EntityManagerFactory emf =
Persistence.createEntityManagerFactory("manager1");

EntityManager em = emf.createEntityManager();
try{
Brand b = (Brand)em.createQuery("select b from Brand as b")
.setMaxResults(1)
.getSingleResult();
System.out.println(b.getName());
}finally{
em.close();
}
}

You can see that this code is very similar to the Hibernate code that I posted earlier. Obviously the class names and some of the methods are different (like getSingleResult() instead of uniqueResult()) but at first glance it looks like getting started is pretty easy. It'll be interesting to see some of the differences between Session and EntityManager.

Tiger Development

After installing Mac OS X Tiger, and restoring applications and user data, my next job was to install development tools.

Java

On the Java side: I'm a bit perplexed why Apple doesn't ship their Java 5 implementation with Tiger. As far back as I can remember they've always shipped the latest and greatest. But this time I had to download. No big deal, but it's hidden on their website. I expected to be able to go to connect.apple.com (their developer website) click on "Downloads>Java" and it would be there. But no, only the Java 5 docs are there. Instead I had to go to the general Mac OS X website and go to the downloads section in there and search for it.

Anyway, that was only a minor annoyance. I was able to download it and install it without any trouble. My next problem was that Java 5 wasn't made the default VM. So I had a little more googling to do before I discovered a couple symlink changes would make everything happy. In the end I have all my Java apps and IDEs (i.e., Eclipse) working with the new Java 5 VM and all is well a week later.

Cocoa

Next thing was a move to XCode 2.1. I downloaded it and installed it without any issues (there was a nice big link on the Apple's developer connect website). I was able to open all my Cocoa projects, recompile and run without issue. So then it was time to move onto seeing what's new in Cocoa in Mac OS X. There's quite a bit, but the one that instantly attracted me was the visualization tools in XCode.

I've always been a big fan of modelling tools and the diagrams they create. I always find it easier to express ideas in a picture and it's always easier to look at a diagram rather than gobs of source code to figure out what someone else was thinking. Well apparently Apple feels the same way. XCode now gives you the ability to generate class diagrams from your source code (Java, Objective-C or C++). And these diagrams aren't static either. As you change things in code the diagrams reflect those changes. Fortunately, they look and behave like UML class diagrams so the symbols are pretty familiar.

Apple also uses this new diagram facility in something they call CoreData. Essentially you create an entity relationship diagram that describes the data that your application maintains and then at runtime, the core data framework will use this metedata to store and retrieve user data in an XML file or a SQLite database. Couple this with the Cocoa Bindings framework, which allows you to bind object properties to UI widgets, and you have some great facilities for building data-centric applications. Now that the persistence and UI parts of the application are taken care of by the Cocoa frameworks you are left to concentrate on the business logic. The big limitation in CoreData right now is that it's XML and SQLLite only. That means if you want to create a multiuser application with an enterprise database server you're out of luck. Secondly, even if it did allow you to go against an Oracle or Sybase server I don't think the tools are really designed for fine grained control over the object relational mapping or the queries that are generated. But I don't want to diminish the productivity of this framework in addressing the the single user data persistence problem. If I was developing a desktop Mac OS X application, I'd be all over this. Here's a nice little tutorial that you may find interesting.

There is also a nifty little feature that allows you to drag and drop an entity from the diagram into a window in Interface Builder and generate a default UI. Apple says you can use this feature to quickly create a starting point for your application or to quickly generate an application to exercise your data model. I was impressed that I could create a fully functioning application that maintained data with no code in just a few minutes!

Monday, August 01, 2005

Tiger!

Well I took the leap and bought Mac OS X 10.4 Tiger today. I also followed the recommendations on the web (kinda of a herd mentality) and erased the hard drive and reinstalled "fresh". That second internal SATA hard drive definitely came in handy for backing up applications and the stuff in everyone's accounts. A few hours later I have everything back to normal (I think). My first impressions is that the Dashboard is pretty cute but I'm not sure how useful (although the calculator came in handy once already). Spotlight is definitely nice (and fast too). Searching for anything across the disk is pretty wicked! Well it's late, and time for bed. I'll post info about the ugly stuff once I come across it. ;-)