Active RDF – is a set of tools for semantic web work using ruby. I have been looking at the Redland RDF Application Framework from Dave Beckett lately. I believe this makes use of it – good stuff!

read more | digg story

You can leave a response, or trackback from your own site.

I am leaving the project that I am leading currently in a few weeks. Today I began handing off the lead to one of the developers on the project. The task of getting the entire team ‘on the beat’ of the project and keeping them there is key for this person to be able to maintain. One of the other developers was asking me today what he could read/ do to ‘totally revamp and update his code style’. In trying to introduce agile practices to a group – the group has a lot to change.

Some of the stuff that we introduced:

• Mock objects (Rhino Mocks)
• Unit testing (NUnit)
• SpringFramework.net
• log4net

Design Patterns including
• Model/ View/ Presenter based architecture
• Strategy

I sent him some of the books, articles etc. that I usually recommend. This chat however got me to thinking – what does it take to become a great developer? There are really 2 transitions that I was thinking about; the transition from a mid-level to a senior developer, and the transition from being a seasoned developer to a world class developer. In the past I have said that the central thing that I am looking for in a developer is someone who is effectively a ‘Good abstract problem solver’. I still think this holds true.

That being said – there are some foundations that I typically look for in a developer – particular mostly to C# and Java developers, but much is also applicable to other development.

Principals

• Inversion of control – see Pico Container, Spring, Martin Fowler, Object Mentor
• Open Closed Prinicipal – see Object Mentor
• Seperation of interface from implmentation – see Object Mentor

Design

• Model domain in software – see Domain Driven Design
• Learn the ‘classical design patterns’ – see GoF book and language specific variants

Code level

• Design by contract
• Assertions
• Guard clauses
• Intention revealing interfaces – see Domain Driven Design
• Effective class composition – single purpose classes and methods
• Learn the Refactoring Patterns – see Martin Fowler

Language Level

• Understand the runtime you are working in
• garbage collection
• how the heap/ stack work
• Threading – deep understanding of concurrency issues
• Be able to program in at least a few different languages

Enterprise

• Understand Databases
• Understand messaging systems
• Understand XML
• Understand heterogenous as many system interoperation mechanisms as possible
• Understand web services
• Understand security concerns

What does it take to be great? A thirst to learn. A thirst to experiment. Coding is what makes you learn. Working with smart people will help you learn. Doing ‘pet projects’ will help you learn. Stretch your ara of comfort all the time. If you think C is hard – do a pet project in it. If you are intimidated by C#, Java, Ruby, Web Services, ANYTHING – just try it – you will see how much more alike they all are then you think. You will also learn to love the differences and functions of all.

I will continue to update this as I need to run

-Chris




You can leave a response, or trackback from your own site.

A great article (*warning* PDF) chatting about the match that could/would exist between Ruby and the Semantic web technologies.

I agree that the match between the way of ontoloties and and the way of languages like Java and C# may be off.

I will be curious to see if any supporting frameworks come about in this space.

-Chris

read more | digg story

You can leave a response, or trackback from your own site.

I just wanted to make a few quickie comments on mock frameworks. I have been using Rhino Mocks daily. It is great. In the past I had tried NMock and just found it too clunky.

In short – NMock leaves you with a lot more ’stringy’ stuff to deal with. Rhino is MUCH more in the language. You type normal code. Your refactoring tools work. Your IDE helps you, etc.
The purpose of using a mock framework is basically so you can just work on testing the CUT (class under test). The CUT should usually be the ONLY concrete class in the test. This all works when you are practicing IoC. When you are using IoC – you pass in dependencies from the outside. When you do this – and you are seperating your interfaces from implementation – you can pass mock interfaces to your CUT. Once you do that – the mock can act as a spy.

1. The mock lets you wriggle into code branches so that you can test pieces of the code that are otherwise difficult to get to.
2. The mocks make your tests simpler. You do not have to instantiate lots and lots of classes correctly – you just set up interfaces and expectations and you are good.
3. The mocks make your tests more stable. You do not have to worry about changing test data etc.
4. The mock can act as a spy and tell you if it is being treated as you expect while it is ‘on the inside’

This used in conjunction with a code coverage tool (like Clover or NCover) helps you to really work your tests to cover your codebase fully.

Carry this over to the Java world – Rhino is much more like EasyMock which I am now writing some tests with. I had formerly used JMock (sort of like NMock in usage) – but I just replaced my jar reference and updated several tests. The tests are immediately more understandable, cleaner and therefore – better.

More another day – Maybe I will get around to posting comparison examples.
Chris

You can leave a response, or trackback from your own site.

It was only a matter of time. Ruby for .net CLR. This will be of marginal importance in the grand scheme I imagine, but ruby is lovely and so is .net.

Most ruby work will ultimately be on *nix machines, so I do not really see the value – aside from the fun/ cool factor. But it does have that

IronPython and Boo are 2 existing dynamically typed languages for the .net run-time. We shall see if adding a 3rd helps.

read more | digg story

UPDATED ** see RubyCLR for a MUCH more complete implementation of Ruby for the .net CLR. Great work!

You can leave a response, or trackback from your own site.

 

My ‘Big Boy’ Gabe                            My ‘Baby Boy’ Micah

      

My lovely wife Shannon (left)               Me.

       

You can leave a response, or trackback from your own site.

I was flipping through Fowler’s Analysis Patterns tonight. He uses the term “Conceptual Modeler” – I like that term. I think it is a very accurate term that describes a key element in software development : conceptually modeling the domain in the software. He also had a quote in the intro of the book that was something like

 

“Much of my skill comes from a knowledge of modeling techniques and how to use them”.

 

I also agree here. I think that much of the value I add to projects comes in the conceptual modeling. This is a notion that I think is often overlooked and more often under appreciated in software development. While I find myself being ‘anal’ as can be as a coder – and demanding the same of my teams – I believe that the modeling part is much more important than just the ‘raw coding’ part.

 

In maybe my all time favorite software book – Domain Driven Design, Evans talks about “conceptual contours”, “digging out concepts”, “supple design”, “making implicit concepts explicit” and “a model expressed in software”. These all echo the same sentiment that Fowler is indicating. In the end – there is an underlying set of real world concepts that we are trying to model in the software. Our task is to make the most useful software model of the real world domains that we are dealing with. We work with domain experts to elicit the real underlying ideas and concepts from them so that we can structure our software in a way that mirrors the real domain.

I often think that what I typically call “Modeling Sessions” are just about the most productive times that I have with my groups. Modeling Sessions are usually impromptu times when I grab 1 or more developers and try to model out some ideas. Since I generally do not believe in BDUF – so these modeling sessions are NOT a week long endeavor. Having a close knit team with extremely high levels of communication enables frequent, relatively brief modeling session.

Basically – we white board, draw on scrap paper and talk around the domain we are trying to model. We do our best to extract the most useful yet simplest model for the domain we are dealing with. Sometimes we have ‘impassioned’ debate (usually between 2 or more senior level developers that have modeled the item in debate differently in the past). In general these sessions have 1 goal – define a set of abstractions for this specific ‘item’. Often we have ‘class notes’ as an output of these meetings – some drawn out interfaces (used to describe behaviors) and perhaps some more ‘entity object’ type structures that model heiricacaldata and/ or database data. “Design patterns”, the classic ones, and the repeated patterns within our applications come up again and again in these meetings. You could hear us say things like:

1. “Usually you would use a strategy pattern for this type of situation” or

2. “In order to be consistent within the application, we did this thing in place X and this notion is similar – should we do it that way here?” or

3. “That thing you keep mentioning – the ‘…’ was it? It is not in the software really – lets make it absolutely explicit” or

4. “Wow – if we introduce this idea, then ‘…’ and ‘…..’ will become significantly more clear and easy to work with – it just makes total sense.”

Modeling sessions also enable more jr developers and/ or new team members to learn a great deal. I believe these sessions can accelerate the learning by ‘amplifying’ the knowledge in a context that is relevant. When people are learning abstract software development patterns and paradigms, out of context they can seem academic and useless. When people are seeing software modeling in practical context – relevant to their work, the ideas become clear, the patterns seem full of utility and fulfil their purpose.

In these sessions, patterns provide a great meta-language. The ‘classical patterns’ and the patterns that are part of the domain model your team has developed become the meta-language of these modelling sessions. You do not really have to say “We can just make a class – who’s only job it is – is to create concrete classes that are derived from this abstract base class”. In stead – you just say we need a ‘factory’. This is also something that Evans talks about in Domain Driven Design – he calls it the “Ubiquitous Language”. When the team is comminicating frequently and effectivley – using a meta-language of ‘normal patterns’ and patterns that are specific to your teams domain model – much more can be accomplished.

Anyhow – modeling sessions – take your team, work with them. Do architecture as a group – this is often a series of ‘modeling sessions’. Software developers really should be 1st class ‘conceptual modelers’ not just ‘coders’.

 

-Chris

You can leave a response, or trackback from your own site.

Dustin Matthews - long time friend of my wife Shannon and her brother Aaron – has died too young.

 Excerpt from the Raleigh News and Observer Obituaries:

DUSTIN MATTHEWS, 31, of Raleigh died Saturday, March 11, 2006.
A memorial service will be held 2 p.m. Saturday, March 18, 2006 in the chapel at the Cremation Society of the Carolinas, 2205 E. Millbrook Road, Raleigh.
Dustin was born on June 18, 1974 in Dunedin, Florida and, in 1992, graduated from Millbrook High School in Raleigh. He later graduated from the Body Therapy Institute in Siler City, NC and worked as a massage therapist. Dustin had a very active business with clientele that included Olympic track and field athletes. He had a passion for yoga, hiking and dancing. Dustin’s trail name was “Comet Kid” and he hiked the Appalachian Trail from beginning to end in 1996. He was a loving son and was well loved by many.
Dustin is survived by his parents, Janis and Audie Matthews of Youngsville; maternal grandfather, William A. Colman of Clearwater, FL; cousin, Amber Skinner of Winston-Salem; several aunts and uncles.
In lieu of flowers, memorials should be made to the Appalachian Trail Conservancy, 799 Washington Street, PO Box 807, Harpers Ferry, WV 25425-0807.

Dustin you will be missed.

-Chris

You can leave a response, or trackback from your own site.

Via : Obie Fernandez (a thoughtworks-er). This magazine ObjectView – looks pretty darn cool.

-Chris

You can leave a response, or trackback from your own site.

Eclipse has great integration with subversion. I have been using subversion for my personal sorce control for a few weeks now. It is working out great. I have been a strong perforce fan, but it is only free for 2 users – ~$750/ user for ‘real’ life w/ perforce. SourceSafe is the devil. ClearCase is the devil. CVS I have had issues with enough. Subversion it is…

Just a few niceties:
In the main workspace area – you can browse the structure of your current workspace file and get a nice diff against the repository file. This is great to have IN the IDE. Subversion is great – you normally do it from the command line – but having the high intagration with the IDE is really great – down to the diff.

It is also nice and easy to simply browse a repository and see what is there.

All in all – this is a great TOTALLY FREE solution for source control – and it is integrated right into the IDE. I am continually impressed by how far they have taken Eclipse. I will go into the latest edition of Ruby Eclipse next….

-Chris

You can leave a response, or trackback from your own site.

Object oriented software development is something that takes people time to get. Often I find myself pointing people to this this article to sum up why I am doing or something, why something feels right or wrong to me.

This is not a new article – I just find myself pointing people to this better explaination than I could give on more and more occasions.

Summary of principals:

The Open Closed Principle (OCP) ?
A module should be open for extension but closed for modification.

The Liskov Substitution Principle (LSP) ?
Subclasses should be substitutable for their base classes.

The Dependency Inversion Principle (DIP) ?
Depend upon Abstractions. Do not depend upon concretions.

The Interface Segregation Principle (ISP) ?
Many client specific interfaces are better than one general purpose interface

The Release Reuse Equivalency Principle (REP) ?
The granule of reuse is the granule of release.

The Common Closure Principle (CCP) ?
Classes that change together, belong together.

The Common Reuse Principle (CRP) ?
Classes that aren’t reused together should not be grouped together.

The Acyclic Dependencies Principle (ADP) ?
The dependencies betwen packages must not form cycles.

The Stable Dependencies Principle (SDP) ?
Depend in the direction of stability.

The Stable Abstractions Principle (SAP) ?
Stable packages should be abstract packages.

You can leave a response, or trackback from your own site.

Well – I have had several domains across the years;

• ChrisDonnan.com
• TradeWeapon.com
• ImpressionOne.com
• XmlPimp.com
• ..perhaps a few more.

In any case – Since I have been posting more and more not just .net related content. I figured I would re-register ChrisDonnan.com (i had let it expire) and go for it.

Wordpress has a big community, lots of extensibility etc. so it seemed like a logical move. In the past I would have not taken a ‘php’ product as I am not a hughe ‘php’ fan – but these folks have got it together

In any case – I am also experimeting with a wiki so I can have some of my standard stuff wiki’d. It is nice to have a domain again to put my stuff.

I managed to export much of my content (to rss and/ or opml) and import it into wordpress – nice. Hopefully I will stay put for a while here.

-Chris

You can leave a response, or trackback from your own site.