About the .Less project


I had a short twitter conversation with Aaron Jensen on the decisions we made developing .Less. As I’ve blogged about before, for me personally it was more of a learning project than something with a set goal, at first. That aside, I had one thing in mind: being able to use less during development, without having to worry about it, add a handler and go!

Less.Net, v0.1

My first solution was to simply install ruby and wrap the whole system call in a HttpHandler. Very clunky, but it worked! I blogged about this a while ago: Using LessCSS in an ASP.NET site.

I got it working, tried to implement it in my web project, and ran into another problem: It’s SLOW. Could be solved with caching, but in development I generally dislike that. It presents another point of failure which can take quite some time to figure out.
Another point was the fact that ruby should be installed. If you’re familiar with the .NET ecosystem you’ll know that a lot of people just want to deploy a single DLL and be done with it. Installing ruby, getting it to install a gem and then using that in your build process is quite a bit of work you want to avoid, if at all possible. That’s two problems I wanted to solve.

Being influenced a bit by the things I saw coming by on twitter (Linq to NHibernate to be exact) I looked into ANTLR for the parsing, which was simply an interesting technique to learn. I got a working prototype for a simple less file, published it, and got in touch with Daniel and Chris, with which we formed the current .Less project. Before joining up, Daniel gave IronRuby a shot for implementing the ruby gem in .NET, but it turned out to be too painful to deploy and too slow.

Perhaps with the next version of the CLR IronRuby will be a good option for Less, but honestly, I don’t expect that to be mainstream for at least another year.

Less.Net and nLess become .Less

After a few talks via skype, we decided to work on Chris’ codebase, called nLess at that moment. The reason why is that the grammar style he used is very similar to the ruby treetop grammar, which makes porting new language features quite painless. Also, I ran into a few problems with my grammar which would require quite a bit of rewriting of the grammar.

We’re not aiming for creating our own dialect, we want to adhere their standard as much as possible. The general idea is to introduce the less syntax in the .NET world, in such a way that it’s recognizable for the average .NET developer. That’s why having a grammar which is easily ported from one to the other is of great value to the project.

The future

While we do want to adhere to the ‘official’ syntax, we’re not bound to the functionality the ruby gem offers. We’ve got a few cool ideas we can do, but not before we’ve got a more edge cases of the current implementation covered. We’re also looking into creating a Visual Studio plugin, to, again, reduce the friction of using less in your ASP.NET solutions.

Another thing that’s on our agendas is to create more viable specs to test. We’re currently using the somewhat outdated ruby specs, which are generally very big umbrella specs. They also don’t exactly do what you’d expect. Hopefully we can create a common set of specs both the ruby gem as our .NET DLL, as the PHP version that’s around there can use. That way it won’t matter which environment you use, your less files will always work.

Well, that’s the story about .Less and how it came to be. If you’re interested in the project, I invite you to go to http://www.dotlesscss.com/ and try it out. We’re usually quite fast on the response to our google group, so if you want to ask anything, feel free to do so.

author: Erik van Brakel | posted @ Sunday, November 22, 2009 10:30 PM | Comments

The importance of specifying your locales


Lately I’ve run into several bugs which were caused by developers incorrectly assuming that the default locale settings were good enough for parsing a value. I’ll show you what I mean.

Case 1

Consider the following snippet:

.something {
    width: 21.4em;
}

This is a simple CSS rule, making all elements with class ‘something’ have a width of 21.4em. In .Less, we parsed this without an explicit locale. The output would only show 21em, truncating the value from the implied decimal separator onwards. Once we set the locale to Invariant (who needs specific locales in CSS?), the problem was fixed. All in all a fix of only an extra parameter on the parse method.

Similarly, I am setting up a private TeamCity server, just for trying out how it works. I used a git plugin to enable downloading the source from github, which threw an exception when parsing the date. Consider the following two snippets:

  private static final String GIT_DATE_FORMAT = "EEE MMM dd HH:mm:ss yyyy Z";
  private static final String VERSION_DATE_FORMAT = "MM/dd/yyyy HH:mm:ss";
  public static final SimpleDateFormat GIT_DATE = new SimpleDateFormat(Constants.GIT_DATE_FORMAT);
  public static final SimpleDateFormat VERSION_DATE = new SimpleDateFormat(Constants.VERSION_DATE_FORMAT);

  private static final String GIT_DATE_FORMAT = "EEE MMM dd HH:mm:ss yyyy Z";
  private static final String VERSION_DATE_FORMAT = "MM/dd/yyyy HH:mm:ss";
  public static final SimpleDateFormat GIT_DATE = new SimpleDateFormat(Constants.GIT_DATE_FORMAT, , new java.util.Locale("en"));
  public static final SimpleDateFormat VERSION_DATE = new SimpleDateFormat(Constants.VERSION_DATE_FORMAT, new java.util.Locale("en"));

The first one is the bugged one, the second one is the fixed one. All I did was make sure the date is being parsed expecting english localization. This simple fix enables the plugin (it’s from the git-teamcity plugin on github) to work on any system, opposed to the ones who happen to have their locale set to any english variant.

This leads me to one conclusion: developing on a non-english locale is a good thing, you’ll find a lot more bugs that way! Joking aside, these examples led me to be a lot more careful with assumptions, especially on region specific settings.

author: Erik van Brakel | posted @ Saturday, November 21, 2009 1:24 AM | Comments