David Siegel, will you be my new lover?

Rick Harding just linked me to this post that pretty much sums up the way I feel about Mono.

http://blog.davebsd.com/2007/12/08/early-criticism-of-gnome-do/

I don’t make the choices that David makes regarding free software. I’ve been using Linux for over 12 years now. I like it. It does a lot of things really great. I run Windows Vista on my laptop. I like it. It does a lot of things really great.

I write code in C# and boo for the .NET platform because I feel that .NET is the best development platform in existence today. This means that in the Linux world, Mono is the best development platform in existence today. My choices are purely personal based on my understanding of the underlying technology. If something were to come out which gave me compelling reason to change my mind, I would develop using that other thing.

That other thing is not Ruby, Python, D or any variants. That other thing doesn’t run on the JVM.

I’m going to go double check some boo code which I run using Mono now. Thanks.

The Good Stuff Is Hidden

Intellisense is great, but it is no substitute for reading documentation. I’m always upset when I hear developers say that their primary source of learning is looking at what intellisense offers them.

There are a few methods which can be considered part of LINQ, which aren’t extension methods. This means that unless you actually type out Enumerable, you will never see then in intellisense. The nature of extensions methods means that you won’t ever type out enumerable, so these methods are less discoverable than others.

System.Linq.Enumerable is where the library implementation of LINQ to objects lives. Empty, Range and Repeat methods are hand tools.

Empty is useful for those cases when you don’t want a null object, but instantiating an Enumerable is wasteful. For example, creating a new empty List of string to pass to a linq expression when some other data source may return null or empty. I’m thinking of combining linq expressions here. The anti-wasteful programmer might say “well, just use a new empty string array”. And that programmer would be right. This would use less memory than a new List. But the really nice part about Empty is that its underlying implementation is just a generic singleton based on type. That means instead of 1000 or 100,000 “new string[0]” in your code, eating up a tiny bit of ram (ok, its pretty small here, I know, but doesn’t every little bit help?) you have only one empty string array that all cases can share.

Range should be familiar to anyone coming from python. It just returns an enumerable range of numbers from start to end. IMO it isn’t as nice as pythons, but I can always write my own. Still not clear? Here is how you would write a summary from one to one hundred million of n-1 + 1/i.

var x = Enumerable.Range(1, 100000000).Aggregate(0f, (a, b) => (float)(a + 1 / (float)b));

That is: sumOfFractions_2007-12-03_10-42-46

Finally, Repeat is similar to range, it just gives an enumerator which yields the same object/value repeatedly.

Example of using repeat to make 5 hello worlds:

var fiveWorlds = Enumerable.Repeat(“Hello World”, 5);
Console.WriteLine(fiveWorlds.Aggregate((a,b)=>a + “\n” +b ));

Funny .NET Graphics

Is it the pedant in me? I just cannot stand these graphics. They seem inaccurate to me.

Ok, so REST builds on WPF, but the AJAX is just the latest version of ASP.NET AJAX which has been a separate download for over a year. LINQ doesn’t build on anything .NET 3.0 either!

Here is another picture which shows the same thing.

This just cannot be right. What parts of LINQ build on any of WPF, WCF, WF or CS? Which parts of ASP.NET build on those? None AFAIK. The same goes for the Add-in Framework.

It deceptive. But it is also a good example of how marketing slides are inaccurate.

MbUnit, NUnit, but not MSTest

Guess who can use MbUnit or NUnit but not MSTest.

Users of Visual Studio Team System 2008 Architecture Edition. That is who!

http://elegantcode.com/2007/11/20/visual-studio-team-system-2008-architecture-edition/

It is just another reason to scrap MSTest altogether. Just ignore its inferiority. Ignore its silly integration with Studio which can be had for free via NUnit in SharpDevelop. Ignore its confusing availability in various projects. Just use NUnit or MbUnit.

I could go on much further with the list of things you must ignore to sanely choose MSTest. Instead I will list only two more things. NUnit works great with Mono on Linux. NUnitForms is a sweet way to unit test forms.

Nant Complexity and the Boo Build System

When I first read the announcement about the Boo Build System (whose acronym I will refrain from using) I wasn’t sure it was necessary. Today I saw an announcement for the ability of Nantbuilder and realized I was very wrong.

Anyone who has used GNU Build tools will know how complex a build system can get. Why isn’t make just good enough? Why aren’t nant or msbuild good enough?

I really don’t believe that the boo build system solves the complexity of a large build system. That said I do believe that an equivalent build project in boobs would be far easier to read than its nant counterpart just due to the nature of boo vs. xml.

Lets take a look at a trivial project configuration in Nant vs. Boobs.

<?xml version=”1.0″?>
<project name=”Hello World” default=”build” basedir=”.”>
    <description>The Hello World of build files.</description>
    <property name=”debug” value=”true” overwrite=”false” />
    <target name=”clean” description=”remove all generated files”>
        <delete file=”HelloWorld.exe” failonerror=”false” />
        <delete file=”HelloWorld.pdb” failonerror=”false” />
    </target>
    <target name=”build” description=”compiles the source code”>
        <csc target=”exe” output=”HelloWorld.exe” debug=”${debug}”>
            <sources>
                <includes name=”Hello.cs” />
            </sources>
        </csc>
    </target>
</project>

vs.

import Boobs.Engine
import Boobs.Compiler.Extensions

Task(“build”) do (ctx):
    Csc(
        SourcesSet : [“hello.cs”],
        OutputFile : “HelloWorld.exe”,
        OutputTarget: TargetType.Exe
        ).Execute()

Task(“clean”) do:
    if Exist(“HelloWorld.exe”): Rm(“HelloWorld.exe”)
    if Exist(“HelloWorld.pdb”): Rm(“HelloWorld.pdb”)

Task(“default”, [“build”])

I know which one I’d rather maintain and I haven’t even used control flow logic. I have always though if statements in XML were goofy at best and stupid normally. In boobs, it IS boo. the if statement is boo’s if statement.

Need to iterate over numbered files? Use boo’s for statement or while statement. These things have always felt awkward in XML. This isn’t Nant that is falling short, it is XML.

If you have a nant configuration which is working for you, then by all means keep it up! But if you are just breaking into CI and thinking about Nant, you may want to consider the boo build system.

NUnitForms Requires Administrator Privilege

I am one of those crazy security paranoid former system administrator turned programmer. I am a windows user. I think I’m on the only one.

I do not run as Administrator. In Linux I use sudo or gksu or some variant. In Windows I get by with runas 99% of the time and the other 1% of the time I just “switch user”.

I’ve been struggling to use NUnitForms. Since I had been struggling I’d been leaving it and coming back to it. Today I made a break through and it had nothing to do with code or understanding how NUnitForms works. Unfortunately it had to do with my crazy security paranoia.

NUnitForms requires administrator privilege. Once I ran NUnit as administrator, the pesky tests started succeeding. But even this was a struggle.

nunitWinMenuResult_2007-11-16_09-36-51

Strangely, when I use the windows menu, search for “NUnit” and click the result, it works fine. When I perform the exact same action and right click and click “Run as administrator” from the context menu, I get a very strange result.

cannotFindNUnit_2007-11-16_09-37-30

Fine. I can browse “c:\program files\NUnit 2.4.3\bin\” and right click launch NUnit.exe as administrator. Thankfully that works. But now comes my gripe!

All of my MRU information is different. In a program like NUnit this isn’t too big of a deal. It is more just annoying.

In Linux, using sudo, quite often it is possible to start a program as root, and yet have it still read its configuration from the normal place. sudo doesn’t change the HOME environment variable by default (this is like USERPROFILE and or HOMEPATH in windows). This means that if programs read their configuration information from a path relative to HOME, that you can start then with sudo and still get your local settings.

I am not sure if this is a good thing or a bad thing, but the flexibility of it is definitely welcome. If I want to set HOME, I can just start sudo with the -H option.

I miss you desktop Linux. Some days more than others, and especially today.

Test Driven Development – There is no excuse

There really is no excuse to not be using Test Driven Development. Any excuses are just that.

The Voidspace Techie Blogger has a great post about Spiking as an answer to one of the common excuses. My question: May I please have a job which involves only spiking all the time?  😉

I really do like doing new things and figuring them out and doing things I’ve never done before. If I have done it before then it isn’t interesting. I’m only half kidding about the spiking all the time job.

Still think your case is special? It isn’t. Still clinging to your excuses? TDD doesn’t work for you? Maybe you aren’t working for TDD! Yes it changes the way you work. That is the point! Its working BETTER!

Now if I could just figure out this NUnitForms I could test that much more.

Toot Toot! That is MY Horn. Thank You Very Much.

I was lucky enough to be interviewed by Josh Holmes of Code to Live fame about boo. I’ve been using boo more and more recently and I just love it. Check out the video!

I was a little nervous during the interview and so I caught myself misspeak. Just to clarify, I said “DLR” when I meant “DSL”. Boo doesn’t use the DLR, so please don’t be confused.

Binsor From Embedded Resource or Any Stream

Jeremy Jerrell has a couple of great posts about Binsor over at Digital Blasphemy.

In his latest he shows how to Embed the Binsor in your assembly, but IMO his implementation is all wrong. If not all wrong, then it is a hack at best. Maybe Jeremy didn’t know that Rhino.Commons is open source.

IMNSHO Files are code smell. Should it really be the responsibility of class XYZ to open and use that file? Why not pass a stream and move the responsibility somewhere else.

Now in the case of Binsor there is good reason to accept a filename. Binsor allows you to include other files in the same directory as the Binsor file. This feature doesn’t work with my supplied solution, nor does it work with Jeremy’s, unless you manually extract each file first. IMO this defeats the purpose of embedding the Binsor config as a resource.

I couldn’t let it go, so I added a method override to BooReader.Read which accepts a stream as a parameter. Due to the nature of Binsor, you still need to name your boo module, so any string name can be passed as well.

public static void Read(IWindsorContainer container, Stream stream, string name)

The use case is very simple:

_container = new RhinoContainer();

Stream stream = Assembly.GetExecutingAssembly()
.GetManifestResourceStream(“Rhino.Commons.Test.Binsor.EmbeddedWindsor.boo”);

BooReader.Read(_container, stream, “EmbdeddedWindsor”);

Because Rhino.Commons is open source I was able to use TortoiseSVN to create a patch and mail it to Ayende. If you can’t wait, the patch will be available here for a while.

Using boo as an embedded scripting application

fallenrogue was twittering about IronRuby and Ruby.NET and I just don’t get the .NET infatuation with Ruby. IMO boo is better for most use cases, especially green field development.

Today there was an interesting conversation in #boo on using boo as an embedded scripting application. I don’t think I can summarize how to do this much better than the IRC conversation.

13:47   Avictus| Hello everyone.  Boo newb here.
13:47   Avictus| I have a question that I was hoping someone in here could
                 answer, or at least point me in the right direction.
13:48     Griep| What’s up?
13:48   Avictus| I’m planning on using Boo as an embedded scripting language in
                 a C# app that I’m developing.  I’m trying to figure out how to
                 expose methods and properties of my C# app to the Boo scripts
                 that the app will run.
13:50   Avictus| There are examples on how to compile Boo scripts from a C#
                 app, and how to call methods that are in the Boo script from
                 the C# app.  But I need to be able to call C# methods from the
                 Boo script.
13:50   Avictus| Is it possible to do this with Boo?
13:50     Griep| It is.  I am personally unfamiliar with exactly what would be
                 needed, but let me search our archives and see what I can
                 dredge up.
13:51   Avictus| Thank you very much.  I was looking over the website, but I
                 couldn’t find anything.  Your help is greatly appreciated.
13:55     Griep| So, what you’ll likely want to do is set up Boo as an
                 interpreter.  You can do this in C# by creating a new
                 interpreter: “InteractiveInterpreter interpreter = new
                 Boo.Lang.Interpreter.InteractiveInterpreter()”
13:55     Griep| Then, you can use “interpreter.Eval(scriptString);”
13:56     Griep| You can use interpreter.load(
13:56     Griep| to load in external references, such as to a library.
13:58     Griep| The main library you’ll probably want to look into is
                 Boo.Lang.Interpreter.
13:59   Avictus| So, if I had a method named myObject.GetSomeData() in my C#
                 app, I could call that from within a Boo script using
                 Boo.Lang.Interpreter?
14:02     Griep| Yes.  You can add references to the interpreter just as you
                 would for a compiler.  So, your could do something like:
14:02     Griep| interpreter.References.Add(System.Reflection.Assembly.GetExecutingAssembly());
14:03     Griep| If myObject is an instance, you would likely need to set that
                 variable for the interpreter to be able to access it as such:
14:04     Griep|
14:04     Griep| interpreter.Declare(“myObject”, typeof(MyObject));
14:04     Griep| interpreter.SetValue(“myObject”, myObject);
14:05   Avictus| Thank you, that looks like exactly what I need.  I appreciate
                 the help.
14:06     Griep| You’re welcome!  Happy hunting.