Target audience: developers
Philipp’s comment: Effective Debugging contains 66 recipes that show you how to track, find and fix bugs with less headaches. The recipes are neatly grouped into chapters. Every recipe has a Things to Remember section at the end which wraps up the described technique.
Some of the recipes are very basic and should be in every developer’s arsenal; at least after having read the book. Some recipes are meant for the hard to crack cases while some may seem very obvious. I like the completeness of Diomidis Spinellis’ approach. It reminds us that successful debugging starts with mastering the basics. If you’re already familiar with a technique, you can always jump ahead to the Things to Remember section and continue with the next technique.
If you’re a .NET developer like me, you will appreciate the tooling you get out-of-the-box even more after having read the book. Though for some of the recipes in the book I would like to see a sample for the .NET universe.
To have a more complete list of Debugging Tools in the .NET Universe and insight on how to use them I’m going to post more articles in the next couple of months.
The book is definitely worth a read and serves as a reference for the more advanced, rarely used techniques.
Go grab your copy today and let me know what you think about the book. Which technique did leverage your debugging skills the most?
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
Imagine the unimaginable
In my current project I’m working with Aspose.Words for .NET to create documents. Aspose.Words works very well for what I have to do. Though when it comes to debugging it starts being inefficient. It’s just a fact that a Word document has a fairly complex object model that has very deep object hierarchies with all its sections, headers, tables, paragraphs etc. This makes it cumbersome to navigate within the document and understand what the document you are inspecting really looks like in the debugger. Why? Continue reading
cross-post from http://blogs.jetbrains.com/teamcity/2013/06/04/improve-build-times-with-compressed-artifacts/
Do you work with build chains and artifact dependencies? Do you wonder why it takes so much more build time when your artifacts get bigger and bigger?
You probably have the same potential for improvement as I had in my current project. Read on to learn how you can get your builds faster and waste less time waiting for your builds to complete. A fast feedback loop is of major importance, especially in agile software development.
In the project I’m currently working on, we have a fairly complex build process with many artifact dependencies between the various stages in our build chain. At some time we felt the build started slowing down. In the next retrospective meeting my team decided that I should analyze the build process and implement improvements to get us back to fast build times.
In this post I’ll only write about how I implemented the improvements. Let’s have a look at our build chain first:
In the above diagram you see the 4 stages in our build chain: build, test, installer, publish. You can see that the artifacts of the Integration-build (.NET) are used in four dependent builds: 3 test runs and the installer. These artifacts are about 1.2 GB in size and consist of thousands of dll’s and other small files. Now, keep in mind that the TeamCity system has to copy those artifacts 5 times per build (e.g. 6 GB in small files). Why 5? – You got it. Once from the Integration-build (.NET) build agent to the TeamCity server (artifact publishing) and 4 times to distribute them to the 3 test run and the create installer agents (artifact resolving).
Remember what you learned about reading and writing very small files from and to a hard disk? It is very slow compared to writing one large file with the same total size. Let’s have some numbers to see the impact on our build times: Resolving the build artifacts takes about 20 minutes for each of the 4 builds. So, it takes 80 minutes of CPU time just to resolve the artifacts in our build, which is triggered on every commit. As we are running these 4 builds in parallel, we actually “only” lose 20 minutes with artifact resolving, but it’s still too much. And it causes a higher CPU consumption on our virtualized server environment.
How can we improve and get our build faster?
Probably you already know it: The new Windows Store App class libraries prevent proxy generating using frameworks like Castle.Core because System.Reflection.Emit namespace is missing in the limited framework they’re using.
But we still want to do TDD and therefore we need a nice mocking framework, like FakeItEasy, don’t we?
In this blog post I will show you the best way I came up with to develop Windows Store App compatible code with TDD.