Loosely Coupled

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...

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...

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...