This is a really quick announcement. I recently released Machine.Specifications 0.9.0. With that release I introduced a breaking change: I disabled the console output capturing by accident. If you are using console outputs in your specs and need to see them then I strongly advise you to upgrade to Machine.Specifications 0.9.1. You only need to upgrade the Machine.Specifications nuget package in your solution. None of the other components are affected. This is the beauty of the new architecture
Have fun and sorry for the inconvenience!
I updated my clean code cheat sheet.
This time there are just minor changes:
- Principles: mind-sized components
- Class Design: do stuff or know others, but not both
- Maintainability killers: tangles
- Refactoring patterns: refactor before adding functionality, small refactorings
- removed duplication regarding one test asserts one thing
- TDD principles: Test domain specific languages
- fixed a bug in the ATDD/TDD cycle (run all acceptance tests)
If you miss something or think that there is something just plain wrong, please write a comment below.
Link: Clean Code V2.4
Today we released the next version of Machine.Specifications. This release implements an important feature to move on in the future. We implemented a complete runner dependency abstraction. What does that mean? Let me take a step back.
The picture above shows the state of Machine.Specifications previous to V0.9.0. The console runner, the resharper runner, the TDnet runner and more were directly dependent upon the same Machine.Specifications version. This means when we release a new version of MSpec you actually had to use also the new version of the ReSharper, Console runner and more. This was not only for you as a user cumbersome it was also for us as the maintainers of the library. We had a massive repository with everything in it and released all as a “big chunk”. That made working, forking and all other git operations heavyweight because the repository was quite large. Continue reading
I attended TechEd Barcelona with a coworker. The venue was just amazing. TechEd was hosted in the Fira Barcelona. The floor space in the fira is 400000 m2. You really have to walk from session to session. But I think that has very positive influence on the conference experience. Because usually when you are always at the same location you are getting more and more tired (mentally) after each session. With the “long” distance walks between the sessions you grab a coffee or tea on the way and head to the next hall (up to 10 minutes depending on your walking speed). This gives you time to think about what you’ve heard in the sessions and also time to “exercise” your body. Good contrast to the sitting only experience of the sessions.
This is an overview of the sessions I visited:
- Day 1
- Day 2
- The Next Generation of Microsoft .NET (Link)
- TWC | A Game of Clouds: Black Belt Security for the Microsoft Cloud (Link)
- Entity Framework Now and Later (Link)
- Windows PowerShell Unplugged with Jeffrey Snover (Link)
- Introduction to NoSQL in Azure (Link)
- Architecting Secure Microsoft .NET Applications (Link)
- Country Drinks Party
- Day 3
- Day 4
I talked a lot on this blog about the fallacies of distributed computing and how messaging addresses some of the fallacies. But messaging does more, it helps to decouple (temporal, spatial and platform coupling vice) your components which build up a system. Service Bus for Windows Server provides messaging capabilities of Windows Azure Service Bus on Windows for On-Premise purposes (self-managed environments and on developer computers). It contains a rich feature set such as reliable queues, a variety of protocols and APIs to interact with it, and a rich publish/subscribe model that allows multiple, concurrent subscribers to independently retrieve filtered or unfiltered views of the published messages.
How do you build your Visual Studio solution, verify your coding guidelines and execute tests?
What steps do you take when adding a new project to your Visual Studio solution?
Living in the past
Let me summarize my past experience. I have tried several different approaches, all of them involved build scripts, and Visual Studio Project Templates or manual editing of *.csproj files. I don’t like any of the approaches. Why? I will show you some drawbacks of this kind of build definitions.
- you have to learn a scripting language
- you try to solve problems which you would solve in your preferred .NET language with less effort
Visual Studio Project Templates:
- making up-to-date versions available to all team members is a PITA (pain in the
- update your templates and you still have to update all previously existing *.csproj files manually
- if you change your build process (e.g. enable StyleCop) you have to release and distribute a new version of your templates
- enough said