Until now we stored the main source of the .less project in Chris Owen’s GitHub account. We now decided to create a dedicated GitHub user to host the project since Chris is no longer actively contributing and may or may not want to add changes that are not meant to be immediately committed into the mainline.

The new repository is at: http://github.com/dotless/dotless

We are still updating all references to the old project (website etc) but the move should be done fairly soon. If you are watching Chris’ repository make sure to also watch the new one as Chris’ repository may start lagging behind the mainline (depends on how often Chris will update his fork).

Oh, and btw: Thanks to the GitHub guys for providing this awesome service. Git + GitHub has simply revolutionized the way I write code and collaborate with people.

It’s been on our feature list for some time and it’s been in the code for some time too. But after fixing a final bug today I guess we can tell the world about it.

The main idea behind –watch is to free you of the burden of having to configure anything but lets you just run the console-compiler once and it keeps refreshing the resulting .css files whenever a change occurs to the .less input file.

How to use? Well, simple. First grab the latest release from our website http://www.dotlesscss.com and then go to your favorite commandline and start the compiler with the –watch parameter:

dotless.Compiler.exe <filename> –watch

You will then get a nice console output telling you what is going on (and informing you of errors if any happen during compilation)

Do you remember that little project I am involved in? That .less thingy I always forget to write about? Well, it’s still around and we are going very strong. We are seeing a decent amount of activity on our mailing list and people throw code at me at various occasions for fixing different problems within the the project.

One of those persons is James Foster, a really nice guy from the UK with some mad programming skills who set out to make .less awesome. Well, he sort of did already, by contributing some major code changes to the .less parser that enabled him to port over some SASS functions to .less. Sadly he does not blog himself, so the honor is mine to report to the world what he did.

Color functions

Before going into details, the main idea is that you are now able to modify any component of a color separately. So far .less has only supported arithmetic operations on colors (like #abc000+ #000def => #abcdef) so if you e.g. want to darken a color while adding 10 points of green to it you where out of luck, making the feature not really all that useful. Well, thanks to James now we can!

Creating colors

.less understands that #FFFF is supposed to be treated as a color, so if you start working off web colors you can just use the hex notation and ignore the following functions. In case you are more the designer type settled in the RGB world and want to have lightness and alpha around, you will need functions to create the colors. And while at it James also added color literals so .less detects a @color: blue; instruction just like it would a @color:#0000FF one. Anyway, if you have your colors RGB or HSL you need to use the following functions to create them:

rgb(red, green, blue)
rgba(red, green, blue, alpha)
hsl(hue, saturation, lightness)
hsla(hue, saturation, lightness, alpha)

You might guess from the parameter names how they work. But to be thorough:

@mainColor: rgb(0, 0, 255); //Blue

Modifying colors

Now, once you hold on to a variable that contains a color you can do some pretty exciting stuff with the following color manipulation functions:

red(color, value)
green(color, value)
blue(color, value)
hue(color, value)
saturation(color, value)
lightness(color, value)
alpha(color, value)

the value can be positive or negative, for instance, to darken a color by 20% you can use “lightness(color, -20%)”.

You pass in a color and then the amount you want to change it. If you omit the change value part the method will return the appropriate component of the given color (meaning: red(@color) will return the red portion of that color, while red(@color, 10%) will increase the amount of red by 10%).

And while at it, James also added some convenience functions for good measure to make your day easier:

greyscale(color)
this is equivalent to saturation(color, -100%)

complement(color)
this is equivalent to hue(color, 180)

mix(color1, color2, weight)
mixes 2 colors together. The weight argument is optional and specifies the percentage of the first color to use compared to the second color. it also takes into account transparency – if a color is more transparent it has less effect on the resulting color.

You can get all of that functionality through the latest .less build from our website http://www.dotlesscss.com or just grab the code from GitHub. If you have any questions or suggestions feel free to participate through our mailing list.

And lastly, let’s give credit where credit is due: Thanks to James for the great work he put into .less. James himself stated that he based most of his work on stuff he saw on the Sass project, you can read about their color functions implementation here: Powerful Color Manipulation with Sass. The initial code for Sass was created by Chris Eppstein for the “compass-colors” project which has now been merged into the main Sass codebase. You can also see his pretty impressive demo here: http://chriseppstein.github.com/compass-colors/

I just finished my presentation about dotless at Barcamp Klagenfurt and promised to upload my presentation slides to Slideshare.

The feedback for the talk was quite good. Turned out better than I hoped. I just hope that the slides do make some sense without me talking alongside.

Ok, today I got this really cool pull request from Jon Galloway for .less. He did some improvements to the T4 Template for .less so that it will run the template on every build if you want that, or that Visual Studio opens up .less.css files. Cool stuff, and thanks a lot Jon! Of course I quickly looked through the changesets and then went ahead and committed it, but I noticed one novice mistake many people run into with MsysGit on Windows.

I am pretty sure Jon only changed a few lines of code, yet the changeset logs every file in the document as changed, thus making it pretty unreadable. This happened to me a lot when I started out with GIT, and finding the solution to this wasn’t easy either. So here is how to fix your MsysGit.

This is caused by a little setting called core.AutoCrlf that is set in MsysGit by default to true. MsysGit will then go ahead and localize the line-ending depending on what machine you are running on. This happens on checkout, so even with abolutely zero changes to the repository you’ll see a lot of local changes where there haven’t been any.

Needless to say how stupid this setting is, it only generates a ton of useless insertions and deletions while sticking to the pipe dream that everyone on the team will use the same tools to generate consistent line feeds (I’ve even had issues with only Windows machines and this setting).

Now the solution to this is rather simple:

By running “git config –global core.autocrlf false” you disable this and the text files will not get changed upon checkout. This now means that Visual Studio will maybe ask you to fix inconsistent line endings when opening a file, but it is still better than having your source control screw you over upon checkout.

Time goes by way faster than I’d like it to and the Barcamp Klagenfurt 2010 is coming up really fast. (6-7. February)

While usually I was quite hesitant to choose a topic due to the diversity of the attending crowd (unfortunately not really enough real technical topics represented there), this year I think I can bring something very interesting to the camp: .less.

The advantages are obvious, with a crowd of bloggers, artists and also technical people talking about something as ubiquitous as CSS, and ways to improve it, will surely resonate well, allowing me to be a bit technical without raising too many question marks above my audience’s heads like last year (where I talked about IoC and Windsor).

As for the talk itself, I plan on first going over general features of Less (since we are a port I can also point people over to the Ruby version if they are more comfortable with that than with .NET ), and then into a tiny bit of detail about how .less works internally.

Finally, I hope to see as many people as possible at Barcamp Klagenfurt! Thanks to the team for organizing this year after year!

Imagine the following: Clint calls telling me “Hey Daniel, I just got a new computer with Windows 7 64 Bit installed, everything is working great so far. The Software you wrote a year ago works fine on it too, only problem: I can’t print”

My immediate reaction: “Reboot the system” (ok kinda lame, but I have spent too much time with problems that went away through a reboot to not suggest it).
Well, but the reboot didn’t help here. Even after rebooting the print dialog was still not showing up.

Now, I know for a fact that the Software runs fine on Win7, I also know it runs fine on Win7 x64 (since I developed it running both x32 and x64 Win7 Beta builds back in the day). And since I am using the PrintDialog class provided by the .NET framework I wasn’t really sure what  could be the issue. I mean, hey that’s a framework class, those things are supposed to run cross platform and be CPU ignorant. But hey, why not simply ask Google the most stupid question I could think of: “windows 64 .net print dialog” ..

And the answer was right there on Microsoft’s MSDN page as a remark:

Also, The PrintDialog class may not work on AMD64 microprocessors unless you set the UseEXDialog property to true.

WTF? (Ok more words come to mind, but since I don’t want to get hatemail for my language I’ll leave it at that).

We are talking about a class in the .NET BCL that is supposed to work cross plattform (at least Windows), be completely CPU ignorant (fully managed), and yet I have to set UseExDialog to true to see this dialog on a AMD CPU? Are you kidding me Microsoft?

Well, the fix was quite easy (thankfully). I went into my PrintDialogFactory and changed one line of code, packed a new release and sent it to my client, yet my confidence in BCL classes has been severely shaken.

I really don’t know anything about the reasons for this odd (to say the least) behavior, but I can say that I am a bit sad to see it monkey-patched like this. Especially in a VM environment like the .NET framework I expect Microsoft to solve their system-specific problems under the hood where I can’t see them and don’t have to care about them.

Ok, I’ve just spent almost the whole day refactoring the hell out of our .less codebase just to add one tiny change:

Allow users to not only load files present on the current file system, but also directly from in-memory strings and VirtualPaths (as requested on the list). The problem here being that not everyone wants to serve his .less files right from the server’s file system but sometimes people have pretty sophisticated virtualized storage systems in place that require them to use the VirtualPathProvider abstraction that was added to .NET 2.0.
You can read up on that in ScottGu’s blog or David Ebbo’s blog, but in a nutshell it’s just another way to open files besides using System.IO.File.Open(), letting you forget about all the nasty stuff of where the file is really located. 

To do so I had to allow uses to plug in different “Sources” for .less code, and so I also had to make a breaking change to the main ILessEngine interface. The Interface was taking a filename as parameter, but in light of our recent support emails on the development list I decided that has to go away in favor of a more open approach (mainly to allow users to simply throw in-memory strings at the engine).

Because I know this will break some code, all implementors of ILessEngine still offer the old string parameter as an overload that then defaults to the default FileSource.

Now, for changing the source provider:

If you want to use anything besides the default filesystem based FileSource provider, you now have the ability to plug in a type implementing ILessSource through the DotLessConfiguration (thus through web.config).
.Less comes with three sources built in: VirtualPathSource, FileSource (default).

FileSource by default just opens a file through System.IO.File, while VirtualPathSource will use the HostingEnvironment.VirtualPathProvider.GetFile() method to open a Stream and read the .less code from there.

To enable the VirtualPathSource in your web application you simply need to modify your web.config a bit:

<dotless minifyCss="false" cacheEnabled="true" source="dotless.Core.VirtualPathSource">
  
</dotless>

The important part is the source attribute as it has to reference a type name implementing ILessSource. So if you want to create your own less source you could simply create another implementation of ILessSource and reference it’s name in the .less config.

If you want to use .less directly from your code to transform something you can just new up a LessSourceObject (the very output we get from ILessSource) and throw your code in there like this:

ILessEngine lessEngine = new EngineFactory().GetEngine(new DotlessConfiguration());
var output = lessEngine.TransformToCss(new LessSourceObject() {Content = "my .less code here"});

As always you can get the latest code from GitHub, or the latest binary release through our TeamCity build server. You can read more about .less (pronounced dot-less) on the project’s website at http://www.dotlesscss.com.

And while at it, we’d appreciate it if you spread the word about .less .

Stop rolling your eyes, I know there are more logging infrastructure libraries out there than there are projects using them. And I won’t say this one is different, it’s not. It’s more or less a little experiment I did to get accustomed to VS2010 and R#5.
Also note that most of the code originated from me writing a logging architecture for a Java OSS project I’m involved with and I wanted to carry the idea over to .NET.

But: I believe it turned out to be quite nice while very very lightweight. So I thought I’d just go ahead and share it.

Usage

Tigraine.Logging has a ILogger interface that exposes the usual suspects:

You just instantiate the appropriate ILogger implementation and are set to go, it will write everything you pass to it.

What makes out most of the code though is the ability to render objects passed into the logger as parameters. This idea came from the Java codebase where there was code like this scattered all over the place:

@Override
public String toString() {
	String ret = this.getClass().getSimpleName();

	if (Config.logVerbosity >= Log.Verbosity.VERBOSE) {
		ret += "(" + this.hashCode() + ")";
	}

	if  (Config.logVerbosity >= Log.Verbosity.VERBOSE) {
			ret += " A={" + this.a + "}, B={" + this.b + "}";
	}

	return ret;
}

Now, I hate that sort of code. It’s just noise and it tends to get messy really soon. And so I started implementing my idea of ObjectRenderers (I know this term is already used by other logging frameworks, and the idea is not new either):

You add a renderer to the logger and whenever a object is passed in of the type, the renderer is invoked to transform the object to a string representation of your choosing. So instead of having to rely on .ToString() to give accurate results, you implement a class that takes care of writing all relevant information of your object down.

Here is a sample:

var consoleLogger = new ConsoleLogger(LogLevel.Debug);
consoleLogger.AddObjectRenderer<TestClass>(new TestClassRenderer());

consoleLogger.Error("Something went wrong with {0}", new TestClass());

The logging framework will call TestClassRenderer.Render to get a string representation of TestClass. This now also means you can have two different renderers, one verbose and one brief, and only hook up the one that’s right for you right now. The calling code does not need to be touched.

You can also define a renderer for a supertype and all subclasses will use that one if no more specific renderer is hooked up. If no renderer is found whatsoever .ToString() will get called.

And since implementing all renderers in their own classes would lead to a lot of code, there is a little helper class that should work for most of you by using some lambda syntax:

var compositeRenderer = new CompositeRenderer<TestClass>
    (p => p.Firstname + " " + p.Nickname + " " + p.Age);

Where to get

You may have already guessed, Tigraine.Logging can be found on GitHub and is open-source under the Apache License Version 2

Finally the Castle.Pagination component has reached v1.1.0 and is ready to be incorporated into the upcoming Castle Monorail 2.0 release.

As for the changes: There are hardly any. Pagination is a solved problem and most of the code changes where bug fixes and minor improvements.

Anyway, thanks Jonathan Rossi for helping me with the release! I can’t wait for Castle to move to GitHub so we can finally put that whole “non-committer sends patches” misery behind us.