Month: August 2008

WPF, adopting to a new style of coding

sarikanLeave a comment

I’ve been working on WPF for a while, and I am quite impressed with some of the changes Microsoft has introduced. First: the event handling issues has been a real trouble for custom controls builders, and at some point you inevitably find yourself in need of building custom controls. Dependency properties, just like routed events, makes it very easy to create and consume composite controls, with data and events for the whole tree connected easily.

The real test for WPF will be the new databinding features I guess. It comes with very powerfull data binding features, and honestly, I’ve never been a fan of databinding. The reason is, even if seemed to provide productivity boost in the short run by eliminating plumbing code between UI and data, as things get  more complicated, data binding mechanism itself becomes a maintanence item. The new databinding stack that comes with WPF seems to attack people like me. I’ll be testing the new features for a while, and try to see if I can really adopt databinding as a development practice for WPF. Needless to say: I’d be more than happy to succeed.

Pulse, holy grail for Eclipse community?

sarikanLeave a comment

I’ve been using Eclipse since it was around version 2, and for the last three years or so, I’ve been writing plugins and sometimes RCP applications based on Eclipse.

I’ve also gotten used to looking for an Eclipse plugin for many things like db tools or complete IDEs for Python etc. Anyone who has worked with Eclipse knows that managing plugins becomes  a pain in the neck in time. In order to keep things clean, I usually keep multiple installations of Eclipse, wasting an enormous amount of space, and also forgetting in which installation I’ve put that darn plugin.

Pulse is a tool that manages your Eclipse installations, and it is a great time and space saver. It lets you manage installations of different configurations, and it lets you save a lot of space by doing so. There are various problems, like in any software tool, MyEclipse does not play very nice with it, even though it has a Pulse based download, but still, Pulse will be a regular tool for my development environment.

Pulse has a subcription based usage and a free one, the difference being able to share your configurations with your friends and other minor things. I am now testing the subscription based membership for a trial, and if you want to take a look at Pulse, you can do so by visiting this link.

There is trouble at the front layer!

sarikanLeave a comment

I’ve been discussing the issue of front ends with Omer, who is an MD who happens to work in Healthcare IT. He is a doctor, and he knows what doctors demand: everything!

After a while the discussion came to a point where we both agreed that the usual way developers produce user interfaces is not simply good enough. I guess we are still making the mistake of accepting medical software as another form of “business software”. It is not accounting, it is not some sort of bookkeeping. Doctors and nurses need to benefit from every piece of technology in user interfaces to make their work faster.

This is not about eyecandy, it is about providing and collecting information as efficiently as possible, using the minimum amount of key presses and mouse clicks. I’ve been writing about MS CUI every now and then, and MS is pushing its GUI related technology into this work now. Both WPF and Silverlight are being used as the implementation technologies for CUI components.  This is not the most compatible approach, even javascript has a wider base, but it is a smart one on behalf of Microsoft.

I’ve seen some very impressive implementations of CUI by MS, and I know that medical staff would like those implementations.

This is the exact point where trouble begins. We’ve been working die hard on model driven development, object models derived from domain models etc.. There is a great deal of effort for making things more streamlined, more product line like (if this is a valid description). Generic approaches decrease flexibility. Now, using domain models is good for representing the domain and related logic in a consistent and more important than that, in an interoperable manner. Software developers love to generalize things, that’s why we have all these frameworks, and the benefits of this approach is a whole other story, to which I can no doubt add  a few chapters. When software people try to connect the domain models to user interfaces they naturally want to be able to decrease the amount of work necessary to create user interfaces. For a modern developer with an object oriented approach (no offense old school ER diagram people, I love you too 🙂 ) a domain model is the actual representation of the domain and the solution to the problem in that domain. User interface is just a layer that connects users to representation of their domain. So why not get rid of UI blues as much as possible, when you understand and represent the domain? In other words, developers are mostly done with the problem when they create a domain model and necessary business logic. The intellectual challenge is usually tougher in that part. UI is just something to be done to connect the users to this solution. So most of the time, being able to generate GUI is a blessing for a domain oriented developer. I’ve seen some guys obsessed with UI polishing and optimization, but they are few in number compared to the first type I’ve just described.

What happens when connecting rich domain models to persistence is basically trouble. As domain model gets more and more complicated, the persistence layer, which is usually a relational db, becomes more seperated due to lack of inheritence, types etc. These are the things that allow us to build a rich domain model in the first place. Fowler offers a few remedies for this kind of situation in his book “Patterns of Enterprise Applications”. The same thing happens when connecting domain models to user interfaces. If you want a capable user interface which is optimized to the max considering user’s experience, you’ll have a hard time connecting the two layers “automatically”. Forms generated from domain models just does not feel right for having the most capable GUI possible.

Maybe if we can find a consistent way to connect MS CUI to domain models, we may have the best of both worlds. I’ll be working on this for a while, and I think everyone in the domain can benefit from it quite a lot.