general

.Less is featured on the new ASP.NET site

Erik van Brakel — Thu, 11 Mar 2010 12:31:24 GMT

I’ve recently had a lot less (pun not intended) time to spend on .less, but I do keep track. Scott Hanselman mentioned the new ASP.NET site went live, and it looks good!

What REALLY caught my eye is the section on open source projects it has, under the ‘community’ tab. It has a lot of nice, established projects mentioned, like Nhibernate, Subtext, Spark and a lot of others. What really amazed me is that .less is mentioned! If you scroll down to the Misc section, there it is! Seems like I really have to schedule my work better so I can invest more time in .less again. That’s a good thing, right?

.Less twitter love

Erik van Brakel — Mon, 23 Nov 2009 14:33:15 GMT

I just checked our analytics after I noticed a bit of retweeting going on after Jon Galloway picked up .Less. Can you spot at which points in our graph twitter was flooded with .Less tweets?

I thought so ;-)

I’d like to use this oppportunity to thank everyone for bringing us extra publicity! Thanks!

About the .Less project

Erik van Brakel — Sun, 22 Nov 2009 21:30:37 GMT

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.

The importance of specifying your locales

Erik van Brakel — Sat, 21 Nov 2009 00:24:00 GMT

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.

Introducing the Smooth Friction testdata generator (v0.1)

Erik van Brakel — Wed, 11 Nov 2009 23:27:19 GMT

Between work, .Less and other things, I’ve been working a bit on a tool I would personally use. How many times did you just need a big set of test data for an application? How many times did you resort to simply dumping randomly generated data into your tables? Well, I’ve did that a few times, and one of the biggest annoyances is that the generated data is usually not really ‘real’, if you know what I mean.

Say I have an application which has keeps customer records. I’d have a name, address, maybe some dates, something numeric and so on. With my new project, I aim to make getting some sample data easy(tm). It’s very, VERY prototype’ish right now, but I want to practice a bit of ‘release early, release often’ this time. So here it is! Take a look at the Smooth Friction test-data generator, and tell me what you think. Is it something you’d use? Should I continue working on this?

Disclaimer:
I am not a designer, so it looks crap. It’s a very early version, so expect bugs. Lots of them. Break it please, and tell me about it and how you did it ;-)

Moved! Well, sort of…

Erik van Brakel — Mon, 11 May 2009 23:45:53 GMT

Okay, I’ve moved to my own host, using subtext as the blog engine. I’ve also renamed my blog to SmoothFriction.nl, to match the URL I am using right now. Thinking hard to come up with a good subtitle now, but the URL is here to stay.

I’m also in the process of fixing the old posts which got a bit scrambled when moving here, as well as adding the SyntaxHighlighter javascript to get those really cool code blocks. Stay tuned!

Note: If you're using feedburner on my blog, the url won't change. So you should still get the updates.