By: Cecil Williams & David Kessler
If you’ve tried to create an NUnitAddin that works with Resharper you quickly found that it simply doesn’t work. In fact, it’s been confirmed that Resharper does not currently support NUnit EventListener addins. While this is true, I’ve found a work around that works very nicely.
» Read more: NUnit Addins That Work With Resharper
ThoughWorks Studios has released an ebook titled “How do you estimate on an Agile project?” where they explore common approaches and their adaptions from real-world projects. The book is comprised of several authors, most notably Martin Fowler. In this ebook they discuss why teams estimate, different methods that teams use to estimate, and provide a couple of case studies.
» Read more: ThoughtWorks releases ebook on Agile Project Estimation
Over the last year or so software development estimates have become a popular topic. The popularity stems from the inherent fact that estimating software development is difficult. Some people are writing about ways to improve your estimates while others are writing about how to manage software development without estimates.
Now we will cover the fun stuff for which we’ve been waiting. In this post, I’ll go over how to setup Sonar for a Java project that utilizes Ant for its build. I’ll go through the basic steps for installing and running a Sonar instance, and how to use a MySQL database for collecting metrics. Then I’ll go into some details around analyzing a Java project using Ant and Sonar. This involves writing Ant script, pointing to the source codes, analyzing the binaries, analyzing JUnit test cases, analyzing Ecl Emma coverage, etc.
Do you sometimes feel like your team spends more time documenting your system than building it? One of the biggest hindrances to progress in a software project is documentation. The Agile Manifesto prescribes that teams should value working software over comprehensive documentation. It doesn’t mean that you should not create documentation; it means you should create documentation that provides value and at the same time does not hinder the team’s progress.
What we covered so far ?
In my previous post I covered the reasons why software quality metrics should be collected and why improvements to the code should be made based on those metrics. In this post I’ll be illustrating how Sonar can fulfill the job of collecting metrics and driving decisions.
Sonar goes beyond just collecting and displaying metrics:
- Sonar can answer the following questions:
- What are our most critical code quality issues?
- Where is the highest concentration of code issues?
- How many working hours will it take to fix the issues?
- What does the metrics trend look like over the past year?
- Sonar can be used to track work tickets assigned to team members.
In short, Sonar helps us analyze the situation, take actions, and quantify the improvement.
If you haven’t heard of Git or don’t understand why you should use it, checkout the talk given by the author to Google (Torvalds, 2007). Git is an excellent version control tool for agile software development. But many of us may not have the luxury of using Git because our company has deemed that we shall use Subversion. Now Subversion is not a bad tool and has added some nice features in version 1.7. But my preference is to use Git. » Read more: Using Git with Subversion
David Morgan and Cecil Williams, March 25, 2013
One of the biggest hindrances to progress in software projects is bureaucracy. Rigorous processes that must be followed unswervingly, deliverables changing hands between independent groups and required approvals – hand-offs, sign-offs, and stand-offs – all get in the way of software projects making valuable progress. So how would you change that? » Read more: Agile Manifesto – Value individuals and interactions over processes and tools
I want to share an experience that my colleague, Travis Klotz, and I ran into recently.
I was trying to manually test a Java web application running in debug mode. It was running really slow, taking several minutes to launch after the compile was finished. And when it did eventually start, using the application was very slow. Pages would take almost a minute to render. So Travis and I started trying to determine the cause. » Read more: Java method breakpoints are evil