The best way to set columns to an equal height is to just grab all the heights, get the max, and then set each element height to the max. I did a bit of search around and found an example of adding max to Array’s prototype. I wrapped that in an if statement that checks if max is currently defined, that way if max gets added to Array in the future, my version won’t conflict.

if (typeof Array.prototype['max'] == 'undefined') {
  Array.prototype.max = function() {
    return Math.max.apply({},this);
  }
}

The trick in the code above is that using apply on the built in function allows max to receive an unlimited number of arguments. This allows me to do the following:

[1,2,3].max() // => 3

In this instance (making equal height columns), I ended up with the following solution.

$.fn.equalHeightChildren = function() {
  return this.each(function() {
    var children = $(this).children();

    var tallest  = $.map(children, function(child) {
      return $(child).height();
    }).max();

    children.each(function() {
      var padding = parseInt($(this).css('padding-top')) +
                    parseInt($(this).css('padding-bottom'));
      $(this).height(tallest - padding);
    });
  });
}

I use $.map to loop through the children and return an array of their heights. At the end of map, I call max() to return the greatest height. The nice thing about this solution is that it even takes into account padding and the box model.

Firstly, it is 11 characters. When I just want to output something really quick, it really annoys me that it takes 11 characters just for the function name, not including whatever it is that I want to print out.

Secondly, console.log only takes one argument at a time. More often than not, I’m outputting the values of a few things, which means I have to type (or copy and paste) those 11 characters a lot. What I’ve started doing recently, is adding this simple log function to my projects.

function log() {
  if (window && window.console && window.console.log)
    for(var i=0, len = arguments.length; i < len; i++)
      console.log(arguments[i]);
}

This simple function allows me to do the following:

log(some_var)
log(one_var, two_var, three_var)

It is only 3 characters and allows me to print out as many objects to the console as my heart desires. Nothing fancy, but it gets the job done and saves me some time and thought.

Not too long ago, I created my second tips site, BlawgTips. I wanted to drive traffic back and forth between BlawgTips and RailsTips, so I created a network bar that sits at the top of each of those. I was shocked at how easy it was. I only wanted it to be one request, so I included the styles inline in a style tag instead of calling another external stylesheet. Below is the code.

jQuery(document).ready(function($) {
  var styles = '<style type="text/css">' +
    "#network_bar                 {float:left; display:inline; width:100%; margin:0; padding:0; background:#222; color:#ccc;}" +
    "#network_bar ul              {float:left; display:inline; margin:0; padding:0;}" +
    "#network_bar ul li           {float:left; display:inline; margin:0; padding:0; border-right:1px solid #333; list-style-type:none;}" +
    "#network_bar ul li a         {float:left; display:block; margin:0; padding:6px 10px; color:#aaa; font:11px/11px helvetica, arial, sans-serif !important; text-decoration:none; text-align:center;}" +
    "#network_bar ul li a:hover   {color:#fff;}" +
    "#network_bar ul li a.current {color:#fff;}" +
  '</style>';

  var html = '<div id="network_bar">' +
    '<ul>' +
      '<li><a href="http://blawgtips.com" title="Over-analyzing the simple art of blogging">BlawgTips</a></li>' +
      '<li><a href="http://railstips.org" title="One man feverishly posting everything he learns">RailsTips</a></li>' +
    '</ul>' +
  '</div>';

  $('head').append(styles);
  $('body').prepend(html);

  // to ensure that there is clearage after network bar
  $('#network_bar').next().css({clear: 'both'});

  $('#network_bar a').each(function() {
    var link = $(this);
    var is_current = new RegExp(link.attr('href')).match(window.location.href);
    if (is_current) {
      link.addClass('current');
    }
  });
});

I define a style tag and some html. I then append the styles to the head and prepend the html to the body. I also add a clear:both to the element following the html added just to ensure things get cleared. I probably could switch that to css. Finally, I loop through the a tags in the network bar and add a class of current to the link that represents the current site a visitor is on.

That is it. The jQuery that actually does the work is less than 10 lines. Now I can put this in an external script and include it on multiple sites to get the exact same network bar on each of those sites. When I add a new site to the network, I simply update this one script and all the sites update with it. Pretty cool.

function addChat(name, room_jid, person_jid) {
  // add chat stuff
}

function showChat(room) {
  // show chat stuff
}

There is nothing wrong with the functions above but you can see the similarities. Both have chat in the name and both are operating on chat based stuff. What I did on the project is move them into a simple Chat object like this.

var Chat = {
  add: function(name, room_jid, person_jid) {
    // add chat stuff
  },

  show: function(room) {
    // show chat stuff
  }
}

Now I don’t have to remember whether I named the function addChat or chatAdd. It is much easier to remember that we have a Chat object and that it has add and show methods. I’m obviously not going to have an Add object with a chat method. Catch my drift? I think this is one of the reasons I got so frustrated with PHP back in the day. The function names were a pain to remember and the parameter order was even worse.

Moving things to an object like this makes them easier to remember and allows your code to grow. If, for example, I wanted to keep track of the current chat with a variable or the number of active chats, I could simply add those to the Chat object. Using functions, your only option would be to have a global variable of sorts, and trust me, those lead to the path of ruin. :)

// if google.com or www.google.com add http:// to the href
if (typeof(scheme) == 'undefined' || scheme == 'www.') { url = 'http://' + url; }

This code is from some JavaScript I’m working on that performs auto-linking of urls and email addresses. Note that there is a comment and if you read the comment you get an idea of what the code is doing. Now I just stated that comments possibly smell, so what can we do to remove the comment and yet retain the intent of the code?

var no_scheme  = typeof(scheme) == 'undefined',
    www_scheme = scheme == 'www.';
if (no_scheme || www_scheme) { url = 'http://' + url; }

We just used a pattern, namely that of introducing explaining variables. The pattern probably seems obvious now that you see it, but how often do we code like the first example. In the example above, the explaining variables are introduced with the act of replacing the, not so obvious, conditions in the if statement, with variables that are named based on the intent of the condition. Our two lines of code are now three, but I guarantee the next programmer (which might even be yourself a few months later) in our code will appreciate that extra line. Everyone knows code gets changed quite often and comments rarely do which leads to confusing and out of date comments.

Next time you start busting out conditional statements or chaining methods together, consider how you could introduce an explaning variable that might make the code intent more clear.

Cross Library Safety

The first thing I do is create a wrapper function which allows me to use $ and not cause conflicts with other JavaScript frameworks that may be included. It is simple and looks like this:

(function($) {
  // safe to use $ here and not cause conflicts
})(jQuery);

Create and Name Your Plugin Function

Next, I created the function inside which my plugin will reside. Whatever you name this function will be how you and others use your plugin.

(function($) {
  $.fn.toggler = function() {
    // the plugin functionality goes in here
  }
})(jQuery);

I have emboldened the function name in the code above to make it obvious. This means that to use the plugin I am creating, someone would have to do $('#some_selector').toggler().

Allow chainability

The next thing to keep in mind is that because jQuery takes any selector, you could be dealing with one or more objects. This means you need to be sure that your plugin loops through each element matched by the selector and applies the plugin functionality.

(function($) {
  $.fn.toggler = function() {
    return this.each(function() {
      // apply plugin functionality to each element
    });
  }
})(jQuery);

The other thing you will notice about the addition above is that I use return. One of the cool things about jQuery is the chainability (ie: $('#some_div').hide().remove()). Returning the this.each iteration allows your plugin to be chained with other jQuery operations and plugins.

Start Building Plugin Functionality

The goal of the plugin I was creating was to allow saying that a particular link is a toggler. So what is a toggler you ask? A toggler is a link that toggles the visibility of another element on the page. The connection of the link to the element is by using the href. By setting the link’s href to anchor to the id of another element, we get two things for free. First, if JavaScript is not enabled, the link will still anchor to the element on the page. Second, we know which element the link is suppose to toggle display for. Take the following html for example:

<p><a href="#foo" class="toggler">Toggler</a></p>
<div id="foo">Togglee</div>

The default behavior of the toggler link is to anchor to the Togglee div wherever it is on the page. We will then use the jQuery plugin we are making to hide the togglee div on page load and then toggle its display each time the toggler link is clicked. First, let’s hide the togglee div and add the click observer to the toggler link.

(function($) {
  $.fn.toggler = function() {
    return this.each(function() {
      this.togglee = $($(this).attr('href')).hide();
      $(this).click(onClick);
    });
  }
})(jQuery);

The first bold line sets a togglee attribute on the toggler that is equal to the togglee jQuery element. Note the $(this).attr('href'). Using the html from above, this would return #foo. $('#foo') is equivalent to a jQuery object of the togglee div. We call hide() to hide the div by default. Because jQuery allows chaining, the hide() call returns the togglee jQuery object and we save a line of code. The long hand way of writing that line would be something like this:

this.togglee = $($(this).attr('href'));
this.togglee.hide();

Because jQuery allows chaining, lines like the ones above can be combined and in my opinion remain readable. Chaining too many things together can lower readability and the obviousness of intent though, so always practice safe chaining.

Observing Clicks

The $(this).click(onClick); line above tells the toggler (which is $(this)) to run the function onClick whenever it gets clicked. We haven’t yet created the onClick function so let’s do that now.

(function($) {
  $.fn.toggler = function() {
    return this.each(function() {
      this.togglee = $($(this).attr('href')).hide();
      $(this).click(onClick);
    });

    function onClick() {
      this.togglee.toggle()
      return false;
    }
  }
})(jQuery);

this is automatically set to the element that fired the onClick, by jQuery, which is our toggler link. Because we assigned the togglee attribute to the toggler link, we can simple call this.togglee.toggle() and it will toggle the display of the togglee div. The return false tells the togglee link to not actually fire the normal event, which would append #foo to the window location.

Allowing For Options

At this point, we could be done but why not allow some options for our plugin. In this case, we’ll add the option to make the togglee div animate with a slide instead of simply showing and hiding. Check out the bold lines in the cold sample below to see what is needed to add options.

(function($) {
  $.fn.toggler = function(options) {

    var opts = $.extend({}, $.fn.toggler.defaults, options);

    return this.each(function() {
      this.togglee = $($(this).attr('href')).hide();
      $(this).click(onClick);
    });

    function onClick() {
      this.togglee[opts.animate ? 'slideToggle' : 'toggle']();
      return false;
    }
  }

  $.fn.toggler.defaults = {animate: false}
})(jQuery);

The first bold line sets the opts variable and uses jQuery’s extend function to do so. Basically, $.extend is a merge tool. In plain english here is what happens: it merges $.fn.toggler.defaults on top of {} and then merges options on top of the first merge. It guarantees that our opts variable will be a hash ({}), will have some defaults ($.fn.toggler.defaults) and yet can be overridden on a per case basis with options passed in by you, the developer (options).

In the second bold line, we tell togglee to call slideToggle if opts.animate is true, otherwise just call toggle. This uses the ternary operator and some cool JavaScript functionality. If opts.animate is true, it returns 'slideToggle', otherwise it returns 'toggle'. This means if opts.animate is true, you would end up with this.togglee['slideToggle'](), which is the sweet functionality I referenced above that JavaScript natively provides. this.togglee['slideToggle'] is a reference to the slideToggle function and when you apply the parenthesis it will invoke the slideToggle function. I feel this way is more succinct, is still readable and again, it saves you a few lines and an if/else statement. Not a big deal, but worth it in this case.

The third and final emboldened line just sets the defaults that get used in the first line if no options are provided by you when you call toggler on some elements.

Example Uses With/Without Options

Now that we have options, you can call the toggler function any of the following ways and it will work.

// will do simple toggle on click
$('a.toggler').toggler();

// will use slideToggle instead of simple toggle on click
$('a.toggler.animate').toggler({animate:true});

That is pretty much it. You can now create a jQuery plugin that is jQuery-ish and has the ability to have options that can be adjusted on the fly, by you and the people who use your amazing plugin. The only other thing I would mention is most people seem to name their plugins jquery.{plugin name}.js. For example, I named this plugin jquery.toggler.js.

Overall, I am intrigued with jQuery. It doesn’t come with everything that Prototype does out of the box, but it is probably enough for most. Even if you do not switch to jQuery, I think it is important to give it a good run as it will help you think through JavaScript in a bit different light. As always, if I missed anything or I was unclear or wrong anywhere in the post, feel free to let me know and I will update.

I wasn’t sure what to expect but knew we would have fun (pictures here). The event was very lax. Every couple hours Google would talk a bit about App Engine but other than that it was really just a hackathon. They encouraged us to build an application while we were there and walked around patiently answering questions.

We had a great time, despite not knowing a lot of python. Thus far, I’m not a huge fan of python but Google App Engine is pretty sweet. When the limits are removed and they start to support more languages, this thing is going to rock! That said, I’ll keep hacking with python, just so I can use it.

Oh, and obviously one of the high points was the schwag. I love schwag! I left with a full stomach, my thirsts quenched, an American Apparel App Engine T-shirt, a few funny stickers and magnets for the fridge. Speaking of full stomach, the food was awesome. Several different kinds of sandwiches, desserts, salads and drinks.

<script>alert('hi');</script>

Obviously, I got an alert and laughed because I forgot to escape html in the chat body. Then, of course, before I could fix it, he sent through this:

<script>document.getElementsByTagName('body')[0].style.display = 'none';</script>

Quite promptly, my whole screen went blank. Escaping the output in the templating engine I was using was simple, but what about when inserting a new chat using JavaScript? In Prototype, the following works.

$('foo').update("<script>alert('hi');</script>".escapeHTML());

I was using jQuery, though, so I searched around a bit for something that does the same. I’m usually quite deft with Google but I couldn’t find anything. The following is what I ended up with.

$('#foo').append(document.createTextNode("<script>alert('hi');</script>");

Since I couldn’t find it anywhere, I thought I would put it here. Hopefully, it won’t take the next bloke a few hours to figure it out.

Hopefully, by now, you realize that last paragraph should be wrapped in a <sarcasm> tag. It seems like browser support, or rather lack there of, has been a hot topic amongst developers lately. I don’t have much to say but let me present with good and bad examples of handling browser support.

Good Example

Recently, 37Signals announced that they will be discontinuing support of Internet Explorer 6 in their products. The first thing they say in the post is when support is discontinued.

On August 15th, 2008 we will begin phasing out support for Internet Explorer 6 across all 37signals products.

Then they explain the implications of this decision.

If you are using IE 7, Firefox 2 or 3, or Safari, you don’t have to do anything — everything will continue as is for you.

Lastly, they explain why they made the decision.

Supporting IE 6 means slower progress, less progress, and, in some places, no progress. We want to make sure the experience is the best it can be for the vast majority of our customers, and continuing to support IE 6 holds us back.

I don’t know how intentional the order of that information was but it is pretty smart. The first thing people care about is when and what. They get that out of the way to assuage the fears that any may have that a product they pay for can no longer be used. Once they get those immediate needs covered, they discuss the why. People don’t care about the why until they know how it affects them.

IE 6 is an extremely outdated browser. It has performance issues and a newer version has been out since 2006. There is absolutely no reason to support IE6 for web applications anymore. 37Signals made a good decision and properly communicated it to their customers.

Bad Example

With much hype and excitement Apple recently launched MobileMe. Being a fanboy, I fired up my browser and signed up. Once into the app, I quickly became frustrated because nothing I clicked seemed to do anything. I know how the web works but I couldn’t get anything to do anything. Then it hit me. I wasn’t in Safari, I was in a version of Webkit (the engine that powers Safari). I closed Webkit and opened up Safari to find that everything worked. All the problems I had went away. Also, open up the app in IE7 and you get this message.

I can understand not supporting IE6 but IE7? Granted they say you can still use it but that it just doesn’t work as well.

Internet Explorer 7 has known compatibility issues with modern web standards which affect Web 2.0 applications such as MobileMe.

To me that is a total cop out. Maybe IE7 won’t perform as well but it is not so difficult to support that a message needs to be shown and users should be forced to click continue to actually use the app.

On top of the IE7 stuff, there are several little things that bother me about MobileMe. In an effort to make it feel more desktoppy, some normal web expectations were thrown to the wayside such as tab indexes and text selection.

</rant>

Go ahead and drop support for IE6 in your web app. You deserve a break from it, but IE7? IE7 is not that difficult to support. There are several ways to skin a cat (or so I’ve heard) and usually one of them will work in all the major browsers.

Bad Start

About three or four hours in, I realized that things weren’t going the way I wanted and that it was going to take a lot longer than expected to implement. The solution that I had come up with felt complex and was going to require a big rewrite to our theme system. Anytime something feels complex, I go back to the whiteboard because it usually means I haven’t fully thought it through. A bit frustrated, I went back to the whiteboard. This time instead of starting with how I would store the data, I focused on how I wanted to present the data (the interface that the end user would see). Again, you can see my scratching below.

Good Start

As I framed in the interface on the board, the problem started to seem simple and I came up with a new way of doing it that would require no alteration to our theme system or any other existing part of Conductor. Also, this new way makes more sense.

Conclusion

So what am I trying to get at? I think this has taught me the difference between good software and bad software. Bad software starts with the developer thinking how they are going to store the data and technically make it work. Good software starts with the end user. It firsts figures out what will be the easiest way for the user to learn and use the feature and then figures out technically how to do it. I don’t think this is a revelation or that I’ve never built anything in this manner. I am sure, though, that I wasn’t as aware of this before when building applications.

Don’t start technical and force implementation. Start with the interface and let things come naturally.

I was going to wait to launch this until I had finished my own blogging system (which I really haven’t started yet) but couldn’t wait. Chances are there are some bugs and I haven’t finished styling/updating everything yet, but there is enough to check out.

I have some cool ideas for this site and for railstips in the near future. That is all for now, just thought I would give people a heads up.

Whenever I run into a small problem, I Google it and I take the internet for granted. I continue in this pattern until I find myself without a beloved internet connection. It is then that I realize I don’t really know that much. I mean, what do I really know? I guess the answer to that question would be, Google.

Not a problem has arose that I have been unable to find a solution for, using the right keywords on Google. Noticing this tonight, as I sipped on my latte, it got me thinking. How ineffecient would I be if I had to code without the internet? Granted, I am a web developer, so at some point I would need the internet to deploy my work, but what would happen if each time I buried my nose in TextMate, I disconnected from the net.

Would I struggle for weeks until desperation forced me to turn it back on? Would I start to challenge my own brain for solutions instead of quickly finding and implementing a solution someone has blogged about? Would I begin to think outside the box and come up with innovative solutions to problems? Or, would I repeat everyone else’s mistakes when a simple search could have enlightened me? I don’t know. Got me thinking though.

package {
  import flash.display.Sprite;
  import flash.net.*;

  public class GATest extends Sprite {
    public function GATest():void {
      init();
    }

    private function init():void {
      sendToURL(new URLRequest("javascript:urchinTracker('/flash_event_folder/they_clicked_to_watch_a_video')"));
    }
  }
}

Nothing fancy.

#!/usr/bin/env ruby -w

$LOAD_PATH << "#{ENV['TM_SUPPORT_PATH']}/lib"
require "web_preview"
require "open3"

html_header("Building ActionScript File")

if ENV.has_key?("AS_DOCUMENT_CLASS")
	filename = File.basename(ENV["AS_DOCUMENT_CLASS"])
	dir = File.dirname(ENV["AS_DOCUMENT_CLASS"])
else
	filename = File.basename(ENV['TM_FILEPATH'])
	dir = ENV["TM_DIRECTORY"]
end

puts "

Building #{filename} in #{dir}

"

swf = filename.gsub(".as", ".swf")
dir = dir.gsub(' ', '\ ') # fix space in path

puts "<pre>"

Open3.popen3("cd #{dir} && /Applications/flex_sdk_2/bin/mxmlc #{filename}") do |stdin, stdout, stderr|
	puts stdout.gets
	if error = stderr.gets
		puts "\n\n" + error
	else
		system("open #{File.join(dir, swf)}")
	end
end

# system("cd #{dir} && /Applications/flex_sdk_2/bin/mxmlc #{filename}")
puts "</pre>"

html_footer

Assumptions

1. You have the free Flex SDK
2. The Flex SDK is installed in your Applications folder (ie: /Applications/flex_sdk_2/bin/mxmlc)

Two Ways of Using

1) If you simply have a file open and you hit ctrl-b, it will create a swf of the same name in the same directory and then open it using Finder. Simple enough.

2) If you have a TextMate project saved with multiple ActionScript files, you can set a Project Specific Shell Variable named AS_DOCUMENT_CLASS equal to the full path to your main document class (ie: /Users/nunemaker/flash/carousel3/classes/Main.as). If that environment variable is set, no matter what ActionScript file you have open in your project, the main document class will be the only file built when you hit ctrl-b.

Screenshot

The code below is all it takes to create the boring drawing app pictured above.

package {
	import flash.display.Sprite;
	import flash.events.MouseEvent;

	public class DrawingApp extends Sprite {

		public function DrawingApp() {
			init();
		}

		private function init():void {
			graphics.lineStyle(1);
			stage.addEventListener(MouseEvent.MOUSE_DOWN, onMouseDown);
			stage.addEventListener(MouseEvent.MOUSE_UP, onMouseUp);
		}

		public function onMouseDown(event:MouseEvent):void {
			graphics.moveTo(mouseX, mouseY);
			stage.addEventListener(MouseEvent.MOUSE_MOVE, onMouseMove);
		}

		public function onMouseUp(event:MouseEvent):void {
			stage.removeEventListener(MouseEvent.MOUSE_MOVE, onMouseMove);
		}

		public function onMouseMove(event:MouseEvent):void {
			graphics.lineTo(mouseX, mouseY);
		}
	}
}

You can try out the example swf file here. Just click on the link and use your mouse to draw as you would in Microsoft Paint.