Monthly Archives: May 2008

jQuery – LINQ to JavaScript

I had the privilege of presenting jQuery at Desert Code Camp today.  jQuery is the do more, write less JavaScript library.  Because it runs client-side, it can be used easily with any server framework.  There’s nice support for intellisense in Visual Studio 2008 as well (with a bug-fix update).

jQuery basically breaks down into two operations: picking things, and doing something with those things.  Picking things is done via a CSS / XPath strign describing the DOM nodes you want to do.  This returns an array of DOM elements (wrapped nicely in a jQuery object) that get passed into each of jQuery’s ‘do it’ functions.  It becomes trivial to change css on all items, change the innerHTML, append DOM elements, even do AJAX and visual effects.  What’s best: this whole process usually takes about 20 characters — very small, very clean, very nice.

The slides from the content can be found here.  We generated all the code we saw on the fly inside FireBug.  Enjoy!


Conditional Compile based on .net framework version

Ok, I’ve been after this one for quite a while. I want to include stuff like Moth.Linq and ExtensionAttribute in .net 2.0 compilations, but exclude them from .net 3.5 compilations. In effect, I want to cross compile to .net 2.0 and .net 3.5. Not only do I want to do this from within Visual Studio, I also want the Continuous Integration server to do it too. Tall order? Yes.

A bit of background:

Moth.Linq is a mechanism for producing LINQ functionality in assemblies compiled in Visual Studio 2008 targeted to the .net 2.0 framework. You add this piece of code, add a ‘using Moth.Linq;’ at the top, and you can use LINQ. Very cool. (Disclaimer: this isn’t LINQ to SQL or LINQ to Entities, just LINQ — e.g. lamda expressions in SQL style syntax.)

– Daniel Moth has another awesome trick for using Extension Methods in .net 2.0 deployed assemblies. Since Extension Methods are a compiler trick, not a function of the language, at compile time, the method itself is put back into a static class, and the calls to that method are magically transformed into calls to that static class’s method passing in the parameter that the extension method was attached to. None of this needs the magic System.Core.dll file that adds all the magic C# 3.0 sauce. Well, to make this compiler trick work requires the ExtensionAttribute inside the System.Runtime.CompilerServices namespace — Inside System.Core.dll. What does it do? I have no idea. But create this attribute, and extension methods just work. Very cool.

– I use NAnt triggered by Cruise Control .NET. NAntContrib has a fabulous task called msbuild that you can pass a solution file to, and it’ll build everything in the solution. Jeffrey Palermo has a great trick for enabling NAnt to build .net 3.5 projects. Combine these, and the standard NAnt build file that’s been working forever now works with Visual Studio 2008 projects as well. Very cool.

– Some developers on the team have VS 2005, some have VS 2008. Some deployment servers run .net 2.0, some .net 3.5. So, the code just has to work in both scenarios. Those of us in VS 2005 hate it when those of us in VS 2008 use the cool C# 3.0 features. Those of us in VS 2008 hate holding back.

So, the task at hand is clear: create a way that NAnt and Visual Studio can conditionally include things like Moth.Linq and Extension Methods. The clear solution: pre-processor flags. I wrap the Extension Method code like so:
#if NET_20
namespace System.Runtime.CompilerServices {
public class ExtensionAttribute : Attribute { }
Now if the preprocessor flag is defined, it is compiled in. If not, it’s not.

Well, that’s all fine and good, but how to get the target .net framework to trigger defining the preprocessor flag? Sadly, I haven’t found a good solution to that, but I did find this:

The idea is from Karsten: define preprocessor flags on the msbuild command line like so:
msbuild /p:DefineConstants=NET_20 /t:Rebuild
Ok, I’m 1/2 way there. NAnt’s syntax for defining the command line args is like so:
<arg value="/p:DefineConstants=NET_20" />
I put that inside the <msbuild> task, insure I’ve defined the framework version NAnt is targeting like so:
<property name="nant.settings.currentframework" value="net-2.0" />
and away we go. This task now defines a perfect .net 2.0 build.

Want a .net 3.5 build? Set the property nant.settings.currentframework to “net-3.5” and don’t set the arg in the msbuild task. I chose to put both “NET_20” and “net-2.0” into properties that I could set to “” and “net-3.5” based on a task passed into NAnt, and we’re good. We now have Continuous Integration building .net 2.0 compatible code. Excelent.

How do we get the VS 2005 guys to do the same? Well, that seems a task for another day. My vote was to give them all VS 2008. We’ll see how that goes over. :D My backup plan is defining project configurations for “Debug 2.0” and “Release 2.0” that define these. That’s likely incredibly fragile though — add a project and you tank that convention. Next in line is make them run NAnt to build, but getting out of Visual Studio to build seems very unintuitive. Make it a menu option in the external tools menu? That seems ripe for confusion for the new employees stepping onto the scene.

Well, in any event, 1/2 the problem is now solved. Wicked cool.


Thinking in JavaScript – A-ha!

I had the great honor of presenting ‘Thinking in JavaScript’ at the Java Users’ Group last night. I love leading a discussion of learning, and this was a great example of it. I was even asked during conversation afterwards if I was a member of ‘the club’ [the Java Users’ Group — JUG]. Well, do I have to know Java to be part of the JUG? I guess not. What a fun and welcoming crowd.

Our premise was thus: you know object-oriented development. You know C-style syntax from either C, C++, Java, C#, or any of the derivatives. You’re approaching JavaScript, and need to get into the mindset of how JavaScript works.

The majority of JavaScript is very much identical to all C-style languages: curly braces, semi-colons, objects, inheritance, debuggers, etc. But JavaScript is also different in a few ways we need to wrap our heads around. During the discussion, we identified 5 points that make JavaScript unique:
  • A JavaScript object is like a dictionary
    • Roughly like Dictionary<string, object>

  • A JavaScript method is an object
    • You can assign and retrieve them

  • All function parameters are optional
    • No function overloading, but no need

  • Constructors declare instance level variables
    • They aren’t private

  • All JavaScript objects reference a prototype
    • The prototype defines common implementation

Each one of these points requires more explanation than just that — thus the 2 hours we spent discussing it. But once you’ve wrapped your head around these few ideas, you can effectively code in JavaScript, because you’ll know how JavaScript thinks. You’ll be Thinking in JavaScript.

The slides for this evening’s discussion can be found here. The source code for the evening was mostly pulled either from the slides themselves and copied into FireBug, or we made it up on the spot. We also discussed jQuery and referenced tutorials available from 15 days of jQuery.

I asked briefly in the midst of the demo if anyone would like to see more jQuery stuff.  Just about every hand went up, so I’ve signed up to present a jQuery session at Desert Code Camp in 2 weeks.  That promises to be a ton of fun too.

If you have any questions, thoughts, suggestions, gripes, or kudos about ‘Thinking in JavaScript’ or you’d like some assistance in JavaScript development efforts, don’t hesitate to drop me a line.  The more we know about how to code effectively, the less spaghetti code there will be for us to clean up later…  :)