December 2005 - Posts
Pff...
Media Center is a .NET application so I needed to have it.
Simple as that :)
MCE allows you to develop and host your own extensions ;)
It took me four days to build a Media Center PC from my old hardware spare parts. I bought a new case, wireless lan adapter, graphics card, tv-tuner card, MCE remote, hard disk and loads of cables. Getting the right (read compatible) hardware and daunting configuration is the key to success. Another issue is the noise-level. With the MCE desktop in my living room noise is important, if not the most important item in Kitty’s acceptance test. I used a 120mm low rpm fan to cool the psu and to supply sufficient airflow. Next I replaced the active cooled graphics card with a passive model. Another ventilator I’m considering to replace is the cpu cooler but that’s a project for a rainy day. So is the placement of sound damping material inside the casing. Now I’ll spend some time with my new friend.
I haven’t yet jumped on NUnit 2.2.4 and not without a reason since it have been replaced by NUnit 2.2.5. Get your copy
here and see the release notes
here.
Rob Caron posted the link for the DSL Tools Prerelease Documentation, containing:
Overview of Domain-Specific Language Tools
Describes the architectural model of the Domain-Specific Language Tools.
Domain-Specific Language Tools Walkthroughs
This section provides walkthroughs of key Domain-Specific Language Tools functionality.
Creating Designers Using Domain-Specific Language Visual Studio Templates
This section describes the different solution templates available to create different types of designers with the Domain-Specific Language Tools
Working with Domain-Specific Language Constraints and Validation
This section explains the use of constraints and validation on domain-specific language designers
Working with Domain-Specific Language Text Templates
This section describes working with text templates.
After a clean installation of VSNET2005 on my box my domain models fail to compile with the following error:
Error 1 Can't start preprocessor (2) C:\CoolDM\Designer\CTC Designer
Grayson Meyer submitted the solution in the MSDN Forums, Domain-Specific Language Tools section.
For the November release at least, you'll still need to have C++ installed to run the DSL tools. This is because the CTC.exe tool (from the VS SDK) is run to build the menu definition (CTC) files. This tool invokes the C preprocessor in cl.exe, which is only installed if you've installed C++.
I believe the plan is to remove CTC dependency on the preprocessor in future releases of the VS SDK.
Thoughts on Modern Software Factories (1)
Before we start thinking about bottlenecks, measurable productivity and predictability in a Software Production Line, I want to elaborate more on Software Factories. A typical Software Factory consists out of one or more specific product lines. The focus in crafting software solutions is competitiveness, and the emphasis is on integration of specific domain knowledge, solution architectures, tools and other reusable assets of the future.
The picture above displays islands of automation where each technology solves a specific problem in the process of developing software solutions. Thus for example, code generators that where developed to take the output (e.g. the UML model of a component) from a UML modeling tool and generate artifacts directly from it. Interfacing islands of automation which have been designed in isolation will always be problematic (Microsoft here uses the term viewpoint for the technical solution). A viewpoint is not always based on a DSL because software factories can use code, sql and a variety of other formants and tools to describe a domain in addition to or instead of models. Relating viewpoints in MDA is done by transformation whereas Microsoft does this by nesting viewpoints and by a variety of operations such as trace, validation, analysis, refactoring, weaving or optimization. I agree with Jack Greenfield that it sometimes makes more sense to edit two viewpoints independently for example and to use a validation tool to make them mutually consistent (see Differences between DSL and MDA). Software Factories blend modeling with other software development practices by schema, template and an extensible development environment. The Software Factory methodology integrates model-driven development, component-based development and agile development practices, including the use of patterns and patterns languages with models, frameworks and tools.
Harry Pierson’s Architecture podcast
While having a background in industrial & engineering always helps in dealing with modern software factories, I think the new book of Keith Short, Mauro Regio and Jack Greenfield called Software Factories Applied will help me a great deal on the practical side. Perhaps it will even inspire me to write up the promised follow up on Thoughts on Modern Software Factories (1).
The discussion as a result of my refactoring posts here and here moved over to the exprementprogramming group here. Kay Pentecost makes the key point according to Martin Fowler summation:
Kay makes the key point. Refactoring does have a cost (you spend time
doing it, even with the nice tools these days) but so does not
refactoring. You have to evaluate the trade-off.
Case closed.
At least I stirred some discussion. Sam Gentile and Jonathan Cogley where so kind to give their point of view here and here.
Sam writes:
They both largely obscure the issue and come out with blanket statements that Refactoring is Not Free, that don't make parse and don't make sense. The central issue is that both of these posts, and especially Fran's comments, and a lot of people who think Refactoring is unnecessarily expensive, are looking mostly at refactoring of entire systems/sub-systems rather that small continual refactoring of code as it is written.
To my believe there is no such thing as big refactorings, if you think there are, then I don’t know what it is you're doing, it sure as hell isn’t refactoring! This discussion is not about continual refactoring.
Sam writes:
Refactoring is small preserving transformations, not system redesigns (although Refactoring can be applied to large system changes)
A valid approach for the example I described here would be to cover a data access components, which abstract a web service, with tests. Then refactor a single method to read from a sql database instead of invoking the service operation on the web service. What I just described is a small refactoring. It takes just a few lines of code. Lots of similar small refactorings make a new system/sub-system. A redesigned system? Perhaps not.
Sam then writes:
Because all our code was all Refactored and every single class had unit tests. It cost virtually nothing
Couldn’t agree more… In my example I wanted to make it clear that this form of refactoring (yes! I’m convinced that lots of small refactorings made sequential is a form of refactoring) does cost.
Refactoring is not free but by doing it right, it pays back!
In my post Agile but Not Quite Yet Frans made the following comment:
One of the key mistakes embedded in agile development is that it assumes refactoring is free. Let me tell you: it's not, far from it. Especially in OO systems where refactoring of designs can lead to severe delays of the project as a whole, it's key to know as much information about the functionality you have to realize with the software you're supposed to be writing, UP FRONT, so you have the best chance to have the 'best' design in the first attempt.
With Frans not being the easiest guy on the planet to convince… and although he has a point…
Refactoring doesn’t add features nor fix any bugs. Refactoring improves the design of existing code in order to make it easier to change. So yes refactoring isn’t free when the application will never change, because you’ll never get the payback. Concluding change is the driving reason to refactor.
A couple of months ago we where up for the challenge to refactor a large portion of a badly performing application. The application had no supporting unit tests, cruddy code and Swiss cheese specifications (its developers only had a sense of what the application had to do). It is in this example where refactoring became costly. At start we tried to cover as much existing code possible (see Improving the Testability of Legacy Code using TypeMock.NET). Although the confident level increased we weren’t able to preserve the behavior of the code while refactoring small pieces at a time. Eventually we had clear signs that the progress we made just wasn’t enough. We then decided to rewrite it from scratch and than refactor it.
Thoughts and/or experiences to share?
The product of the discussion between Ralf Westphal and Ingo Rammer is this decision flow chart.
We’ve already had this discussion in our office a couple of times. In this discussion I always ended up on the left side of the decision flow chart where most of my colleagues picked the right side. I’m not saying either one is right or wrong… just different. I can foresee the discussion whether a remote interface should look different from a local interface evolving in the ObjectRelationalMapping vs. Relational debate.
More Posts
Next page »