The TestDriven.NET Quickstart: Not So Quick

November 11th, 2007

So I’ve started playing with TestDriven.NET, a Visual Studio Add-In that lets you run NUnit by right-clicking and choosing Run Test(s).

There’s a Quickstart page to get you up and running, but some details were omitted:

  1. Your project needs a reference to nunit.framework.dll, probably located in
    C:\\Program Files\\TestDriven.NET 2.0\\NUnit\\2.4
  2. Add this to the top of your file:
    using NUnit.Framework;

    If you want to use the nifty Assert.That(foo, Is.Not.EqualTo(bar)) syntax, also add

    using NUnit.Framework.SyntaxHelpers;

If you don’t do that, when you try to Run Test(s) you’ll get

The type or namespace name 'Test' could not be found
 (are you missing a using directive or an assembly reference?)
The type or namespace name 'TestFixture' could not be found
 (are you missing a using directive or an assembly reference?)

Some of you are thinking “Well, duh,” and in general I’d agree, but the QuickStart really ought to mention it. Since all it says is to right-click and run the tests, I initially thought something had gone wrong during the installation.

Bonus Linkage for Nifty Syntax: Troy DeMonbreun’s Learn the new NUnit 2.4 Constraint-Based Assert Model, is a handy quick-reference.

Agile Project Management with Scrum

August 18th, 2007

I just finished reading Agile Project Management with Scrum by Ken Schwaber. It was an easy read with entertaining war stories, but when it comes to the Scrum methodology itself I find myself a bit torn.

On the one hand, it seems like an entirely reasonable and sane way to manage a software project with constantly changing requirements while producing a minimal amount of overhead in the form of paperwork.

On the other hand, it seems that you can’t have a software development methodology without high-priced consultants to show you how to do it. Honestly, though, Scrum is simple enough that I can’t see why you’d need one…

Unless, of course, they invent their own jargon, in which case it might sound pretty complicated. It might even sound so complicated and different from what you’re doing now that you might decide that a consultant sounds like a pretty good idea after all. Hmmm…

Let me save you the money. Here’s a description of Scrum using the jargon:

  1. At the beginning of a Sprint, the team meets with the Product Owner and the Scrum Master to update the Product Backlog
  2. The team creates a Sprint Backlog by selecting the items in the Product Backlog that it will turn into sashimi1 during the Sprint
  3. Each morning, the team holds a Scrum to coordinate the tasks it will work on
  4. At the end of the Sprint, the team holds a review meeting where it demonstrates the work accomplished
  5. All meetings are time-boxed
  6. Once a cycle is completed, it begins again, updating the Product Backlog for a new Sprint

And here’s a description of Scrum in English:

  1. Every 30 days, the team meets with the Product Manager and Team Lead to update a prioritized list of features and tasks
  2. The team decides decides how many of the top priorities it can handle in the next 30 days, and commits to finishing them completely
  3. Each morning, the team holds a short meeting to discuss current status of the tasks on the list and address any issues that arise
  4. At the end of the 30 days, the team demonstrates the work accomplished to the stakeholders
  5. All meetings are limited to a fixed time (e.g., 15 minutes for the daily status meeting) in order to keep the work moving forward
  6. Once a cycle is completed, it begins again, updating the list of features and tasks to reflect new prorities and choosing those to be accomplished in the next 30 days

That said, it’s still worth reading. The stories of teams using Scrum in the real world are fun to listen to, and you might even learn something. Particularly when it comes to Software Engineering, it’s easy enough to get caught up in a lot of abstract theory about the software lifecycle (or raw fish, or whatever) that it’s very helpful to see how it’s actually put into practice.

I have to say, though, that when it comes to consulting, Schwaber almost lets the cat out of the bag. In Chapter 5, The Product Owner. He tells a story about working with a company where both team and management were pretty skeptical of Scrum, so he decided to keep it low-key:

… I told them that we used a prioritized list of things that they wanted done to drive development cycles of one month. Every month, we’d show them completed functionality, we’d review the list of what to do next, and we’d figure out what the team could do next… Scrum seemed simple, easy to understand, and [...] very straightforward.

Of course, if you put it that way, how are you going to make any money? Certified ScrumMaster? Sounds good. Certified Guy-Who-Keeps-the-Prioritized-List? Not so much.

Bottom line: if you want to know about Scrum, read about it on the web, then try it. If you’re like me, you’ll read the material available on the web and figure that it seems way too simple — there must be more to it, and decide that you need to purchase a book or two to really understand the methodology.

Well, yes and no. If you like reading (and I do), and if it makes you feel better (and it did), go ahead and get the book. It’s short read (fewer than 150 pages), it’s pretty entertaining, you’ll probably learn something, and it might even fire you up, thinking “hey, yeah, this could work!” On the other hand, if you’ve read the available materials on the web, you’ve pretty much nailed it. The only way you’re going to get any better at it is by doing it.


1At least, I think that’s what sashimi means; the term is used before it’s defined, and it doesn’t appear in the book’s glossary. From searching the web, it appears that it might be the name of an actual Japanese project management methodology. Or possibly just raw fish.

Learn to Program

July 13th, 2006

I’m a big fan of the Pragmatic Programmers, so when Ruby first appeared on the scene I bought a copy of the first edition of Programming Ruby. Honestly, it failed to grab me. It looked like a nice enough language, but its syntax is sort of a hybrid of Perl and Python. Given that I already know both Perl and Python, I couldn’t see the point of spending much time on Yet Another Language, especially one that was more of the same.

Still, buzz continued to grow. I picked up a copy of Hal Fulton’s book The Ruby Way. This one included Appendices explicitly for Perl and Python programmers, as well as several “real-world” examples, so I gave it another shot.

Actually, I started to give it another shot. But since the Appendices were squarely aimed at me, I started there. Big mistake — I fell asleep. Several times. I put the book aside and figured I was done.

Three years later, in 2004, along came Ruby on Rails. Wow. Do I really need to tell you how impressive Rails is? But at the time I wasn’t working on any web applications, I still wasn’t thrilled with Ruby as a language, and I certainly wasn’t thrilled at the prospect of learning a whole new language just to write web apps.

More recently I’ve been looking at the cavalcade of Rails clones. I think I’ve settled on CakePHP as the best documented, most mature, and easiest to learn. But just as I was getting started, it occured to me….

As I tell students, the best way to learn is by going straight to the source, not by reading the nth re-hash by someone else. I’m still planning to learn Cake, but really, why not start with the best? (Or at least with the original.)

Ok, back to Ruby. In the years since Programming Ruby was published by Addison-Wesley, the Pragmatic Programmers have started their own publishing company, The Pragmatic Bookshelf. Which brings me (finally) to the ostensible subject of this review, Learn to Program by Chris Pine.

The purpose of Learn to Program is, well, to learn to program. The language just happens to be Ruby. Honestly, I don’t even remember when I first learned to program — I must have been 7 or 8 years old. (BASIC, on a Timex-Sinclair 1000, if you must know). I can’t really comment on how well the book succeeds in that goal, because I’m clearly not the target audience.

I read through the book fairly quickly, since I already understand the concepts. A couple of things concerned me, though. The explanation of “variables” seemed overly complicated. I think the author was trying to explain references, without actually using the word “reference”.

Ditto his explanation of recursion — I admire the attempt to suggest that recursion is a perfectly natural concept (the title of Chapter 10, on recursion, is “There’s Nothing New to Learn in Chapter 10″), especially since most CS1 textbooks for imperative languages make it far too complicated. But c’mon. If it’s so easy, why does “nothing new” take 17 pages to explain?

So I can’t tell you whether it’s a good book for a beginner, but it was a good book for me. The truth is, the only way to learn a new programming language is to write code. You can’t just sit and read a book about programming; you need to do it yourself. In this, the author succeeds wonderfully. The exercises he suggests (under the heading “A Few Things to Try”) are geared toward putting the concepts you’ve just read about directly into practice. And they’re straightforward enough that, instead of thinking “oh great, another programming exercise,” you’ll be thinking “hey, that sounds easy enough,” and you’ll dive right in.

Even better, they’re fun. No lame “Hello, world” or farenheit-to-celsius converters here. (Oops, I think I just insulted K & R.) Instead you’ll find such gems as

  • An “Angry Boss” program, which rudely asks you what you want, then yells and fires you.
  • Generating .m3u playlists for use in WinAmp
  • 99 Bottles of Beer on the Wall

The example programs are great, too. A psychology student who’s dying to found out whether you wet the bed as a child? An algorithm from the game Civilization III? A baby dragon? Heh. Baby dragons. If you’re looking to pick up Ruby, this is a fun way to get started. Oh, and my impressions of Ruby now that I’ve written a few short programs? It’s kind of a nice language. You can slurp the contents of a file in a single line. It switches seamlessly between fixed-sized integer types and “big” integers. (As it turns out, so does Python, but I’d never seen it before). YAML is nicer than Perl’s Data::Dumper. I like that you can add easily add methods to built-in classes, even if it’s probably a bad idea — being able to type 3.factorial is coool.

Ruby strikes me as being sort of like Python, if Python had been written by someone who liked Perl. I don’t think, though, that it goes the other way: Ruby is not sorta like Perl. It just has enough Perl-ish bits to make the transition less painful.

I’m having trouble deciding on my next Ruby book. I’m leaning toward the Pickaxe Book, but Ruby for Rails looks good, too. After all, that’s why I was planning to learn Ruby in the first place.

By the way, click here for some bits of Ruby code. Nothing spectacular, but they’re sitting here on my hard drive — no point in not sharing them.

Compiling Fl-Inventor on Windows

June 15th, 2006

Another option for Open Inventor programming on Windows is the Fl-Inventor library. Here’s how I got it to build:

  1. Download the latest version of FLTK 1.1 from http://www.fltk.org/. At the time of this writing, the latest is fltk-1.1.7-source.zip
  2. Unzip somewhere convenient, say C:\fltk-1.1.7
  3. Open visualc\fltkdll.dsw with Visual Studio. (I’m using 6.0. If you’re using a later version, your mileage may vary.)
  4. Choose Build, Set Active Configuration… and choose fltkdll - Win32 Release

fltkdll

  1. Choose Build, Build fltkdll.dll.
  2. Download and install an older version of CMake from http://www.cmake.org/files/. (The latest version won’t work without change, and the last thing I need to learn is a new build tool.) I used CMSetup14.exe.
  3. Download fliv-1.0.1.tar.gz and oiv_linux_w32-4.tar.gz from http://fl-inventor.sourceforge.net/. Unzip them both into the same place.
  4. Change to C:\fl-inventor and type “cmake .
  5. Back in Visual Studio, open FLINV_ALL.dsw
  6. Set the Active Project Configuration to “ALL_BUILD - Win32 Release”.

all_build

  1. Choose Project, Settings…. Settings For: should be set to “Win32 Release”, and all sub-projects should be selected.
  2. Holding down the Ctrl key, de-select ALL_BUILD. Some more tabs should appear to the right. Select the C++ tab, and change Category: to “Preprocessor”. Under Additional include directories:, add C:\fltk-1.1.7.

include-directories

  1. Holding down the Ctrl key again, de-select FL, FreeType2, and Jpeg. A Link tab should appear to the right. Select it and Change the Category: to “Input”. Under Additional library path:, add C:\fltk-1.1.7\test. Click Ok

library-path

  1. Choose Build, Build. The build will take several minutes.
  2. Exit Visual Studio. You should be able to run the example programs from C:\fl-inventor\install\bin

Open Inventor on Windows

June 14th, 2006

The Open Source version of SGI Open Inventor is Linux-specific, and while it probably ports easily enough to other UNIX platforms, it doesn’t look like a very attractive option for Windows.

If you want to do Open Inventor programming on Windows, the options seem to be:

  1. TGS Open Inventor, a commercial product
  2. Coin3D, a GPL clone of Open Inventor
  3. a Win32 port of the Open Source SGI Open Inventor that requires the SoQt library from Coin3D

Coin3D is probably the best choice, but it seems to include only the OI libraries, not the OI command-line tools like ivview and ivnorm.

Alternatively, the Win32 port of Open Inventor does incldue pre-compiled DLLs of Inventor, but not of the SoQt library or command-line tools.

I’m honestly not sure what the best solution is. I’ll post some instructions when I come up with something.

Minimal Ray Tracer

May 20th, 2006

Some code to accompany tonight’s lecture: a version of Paul Heckbert’s Minimal Ray Tracer from Graphics Gems IV.

I’ve updated the code to do the following:

  • compile with GNU C
  • output plain PPM
  • generate a 1024 by 1024 image instead of the tiny 32-pixel original

I’ve also included a JPEG version of the image, generated with ppmtojpeg,

If you want to experiment with changing the scene defined in ray.h, you’ll probably want to download NetPbm for Windows.

Assignment 10

May 14th, 2006

If you didn’t finish Assignment 10, you can download assignment10.c as a starting point for Assignment 11.

Pixar’s On-line Library

May 13th, 2006

I happened across this the other day: Pixar has made available an On-line library of technical papers. Many of them are probably a bit advanced, but worth a look if you’re considering further study.

Demos for tonight’s lecture

May 13th, 2006

There are two demonstration program for tonight’s lecture:

You will need the texture mapping technique for Assignment 11.

Material Colors

May 10th, 2006

Here’s a function to set the current drawing color, whether or not lighting is enabled:

void color(double r, double g, double b)
{
    float color[4] = { r, g, b, 1.0 };

    if (glIsEnabled(GL_LIGHTING)) {
        glMaterialfv(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE, color);
    } else {
        glColor3f(r, g, b);
    }
}

Note that although the color can be set for GL_AMBIENT and GL_DIFFUSE separately, you’ll usually want them to be the same.

Alternatively, you could try reading about GL_COLOR_MATERIAL.