I'm in the process of playing around with WPF. XAML is the markup language for creating WPF based UI. But, its actually more generally useful than that.
It can be used for any objects. Which makes its reasonably good for any kind of object creation / dependency injection / configuration.
I haven't had a chance to play with this much yet, I'm still on the steep part of the learning curve for WPF and the underlying architecture. I'm looking at how MVP/MVC and TDD fit in with it all.
Thursday, 26 April 2007
Wednesday, 18 April 2007
As little Unit Testing as possible
When you first start learning TDD. It's all about creating unit tests. However, very quickly you learn its actually all about making as few unit tests as possible.
One of the traps people can fall into when doing TDD is testing lots and lots and lots of stuff. This means when you change your design you break lots of tests.
Ideally what you want is tests that test your intention. Tests that show what the code has to achieve. It doesn't matter too much how the code achieves it, and you don't really want to test how it achieves it. That way you can vary how it is implemented without breaking lots of tests. ie, Encapsulation.
Of course there are going to be plenty of things that may break tests as they slice through a layer of encapsulation.
However, if you test things pretending that the thing will magically do what you want without worrying about how, then it can be a heck of a lot easier to get good tests. When you test with a particular implementation in mind, you often get very concrete tests that fall over as soon as you try changing things.
One of the traps people can fall into when doing TDD is testing lots and lots and lots of stuff. This means when you change your design you break lots of tests.
Ideally what you want is tests that test your intention. Tests that show what the code has to achieve. It doesn't matter too much how the code achieves it, and you don't really want to test how it achieves it. That way you can vary how it is implemented without breaking lots of tests. ie, Encapsulation.
Of course there are going to be plenty of things that may break tests as they slice through a layer of encapsulation.
However, if you test things pretending that the thing will magically do what you want without worrying about how, then it can be a heck of a lot easier to get good tests. When you test with a particular implementation in mind, you often get very concrete tests that fall over as soon as you try changing things.
Monday, 16 April 2007
Architecture Camp Finished! + My Powerpoint presentation
Architecture Camp was really good! It was great to see people really interested in the content presented and activelly discussing ideas.
Some interesting things to me...
Quite a lot of people were using mindmaps to take notes, great stuff!
There was quite an agile theme to many of the talks.
Martin Fowler is quoted a lot!
Integration / Deployment Architectures are hot topics.
No one had any idea where one would go to buy yellow camo
---
Heres my Slides from my talk. Most happy to answer any questions or discuss any ideas related to them!
Some interesting things to me...
Quite a lot of people were using mindmaps to take notes, great stuff!
There was quite an agile theme to many of the talks.
Martin Fowler is quoted a lot!
Integration / Deployment Architectures are hot topics.
No one had any idea where one would go to buy yellow camo
---
Heres my Slides from my talk. Most happy to answer any questions or discuss any ideas related to them!
Wednesday, 11 April 2007
Pearls Before Breakfast
There's a great article in the Washington post called Pearls Before Breakfast. It's about how a top classical violinist in America (just voted Americas top classical musician) went to the Washington DC Metro and started busking.
Most people walked on by.
What does that mean? The article explores some of the possibilities. But, there's a couple of things I take from it, quite often things of beauty (music, art, design) need to be presented within a context for you to appreciate it. Relating this to software design, this means unless we stop and look at good design and appreciate it for what it is, we are most likely to pass it by never realising it was good design.
The next point to take away is also really interesting. It's also really odd, because I was talking about exactly this with a co-worker yesterday! That is Immanuel Kant (philosopher) said that beauty cannot be truly experienced unless we have a sense or morality. or, Without a sense of whats right and whats wrong, we can't appreciate beauty. Appreciating beauty is not the same as liking something either. I think theres an element of objectiveness to beauty and whether we like something or not tends to be quite subjective. Having said that, Kant didn't quite say this at all, he painted a fuzzier picture of how beauty and morality tend to interact. Kant's most famous moral idea is "The Categorical Imperative". This a set of 3 basic "rules", however, most of interesting discussion is based around the consequences of those rules and what they mean.... Anyways! How does this relate to software development? It means we really need to spend some time understanding what good code is and what bad code is. The tricky thing is that what's good and bad is not carved into a rock anywhere. However once we start developing a sense for what good and bad is we then tend to recognise beautiful designs and why they are beautiful. With a bit of luck we can hone our sense of "Code Morality" so finely that we won't walk by a Masterpiece out of context.
Most people walked on by.
What does that mean? The article explores some of the possibilities. But, there's a couple of things I take from it, quite often things of beauty (music, art, design) need to be presented within a context for you to appreciate it. Relating this to software design, this means unless we stop and look at good design and appreciate it for what it is, we are most likely to pass it by never realising it was good design.
The next point to take away is also really interesting. It's also really odd, because I was talking about exactly this with a co-worker yesterday! That is Immanuel Kant (philosopher) said that beauty cannot be truly experienced unless we have a sense or morality. or, Without a sense of whats right and whats wrong, we can't appreciate beauty. Appreciating beauty is not the same as liking something either. I think theres an element of objectiveness to beauty and whether we like something or not tends to be quite subjective. Having said that, Kant didn't quite say this at all, he painted a fuzzier picture of how beauty and morality tend to interact. Kant's most famous moral idea is "The Categorical Imperative". This a set of 3 basic "rules", however, most of interesting discussion is based around the consequences of those rules and what they mean.... Anyways! How does this relate to software development? It means we really need to spend some time understanding what good code is and what bad code is. The tricky thing is that what's good and bad is not carved into a rock anywhere. However once we start developing a sense for what good and bad is we then tend to recognise beautiful designs and why they are beautiful. With a bit of luck we can hone our sense of "Code Morality" so finely that we won't walk by a Masterpiece out of context.
Subscribe to:
Posts (Atom)
