Rob's Blog

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!

Rob

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 { }
}
#endif

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.

Rob

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...  :)

Rob

I was asked on short-notice to fill in for the Java Users Group, and to present CSS. I have so much fun speaking, teaching, and learning with fellow developers that it was a no-brainer to say yes. However, what was so unique to me is I'm not a Java developer. I'm a C# / ASP.NET developer. It really emphasized to me one of the really cool truths of internet development: there are 1000 server-side technologies and web servers you can use to host your content, but at the end of the day, there are just 3 types of content that get rendered through the web to the client's browser: HTML, JavaScript, and CSS. (Granted, browser plugins allow for other things, but not natively.)

So, after the full disclosure disclaimer, we from opposite sides of the technical globe were able to discuss Web 2.0 very effectively.

I've presented "CSS - A complete journey" before, and it just keeps getting better and better. CSS has some quirks, but it's by no means hard. Once you understand how to reference CSS from the page, how to attach styles to elements, and a bit about order of precedence, everything else is just futzing with browser incompatibilities.

Here are the slides and sample code we used during our discussion on CSS. Included is the page from CSS Zen Garden that we adjusted using the Firefox Web Developer Toolbar plugin. Included as well is the Box Model discussion from Brain Jar's site. I wish I had created each of these brilliant works, but alas, credit is due to their authors.  Included as well is the positioning mini-site I built to show the effect of float, position, and overflow.  And as with HTML and JavaScript, this is a client technology.  You can view source on any page you can see, look through their CSS, and discover how their solutions work.  Thus every page on the internet can be a learning tool.

I look forward to next month's Java Users Group, where they've invited me back to discuss "Thinking in JavaScript".  We'll look at how we can leverage our knowledge of C-style syntax, OO principals, and html DOM to become instantly productive in JavaScript.  I can't wait.

There's a bug in the Validator Callout in the AJAX Control Toolkit documented by bugs 10900, 12342, 15698, and 11701 on the Code Plex site.  All 4 bugs describe the following undesired behavior:

1. Pull up the AJAX Control Toolkit Sample site's Validator Callout example (here)
2. Push submit
3. Note that both fields are invalid, and the first field shows the Validator Callout
4. Add text to the first TextBox
5. Push submit
6. The Validator Callout for the top text field is gone, the Validator Callout for the second TextBox is not shown but should be
   

This is the symptom identified by these 4 bug reports.

The problem?  The Validator Callout set this._isOpen at the top of the show() method, but actually did the showing at the bottom of the method -- after checking a few more things.  So, when you push submit in step 2 above, it actually sets this._isOpen = true on both Validator Callouts even though only one is actually visible.  Once you fix TextBox 1, and push submit, it runs through the validators again, notes #1 is now valid, and #2 is still invalid.  It also notes that #2 says it's visible, and doesn't bother showing it.

The solution is uber-simple:

- Replace the get_isOpen() function at the bottom of ValidatorCalloutBehavior.js with this one, which actually checks if the pop-up is visible:


- Delete all lines that assign something to this._isOpen (e.g. this._isOpen = false;)

- Replace all lines that use this._isOpen with this.get_isOpen().  By my count, there are two such lines: one in show() and one in hide().

That's it.  It now no longer guesses if the validator is visible, it checks the table it created to see if it's actually visible.

I've submitted the patch to the 4 bugs on CodePlex, and hopefully it'll get into the next release.  If you're anxious to have this bug fixed as much as I, you can just download the modified file from CodePlex here including the JavaScript unit test that proves the problem existed and is now solved.

Rob

The LINQ to SQL Visualizer is a phenomenal tool.  This is how debugging should be done.  Scott Guthrie introduced it in the Visual Studio 2008 Beta 2 timeframe, and I've been hooked ever since.  It's now bundled in the Visual Studio 2008 RTM samples, though it's not installed by default.  Instructions of how to install it are here.

Well, I'm splunking along in some code that happens to be in a transaction.  I've just inserted a row, and I'm about to execute the select that refreshes the business object with generated content including the primary key.  I open up the Visualizer, and push the Execute button.  Nothing happens, and the window freezes.

It dawns on me that the unit test's transaction has locked the row in question, and the Visualizer can't get to it.  Well, that's all fine and good, but why wouldn't it be in the same transaction and/or join the transaction and/or create a rollback point in the transaction in process so the "execute" button can be undone once the window is closed?

I emailed Scott Gu, and he passed on my question.  (Scott is phenomenally awesome with email, by the way.  I can only imagine how many emails he gets from users across the globe, and each time I email, I get a personal response.  I hope I can be that awesome when I grow up and get an office with a window.)  The answer came from a tech that Visualizers don't use the same app domain as Visual Studio, so reusing the connection was impossible, making subscribing to the transaction also impossible.

Since this is sample code, and thus the code is provided, I'd like to take a stab on an off hour changing the sample to store the SqlConnection (or IDbConnection) rather than the ConnectionString and see if it works.  I expect it won't, but if it did, wouldn't it be cool?

In the mean time, I'll just remember to look in the LINQ to SQL Visualizer but not execute if I'm inside a transaction.  If I'm that curious, I'll grab the query, finish the transaction, and execute it inside Sql Management Studio or LinqPad.

Rob

For ages I've wanted to be able to put a comment of some kind in my code that I could get to come up during a build.  "Hey, you haven't finished this" or "This is an assumption we need to run by the suits" or "you dork, how could you even think to do it this way" or similar -- notes to myself and others that there is work left to be done here.

Well, after trying unsuccessfully to look towards subclassing or hacking the Obsolete attribute the answer was handed to me:

1. I build comments in the form // TODO: or // ASSUME: or // BROKEN: or similar, I choose the View menu, and choose Task List.  Ok, granted, that's been there since the beginning of time, but who put that there and why didn't they tell me?  Holy cow, that's cool.  I can even configure it with my own set of commentaries like // DORK_MOVE: or // INSECURE: or // WHAT_WERE_YOU_THINKING:

2. There's a pre-processor directive called # warning.  Put what ever message you want after, and it shows up in the normal error list.

With these two tools now in the arsenal, I can capture my thoughts in the place most relevant to the task at hand -- in the code.  And I can be reminded of them in the place most relevant to the task at hand -- the next tab over from the build output window.  Very nice.

Rob

Ok, I stumbled with this one enough times to log it here.  I want to tune a database I'm working with.  I dutifully fire up Sql Server's Profiler, and no where in the options do I see "filter by database".

Ok, the option is there, but it takes some doing to get there.  When you're building the profile, in the events selection tab, choose "show all columns", then you'll find the "Database Name" column.  Pop in the database name in question, and you're golden.

source: http://sqljunkies.com/Forums/ShowPost.aspx?PostID=14078

I had the great privilege and honor of presenting "Thinking in JavaScript" at the SouthEast Valley .NET Users Group this evening.  All in all, I had a ton of fun.  If anyone else got anything out of it, all the better.

The main point of my discourse was that JavaScript isn't hard by any means, it just takes an introduction to how it thinks.  Microsoft's ASP.NET AJAX has made it feel much more like the .net languages we're used to.  But there are still some inherent differences between a compiled language and a dynamic language.

The main focus of the discussion is these few points:

• Every object is a Dictionary.  In C#, think of Dictionary<string,object>.
• Functions assigned into the object's 'dictionary' are like methods.
• Functions are objects, and can be assigned like variables.  In C#, think of delegates.
• Every parameter in a function is optional, allowing for uber-easy "function overloading".

We also covered incredibly cool tools for working with JavaScript:

• FireBug -- getfirebug.com
• Web Developer Toolbar for Firefox -- addons.mozilla.org/firefox/addon/60
• Visual Studio 2008's JavaScript Intelisense
• JSView plugin for Firefox -- addons.mozilla.org/firefox/addon/2076
• IETab plugin for Firefox -- addons.mozilla.org/firefox/addon/1419
• YSlow plugin for FireBug that evaluates your code based on Yahoo's Best Practices

You can open up MicrosoftAjax.debug.js file by cruising to C:\ Program Files\ Microsoft ASP.NET\ ASP.NET 2.0 AJAX Extensions\ v1.0.61025\ MicrosoftAjaxLibrary\ System.Web.Extensions\ 1.0.61025.0\ *.debug.js (spaces added for clarity)

And the coolest thing of all -- anything built in JavaScript is available for download by choosing "View Source".  When you publish anything in JavaScript, you don't publish a compiled assembly, you publish your source.  Thus anything created in JavaScript becomes awesome reference material -- bonus!

The slides for this are in Powerpoint 2007 format and available here.  The code we walked through was from Rob Bagby's webcast series on the ASP.NET AJAX Client Libraries available from his blog: blogs.msdn.com/bags/archive/2007/06/07/latest-asp-net-client-libraries-webcast-sample-code-and-links-to-all-sessions.aspx and blogs.msdn.com/bags/archive/2007/06/07/links-to-remaining-asp-net-ajax-client-libraries-webcasts.aspx

Thanks to all who came -- you got some cool swag, and thanks to our sponsor who bought the pizza and showed us just how much we love LINQ. :D

Rob

Ok, I've forgotten this more times than I care to remember, and each time, I have to re-Google it.  I hereby commit it to digital memory:

If you have a DropDownList control like so:
     <asp:DropDownList ID="mycontrol" runat="server"></asp:DropDownList>

and you want to get it's selected value in JavaScript, do it like so:
     var control = $get('<%= this.mycontrol.ClientID %>');
     var selectedvalue = control.options[control.selectedIndex].value;

And there ya have it.  I hereby have forgotten it already... :D

Rob