Chris Donnan : Programming - Brooklyn Style

Outline for Spring Framework presentation0
chrisdrop posted in java, c#, patterns and principals, programming, .net on April 30th, 2006

I am planning to do a Spring Framework (.net, java)seminar at the new Finetix office. The general gist is that I would like to cover the .net and java implmentations and I would like this to be open to the public. I already spoke to the Spring.net folks and they will make a post when I have a date sorted out. I imagine I can get the original java based Spring folks to post as well. Anyhow - I was asked to put together a general overview - this post will cover my initial thoughts. I hope that I can comple one of the folks in the Finetix office (perhaps a particular collegue that spent the past serveral years @ sun) to do the Java portion of the chat - while I will do the .Net portion. Below are the .net relevant thoughts I have so far. If one of the other guys will not do the Java chat - I surely will do it.

1. Intro to Inversion of Control
1. compare and contrast vs service locator
2. The importance of seperating interface from implementation
3. Eliminating the need to pass references through classes that should not need to depend on them
2. Defering singleton-ness decisions from implementation - when you can - INTERFACE BASED SINGLETONS
3. How IoC relates to testability
1. Unit test framework (NUnit)
2. Mock framework (Rhino Mocks)
4. Spring general components overview
1. Core Container
1. object factory
2. initialization method
3. getting properties off of objects in spring
4. prototype vs singleton
2. AOP - basic intro
5. Setter vs Construction Injection
6. A demo of Spring for implementing a large strategy pattern implementation (.net based)
7. The need for service locator in UI applications, Windows Forms, Swing UIs
8. Touch on Copeland Ruby example IoC container, PicoContainer, MicroKernel/ Windsor, etc.

That is about it - anyone with thoughts - put em out there.

-Chris

Bijection and “Subversion of Control”0
chrisdrop posted in java, c#, Development Tools, patterns and principals, programming on April 4th, 2006

So

Been using SpringFramework.net on my current project for ~5 months now. All in all - it has been very helpful in a few ways. One of the things that I have needed in the past was to associate objects created dynamically with stuff IN the spring context.

For example: I need to take some logon information at some point - with this logon information - I need to pass it to legacy objects that NEED to use constructor injection - else the throw exceptions etc. So - I want to push dynamically created content.

Enter Seam…

Interesting…. As usual - the folks at JBoss are doing interesting stuff. One of thier many sub-projects; Seam - “Contextual Components” is one of the more interesting things they have going on IMHO. Seam does lots of stuff - but this I found most interesting:
excerpt: (wouldn’t xlink/ xpointer be handy for things like this excerpt)

The notion of inversion of control or dependency injection is an elegant means for a container to assemble stateless components or services. But for stateful components it is insufficient. Subversion of control (or bijection) is a unique feature of Seam that allows auto-assembly of stateful components.

WOW. Isn’t that just fantastic! Bijection, Subversion of Control. Anyhow - I will be posting more about Seam as there are several truly noteworthy things that they are doing over there with Seam. This is essentially where a variable can be annotated with an “In” and/ or an “Out” marker. Then the container can get data off of and/ or inject data into, thus providing ‘bijection’ for objects created at runtime - with state.
(** this is NOT the same as this reference to ‘Subversion of control’ where a container ref is passed to the object.)
I will also mention - as I have in the past - that another alternative to Spring on .net (2.0 only) is the Object Builder in CAB is one of them. I would love to work on a ‘bijection’ update to spring.net, objectbuilder - or something new

Excited about technology as always.
-Chris

Mock Frameworks - C#/ .Net and Java0
chrisdrop posted in java, Development Tools, Agile Development, coding, patterns and principals, C++, programming, .net on March 24th, 2006

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

Why not to eat exceptions - an example0
chrisdrop posted in c#, coding, patterns and principals, programming on March 20th, 2006

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

SCBAT, Guidance Automation, Code Generation and Rails0
chrisdrop posted in ruby, c#, trading, Development Tools, coding, work, patterns and principals, Developers, User Interfaces, programming on March 17th, 2006

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

Software modeling sessions and being a “Conceptual Modeler”0
chrisdrop posted in patterns and principals, programming on March 16th, 2006

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

Microsoft CAB ObjectBuilder vs SpringFramework.net0
chrisdrop posted in c#, patterns and principals, programming, .net on March 14th, 2006

Sam Gentile has 2 recent posts that made me realize - I never blogged the most excellent Microsoft CAB (Composite UI Application Block) yet! First - let me say - that I am a huge fan of CAB. I have spent the better part of the past few years just building Smart Client applications. I have also spent lots of that time building a reusable Desktop Application Framework (DAF). This makes CAB right up my alley.

Many times looking at CAB I have had to say to myself “Well - they handled that aspect of the application this way - nice - we did 99% the same thing”. That is nice personal validation as well as nice validation for the teams that I have worked with. I have also said to myself - “Well - they certainly did that better than we did”. This is a great learning point. Sometimes - I have had to ask “well - should they (the CAB team) have done this more like we did - or like someone else did?”.

One of the things that I am wondering about presently is the Injection Model/ ObjectBuilder infrastructure.

IoC/ Dependency Injection/ The Hollywood Principal

See: @PicoContainer.org, @MartinFowler.com

For those not familiar with IoC (or another of it’s monikers) - the idea is pretty simple. You classes/ components should depend on abstractions (interfaces usually) and any dependencies should be able to be passed in via constructors (Constructor Injection) or setters (Setter Injection). Read the refs to see why if you do not follow - suffice it to say - it makes your code more flexible I and others have found.

Spring

In any case - I have been using SpringFramework.net for our desktop portion of our current application (Credit Derivative Trading Application for traders). The Java based middle tier members of my team is also using the original - SpringFramework for Java.

In spring - you configure dependencies in XML. So - lets say I was looking for the object with the ID “Views.MainBlotter”. This would give me some class (indicated by the “type” attribute). This would also set any constructor args (using “constructor-arg” tags) and/ or set any dependent properties (using “property” tags).

CAB’s ObjectBuilder

CAB takes a different approach. They use attributes on the classes to indicate dependencies. Then there are Builder classes (ObjectBuilders) that manage to specify the implementer at various stages of the application lifecycle (’the pipeline’ of lifecycle events moreover)…

There are several ‘out of the box’ strategies for setting properties including:

Table 1 – The stages of starting up a Composite UI Application Block application

Pipeline stage	ObjectBuilder Strategies
PreCreation	TypeMappingStrategy SingletonStrategy ConstructorReflectionStrategy
Creation	CreationStrategy
Initialization	PropertySetterStrategy PropertyReflectionStrategy MethodReflectionStrategy MethodExecutionStrategy
PostInitialization	BuilderAwareStrategy

The application blocks that use ObjectBuilder add specific strategies to the pipeline, and you can add your own strategies if required.

These strategies are all useful at different stages of the ‘pipeline’ of the application lifecycle. There is certainly lots of flexibility here with this set of object creation notions. I am not sure that it is all necessary - or that I like it as compared to spring - BUT this may just be because I am accustomed to spring. That being said - I am going to try some work with the ObjectBuilder infrastructure in CAB and we will see where I stand after doing an apples to apples comparison.

More eventually;

Chris

An old yet still applicable article all developers should read (IMHO)0
chrisdrop posted in coding, patterns and principals, Developers, programming on March 12th, 2006

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.

Ruby…. The dynamic language debate continued1
chrisdrop posted in ruby, java, c#, coding, patterns and principals on March 8th, 2006

So…. I spend most of my day typing C# code for the past several years. This is of course not to mention running dev teams to ‘get the job done’, being a husband, dad, etc. I also spend time writing Java code, Ruby code, when I need to - C++, etc, etc - i will spare the list. That all said - there is so much debate lately regarding dynamic vs static typing…. I think that there are some missed points in these debates as I have been experiencing while writing my C# to Java converter (lets call it Hydrogue).

Many of the ‘debates’ regarding static vs dyamic typing seem to have left out much of what my experience tells me are key differentiators. Most of the dynamic language fans say:

“Type errors are such a small part of the error spectrum - why be burdned by type constraints???. Focus on unit tests.” Sounds good - take away the ‘constraints’ of strong typing.

But:

1. Dynamic languages force you to know the implementation - or the type expected - how about that! This is the biggie in my mind. BREAKS ENCAPSULATION/ INFORMATION HIDING.
2. When data modeling - I WANT to know the types/ subtypes etc of aggregate objects (see 1st bullet too - I must go look around to see the ‘interface’ of an object/ sub-object)
3. Tools have a hard time helping
1. Refactoring support
2. Intellisense like support
4. “Duck typing is fine” - but it does NOT help me when I need to expect certain ‘interfaces’ will be passed into a routine. (related to bullets 1,2)

The worst of all of these has been point 1. Without knowing types of objects - I am constantly having to run around and look at routines innards to see what methods they will be calling on my objects I pass to them. If I pass an interface reference - this is effectively saying - you can call only these things on me - and I expect it. With out this notion - I need to go look inside and see what the client class will call…. thus breaking down encapsulation.

It is hopeful/ possible/ likely that a dynamic language IDE will support statement completion (Ruby Eclipse does MINIMALLY). When this happens - it will be beyond helpful. I find that even though it is ‘more code’ I can turn out more code in an automated fashion using IDEs that support refactoring, intellisense, AND INTELLIGENT find usages/ implementors, etc.

That all said - I LIKE Ruby. Writing Hydrogue has been fun, educational and useful. Just pouring over the C# language spec @ msdn has been worth the work as my understanding of the bowels of C# from the inside out have gotten all the more clear. The extra Ruby education has been great - and getting everyday back into Java has been great as well. I will just say that - either IDEs have to get smarter, or I do to be as productive with a dynamically typed language as I am with a strongly typed language.

My thought was, and continues to be - the right language for the right job. I am not convinced (as many others seem to be) that dynamic languages are ready to do the things that C#/ Java do (much less C++). Perhaps I will be more convinced to use Ruby for ‘bigger’ or ‘more complex’ applications eventually. I will keep working with Ruby and hopefully by the time the tools catch up - I can contribute to the community of developers that start with them…

Enough;

Chris

Spring.Net, AOP and other fun things0
chrisdrop posted in Uncategorized, c#, Development Tools, coding, patterns and principals on October 13th, 2005

Fowler Dependency Injection

Spring.Net, Cool AOP and other stuff framework. It seems some other Finetix guys are into this so I am doing some homework here.