First thing to note is that even after I’ve gotten quite a few referrals, I’m only up to a little over 3 GB on DropBox, whereas I started with 5 GB w/ SugarSync. In addition to that, since I paid for the service, my wife (my referrer) and I will both get an extra 10GB just because I got a paid plan, which will help her store her photos on SugarSync without needing a paid plan herself. I’m not sure if this lasts forever or only while I have a paid account, but regardless, assume each paid plan is 10GB bigger than advertised (check SugarSync for details). Last but not least, after signing up for a free plan, I got e-mails for half off any yearly plan, which allowed me to get 60BG of storage for only $50.00 for a year.

The one category in which SugarSync did not win against DropBox was in the upload speed category. SugarSync does appear slower, but I have not done enough tests to say that this is always the case, and it was still fast enough to satisfy my needs, so I’m going with the option that provides me the most free space, the cheapest paid space, and the most configuration options so that I can organize my files the way I want to rather than having to drop them all into a DropBox folder.

So, let’s say that you’re a small webshop and you have a custom CMS that you use for all your sites, but you also do some WordPress and BrochureWare sites that have some common files (e.g. CSS reset files, particular folder structure you want all your people to use, etc.). To simplify your life, you want this all under a single source control repository so that you can “branch” your templates for every website, and your structure looks something like this:

/Templates/CustomCMS
/Templates/WordPressTemplate
/Templates/BrochureWareTemplate
/Sites/WordPressImplementation
/Sites/BrochureImplementation
/Sites/CustomCMSImplementation

You can basically think of this as having 3 trunk/master folders in a single repository. With subversion this is extremely easy because every folder is essentially it’s own little repository. When you’re creating a new custom CMS site, you just branch the /Templates/CustomCMS/ to your Sites/SiteName folder and start working on it. If you find a bug in the custom CMS and fix it, you can merge it back up into your /Templates/CustomCMS folder. When you’re checking out code, you can also check out just a sub-directory rather than having to checkout the entire repository. With Git, this isn’t so easy. A Branch in Git is a branch of the ENTIRE repository. There are some tools for bringing external repositories into a subtree of a Git repository, but still not for branching off of that directory only. So, for similar functionality to the above folder layout, you’d have to have 3 separate repositories with Git.

For larger projects, where you only want a single repository for the entire project, Git seems to win out for me. However, for these much smaller projects that can kind of all be lumped together easily in a single repository in Subversion, Subversion is the winner.

This is some bogus code…the list would always be empty…but assume myObjs actually does contain a list of items in it.  We could use an extension method that would allow us to build a delimited string from ANY enumerable list of objects or strings.

The above extension method would allow us to change the first code example to the following:

And the best thing, is this can be used with pretty much any enumerable list/array, so you only have to write it once.

I hate really long if()s. So, this lead me to think along the lines that there’s got to be a better way to do this. 3 separate statements all checking the value of a single variable is excessive in my mind. I wanted the code to read like this to simplify the conditions and make them more readable:

In many other languages the above would be impossible, we’d have to write IsIn(myInt,1,3,5) which isn’t as intuitive to read. However, as of version 3 or 3.5, .NET allows us to write extension methods so that we can write the code exactly as I outline above. In order to write an extension method, you have to have 3 things: a static class, a static method, and the first parameter of the static method needs to have the “this” keyword before the parameter and be of the type that you wish to extend. So, to create a method that does exactly what’s shown above, we could do it like so:

Using the “this” keyword in a static method and class allows you to use the method as-if it were part of the Int32 class. If you’re unfamiliar with it, the second parameter also has some magic with the “params” keyword. My co-workers told me about this while I was working on this method which saved me from writing overloads for 2, 3, and 4 parameters. The params keyword can be used as the last parameter of a method to allow an unspecified number of parameters to be sent in as an array of a specific type, which keeps you from having to do: myInt.IsIn( new[]{1,3,5} ). You can look into it further if you like by clicking here.

So, this method leverages extension methods and will let you assign any number of parameters to check against, which is great. However, the problem with this is that it’s only going to be able to be used by the Int32 object. The result would be that if I wanted to do the same thing for other types, I would need to write an overload for them. So, I’d end up with overloaded methods for Int64, Decimal, String, and maybe a number of my Enums, etc. I could easily end up with 10 or more overloaded methods that all do exactly the same thing. On the other hand I could write the extension method so that it extends object instead of Int32, but then my code would no longer be strongly typed, and it could result in unforeseen runtime issues. So, this brings us to Generics. If we change this method as follows, it can be used by ANY object and still require all parameters to be of the same type as the object we are comparing against:

The “T” generic here: IsIn<T>( this T instance ) makes this extension method available to ALL objects. By using “params T[] values” we are requiring that the parameters passed into the method for comparison are of the same type as the object being compared against, keeping us from runtime issues where things would be equal but aren’t because they’re not the same type. We now have a very powerful method, and if you are working in the same namespace or use the namespace in your file, you’ll see the IsIn method show up in your Intellisense in Visual Studio. So, this method is now extremely re-usable and can make multiple conditional checks against the same variable much more readable.

However, there is one more thing that can make this code even cleaner. I was quite happy with the above method and would have stopped there. However, I have Resharper installed, and it was underlining the foreach. So, I hovered over it, and it was telling me to change it to a LINQ expression. So, having learned to trust ReSharper a bit, I decided to click the little lightbulb icon next to it and let it reformat my method, which changed my code to this:

I love ReSharper…it’s the only application I’ve ever had that actually taught me programming tips & tricks on the fly. As a result, I have an extension method that uses Generics so that it can be used by ANY object, using the params keyword so that I can pass in any number of parameters to compare against, and using LINQ so that my method is extremely short and readable.

Now, there are other ways to skin this cat that don’t involve coding an IsIn method, such as: “new[]{1,3,5}.Contains(myInt)”, but I think that the IsIn adds quite a bit to readability over doing that.

Anyway, hopefully this little tidbit will help someone.

jBind can work with objects and arrays to build out the template. So, we needed a calendar object with properties, such as MonthName, and an array of Weeks. Each Week, then, needed to be an object with an array of Days, which are in turn their own object with properties such as “DateNumber”, “DayOfWeek”, and other properties that might be used within the calendar HTML to display or help locate specific days.

I’ve stripped down the below code a little bit, but left in namespacing and the arrays for Days of Week and Months so that you can see more of the functionality working and understand it.  The below calendar code is technically not dependent on any JavaScript library, but it is optimal for use with jQuery’s jBind Templating plugin.

var w3              = new Object();
w3.Calendar         = new Object();
w3.Calendar.Arrays  = new Object();

w3.Calendar.Arrays.Days = [
  {Abbr: "Sun", Name: "Sunday"},
  {Abbr: "Mon", Name: "Monday"},
  {Abbr: "Tue", Name: "Tuesday"},
  {Abbr: "Wed", Name: "Wednesday"},
  {Abbr: "Thu", Name: "Thursday"},
  {Abbr: "Fri", Name: "Friday"},
  {Abbr: "Sat", Name: "Saturday"}
];
w3.Calendar.Arrays.Months = [
  {Abbr: "Jan", Name:"January"},
  {Abbr: "Feb", Name:"February"},
  {Abbr: "Mar", Name:"March"},
  {Abbr: "Apr", Name:"April"},
  {Abbr: "May", Name:"May"},
  {Abbr: "Jun", Name:"June"},
  {Abbr: "Jul", Name:"July"},
  {Abbr: "Aug", Name:"August"},
  {Abbr: "Sep", Name:"September"},
  {Abbr: "Oct", Name:"October"},
  {Abbr: "Nov", Name:"November"},
  {Abbr: "Dec", Name:"December"}
];

w3.Calendar.Week = function( weekNumber ) {
  this.WeekNumber = weekNumber;
  this.Days       = new Array();
}
w3.Calendar.Day = function( cssClass, week, date ) {
  this.CssClass       = cssClass;
  this.DateNumber     = date == null ? "" : date.getDate();
  this.DayOfWeek      = date == null ? "" : date.getDay();
  this.DayOfWeekName  = date == null ? "" : w3.Calendar.Arrays.Days[this.DayOfWeek].Name;
  this.DayOfWeekAbbr  = date == null ? "" : w3.Calendar.Arrays.Days[this.DayOfWeek].Abbr;
  this.WeekNumber     = week == null ? "" : week.WeekNumber;
  // other properties you might want to stick in template such as IsWeekend, etc.
}
w3.Calendar.Builder = {
  getData: function(year, month) {
    this.jsMonth            = month-1; // JavaScript uses 0 for Jan, etc., so subtract 1
    this.Data               = new Object();
    this.Data.Weeks         = new Array();
    this.Data.Year          = year;
    this.Data.MonthNumber   = month;
    this.Data.MonthAbbr     = w3.Calendar.Arrays.Months[this.jsMonth].Abbr;
    this.Data.MonthName     = w3.Calendar.Arrays.Months[this.jsMonth].Name;

    var oCounter        = new Date( year, this.jsMonth, 1 );
    var iWeekCounter    = 1;
    var CurrentWeek     = new w3.Calendar.Week( iWeekCounter );

    // fill up week with empty days until day matches day for 1st of month
    for( var i=0; i != oCounter.getDay(); i++ ) {
      CurrentWeek.Days.push( new w3.Calendar.Day( "empty", null, null ) );
    }

    // fill up week with days.  Start new week on Sundays
    while( oCounter.getMonth() == this.jsMonth ) {
      CurrentWeek.Days.push( new w3.Calendar.Day( "date", CurrentWeek, oCounter ) );
      oCounter.setDate( oCounter.getDate() + 1 );

      if( oCounter.getDay() == 0 ) {
        this.Data.Weeks.push( CurrentWeek );
        CurrentWeek = new w3.Calendar.Week( ++iWeekCounter );
      }
    }

    // fill up last week with empty days until Saturday is filled
    while( oCounter.getDay() != 0 ) {
      CurrentWeek.Days.push( new w3.Calendar.Day( "empty", null, null ) );
      oCounter.setDate( oCounter.getDate() + 1 );
    }

    this.Data.Weeks.push( CurrentWeek );
    return this.Data;
  }
}

These properties can then be used as needed in the template.  So, here is the beauty of jBind. We put the following HTML at the bottom of our page inside a hidden div.  Notice how simple and clean the HTML is:

<div id='Template' style='display:none;'>
<!--data-->
<div class='header'>{MonthName}, {Year}</div>
<table class='calendar'>
   <thead>
     <th class='week'>&nbsp;</th><th>S</th><th>M</th><th>T</th><th>W</th><th>Th</th><th>F</th><th>S</th>
   </thead>
   <tbody>
     <!--Weeks-->
       <tr><td class='week'>{WeekNumber}</td>
       <!--Days-->
         <td class='{CssClass}' DayOfWeek='{DayOfWeekAbbr}'>{DateNumber}</td>
       <!--Days-->
       </tr>
     <!--Weeks-->
   </tbody>
</table>
<!--data-->
</div>

So, now we have a template and a way to create a calendar object to populate it.  All we have to do now is combine the two, which can be done easily.  However, now, obviously our code becomes dependent on two JavaScript files, the jQuery core, and the jBind plugin.  Once you have those two files linked, you can plugin your calendar code to your template like so:

$(document).ready( function() {
  var data        = w3.Calendar.Builder.getData( 2009, 5 );
  var template    = $('#Template').html();
  var formatted   = $(template).bindTo(data);
  $('#WhereToPlaceHTML').html( formatted );
} );

Using this approach, you have an extremely flexible calendar system that can be built with any template. Then, you just run your script to populate/manipulate the calendar as needed thereafter.

Benchmarking?

Now, I haven’t done any benchmarking to see if the above is any slower than traditional string-concatenated templates. To build an entire year of calendars on a single page was taking about 6 seconds in FireFox and 10 seconds in IE, which is a bit slower than I’d like, but I’m not sure JavaScript would be any faster using string concatenation, and with the ease of use, and flexibility provided by the template engine, I consider it well worth it.

In any case, having gotten a modicum of experience in these 3 frameworks, I figured I’d throw out my two cents for anyone looking into JavaScript frameworks and trying to decide what to use.

Prototype

Prototype is a great object-oriented base-code, with features that are very useful for building your own code.  It has some really handy methods, at least one of which I can’t live without: Function.prototype.bind (look it up).  However, overall, even with script.aculo.us, it just seemed like we were always re-inventing the wheel.  That’s great, as I love the experience of creating all my own tools, but with deadlines, etc., you end up with a wooden wheel when you really want a high performance radial tire.  So, my opinion is that if you’re going to use prototype, use it in conjunction with another library that has more pre-built standard features. Or just take the useful features of prototype and add just those parts to the other library.

JQuery

JQuery is a step up from prototype in terms of it’s pre-built features.  With the JQuery UI, you have access to a lot of common functionality features: Accordian, Dialog, ProgressBar, DatePicker.  You also have ways to easily implement things like drag/drop and making a list sortable.  There are also a lot of really nice plugins that you can use in conjunction with JQuery.  So, JQuery is a great library to work with. If you want to use JQuery and like how they did things, then I don’t think you can really go wrong with it.

That said, I did end up adding an additional method to handle class inheritance, and I borrowed the Function.prototype.bind that Prototype uses and is extremely handy if you ever pass functions that are within a class to an event handler.  However, these things were easy to add and I don’t really consider them as a detraction from JQuery.  Really, about the only problem I have with JQuery is that I have a $(document).ready() with about 50 calls in it to get it to make conversions on the HTML, whereas, I would really like it if JQuery had a parser that would automatically convert HTML on the page based on tag attributes, which leads me to Dojo.

Dojo

I have to say that I really love the dojo framework.  It is the behemoth of JavaScript frameworks, with more extensions that come with it by default then you’ll probably ever need.  Additionally, since it only loads up the extensions that you need (on-demand) you have access to EVERYTHING without weighing down your users with the entire framework of code.  However, I love dojo for a completely different reason, and thats for its parseOnLoad ability.  You simply specify an attribute in a tag like so: <tag dojoType=”namespace.to.type”>, and add any other attributes applicable to that type, and dojo will automatically parse the page, load the needed JavaScript files for that type (again, on-demand), and convert the tag to that type using the attributes that you specified.  This allows your HTML and CSS to define the attributes of what is displayed instead of having to assign those values via JavaScript in an onload handler like you would with JQuery.  I consider this to be a much more natural way of defining things in a web page.

To try to explain this, though, an example is much better.  So, let’s say we want a tooltip that can display HTML formatted text rather than just the text tooltip we get with the title attribute.  Well, we can do this quite easily, and the greater part is that we can do it with ZERO Javascript coding, like so:

<a id="phrase">Hello World</a>
<div dojoType="dijit.Tooltip" connectId="phrase">
<b>a phrase that is apparently impossible to program without</b>
</div>

If Dojo is set to parse automatically, it will parse the above, find the dojoType=’dijit.Tooltip’ tag, convert it to a tooltip popup and hide it from the browser display. Then, the connectId=”phrase” tells it to assign onmouseover and onmouseout event handlers to the tag with the id “phrase”…presto, no JavaScript in your HTML at all, no need to call anything onload…it’s non-programmer friendly because it’s just HTML, and it’s programmer friendly because there is a nice separation between the code and HTML.

Now, I was originally going to finish this block by talking about how big of a file size dojo has, and how it was the heaviest framework of the bunch to somewhat show it’s negatives. However, then I took a closer look at JQuery. Once you add JQuery-UI, which for my own use is a must…JQuery doesn’t really provide much (if any) bandwidth savings. Combine that with Dojo’s ability for on-demand script, so that you’re only loading what you need, when you need it…and it just comes across as dojo being the all-around winner, at least in my book. Additionally, if you do use particular extensions on a regular basis, you can compile these into a single file and gzip compress it for additional savings.

Note on GZip Compression

In the case of either JQuery or Dojo, make sure that you do take advantage of gzip compression. If you use something like the Google CDN, then google takes care of this for you. However, if you’re using a local copy, make sure to take a look into getting compressed files, or how to compress them using server-side script for custom solutions.