During the hollidays I was visiting some friends for a round of junkfood and movies. As one of my friends was showing off his new tv I noticed how his menues looked a lot like what I get when accessing my PS3 over the network. I know however that he does not own a PS3. so I got curious. It turnes out that he had installed a PS3 media server on his PC.

I had never heard about the PS3 media server before, so I looked into what it has to offer. It turnes out that it is a free application that makes it possible to allow access to any folder on your network through the PS3. This was a limitation that had annoyed me immensely when using the PS3 to access media on my LAN (my Synology NAS box actually was the one giving me a hard time), so I quickly downloaded and installed the media server on my own box. It worked without any questions asked, and solved the one thing that I was not happy with when using my PS3 to play movies and music. So I can only give it my clear recommendation.

Well this is one of those posts that start out being as a reminder for myself, since I had to do a script that I don't want to waste my time having to write again later on. Basically I ran into a customer who wanted week numbers added to a calendar. This seemed basic enough, but apparently getting a weeknumber is not a native thing in javascript.

First I picked up a script to add a getWeek method to the Date prototype, and I was a happy man. Sadly not customer not quite as much. It turns out that we do not follow the ISO 8601 standard for defining weeknumbers here in Denmark. According to my projectmanager the rule of thumb is that the first thursday always falls in week 1. This made me add a little extention so I now have a getIsoWeek and a getWeek method on my Date objects and this is how it was done.

/**
* Get the ISO 8601 week date week number
*/
Date.prototype.getIsoWeek = function() {
    // Create a copy of this date object 
    var target = new Date(this.valueOf());

    // ISO week date weeks start on monday 
    // so correct the day number 
    var dayNr = (this.getDay() + 6) % 7;

    // Set the target to the thursday of this week so the 
    // target date is in the right year 
    target.setDate(target.getDate() - dayNr + 3);

    // ISO 8601 states that week 1 is the week 
    // with january 4th in it 
    var jan4 = new Date(target.getFullYear(), 0, 4);

    // Number of days between target date and january 4th 
    var dayDiff = (target - jan4) / 86400000;

    // Calculate week number: Week 1 (january 4th) plus the  
    // number of weeks between target date and january 4th  
    var weekNr = 1 + Math.ceil(dayDiff / 7);

    return weekNr;
}

/**
* Get danish weeknumber.
* According to danish weeknumbers the first thursday always falls in week 1
*/
Date.prototype.getWeek = function() {
    var weekNr = this.getIsoWeek();

    var firstThursday = new Date(this.getFullYear(), 0, 1)
    while (firstThursday.getDay() != 4) firstThursday.setDate(firstThursday.getDate() + 1);

    if (firstThursday.getIsoWeek() == 2) weekNr--;

    if (weekNr == 0) weekNr = 1;

    return weekNr;
}

Not too long ago Microsoft released the Ajax Minifier, which can be downloaded from codeplex. It's basically just another javascript minifier, but the good thing about is it that the download includes both a commandline tool, an MS Build task and an assembly, so you can do your minification any way you like. Either way you wait to use it is very simple and it is explainted in the chm file which is included in the installation.

Today I finally got around to using it, for a HttpHandler that I wrote to serve some javascripts that I wanted to aggregate into one file and have them minified. It really took no time at all, and reduced my site from needing 13 files to 1 that was reduced in size by a little over 30%. All it required was about 10 lines of code in the HttpHandler (including handling caching). So basically what I am saying is that there is no excuse not to get this performance boost, since it is really low hanging fruit ripe for the plucking.

A little while ago I read about a nice little library called .less, which is a port from ruby less, that lets you write css, but with the added features of enabeling variables, operations, mixins and nesting. Today I decided to try it out, and I definately want to give it my recommendation.

Using variables makes stylesheets a lot more maintainable because it allows you to avoid having colorcodes scattered all around the stylesheet simply by writing:

@listbackground_color: #E3EFFF;

Nesting just makes it more maintainable and gives the stylesheet a better sence of structure like this:

table.MapsList
{
  background-color: @listbackground_color;       
  tr th
  {
    width: 300px;
    background-color: @listbackgroundheader_color;
  }
}

Finally mixins makes it possible to keep the stylesheets more DRY (don't repeat yourself) like so:

.rightBackground { background-repeat:no-repeat;background-position:right; }
th.headerSortUp { .rightBackground; background-image: url(desc.gif); }
th.headerSortDown { .rightBackground; background-image: url(asc.gif); }

An added bonus is that you can toggle caching and minimizing from your web.config.

Last time I looked at how IronPython is integrated with .NET which makes it possible to use all of the good stuff that we know and love from .NET. The obvious next thing to look at is doing the inverse and see how it is possible to run IronPython code from within a .NET app written in this case in C#.

The main scenario for this is to allow advanced users to write their own scripts that can extend the behavior of the application, or allow them to express complex logic. An example that comes to mind for me is a system I am working on at work, where we are doing payroll processing for any kind of company. Here a viable option could be to allow the rules for the processing to be expressed with scripts – since the tax laws have a tendency to change frequently it would be a valuable extensibility point.

The most basic way to run IronPython code from C# is to do like this:

var engine = new PythonEngine();
engine.ExecuteToConsole(@"print ""Sweet dude!""");

As you can see it is pretty simple to get code to run in the first place. It is not of much use however if it is not possible to pass in variables to the context in which the IronPython code is run. This is accomplished by passing in a module and a dictionary of variables like so:

engine.ExecuteToConsole(@"print ""Cool: "" + str(2+val)",
    engine.DefaultModule, new Dictionary<string, object>() { { "val", 6 } });

Again, this is pretty straight forward. Besides passing variables it would also be nice to be able to define global variables that can be used and accessed again after the script is run. This example shows how to do just that:

engine.DefaultModule.Globals["val"] = 6;
engine.ExecuteToConsole(@"val = ""Cool: "" + str(2+val+2)",    engine.DefaultModule, null);
string modifiedValue = (string)engine.DefaultModule.Globals["val"];

One thing to note here is that i set the global variable to a value of 6 which is an integer but I end up getting a string back. This is because IronPython is a dynamic language which allows the type to be changed which is done in the script because it is added with a string.

Now my guess is you might be thinking that there must be other ways to run scripts than to execute them to a console. Well of course there is. The PythonEngine has several overloads and alternate methods that can be used to run scripts. I wont go over them all but I’ll finish up with a sample that I think will probably be one of the ways I will end up using most often. In this case I simply evaluate a script that returns a value. This way a script could be used to define some logic and simply return the kind of result I need:

string myResult = engine.EvaluateAs<string>(@"str(2+2)");

Mainly there are two groups of methods to run IronPython code – you can either execute or evaluate the code, with the difference being that evaluating it returnes a value. There are also methods to execute code from a file, which might be convenient.