Showing posts from 2009

A few quick notes

It's been a quiet few months. I haven't worked on too many things I've felt like writing about. That's not to say I haven't been busy. One thing I've been reading more about building great teams and delivering more to our customers. I'm just starting to read Creating Magic: 10 Common Sense Leadership Strategies from a Life at Disney . Obvious from the title, this book outlines the approach Disney teaches all of it's Cast Members (employees) on how to be great leaders and provide their visitors with great experiences. I've been wanting to read this for some time and I'll be sure to write more as I work my way through it. Some related blog posts I've enjoyed recently are: The Duct Tape Programmer from Joel on Software where he reviews a chapter of the book Coders at Work . The post basically talks about doing the simplest thing possible to get something out the door and into people's hands. Amen to that! I've also been enjoyi


I was inspired by this talk from RailsConf given by Robert "Uncle Bob" Martin. It's a really entertaining talk and you should check it out if you haven't already. During the talk, the topic of professionalism came up and what it means to be a "professional software developer" (maybe 2/3 of the way through). Professionalism in software development is a topic that's not well defined and certainly has different meanings to different people. Can you be considered a pro, for instance, if you don't provide a set of automated tests for your code? What if you don't use source control? Do you feel the need to always create a custom build file (make, ant, or maven script) so you can build independent of an IDE? Do your "professional" standards change depending on if you're creating "prototypes" rather than designing code for production? I know which things I strive to do on every project I work on. But the standards for the t

More stuff to get excited about

Chrome OS I'm excited about Google's announcement to release what sounds like an ultra lightweight OS to basically surf the Internet. I'm hoping this device will allow me (and others) to breathe new life into old, underpowered laptops, allowing them to essentially work as netbooks. This could also open up new and inexpensive opportunities for schools to recycle or prolong the life of expensive computing equipment and expand horizons of their students. I've been watching the One Laptop per Child (OLPC) movement for some time and I see this as another avenue toward their goal. I don't share the optimism that this OS will somehow replace Windows. Sometimes you need extra horsepower and functionality. I edit a lot of photos and create some simple video, but the web tools I've tried to do either task can't hold a candle to the four-year-old version of Photoshop Elements I own. I'm not sure CPU intensive apps like this will port very well to the web.

Interesting Tidbits

It's been a while since I had a post to talk about some of the new(er) technology I'm just hearing about. Here are three things that got me excited recently. First person user interfaces I came across this article on First person UIs . Basically it works like this: you have a location aware device like a smart phone with GPS and a camera. You're walking around and you see a historical building, business, or other point of interest (POI). You point the device's camera at the object and WHAMO - you instantly get a bunch on info about the object. This can include the name of the POI, how far it is away, a phone number to call, a history, and a bunch of other interesting tidbits. It will be like having a virtual tour guide in your pocket. This is very cool! This concept is also called "augmented reality". Google App Engine, Big Table, and more on the Cloud I recently watched this talk on Google App Engine . I've been watching Amazon's EC2 for s

Maven - Why not?

I guess I still get a little surprised when I see code for a Java project and there's not an automated Maven build. These projects often have an Ant script (many times the default one generated by Netbeans or Eclipse), but seldom a Maven POM file. I wonder why? Especially since Maven is so easy to use and really adds value over a vanilla Ant build. Maven takes an Ant build to a higher level of abstraction to where it's easier to manage and change. What I think I like most, is the idea of the Maven repository. It's a nice way to store and share application dependencies. In a typical Ant project, dependent JARs will be stored in source control along side the source code (typically in a lib directory). This can make initial checkouts of these projects S-L-O-W. Compounding the problem is when a set of projects use a framework like Spring. Each project will store it's own set of Spring jars with the source, forcing developers to download the same set of jars mult

Spring Revisited

Recently I retrofitted some code I was working on to utilize Spring . It's been some time since I'd used it and I'd forgotten how much I enjoy coding in this framework. It really helps me write better, cleaner code. As developers, we always strive to create plug-and-play architectures - you know, code to an interface, achieve easily swappable implementations, etc. That in itself really isn't that hard to do, but Spring really shines in enforcing this idea. My original code (for Jena) needed to grab some Resource references from the model and looked something like this... {method declaration} OntologyModel model = {get model reference} URI resourceUri = new URI(""); Reoruce myResource = model.getResource(resourceUri); {additional business logic} The equivalent Spring configuration replacement for this code looks like this... <bean id="myResource" class="com.myCompany.Resource" factory-bean="

Jena Lessons - More On the Reasoner

Back when I started working with Jena, my first "ontology task" was to iterate through a subset of objects in the model, perform some operations to slightly modify these objects, and then store the objects back into the model. Sounds simple right? In a traditional database application, this program would consist of a SELECT statement, followed by some business logic, and conclude with a SQL UPDATE . I've probably written code like this hundreds of times. It's simple and runs quickly. On paper, the ontology task seems even easier. Once opening a Jena ontology model , you can query for objects ( Resources ) in any number of ways (including a SQL-like SPARQL syntax). From there you simply create or modify properties on the resource. Since the ontology model is in memory, the changes happen real time (no need for an UPDATE ). And while you could persist the changes, there really isn't any need to. While this seems quite easy, I noticed severe performanc

Mentoring - Reading List

Since outlining a brief list of online technical resources for my rookie coder, I thought it'd be a good idea to also supply a brief reading list of technical books that could have a place on any programmers shelf. For this list, I wanted to focus on books that provide transferable skills - suggestions of different techniques and ways of thinking than someone might otherwise be exposed to. This knowledge can be able leveraged regardless of specific technologies or platforms. Here's the list: Core J2EE Patterns – I have an earlier version of this book and it’s a solid J2EE reference. The real benefit in this book is the set of J2EE architectural patterns (which builds on the Gang of Four [GoF] core patterns) and would also apply to server side development in .Net. Some of the info on JSP or EJB may be a little dated with recent additions to the Java language, but still a great reference. Patterns of Enterprise Application Architecture is another great book with a similar

Jena Lessons - The Reasoner

Earlier this year I started to work with ontology , specifically utilizing Jena to process and manipulate an ontology model. I thought it would be good to share some of what I'm learning as I gain experience programming in this environment. I thought I'd start with a quick discussion of the Reasoner . First, let me give my 10-cent understanding of ontology and where the Reasoner fits in to all of this. For me, it's easiest to think of an ontology as an object store. There are classes, and the classes can be related to each other in a number of ways. In an object oriented sense, these relationships can be associations , aggregations , or through inheritance . Both the class definitions and the instances of these classes are stored in the ontology. Like a regular Java class, an ontology class definition might include a supertype and some distinguishing properties. When an instance of the class is created, the instance gets a unique name (a URI), at least 1 statement

Mentoring - Online Technical Resources

As I stated in my last mentoring post , one thing new professionals need to learn is how to stay technically current and continue to grow their skills in the absence of formal training. Here's a list of some online technical resources and tools I think any new professional would find helpful. Martin Fowler's Bliki . Martin Fowler always has interesting things to say about object oriented design, agile development, and software development in general. He is a thought leader and always says smart things. InfoQ This site has a ton of info about a ton of software development topics. What I like most about this site is that there are a lot of videos. I learn better this way. It’s nice to watch someone explain a topic and see the examples. Here’s a Martin Fowler presentation on InfoQ about SOA and ESB. StackOverflow . This is basically a Q&A site for software developers. It’s fairly new and high quality. If you really get stumped on how to do something or want

Early Adoption?

When is the right time to adopt some new technology - the shiny "silver bullet" solution that's going to meet all your current and future business needs, make your team ultra responsive to your users, and totally allow you to kick butt? Before screaming "get it now! get it now!", consider the following. This technology is new, cutting edge stuff. Not many people are doing it. Where can you find help and support when you inevitably hit some road blocks? Will you be forced to troll message boards and user groups for solutions? Will you be using the technology in a way that hasn't really been anticipated, pushing you out even further from the mainstream and making it even harder to get good support? Is this a technology you're buying? If so, how's the company's technical support and reputation? What success stories can they point to? Can you "make do" with some existing (better supported, more widely implemented) solution until thi

Mentoring - Intro

Recently, I was asked to act as a mentor for a junior level developer. It was a little awkward in as much as I hardly know this person - we've only briefly met, we're not working on the same team, and not even for the same company. I'm not even sure what to topics to mentor on. Remembering back, one of the hardest things for me when I transitioned from a college setting to professional was learning how to stay current and continue to push my skill set forward. Until graduation, you're continuously being fed information and guided on what to learn. After, you need to learn to forage for yourself. Learning how to do this and where to look is where I thought we might begin. Like any new relationship, I thought the best place to start was with a brief introduction, then see where I might be able to best help this new professional. Here's an excerpt of my introductory email: (Introductory text..) Just to give you some insight into my background, I've been profe

Technical Debt

This topic seems to be pretty popular lately. First I saw Martin Fowler's comment on technical debt last week. Then Jeff Atwood brought up the topic in this week's StackOverflow podcast (@53:30). Basically, technical debt is the price you pay down the road for a "less than optimal" design choice today. I particularly liked Atwood's metaphor that you know you've incurred technical debt when you give a long sigh every time you need to modify some part of the code base. You know that the changes are going to be painful (and expensive) to make. It's time to refactor. A few comments based on my experience. I've been noticing less technical debt in my own code since starting to follow a test driven development approach more religiously. Maybe there's something about this approach which makes your code more "real than theoretical" from the start. It helps you make better decisions without thinking about it too much. Maybe it's becaus

Value Teamwork

Nova's episode this past week was titled "The Spy Factory" . It wasn't quite what I expected, but it was fascinating. Basically, it was about the NSA and how it was tracking Al Qaeda members and their movements (in the US), long before the September 11 th attacks. It also touched on the CIA and how they also tracked Al Qaeda movements into the US. The CIA approached the NSA to share information (since they couldn't legally conduct a domestic investigation on these potential terrorists) but the NSA refused to share any information. Once Al Qaeda activity came stateside, it seems neither agency alerted the FBI. It all seems so foolish. All of these agencies are supposed to work together for our common safety. Was their unwillingness to work together driven by ego, politics, the desire to be national heroes, any or all of the above? Obviously, this sort of behavior is not limited to government offices. I've seen this same behavior on teams and in org

I Don't Know

Why are these three words so hard for some people to mutter? The fear of being caught without an answer is so scary, that some people will say anything to avoid having no answer at all. It's a big problem. Consider this: you ask a question and you get an answer. You accept the answer as true because you think, "why would someone mislead me?". And you're right, they're not intentionally misleading you, but they have an intrinsic need to give you an answer - any answer - so that they don't "lose face" or something. I just can't wrap my head around this behavior because most likely, you'll take some course of action based on the answer to your question. But when you start to notice things - things that don't make any sense and couldn't possibly happen if the information you got was correct -you'll spend a lot of effort reevaluating your beliefs and doing your own research. Eventually (and after some frustration), you'll fin

New Surroundings

I would really like to post more often, but frankly, I've been too busy. The New Year brought a change of job scenery and I've been really busy getting up to speed and learning a ton of new things. That's not to say I haven't been writing at all. As I come up to speed here, I'm taking the opportunity to capture what I learn in a development wiki. My new team has a wiki instance in place, but it's been lightly used to this point. I'm a huge fan of using wikis for development . I like to leverage the wiki as a focal point to capture technical ideas and documentation for the team. Most people seem eager to contribute, so I hope it takes off. One point here, we're using the wiki included with SharePoint . It's not nearly as hard to edit as MediaWiki (the Wikipedia wiki engine), but I still prefer MoinMoin (used by many Apache projects). The heart of the software being built here relies on Ontology , and leveraging the data stored in that ontolog

Happy 2009!

As the work calendar turns to 2009, it's natural to reflect on the past year. Professionally, 2008 was a very frustrating year. Part of it had to do with the tools I was using, part of it had to do with the project I was working on, and a lot of my frustration was that I felt like I wasn't being heard. Instead of rehashing some of the difficulties I've experienced over the past year, I invite you to read some of my previous posts . So, how do I hope to course correct in 2009? Do More Many times in 2008, I found myself waiting for others to complete some part of their work so I could do mine. Other times, we hit limitations of the development platform we were working on and waited for management approval for how we should proceed. In these instances I often had an alternative in mind for how to proceed, but didn't. I instead hung back and tried to let others do their jobs, make their own decisions, and get consensus on an approach. I regret this approach. I wish I h