Infragistics NetAdvantage for WPF - the most complete offering so far. We spent a few hours with some nice and bright folks from Infragistics this past friday. I did my best to tell them they need to make their grid fffffaaasssstttt!

SandDock for WPF – not tried it yet. Seems like it will be …. docking.

Xceed Datagrid for WPF - looks nice. I will toy with it sooner than later – maybe next weekend.

Blendables Essentials Mix - seems like a newcomer. Looks like some potentially interesting stuff more on the real UI, 3d side of things.

WPF Ribbon - well – looks lovely. A ribbon is coming from Infragistics, but this one looks nice for now Perhaps I will try this before Xceed’s grid.

ComponentOne Studio Enterprise for WPF - Chart, Grid, Schedule .. not done yet. Later this year

Syncfusion – when last we spoke – I got the feeling it was a beginning of ‘08 thing at best. Sad – help  us out here guys !

Thats about it. Please post more if you got ‘em.

-Chris

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

Attached Properties is another use of the dependency object infrastructure. This stuff is a set of real underpinnings of WPF and is very very related to XAML. Attached Properties seem to be specifically useful to someone writing a class that will be used in XAML.

This just about sums it up:

One purpose of an attached property is to allow different child elements to specify unique values for a property that is actually defined in a parent element.

Now in XAML – this looks like this:

The CheckBox has an attached property that is refering to it’s parent DockPanel. This is a nice convenience for XAML style declarative programming – and I see how/ why this whole dependency property, attached property business is around.

The other stuff that still seems strange to me is all of the static metadata stuff that has to be done to register all of these dependency properties, attached properties etc with WPF.

Anyow – again – my 2 yr old is callin’ me

-Chris

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

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.

OK – I have had a “pet project” using WPF for a few months now. We will be “starting for real” in a few months “at the office” it seems. I will have to have built ~2-3 pet projects over the next 2 months to be happy.

I wil say – the web is great. There is nothing better than working with WPF to understand what is happening. I think a lot of people have mixed thoughts about WPF, but for the past several years now, I have been trying to move to a more declarative style of programming in general. I have typically tried to make it so that i could wire together a bunch of stuff for a scenario using Spring.net – or hand rolled domain specific XML. This is in the spirit of XAML… They have objects that have lots of properties – then you declare the behavior as you need in XAML (or you let a tool do it more likely).

There are several key concepts that developers need to get a handle on. As soon as you get past the “initial playing around” with WPF and try to make a real, clean, well written, maintainable piece of software – you will need to really understand WPF and how it works. So, on to…

Understanding Dependency Properties.

Single most helpful statement in starting to understand WPF Dependency Properties: 

Dependency properties and the WPF property system extend property functionality by providing a type that backs a property, as an alternative implementation to the standard pattern of backing the property with a private field.

From MSDN’s Dependency Properties Overview

Another useful statement can be foun in Windows® Presentation Foundation Unleashed

A dependency property depends on multiple providers for determining its value at any point in time. These providers could be an animation continuously changing its value, a parent element whose property value trickles down to its children, and so on.

Dependency properties are understood by XAML only. It is all “normal .net (C#)” but it is only meaningul within the context of XAML. Dependency properties give you a type as a property, so you get a level of indirection that buys you:

1. Property change notification
2. Support for different providers (various ways to change the value of the … uhm value)
3. Property inheritance (think of it as propagation of a value to child controls)

The implementation of dependency props – it looks odd, but it makes sense if you think of it something like:

My class is implementing its property in a way that it can be hooked into WPF intimately.

(this is verbatim from the WPF Unleashed book)

The static DependencyProperty on top – is point of ref that wires up the connection in the static constructor. It is used to attach the change notification method, the metadata info, the type info, etc. (All this static business is a bit disconcerting for me as a TDD anti-singleton type.) Note the “normal” .net property IsDefault – looks like a normal property. The rest of that stuff is the implementation of the property – in such a way as WPF is “wired into it”. Now you get the Property change notification, property propagation, hook points for value changing, etc. Now your class is all bound to WPF… This is another item that provides food for mental thought…

That last paragraph has some uglies in it…

• #1 Static singleton stuff (you are bound to global stuff from your environment -ugh).
• #2 more of the same, your implementation is explicitly bound to its runtime environment.

I am open to new things That said – those things make me a bit uncomfortable. I believe in a style of programming that allows you to be declarative, and to wire together components. I believe you can use labels, identifiers, strings, and all that stuff to be the glue to stick stuff together. This gets you a bit away from a very strong compile time safety, yet you get the benefits of a much more dynamic and flexible style of programming. I think the ideas of XAML works right into my general modus operandi. I think it is important to be careful to make sure we can still write testable code!

As systems get bigger and bigger and more complex – more risk is at play. Especially on Wall St – lots of $ can be lost if you are buggy. Testability is a cornerstone to sustainability. For me – the key takeaway is to ONLY bind up your presentation tier into the WPF specific stuff. Just like today – there are lots of apps where WAY too much is way up in the view code.  I still want a POCO (plain old CLR object) feel when programming!

Anyhow – that is it for me – 2 year old is now awake and wants to play!

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