I have had versions of all of this stuff installed for some months now. Stuff you ask… this stuff:

• Expressions Blend
• Visual Studio Orcas (and .net 3.5 friends)
• Visual Studio 2005 extensions for .NET Framework 3.0 (WCF & WPF), November 2006 CTP
• Infragistics NetAdvantage for WPF
• ReSharper 3.0 EAP

All of these things - individually are nice and fine-ish. They all crash and flop – but they are somewhat OK. Now that I am trying to really do productive work using multiple of these together – I am agahst at the pain in the (*&#$ that I am having with these darn tools!!!! All I can say is that I cannot wait for a single IDE that I can use to make WPF based desktop apps.

• Resharper efforts – abandoned in Orcas (hard to work without it I must admit!). Too many flops – ‘nuf said. This is hard for me as I am a die hard fan! Working for the most part in VS2k5+Cider.
• Orcas – does not play nice – crashes while working a good bit. I will say the designer seems more stable than the Cider (VS2k5 Addins) stuff. The best part is really the nice designer, which I cannot get to play with Infragistics, but is lovely for the “base stuff”
• VS2k5 Cider Addins – designer flops hard – often - painfully, but I am still using it lots
• Blend – happy to say – relatively stable, using mostly with Infragistics stuff – both play nicely. I am NOT happy that the code editing has to take place – elsewhere, I cannot get a good flow here yet (I guess again – i am lost without ReSharper ). NO XAML Intellisense ????
• Infragistics stuff – nice in general. Not too many flops that I can attribute to some IGistics-ism. Once designing in Blend, and editing it more in VS2k5+Cider works

Again – it all works - more or less, it is just not like normal work yet. My current mode is still – style in blend where I can (using some inline XML Data Source stuff to make it look like something). Edit in VS2k5+Cider (Resharper works for the most part), back ‘n forth. Orcas is basically out of the loop – except stand alone “play”.

Thus far – that is my story – may it improve soon!

-Chris

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

I am happy to be going to a Certified Scrum Product Owner Course this week in Boston. Having done the scrum thing for a number of years now, I am looking forward to speaking with and thanking the 2 people giving the course Ken Schwaber and Mike Cohn.

Ken Schwaber is one of the folks to really started scrum. Without Ken’s writings and efforts – many more of my projects would have been less successful. Scrum has been a key part of my software belief system for some ~4 years now.

Mike Cohn on the other hand has had a profound impact on how I have been doing “requirements”, software planning and estimation. I look at Mike’s work as a sort of 2nd generation of stuff on top of scrum. Mike’s work in using user stories as the product backlog has been instrumental in how I view “requirements”/ feature management – product backlog development. This set of work has built upon the initial “scrum stuff” in a way that has really helped deliver software.

This particular course is focused on the product owner role. I have been spending lots of time “getting together meaningful product backlogs” for all of the teams moving to scrum at my current firm. It is an interesting effort and challenge. I am also trying to coordinated stuff between multiple product backlogs, deal with lots of “technical focused teams”, “infrastructure teams” etc. In a big firm – there is a lot going on! It seems this course is right in the space I need some extra guidance. I think I am aware of all of the writing, newsgroups etc – and these resources have been extremely valueable in going about my business. I have all of the “textbook answers” – now – where the rubber meets the road in daily life – any extra guidance would be great.

-Chris

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

 

I opted for the mult-touch/ multi-view, lotsa RAM and the fast hard drives, vista biz… It rocks. I take LOTS of notes, then re-enter them in the computer(s) all the time. Then I also email that stuff around to myself a lot. I also make lots of pictures that I print out, and write on in meetings. I bring the same prints to lots of meetings to visually show ideas. I pitch ideas all the time – largely the same ones to different people – often. I know this will be a real value add to my daily work life!

-Chris

 

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

In Conquest through extreme composition + glue, Part 1 I set the stage with some driving factors, thoughts on plugability, testing and more.

In Conquest through extreme composition + glue, Part 2 I talked in depth about The Dependency Inversion Principle and how it drives away the “pass through problem” and drives you into an extremely composition based approach.

The basic gist is that you want/ need to have the composition so that you can vary the behavior of your objects by (not editing the code) giving the target class different dependencies (the guys that do the class’s real work). The potential problem this leaves you with, is an object that can have lots of behaviors, but you have the liability of giving it the stuff it needs when you want to use it.

Ideally, you want the target object, and to give it the items you need to give it, on a scenario by scenario basis. In situation A, you want your class to behave 1 way, in situation B, you want it to behave another. What you want to do, is have something that is able to glue this stuff together.

This glue is the bit that you create variants of in order to stick together different stuff in your scenarios. You get the reuse of composed objects that allow their dependencies to be set onto them. This gives you isolation, testability, simplicy, extensibility, etc. In order to stick it together, I woke up ~5 AM last week with an idea…..

I have been a springframework.net zealot for some time. I am still a big fan. A few co-workers had feelings about spring that I had to at least to a level see.

• XML – there are WAY too many XML DSLs in the world. Too many “config files”. Too many different XML formats, etc. Spring is one of those.
• Type obsession. You are always concerned with what “type” you are dealing with in general, type, type, type *as opposed to new Something(), you have MyNamespace.MyType, AssemblyName, etc.
• All reflection based runtime object creation (this is a bone of contention for sure)
• ….Why not just use code?

So – in response – using Glue looks like the Java spring code configuration:

From there, we are just like spring. We can configure Prototype objects (ala factory style), Singleton object, we have constructs for ConfigureObject (inject properties after a class is already alive). We also have some minor trickery that we can use to automatically inject dependencies into winform (or WPF) GUI apps. We also have a way of allowing interested parties to have the ObjectContainer automatically be “stuck onto” them (similar to spring, looks like in their OSGi efforts they are still using the “Aware” pattern for this same thing).

You can also manually register stuff with the container, or replace existing definitions with the ObjectContainer if you like:

The magic of all of this comes from what I have been refering to as  “defered new”. When in spring, you specify a type, this type is reflected to life whenever it needs to create a singleton or a prototype object. In this example, once the class is loaded, the configuration is actually “normal code”. The fact that the Registration of a prototype or singleton is actually a function pointer (delegate) means that the “new” is not done “on the spot” – but defered until you ask for the label (“name1″ in above example”). Note also the passing of the ObjectContainer itself to every registration. This means that any single object defition can do the “spring ref” and get its properties/ constructor arguments from the ObjectContainer, thus not knowing or caring about it’s dependencies dependencies.

This does feel nice to me. I would rather type code. I find myself all the time cut n pasting the actual code constructor into the spring xml file, then mangling it into the XML spring format. The lessons that spring has taught me are great. We’ll see how this all pans out. I KNOW we need some kind of “glue” weather it is this Glue or spring, some other DI container, etc…. We need something in the space for our “Extreme composition + glue”.

-Chris

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

Luke Melia’s IronRuby Talk

EMS’s are important – (I have been chattering about this lately – great stats)

So what’s the deal with Spring-OSGi? (THIS is a great one)

-Chris

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

Dell Ships Ubuntu 7.04 PCs Today

Wow!

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

In a prior post I talked about how important it is to “slice the work vertically” and not to get lost in BDUF land. In general, I think architecture needs to be “right sized” to the project. A teeny app needs little or no real “architecture planning” a huge app certainly needs some. The trick is not to think you can do BDUF for real, you just hide work and make the other BDUF believers “feel comfortable”.

I am certain in my current role that people think I am “a classic agilist” ready to run off and work with no longer term vision, plan, agenda. If we do that, we will surely get into a bad place is the criticism.

• I believe that NOT writing tests
• Not acknowledging technical debt and addressing it
• Not time boxing
• Delivering infrequently to the cleints
• Inexperienced developers/ naieve assumptions

These are the primary things that make you “get in a bad place in the future”. Certainly – refactoring on the enterprise scale costs lots of $ as you are forced to change lots of nodes/ components/ layers. Limiting the scope of refactoring is very important at the enterprise level.

Blah, blah, blah – so what is this architecture business and how do we do it? I have been using this simple model:

The plinko architecture formula

• Prior art (someone did something like this in the past)
• Vision (if we had this XXX, then all these other problems would go away)
• Collective experience of the team
• Well known components (we KNOW we will be using our corporate XXX service/ component/ etc)
• +
• Development Spike (time box, rapid prototype 10 ways to solve each problem)
• =
• “Ballpark architecture”

This set of stuff defines the “buckets” at the bottom of our “plinko board”- our “ballpark architecture”. We then take our features and while we implement them, we let the parts of our solution fall into our architectural buckets. This lets us have a set of basic working models, yet our architectural implementation evolves alongside the actual problem, not in a silo!!!

I am a HUGE believer in “co-evolution” of frameworks/ architectures evolving WITH the problems they solve. Building entire frameworks and architecture models detached from real problems just delays the learning. You learn on the day you start to USE the framework/ architecture model where you were wrong, what inconsistencies you have and what you REALLY need.

So – my 2 cents is – do not build in a silo. Use the Plinko architecture formula above for your basic architecture approach….

-Chris

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

 

Lately I have been trying to help some folks understand the need for extreme composition + glue. One way I have been trying to describe classes to people is that they have 2 sides… draw a line down the middle and there are the behaviors, and the stuff you need to carry out those behaviors.

 

 The Dependency Inversion Principle  asks us to depend upon abstractions and allow them to be passed in. This means you are effectively cutting off the “dependency members”. You are explicitly NOT depending on whatever your dependents need to do their work. This is a key element.

 

 

 

Having dependencies all over the place is a bad thing in case we have not figured this out yet. They make our code complex and very hard to understand because of the noise. They also drive what I call “the pass through problem”. Whenever you are “newing” your dependencies, you need to know how to build them, how to give them what they need to survive. This is quite a burden sometimes.

To illustrate – assume that we have classes A,B,C. They are happy and fine classes – they are simple – yet we need to add a new feature. In order to do this – we see that our happy simply C instance needs an X. How do we get it to him?

Ultimately we do not want to have to do this! This is the mess we were talking about above – knowing about what our dependencies need to do their work.

The Dependency Inversion Principle again here – it means that we cut of the dependency interface. This all sounds very good. Whenever you need something, simply declare a settable property or constructor argument for one of those, and move on. Do not try to get one or create one, expect that “it will be given to you”. This is the sentiment of The Dependency Inversion Principle .

I spent some time on friday moving around some code from a smart team member that I think quite well of. This code had stuff all over that checked to see if something was alive, if not, got it or newed it. In some cases, it tried to get it 1st, then if it could not, it newed it. This code accounted for some ~60 lines of code in a ~500 line of code area of code…

 This was something like:

…

if (null == applicationThingy)

     ISomeType servicex = GetService(typeof(ISomeType));

     if(null == servicex)

        servicex = new SomeTypeImpl(null, someArgument);

servicex.DoSomething();

…

The only meaningful but in the “value chain” of that code was the very last line – the DoSomething() call to the service. What I did was to go through the whole class and simply cut out all that stuff, and create a public settable property for the ISomeType service. What I found was that I got rid of > 1/2 the ~500 lines of code, as a lot of it was stuff for the dependenicies of dependencies. In short - whenever you need something to implement your behavioral interface, you do not want to care about how to create it. If you DO create it – you will have a concrete class dependency anyhow and it will be difficult to vary the behavior of your program without editing your code.

So – once you start doing this – you are left with a class that is much smaller – yet it has a number of settable properties and/ or constructor arguments that you can be given your dependency properties. Again, a user of your class should know NOTHING of your dependency properties. A user of you should be doing the same thing!!! They should be relying on whatever behavioral abstraction you represent -and allowing you to be passed in – given – by someone. The effect of this cascades. Nobody knows anything about how their parts work…. this is the extreme composition I am refering to. Systems should be assembled in this way. Systems assembled in this way really follow The Open-Closed Principle. Your code does not have to change, but – if you are given a different dependency set – your behavior can vary greatly.

This entire pattern, relying on abstractions that can be given to you – cascaded through a system is extremely powerful. You now have all the “seams” you need to substitute behaviors. You have an abstracted system of bits that can be tested in isolation. What you DO get at this point is something way up high in your application that looks like this:

Application x = new Application(new Foo(new ThingFooNeeds(new ThingFooNeedsNeeds(new ThingINeed(1,”yeah”)))));

.. only X around a zillion times bigger if your app is non-trivial. This is how things are “given” ala inversion of control/ DIP. So – once you really really do the dependency inversion thingy – you earn yourself another problem – the need for some “programmatic glue” to stick it all together. You could hard code all sort of factories all over of course. These are often static and always need changes frequently. They are also usually a switch statement We would prefer a stronger solution.

Spring solves this problem, Pico Container solves this, Object builder solves this, structure map solves this, nanocontainer solves this, copeland in ruby solves this.. There are many many many solutions for solving this problem – dependency injection frameworks/ containers.

I have spent the better part of the past few years using spring.net for this particular set of goals. That being said, there are plenty of valid concerns for using spring (I am specifically refering to spring.net in my particular case).

XML is not that great. Yet another config language. Problematic to debug, reflection based, etc, etc. Type obsessed programming model. The list goes on. Moreover – I AM a spring fan to be clear, but – in order to sort out these specific concerns, and inspired by Rod Johnson’s “Pure Java Configuration” ideas, and in order to satisfy some co-worker’s concerns I have come up with a mind-numbingly simple and easy to use alternative implementation for .net. “Glue”…. So in part 3 I will introduce glue…

-Chris

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

We are currently in a 2 week design spike. We are developing a solution with one primary goal:

Integrated User Experience

The product will be used to unify many .net based applications. The product must enable developers to deliver faster than ever to their trading clients. The product must provide radical levels of integrated user experience. We must go far beyond our simple “plugin model” if we are to provide the ability for peer plugins to be themselves extensible, for the host application to be itself extensible and for all participants to get maximal reuse.

Amidst the course of this spike, we are all coding a lot and talking a lot. The team has lots of smart folks with a collective ton of experience building desktop applications serving the hard demands of traders. We are trying hard to keep our deliverables “end user effecting” yet during the spike, we are basically focused on defining a basic set of architectural buckets (see plinko model) into which our end user effecting features will fall during implementation.

What do we really want?

1. extensibility/ plugability
2. reusability
3. testability

I think the crux of it is:

1. Really practicing composition
2. Really practicing The Dependency Inversion Principle
3. Sticking stuff together contextually – some glue
4. … sort of an afterthought … Getting away from too much procedural programming hiding in OO code.

That is really it. We want to rely on abstractions and not know/ care about what our implementing parts need to have in order for them to work. We want to support The Open-Closed Principle by varying the behavior of our system by providing different collaborating implementors.

I am trying hard to help a lot of folks understand the need for The Dependency Inversion Principle. I am trying with step by step success to move lots of folks to really writing unit tests. I believe this:

1. You start writing unit tests
2. You earn the understanding of why you need The Dependency Inversion Principle
3. You practice The Dependency Inversion Principle
4. You get more adaptable software that is composition based
5. You earn the problem that spring and other dependency injection containers solve – the need for “formalized glue” to stick everything together.

I have seen this evolution time and time again. In stead of “ramming this all down people’s throats” – I try to let people “earn their next problem”. As soon as people earn the next problem, they see the value of the solution at the next level.

Anyhow – this bunch of stuff says, ideally you are:

1. Relying on abstractions
2. Allowing your implementors to be given to you in stead of newing your concrete dependencies

Your abstractions typically have N implementors – a bucket of IThingable’s are available. This is plugability - the reliance on an abstraction and the ability to “inject” something along that seam. The isolation factors of The Dependency Inversion Principle gives you the testability. The fact that you have buckets of things that can be implemented at a level of abstraction + composition gives you the reusability.

This gives us a picture that looks like .. coming in part 2

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