I released a newer version of IronRubyUnit yesterday.  This version fixes problems with the "are_equal" assertion.  If you experienced these you will probably want to download this newer version and try again.

I'm continuing my development using 100% TDD using IronRuby, IronRubyUnit, and Chiron.   It works pretty good so far.  I am using a very unusal combination.  I am using JScript .NET on the server and IronRuby on the client.  Yes you heard that right.  Ruby on the client and JavaScript on the server.  I like it so far.  I would like to use IronRuby on the server using .NET but they aren't ready for that yet, so I chose to use JSNUnit ad JScript on the server.  Doing this allows me to stub anything without using a mocking framework on both client and server and I never have to use a compiler.  It's like driving a motorcycle instead of taking a train I think.

For more information on IronRubyUnit, see my previous post.

I am pleased to announce the release of IronRubyUnit 1.0.  IronRubyUnit is a unit testing framework designed for test-driven developers who wish to develop Silverlight applications in IronRuby.  This was a port of the JSNUnit framework to Silverlight and IronRuby.

This framework depends on using Chiron in the Silverlight Dynamic Languages SDK.

I have also released a completely dynamic version that you can play with on the web called the IronRubyUnit Console.  This is an early version, but I thought that I should make it available since there is very little out there to help developers who do strange things like attempt to use IronRuby on Silverlight with Chiron and insist on using Test-Driven Development and perhaps do the whole thing on Mono.

You can develop using Chiron and the Silverlight Dynamic Languages SDK using any editor really.  If you need one, you can dowload one of Microsoft's free versions of Visual Studio.  Notepad even works.  I haven't tested this on the Mac or on Moonlight yet, but I don't see any problems with doing that.

The code is pretty simple.  This should make it easier for you to change to your own liking.  Tests are created by inheriting from "Test" and then instantiating them immediately after.  This registers the test for the runner.  The test runner runs inside the browser in Silverlight and runs with every refresh.  A code.rb file is provided to type in your production code and a test.rb file is provided to write your tests into.

When it comes time to deploy your application, you need to use Chiron to create an empty applicaton and copy the code.rb file and the .xaml file into the empty project before following the Chiron instructions to create your xap file.

To start:

1. Download the Silverlight Dynamic Languages SDK
2. Unzip the SDK and put it into a directory
3. Download IronRubyUnit 1.0
4. Unzip it into a sub-directory under your SDK directory
5. Start Chiron in the SDK directory "server /b"
6. When the browser comes up, navigate into the IronRubyUnit directory
7. Click on index.html

If you are notified to install Silverlight 2, make sure to do it.  This requires Silverlight 2.  Use your editor to modify the test.rb and the code.rb files in the "ruby" directory to create tests and code.

 

I am pretty impressed with Microsoft's new Dynamic Language Runtime (DLR) and languages that they recently released with Silverlight.  This library makes it possible to use scripting languages with .NET.  A great deal of effort has gone into this project and it is pretty cool.

IronRuby runs on the DLR in Silverlight 2 and it's pretty cool too.  Something about using these new langauages on top of .net really brings out creativity and potential for me.  Perhaps it's because I remember back when the "microcomputer" was new.  Almost all of the department stores had these gadgets in their electronics departments.  The only way to use these amazing things was to program them in BASIC and leave them on or save the program on a 5.25 inch floppy disk if you could afford one.  The form of BASIC on computers like the TRS-80, Apple IIe and Commodore was dynamic.  You just type in your program and run it right out of memory.  Computers took about 10 seconds to boot and you could start programming right away.  This same thing happened when browsers started using JavaScript.  Suddenly you could just type in a program and amazing things would appear.  I think that the DLR puts you in a place in .net where creating and discovery can be done at a rapid pace.  I think that this is what caused "Personal Computers"  and "the Web" to become what they are today.  Finally, we have the whole .net framework to play using the same ideas.

I think that one thing that holds people back from seeing the genius of this release is the baggage that we have gotten used to.  We automatically think about compilers and dlls and environments.  The DLR really hides all that and lets you get right to work.  It works best when you to use a rapid feedback loop.  Just turn it on, type some code, see it work, try some more, see it work, etc.  Another problem that I think hides the power of the DLR a lack of communication about it from Microsoft because the investment by Microsoft has been pretty small compared to the value it is to me.  Microsoft is relying on "the community" and that makes it hard to spread the word, unless, of course, we do it.  The team working on the dynamic language runtime is pretty small, but the power of what they have been able to do proves that there is something to this concept.

After investing hours this weekend trying to port my JSNUnit to IronRuby and Silverlight (the first version of which I plan to release soon),  I discovered that one of the best ways to get the information I needed was to play as much as I could with the "DLR Console".  This is actually an demo that was originally made for Mix  a couple of years ago by Jim Hugunin.

The DLR Console takes about 10 seconds to start and you can start programming immediately right online without installing anything (you do have to have the Silverlight 2 plug-in).  You can choose between IronPython, IronRuby, or XAML.  You type something and it will give you immediate feedback.

I suggest starting with the DLR Console and use the .net Silverlight 2 library documentation to think of things to try and things to play with.  It's a lot of fun and the rapid feedback allows you to learn very quickly.

When you want to start writing software for the DLR, I suggest downloading the Silverlight Dynamic Language SDK.  Have fun!

C# may very well turn into the most popular general purpose language after all.  It isn’t a big surprise to me because years of very hard work have gone into what we have today and it is clear that the hard work continues.  I have been traditionally very hard on C#, mostly because if it’s lack of dynamic typing and meta-programming support and the difficulties that it causes agile developers.  It is a language that has attempted to stay “Explicit Typing Only” at my expense, it seemed.  It seemed to me that JavaScript, with all if its warts, was running circles around C# and laughing.  JavaScript already had closures, lambda functions, and dynamic typing many years ago.

It has long been my opinion that a good general purpose language needs to give the programmer the choice.  If the programmer wants to use only explicit typing, then they should have that choice.  If the programmer wants to use dynamic typing only, the programmer should also have that choice.  If the programmer wants to find a good mix of the two, that sounds great too.  C# seems to be the one that will reach this great place if things continue as they appear to be.

I hope to talk a little bit more about what I think is so great about what’s going on with C# in the days to come and how it can help a real software development practitioner.

I would like to suggest that we consider copying the movie business and employ “Producers” in software product development.  I have never seen this in the jobs I have done, but I bet they are out there somewhere.  I would be very interested in knowing if anyone out there has been formally called a software product “Producer”.

Extreme Programming used the word “On-Site Customer” which I think works fine, except that I don’t think that it communicates as well as the word “Producer”.  I like “Producer” because it makes it clear that this person is responsible for the “Product” not the “Software.”  The Mary and Tom Poppendieck in “Implementing Lean Software Development” made this concept clear to me.  Software is really only a part of the effort of making a real product.  If this is so, then someone other than the “Programmer” needs to step up to the plate and take charge or else we will most likely have problems.

The way I see it, I wasn’t really trained to be a producer.  I’m a programmer.  I am still considering this concept, but I think that the difference between the producer and the programmer is that the producer must describe what the machines should be thinking about and the programmer makes them think that way.

When a programmer is only given a product description, it still leaves too little information for them to really know where the machine is supposed to think and when other machines and people are expected to take over.  I can see that this could require a significant amount of conversation between the programmer and the producer, but it would still be the producer’s job to clarify to the programmer where the “line” is between their work and the outside world.

If a producer was a part of the team and given that title, I think it might help out quite a bit.  I have seen that these people are already in the business, but they deserve the proper title and pay!