Loosely Coupled

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

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

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

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

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