Thoughts on Technology, Methodology and Programming.

Archive for July, 2006

Charlie "Discovers" Ruby

Posted by Marcus Wyatt on 31 July 2006

Charlie Poole (From NUnit Fame) does a brilliant intro post on discovering Ruby:

This week at OSCON 2006 I finally learned some Ruby. I’ve been meaning to do this and learning by listening to Dave Thomas and Mike Clark seemed like it would be much more fun than simply reading a book. Turns out I was right.

In the process, I discovered a cool thing about Ruby and invented a really neat way to use it. Except not really: other folks already knew about my “discovery” and my “invention” has been invented a few times before! Oh well! It was fun and I learned a lot. If you don’t know Ruby, some of this may be new to you as well. If you do know it, perhaps you’ll find something to smile about here.

Technorati Tags: powered by performancing firefox

Posted in RoR | Leave a Comment »

TeamLook – Combining Outlook 2003 and Team Foundation Server

Posted by Marcus Wyatt on 25 July 2006

I found this great Microsoft Outlook 2003 add-in developed by Personify Design to enable effective communication between team members while integrating with Team System at the same time. Here is some marketing guff:

Personify Design TeamLook™ extends Microsoft Outlook 2003 so that all stakeholders in a software project can communicate more effectively and gain accurate visibility into project status. TeamLook™ connects to Visual Studio 2005 Team Foundation Server and enables users to view WorkItems, Reports, and other artifacts stored in their Visual Studio 2005 Team System installations. With constant synchronization TeamLook™ functions in a similar manner to other Microsoft Outlook features, reducing training costs and enabling organizations to realize immediate productivity gains.

Cool TeamLook™ Features

The possibility this application gives a development team to stream line their communication and task tracking process, just blew me away.

Here is a nice screen shot.

Create a workitem from an email; this is a really nice feature, because our project managers live in their inbox

For more information, check out their Discover TeamLook page. I’m finding Team System is becoming more useful as people are adding more value on top of the existing system. TeamLook is one such value add item I think you’ll struggle to live without.

Technorati Tags:

Posted in Development, Software | Leave a Comment »

More convinced about Behavior-Driven Design

Posted by Marcus Wyatt on 25 July 2006

C. Keith Ray has the following post:

I am now convinced that the word “test” in Test-Driven Development is a barrier to understanding that TDD is a design process. Next time I give a presentation on that subject, I will use “Behavior Driven Design” and “Behavior Specs” rather than “Test-Driven Development” and “Programmer Tests”. I have slides on TDD and BDD for your perusal. Compare them and see what you think. (Better, show the BDD slides to people not familiar with TDD/BDD and see what they think.)

TDD Slides (pdf)

BDD Slides (pdf).

Please note: Under Creative Commons copyrights, you may use these slides, unmodified, for non-commercial purposes.


Technorati Tags:

powered by performancing firefox

Posted in BDD, TDD | Leave a Comment »

Regulazy – Awesome little Regex tool

Posted by Marcus Wyatt on 22 July 2006

Today I downloaded Regulazy and had a play. Regulazy is a great little Regex utility to make your life so much easier. Well worth the download if you are like me, regular expression impaired.

Regulazy is a visual Regex Creation tool for beginners.
Easy point and click user interfaces, predictive technology and much more!
Still in alpha, but more features are coming!

  • Point & Click: No need for regex knowledge
  • Predictive technology: Regulazy tries to give you the best options for the selected text
  • Code Sample Generation in VB.NET and C#

powered by performancing firefox

Posted in Development, Software | Leave a Comment »

Twelve benefits for doing TDD

Posted by Marcus Wyatt on 22 July 2006

J. Timothy King list the following twelve benefits you get from doing Test-First programming:

  1. Unit tests prove that your code actually works. That means you have fewer bugs. No, unit tests can’t replace system and acceptance testing. But they do supplement it. The fewer bugs that make it to QA, the better.
  2. You get a low-level regression-test suite. You can go back at any time and see not only what broke but where the bug is. Many teams run the unit test suite as part of the nightly build. It’s a low-effort way to catch bugs before the build goes off to QA.
  3. You can improve the design without breaking it. This is actually part of step 3 above, the refactoring step. So test-first code usually doesn’t need to be refactored. I have worked on some systems that were so screwed up, like a psychotic individual, you just couldn’t untangle them. Having unit tests in place, you can do powerful refactorings that can untangle the most challenging of system psychoses.
  4. It’s more fun to code with them than without. You know what your code needs to do. Then you make it do it. Even if you don’t have a working system, you can see your code actually run and actually work. You get that great “I’ve done it!” feeling. Now repeat every minute or so. Just try test-first if you want to be high on endorphins, proud about your work, and motivated to do more.
  5. They demonstrate concrete progress. You don’t have to wait a month for all the pieces of the system to come together. You can show progress even without a working system. Not only can you say you’ve written the code, you can actually demonstrate success. Of course, this is another distinction that traditional programming teaches us to ignore. “Done” doesn’t mean you’ve written the code and checked it in. “Done” means the code actually runs in the system without bugs. Running unit tests is a step closer to the latter.
  6. Unit tests are a form of sample code. We all encounter library functions and classes we don’t know how to use. And one of the first places we go is the sample code. Sample code is documentation. But we don’t usually have samples for internal code. So we’re left sifting through the source or through the rest of the system. Because Bob, the guy who wrote that code, is no longer with the company, so we can’t actually ask him how it’s supposed to work. But unit tests are documentation. So when you can’t remember how to use class Foo, read the unit tests to find out.
  7. Test-first forces you to plan before you code. Writing the test first forces you to think through your design and what it must accomplish before you write the code. This not only keeps you focused, it makes for better designs.
  8. Test-first reduces the cost of bugs. Bugs detected earlier are easier to fix. Bugs detected later are usually the result of many changes, and we don’t know which one caused the bug. So first we have to hunt for and find the bug. Then we have to refresh our memories on how the code is supposed to work, because we haven’t seen it for months. Then finally we understand enough to propose a solution. Anything that reduces the time between when we code the bug and when we detect it seems like a obvious win. We consider ourselves lucky to find out about bugs within a few days, before the code is shipped to QA or to customers. But how about catching them within a few minutes? That’s what test-first accomplishes with the bugs it catches.
  9. It’s even better than code inspections. Code inspections, they say, are better than testing, because using them to detect and fix bugs is cheaper than testing. After the code ships, it’s much more expensive to fix the bugs. The earlier we can detect and fix bugs, the easier and cheaper and better. That’s the advantage of having code reviews: Code inspections catch more bugs within a few days, rather than a few months. But test-first catches some bugs within a few minutes instead of a few days. It is even cheaper than code inspections.
  10. It virtually eliminates coder’s block. Ever wonder what statement to write next? Like writer’s block, coder’s block can be a real problem. But test-first systematizes the structured part of coding, allowing you to concentrate on the creative part. You may get stuck on how to test the next bit or how to make the test pass, but you’ll never be left puzzling over where to go next. In fact, usually you’re left with the opposite problem: You know you need to take a break before you burn out, but you’re on a roll and don’t want to stop.
  11. Unit tests make better designs. Testing a piece of code forces you to define what that code is responsible for. If you can do this easily, that means the code’s responsibility is well-defined and therefore that it has high cohesion. And if you can unit-test your code, that means you can bind it as easily to the test as to the rest of the system. Therefore, it has loose coupling to the pieces around it. High cohesion and loose coupling is the definition of good, maintainable design. Code that is easy to unit-test is also easy to maintain.
  12. It’s faster than writing code without tests! Or to put it another way, skipping unit tests is faster, unless you actually need the code to work. Most of the effort we spend on code, we spend fixing it after we’ve checked it in to the source-code repository. But test-first eliminates much of that waste by allowing us to get more of it right to start with and by making bugs easier to fix.

I would recommend you read the complete post as it is very informative.

Technorati Tags:

Posted in TDD | Leave a Comment »

It’s Not Just Stand-up

Posted by Marcus Wyatt on 19 July 2006

Martin Fowler posted this great article written by Jason Yip on Stand-up meeting patterns. Who would have thought that a soft process like a meeting can be described like a pattern. This is well worth the read. Here is an excerpt from the article:

The daily stand-up meeting is simple to describe: the whole team meets every day for a quick status update. This short definition does not really tell you the subtle details that distinguish a good stand-up from a bad one.

People who have experienced good stand-ups will generally know what can be done when things aren’t working well. This capability is obviously less likely for people with limited experience to reflect on. I’ve written this paper as an attempt to partly compensate for inexperience by describing the benefits and consequences of common practices for daily stand-ups. These patterns of stand-ups are intended to help direct the experimentation and adjustment of new practitioners as well as provide points of reflection to experienced practitioners.


Posted in Communication, XP | Leave a Comment »

Refactoring – Going Generic

Posted by Marcus Wyatt on 18 July 2006

This post on the JetBrains.NET Tools blog descibes a nice way to refactor your array declarations to generic lists.

So, now that people are migrating from .NET 1.1 to 2.0, it would be great to somehow convert legacy interfaces from arrays to collections. For this, ReSharper comes in extremely handy. We ourselves used the following procedure when developing ReSharper 2.0 and we think it can be useful to you, too.

The post will give you a good introduction to a few of the really cool features of ReSharper.

Technorati Tags: ,

Posted in Refactoring, Software | 1 Comment »