NU – gem like packaging for .NET

by DotNetNerd 26. July 2010 20:37

I just had a look at NU which is made to be for .NET what gems are for Ruby. Why should you care? Well if you are like me downloading new versions of miscellaneous open source projects and updating them along the way is not your favorite thing. It’s just tedious and seems to be a hassle for something so basic. This is where NU gives you a hand.

If you have IronRuby running simply open an command line and type:

igem install nu

Then when the installation is done go to the root of your projects folder (eg. D:) and type:

nu install <some_gem>

I started out running “nu install nunit” and “nu install nhibernate” and in less than a minute I had nunit, unhibernate, log4net, castle.core and castle.dynamicproxy2 unpacked to D:\lib like this.


IronRuby 1.1 with LINQ support

by DotNetNerd 20. July 2010 08:37

Finally LINQ is supported in IronRuby now from v. 1.1 and I think it has been solved quite elegantly without any real syntactical gooeyness. Trying it out has been made very straight forward by looking at the 101 LINQ samples rewrite for IronRuby.

From day one LINQ has seemed a natural fit with IronRuby already having a similar approach with functions such as .each {|item| ...} which is accessible on anything that can be enumerated - very much like a big part of LINQ is extentions methods to the IEnumerable interface. No doubt there has been some challanges around how to map generics, extention methods etc between the languages, but syntactically it seems a natural fit.

products.where(lambda { |p| p.units_in_stock > 0 and p.unit_price > 3.00 }).each { |x| puts x.product_name }

Combining functional methods from LINQ with the existing Ruby methods just makes the "Integrated Query" syntax even better. So now we get a .each method with LINQ even though Microsoft originally didn't want to include it :)


Tags: ,

IronRuby and hashes in metaprogramming

by DotNetNerd 29. June 2010 19:39

This will probably be one of the shortest blogposts I'll ever write, and probably the one with the least amount of code - besides an occational rant. The reason is that like pictures sometimes say more than a 1000 words, so does elegant code.

module MyModule
class MyClass
def write_stuff text
puts text

m =
actions = {:write_stuff => "Hello action packed world!"}
actions.each {|key, value| m.method(key).call(value) }

It might just be me who is weird - but I think this way of doing eg. a strategy pattern is pretty cool.


Hello rake-world

by DotNetNerd 27. May 2010 16:31

Rake is a quite popular build framework, that has its strengths in the fact that it is code (no more xml), and it is very simple to get started with. Actually setting it up is a 3 step process.

  1. Make sure the path environment variable is set to point at your ironruby/bin folder.
  2. Run “igem install rake” from the commandline
  3. Write a Rakefile.rb like the following and place it at the root of your site

require 'rake'

task :default => [:say_hi]

desc "Does quite a bit of greeting"
task :say_hi_to_me do
    puts "Hello me. Now that was easy."

task :say_hi_to_world do
    puts "Hi world!"

task :say_hi => [:say_hi_to_me,:say_hi_to_world] do
    puts "I’m, all hellowed out"

This really all it takes, so now you are ready to run your tasks from the commandline by writing: “rake” or “rake say_hi_to_me”.

Now for this to get really interesting you will need albacore which makes it easy to do all kinds of basic tasks.

This is installed with the command “igem install albacore”, and makes it possible to do builds and run unittests like this:

require 'rake'
require 'albacore'

task :default => [:full]

task :full => [:clean,:build_release,:run_tests]

task :clean do
    FileUtils.rm_rf 'build_output'

msbuild :build_release do |msbuild| :configuration => :AutomatedRelease
  msbuild.targets :Build
  msbuild.solution = "TestApp/TestApp.sln"

nunit :run_tests do |nunit|
    nunit.path_to_command = "tools/nunit/nunit-console.exe"
    nunit.assemblies "build_output/TestAppTests.dll"


Tags: ,

Silverlight and IronRuby – a match made in heaven

by DotNetNerd 25. April 2010 10:31

A couple of months ago I was starting to read about IronRuby, and while thinking about what my first little pet project should be I saw a tweet from a guy who was enjoying the combination with Silverlight. I gave the idea some thought and liked the idea of using a dynamic language to make a rich internet application. So after reading IronRuby UnleashedI started out doing a version 2 of my site – which is just a little toy selfpromotion site.

Getting started was pretty straight forward because with IronRuby there is a small webserver called Chiron, which can make a project template. All you have to do is open a cmd, and go to the library where IronRuby is installed and type script\sl.bat ruby <projectpath>

Armed with my starter template I began playing around and got my layout in place. I also tried using some 3rd party components by referencing some dll’s and all that basic stuff. Most of it went smoothly, but I did run into an assembly ( that threw an exception when used with Silverlight/IronRuby. Using it from a console project in IronRuby worked fine, so I quickly decided to just go directly against the flickr api using the .NET WebClient class. Running the site from chiron was as easy as calling script\chr.bat /d:<projectpath> /b:index.html

When I had the first couple of pages ready and had written a picturegallery showing the last 5 pictures I have uploaded to flickr I wanted to get the site deployed, so I would no longer depend on chiron. From my book and by looking at blogs it seemed to be smooth sailing, because chiron has a function that makes a .xap file which is all you need. To my surprise when I referenced the .xap file from the html file in my my project it looked like it loaded, but then just stopped at 100% without showing my actual site. I felt pretty stuck, because I had no exception or anything to go on, and my site ran fine when I was using chiron.

I then wrote an email to “Iron” Shay Friendman, who wrote the book that I was using as my inspiration. I thought it was worth a shot, and that I could not be the only one with that problem. Later that day he wrote back, and (as the nice guy he is) told me that he did not know the solution off the top of his head but he would look at it as soon as he had a couple of available hours. A few days later he had found a solution, and it turnes out a few things need to be done differently when running it outside of chiron. So this is basically what I want to share with this post :)

What you need to do is:

1) If your .rb files contain references like “app.xaml” it should be changed to app\app.xaml – in other words the references should be from the root of the solution and not from the app folder where the file is located.

2) Make the .xap file using the command script\chr /d:<projectpath> /z:<projectpath>\app.xap

3) In the index.html file where the .xap file is referenced find the like starting with <param name="initParams".
Change its value attribute to "start=app\app.rb,reportErrors=errorLocation".

And easy as 1-2-3, your site should work when running the index.html file.

Shortly put it really has been a fun project, and I really like the IronRuby and Silverlight combination, so it is definately not my last project where I will combine the two.


IronRuby - godt begyndt

by DotNetNerd 13. December 2008 19:49

Nu synes jeg igen det er ved at være på tide at rode lidt med et nyt sprog, så jeg har kastet mig over (Iron)Ruby, som opfylder samme krav som F# gjorde da jeg gik i krig med det. Det er nemlig et sprog der giver nye udfordringer idet jeg ikke får har arbejdet så meget med dynamiske sprog, og samtidig er det anvendeligt på .NET platformen.

Udover at IronRuby er anvendeligt på .NET platform er det samtidig Ruby varianter der er skrevet til andre platforme, så der er helt sikkert gode perspektiver i at lære sproget. En mulighed for fremtiden er også at se på Ruby on Rails, som de fleste nok har hørt omtalt som et virkelig interessant framework til udvikling af RAD MVC webapplikationer.

Hvis man skal i gang er der tre sider jeg vil anbefale som er: - den officielle side der fungerer som en wiki. - en god side om Ruby med adgang til en RIPL der kører i browseren så man kan lege lidt. - en rigtig god intro side der gør at min blogserie om emnet nok bliver en del kortere end den om F#, da man allerede kan finde meget her J

Derudover skal man for at komme i gang Herfra kan man hente og installere Ruby fra og nyeste version af IronRuby kan hentes fra deres svn repository svn:// For at komme i gang kan man blot compile solutionen og køre console applikationen, så har man mulighed for at lege med lidt kode.


Dynamic Language Runtime

by DotNetNerd 3. November 2007 23:36

DLR - Dynamic Language Runtime.

Jeg fik for et stykke tid siden øje på en blogpost der omhandlede endnu et tiltag Microsoft arbejder på til .NET frameworket - nemlig en Dynamic Language Runtime. Umiddelbart tænkte jeg "fint nok men hvad skal jeg bruge det til". Det spørgsmål fik jeg så besvaret nu her da jeg faldt over en video fra MIX07 omkring dette emne. Jeg vender tilbage til videoen senere, da den indeholdt et temmeligt fedt eksempel som jeg vil gengive.

Kort fortalt er styrken ved dynamiske sprog at de "bare er tekst" ligesom en aspx- eller xaml-fil. Derved giver de nogle muligheder for især webudviklere ved egentlig at vende en smule tilbage til webudviklingens barndom. Idet sprogene er fortolkede, og altså "bare tekst" der ikke skal kompileres for at kunne afvikles, kan man arbejde uden konstant at skulle igennem en code-compile-review cyklus.

Dette kan især være rart hvis man skal udgive rettelser til en webapplikation, men også under selve udviklingen da man kan sidde med browseren fremme på den ene skærm imens man retter i koden på den anden og ser ændringerne slå igennem med det samme.

Hvilke sprog kan man så kode i?

Til at at starte med arbejder Microsoft på at udvikle implementationer baseret på sprogene:

  • IronRuby
  • IronPython
  • JavaScript
  • Dynamic VB

Ligesom med den almindelige CLR er det meningen at det skal være muligt at udvide med flere sprog hen ad vejen. De 4 sprog der er med til at starte med er valgt ud fra at de for det første er meget udbredte, og så for JavaScripts vedkomne fordi det giver mulighed for at man meget let kan genanvende sine eksisterende Ajax scripts i f.eks en Silverlight applikation. VB er som altid representeret af hensyn til Microsofts eget Office team. IronRuby og IronPython er enormt populære sprog der er svære at komme uden om - og de har en force i at de begge har en lækker syntaks der er meget lidt verbos.

Mix and Match

Der før omtalte eksempel fra MIX07 synes jeg gav en virkelig god idé om hvilke muligheder der vil være for at lege "Mix and Match" i fremtiden, da det illustrerer hvor enkelt man kan blande forskellige sprog - hvad end det er CLR eller DLR sprog, og hvad enten det er ASP, Silverlight eller helt almindelig HTML.

Eksemplet er en Silverlight applikation skrevet i Ruby og benytter en knap skrevet i C#, som kører et animationsscript skrevet i DLR JavaScript der viser tekstelementer der floater rundt. Teksterne er hentet fra en service skrevet i VB, udfra et ord der er indtastet i en HTML textbox som tilgås via Silverlights HTML DOM.

require 'Silverlight.Samples.Controls.Version='

Controls = Silverlignt.Samples.Controls
Document = System.Windows.Browser.HtmlPage.Document

JS = require '3dText.js'
VB = require 'technorati.vbx'

def initialize(s, e)
    button =
    button.Text = "Click me"


    root.children.add button do |s, e|
        term = Document.txtSearchTerm.Value
        items = VB.GetTitles(term)
        items.each { |item| JS.initializeName(item)}

Som man kan se er Ruby meget letvægts, og hvis man tænker over antallet af komponenter skrevet i forskellige sprog fra forskellige miljøer der arbejder sammen her kan man ikke undgå at blive lidt imponeret over hvor smertefrit CLR og DLR sprog taler sammen.

Det er værd at bide mærke i de første 5 linier fra eksemplet hvor man ser hvor let det er at importerer komponenter fra serveren, samt at referere til dynamisk kode skrevet i andre sprog. Det er ganske enkelt bare at bruge en simpel require statement.

Derefter viser eksemplet en initialize metode, som det er defineret i den tilhørende XAML fil skal kaldes ved init. I initialize instantieres så en knap, og en tilsvarende initialize metode på JavaScript komponenten kaldes. Knappen tilføjes så til et canvas der er navngivet root. Knappen for derefter tildelt en anonym eventhandler, der clearer den liste af tekster og tilføjer nye ord hentet fra VB servicen. Til sidst er det blot at starte animationen og så er koden kørende.

Hvordan platformen blev til.

En sjov historie fra videoen er at en af dem der har været med til at lave det oprindeligt startede med at ville skrive en artikel for at lave grin med Microsoft, da han havde hørt at .NET var elendigt at bygge dynamiske sprog oven på.
Han skrev så en implementation af Python oven på CLR'en - og til hans store overraskelse sparkede den røv på den originale Python. Med andre ord viste benchmarks at hans implementation performede dobbelt så godt! Derefter endte han så med at arbejde for Microsoft og har været med til at bygge denne platform til at hoste dynamiske sprog.

Who am I?

My name is Christian Holm Diget, and I work as an independent consultant, in Denmark, where I write code, give advice on architecture and help with training. On the side I get to do a bit of speaking and help with miscellaneous community events.

Some of my primary focus areas are code quality, programming languages and using new technologies to provide value.

Microsoft Certified Professional Developer

Microsoft Most Valuable Professional

Month List