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.

Atlas is microsoft’s framework for developing Ajax applications for ASP.Net 2.0. The latest is now the march CTP -moving up from ‘beta’ status to ‘community technology preview’. As much as I loathe the ‘ajax’ name and all of the hype around this old stuff – It is still as cool as it was when we did it 3 years ago (or longer).

-Chris

read more | digg story

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

Well, I have often complained to my teams that “you should never try/ catch everything – and eat it up without letting anyone know”. Now – I have an example from a current project where I found some scary code this week. Thankfully this is not representative of the entire codebase.

Do you see what we have here:

This is a friendly recursing stack exploding problem. If we get ANY exception during the ‘try’ block – then the desired effect is just to set the _issuerID to a default value – 0. However – due to a ‘typo’ the call actually does what??? It calls back to the same property getter, then – the same thing happens again and again and again and again… you get the picture.

To make matters worse – lets look at another bit from this 1 line try block…..

Now – if we were to go through the exercise of delving down into all the calls in the _fullTrade.InstrumentID – we would see the same lovely pattern of – “try/ catch everything eat it”. This means that when we call that property, We get even more eaten exceptions that we are unaware of.

Now – lets take this and look at the real effects of this: Lets say that we load 1000 instances of these objects. Then lets say that we need to put all 1000 of these on the screen somehow and we call this particular property. If were to make 1000 calls like this and all 1000 calls threw and ate 6 errors – then we are ‘eating’ a hidden 6000 thrown exceptions. You witness my dismay herein.

In any case – the argument that I was presented with by the perpetrator was; “it makes the code easier to read to not have all the ‘precondition checks’ etc. before just executing the 1 line of code”. That is an admirable goal – to have code that is easy to read. This must be measured with the desire to not throw and eat 6000 exceptions.

Thankfully – someone was nice enough to put in this recursion error that I happily found and expelled. In addition to the joy of killing a bug – I got to purge a bad practice from the project – NO EATING EXCEPTIONS BLINDLY!

-Chris

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

While reading Sam Gentile’s blog today I came across an article regarding the SCBAT (Smart Client Baseline Architecture Toolkit) and GAT (Guidance Automation Toolkit). I was also discussing this stuff this morning with my friend and collegue Marc. In any case – this stuff reminds me of something I had advised doing (and have begun doing) for a current project. It also reminds me of something in Rails.

The essence of all of this stuff:

You have some application patterns, structures and practices. You want to create all the ’stuff’ you need to use the architecture pattern effectively and efficently, with as little confusion as possible.

For example:

In the now famed Rails web development framework – when you want to create a new project, new view/ controller etc, you just issue some command line .. commands.

For example – to create a new application you can issue a command like:

rails path/to/your/new/application

This will create the folders, base files, etc for your new web application: folders for views, controllers, models, etc. You can also use the rails generate command to create new controllers etc. like:

rails script/generate controller SomeController

Now you have the basics of your Rails application.

SCBAT with GAT

Now – looking at the SCBAT – these great fellows are trying to do is to allow you to enter some data – and it will spit out all of the folders, code etc to make a compliant CAB application. This automates away all of the grunt work, it makes it clear what is needed and it provides the guidance needed to use the frameworks. This is what Sam is talking about in his post here. Cool stuff – making it easier for the team to work effectively with the frameworks.

Frameworks/ System architectures for non-trivial applications are complex. It is a fact of programming life. That being said – doing as much ‘Guidance Automation’ as possible sets the team up for success and takes away increasing amounts of potential error.

Prototype Spiked for a current project as Guidance Automation

I will be leaving my current project (a credit derivative trading smart client application) in 6 weeks. I will be going to a new project (FX options trading stuff). As I have been trying to set up the team I am leaving behind up for continued success using the application infrastructure we have developed – I considered making a custom sort of code generator that functions as these other GAT type things/ Rails type things do… it would take the basic data and go create all the classes, events, folders, etc needed to use the framework effectively.

A screenshot of the basic code generator.

In a few hours I was able to create an application that would take in the information about what the View was to do – and to automate the creation of many classes needed. Since we are using a Model/ View/ Presenter pattern where the View communicates with the Controller via events, there is a set of pattern classes that we can simply create if we know what the view/ controller are trying to do. Hopefully before I leave here – I will be able to leave the team with their own custom Guidance Automation type applicatio that will help keep them on track. This was in truth inspired by how rails works. I am looking forward to using CAB, SCBAT and enabling more and more code generation and other types of guidance automation.

-Chris

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.