0 Comments

I wanted to try something new this time, so I recorded my blog post as a screencast. Since I mostly write about code I thought it might be a good way to illustrate it in a video instead of in writing. It does add a new level of simplicity and understanding to the message. Please check it out and tell me if you like the video more than a regular blog post.

[vimeo:8338567]

I hope the video illustrates just how easy it is to embed images in stylesheets and also how to use the online tool for image to base64 conversion.

0 Comments

My grand plan of 2009 was a new year’s resolution that would take me around the world. The plan was simple:

In average, I need to visit a new country that I may have visited before, every month of 2009.

Last time I wrote about my plan on this blog, I just got home from Greece and Albania in July and the plan looked to succeed. According to my original plan, I had to go to Egypt and Monaco this fall, but unfortunately that never worked out. So instead, here’s how the grand plan of 2009 ended.

August

This was a good month that began with a trip to the Fringe Festival in Edinburgh, Scotland with one of my Scottish friends. It’s the world’s biggest arts festival and a lot of fun with hundreds of venues. I saw some excellent comedy acts.

Mads Kristensen in Edinburgh

A week later I did a major travel mistake – underestimating jet lag. I flew to Boston on a Friday morning and back home Sunday afternoon. So a small trip with an 8 our flight both ways. I landed in Copenhagen airport Monday morning at 9am and went directly from the airport to the office. I won’t do that ever again. Well, I probably will…

Mads Kristensen in Boston

September

The plan here was to go to Monaco and win big on the casinos, but alas, my travel buddy backed out.

October

It proved that the best trips in 2009 where the last two ones. In the middle of October I took a 12 day guided tour through the major cities and sites of Iran - Tehran, Shiraz, Isfahan, Yazd and Qom. Iran is filled with sights and relics from the Old Persian Empire and it totally changed my views on Iran. I also got the chance to meet Keyvan Nayyari in Tehran.

Mads Kristensen and Keyvan Nayyari

On the way home, we had time in transit in Istanbul airport in Turkey. So we ventured out to see the Blue Mosque and the Bosphorus Strait. It was also in Istanbul we had our first beer in 12 days, because alcohol is banned in Iran.

 


November

My parents were invited to a wedding in India and as soon as I heard, I wanted to tackle along. I’ve seen pictures of Indian weddings before and there was no way I would miss that opportunity. The groom was so kind to invite me as well and another big adventure unfolded. Only 2 weeks separated the trip to Iran and India. We started at the Fort Aguada resort in Goa for a couple of days before the wedding, then 4 days of constant partying with the bride and groom and then a few days in Mumbai before heading home.

Mads Kristensen in Mumbai

Conclusion

And with this the grand plan of 2009 succeeded and my goal was reached. Here’s a list of the destinations I visited in 2009 in chronological order

  1. Düsseldorf, Germany
  2. London, England
  3. Chişinău, Moldova
  4. Seattle, Washington
  5. Malmö, Sweden (this one doesn’t count since it’s a ½ hour drive from where I live)
  6. Malaga, Spain
  7. Gibraltar
  8. Stirling, Scotland
  9. Amsterdam, Holland
  10. Corfu, Greece
  11. Sarande, Albania
  12. Edinburgh, Scotland
  13. Boston, Massachusetts
  14. Tehran, Iran
  15. Mumbai, India

According to TripIt, that amounts to 73.000 kilometers which is almost twice around the world.

For 2010 my plan is more relaxed. So far I have planned a trip to South Africa, Las Vegas and Seattle – a mix of business and pleasure. Also, for summer my dream is to take the Transsiberian Railway through Russia to Mongolia and China, but no plans yet.

0 Comments

A few days ago, Google released their Closure Compiler project for optimizing JavaScript. Here’s what they write about the Closure Compiler:

The Closure Compiler is a tool for making JavaScript download and run faster. It is a true compiler for JavaScript. Instead of compiling from a source language to machine code, it compiles from JavaScript to better JavaScript. It parses your JavaScript, analyzes it, removes dead code and rewrites and minimizes what's left.

The interesting part of the Closure Compiler is that it not only removes whitespace, it also rewrites your JavaScript code to make it smaller and optimizes the code for better performance. My tests show that it can reduce JavaScript files by about 60% - and that’s before HTTP compression! Considering how much JavaScript a modern website uses, this is no less than amazing and highly useful.

The Closure Compiler comes in two flavors – a Java based command line tool and a RESTful API. I’ve been playing around with the API and it works great and very fast.

The code

The C# class I’ve written takes a JavaScript file and passes it through the API and then returns the compressed JavaScript as a string. The class contains one public and one private method and is only 47 lines of code including 16 lines of comments.

public string Compress(string file)

{

  string source = File.ReadAllText(file);

  XmlDocument xml = CallApi(source);

  return xml.SelectSingleNode("//compiledCode").InnerText;

}

 

private static XmlDocument CallApi(string source)

{

  using (WebClient client = new WebClient())

  {

    client.Headers.Add("content-type", "application/x-www-form-urlencoded");

    string data = string.Format(PostData, HttpUtility.UrlEncode(source));

    string result = client.UploadString(ApiEndpoint, data);

 

    XmlDocument doc = new XmlDocument();

    doc.LoadXml(result);

    return doc;

  }

}

How to use it

You can use the class to do various cool things. You can write a MSBuild or NAnt script that automatically compresses your JavaScript files as part of a continuous integration process or, as I prefer, write a HTTP handler to do the same but at runtime. Remember to output cache the compressed result. Here's an example of using the class from ASP.NET:

GoogleClosure gc = new GoogleClosure();

string script = gc.Compress(Server.MapPath("~/script.js"));

Remember that the class doesn't do any exception handling, so you might want to stick that in yourself.

Download

GoogleClosure.zip (905,00 bytes)

0 Comments

Recently I had to use iframes on a website conforming to XHTML 1.0 Strict. As you might know, the XHTML 1.0 Strict doctype doesn’t allow the use of iframes. The XHTML 1.0 Transitional doctype on the other hand, does allow you to use iframes, but I don’t like to use that doctype. The reason is, as the name implies, that it’s a doctype meant for make the transition from HTML into XHTML – a sort of a temporary solution.

When building new websites I like to use a strict doctype because it doesn’t allow for many of the style and behavioral tags that is much better placed in stylesheets and JavaScript.

What’s needed is a doctype that conforms to XHTML 1.0 Strict which also allows for iframes.

A solution

What I came up with was very simple, but may be considered a hack by some. Basically, I took the doctype declaration (DTD) of XHTML 1.0 Strict and added support for iframes. I found how iframes was supported in the transitional DTD and copied it to the Strict DTD. It allows for some attributes like width and height that the Strict DTD doesn’t, so I removed those and then added support for the allowtransparency attribute.

So to make iframes work on your own invalid XHTML 1.0 Strict page, just replace the doctype at the top of your pages with this new one:

<!DOCTYPE html SYSTEM "http://madskristensen.net/custom/xhtml1-iframe.dtd">

I suggest you download and host the DTD on your own server instead of using mine in case I forget to pay my hosting fee.

Check out the demo of XHTML 1.0 Strict with Iframe

A hack?

Some might say it’s a hack because by using this DTD the page is no longer XHTML 1.0 Strict. That is correct. It is now something new and different, but completely identical to XHTML 1.0 Strict with support for iframes. So it’s XHTML 1.0 Strict with Iframe.

XHTML have build in support for custom DTDs and thus this is completely supported and valid XHTML. If you don’t like using other doctypes than the few main ones created by the W3C then I have to ask why? What does it give you, your users or the quality of the page that this new one doesn’t?

In my book, it comes down to using a doctype that is based on known standards (XHTML 1.0 Strict in this case) so it still make sense to other devs when they read the markup. It’s also important that the DTD is strict (yep, this DTD is still strict), but most of all it’s important that the markup conforms correctly to the DTD so the entire page is valid. Remember, when using custom DTDs your page is still valid XHTML.

Note

I tried using XHTML 1.1 modules to build the DTD, but it never worked out for me. I got to the point where the iframe tag was valid, but not allowed in any other tags including body. I couldn’t seem to find a way to get full support for it. If you know how, please let me know.

0 Comments

In the past few days, I’ve worked on finding a way to do static code analysis on JavaScript files.The resaon is that I want to apply some sort of binary and source code checking like FxCop and StyleCop provides for C#.

There exist some tools for linting JavaScript like JavaScript Lint, but linting only checks syntax and not implementation. To do that I found the Jscript compiler build into the .NET Framework to be just what I wanted. It compiles JavaScript and reports if it finds any errors.

To test it out, I wrote a simple C# class that takes an array of JavaScript files to compile. I then called the class from a unit test, so I could make the test fail if the compiler finds any errors with the script files. The class contains a single public method called Compile and here is a simplified example on how to use it from any unit testing framework. You can download the class at the bottom of this post.

[Test]

public void JavascriptTest()

{

  string[] javascriptFiles = Directory.GetFiles(@"D:\Website", "*.js",
SearchOption.AllDirectories);

 

  using (JavaScriptCompiler compiler = new JavaScriptCompiler())

  {

    compiler.Compile(javascriptFiles);

    Assert.IsFalse(compiler.HasErrors, compiler.ErrorMessage);

  }

}

What’s nice is that by doing compile time checking of JavaScripts, I get that extra little security that’s so hard to get when developing JavaScript heavy websites. The Microsoft JScript compiler isn’t perfect, so I still recommend using a linting tool as well. The two approaches cover different scenarios. I hope to have a very simple implementation on using a linting tool soon.

Download

Remember to add a reference to Microsoft.JScript in your Visual Studio project before using this class.

JavaScriptCompiler.cs (2,48 kb)