Archive for the ‘languages’ Category

The TestDriven.NET Quickstart: Not So Quick

Sunday, 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.

Learn to Program

Thursday, 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.

Catching up

Wednesday, May 22nd, 2002

Not sure how I could have missed mentioning this, but apparently I did. My little Google Outline Browser was featured quite prominently in Jon Udell’s Byte column last month. I’m quite gratified, and a little guilty that my own doctitles aren’t quite up to snuff.

Jini configuration hell

Friday, May 3rd, 2002

Since its introduction, pundits have wondered why Jini has failed to catch on like other Java technologies. Having recently tried to take the plunge into JavaSpaces, I believe I can answer that question.

Put simply, Jini is too hard to configure. I consider myself fairly intelligent, and I have a lot of Java experience and a fair amount of Solaris experience. Nevertheless, it took me over a week of wasted evenings trying to run the Ray Tracer example included with the Jini distribution. Running this example requires no less than 6 processes to be running, 4 of which require commands spanning multiple lines to start.

You can see the fruits of my labor, a shell script that starts everything running. For everyday use, I’ve broken it into 5 different shell scripts: jini-start-all.sh, jini-start.sh, jini-stop-all.sh, jini-stop.sh, and one for the application (e.g., browser.sh or raytrace.sh).

I haven’t even started writing my own programs, this is just to run the example. Folks, developers are going to be slow to adopt Jini until this get easier.

A tip for Google API experimenters

Friday, April 12th, 2002

Check out Jython and use the Java API docs. Not only is Python a nicer language, but you can leave out the “get” and “set”. Place googleapi.jar in your jre/lib/ext directory and try the following:

import com.google
engine = com.google.soap.search.GoogleSearch()
engine.key = '00000000000000000000000'
engine.queryString = 'google api'
answer = engine.doSearch()
for result in answer.resultElements:
    print result.URL

(Replace 000… with your key)

Much nicer.