Anyway, I think this would work best as a step by step guide. I’ll go through the steps I’ve had to learn about; you may want to skip over some if you’re already know what you’re doing in them.

1. Build your player in Flash

I downloaded the Adobe Flash trial for this. You’ll want to create a stage that is not much wider than 500 pixels. I went with 504px. What you’re going to be playing depends entirely on you. My purpose was simply to play audio files (MP3s), so I used Sound and SoundChannel to control that. The audio file to be played was requested with an URLRequest object.

If you want a more thorough introduction on how to set up a simple sound player, this video from 2008 is still a good starting point, even with the latest version of Flash (12, CS6):  Build Simple Sound Player: Flash Tutorial AS 3.0

Using parameters

The important part about the ActionScript is using parameters. Parameters will be passed to the eventual SWF through the querystring, that is, the bold part in this URL: http://example.com/my-player.swf?param=value&otherparam=value

In ActionScript (3), you can access these variables the following way:

loaderInfo.parameters.parameterName

To check if a parameter is actually present:

loaderInfo.parameters.hasOwnProperty('parameterName')

This way you can use default values for parameters:

var myParam = loaderInfo.parameters.hasOwnProperty('myParam') ?
    loaderInfo.parameters.myParam :
    'defaultValue';

Since hasOwnProperty returns a boolean value (true or false), this statement assigns either the value of myParam from the querystring, or 'defaultValue' if no such parameter was specified, to the myParam variable. It uses a ternary operator.

2. Export the SWF file and include it in your website’s assets

This is fairly straightforward. You’ll want the swf to live someplace where it’s directly accessible. I let mine live in the document root directory.

3. Add Open Graph meta tags to the page

This is where the Facebook magic happens.

Facebook will read this Open Graph data when your page is being linked to, and extract the Flash file for embedding. These are the ones you will need:

og:video

Full URL to the SWF file, including parameters for this page:

<meta property="og:video" value="http://example.com/your-player.swf?param=value&otherparam=othervalue">

og:video:width, og:video:height

Specify the dimensions of your Flash movie:

<meta property="og:video:width" content="504">
<meta property="og:video:height" content="115">

og:video:type

The mime type of the file:

<meta property="og:video:type" content="application/x-shockwave-flash">

og:url

Something that might be optional, but is highly recommended:

<meta property="og:url" content="Canonical URL to this page">

The canonical URL is the best URL to reach this piece of content on your website. (In case there are multiple URLs that get you there.)

I’d advise you to go read more on The Open Graph Protocol, as well as having a read through David Walsh’s article on Open Graph meta tags for more magic you can implement with these.

4. Set up SSL (sort of optional)

The one catch about embedding stuff on Facebook is https. Many users are browsing Facebook with “secure browsing” on by default. The result is that your Flash component won’t get loaded if it doesn’t live at an https:// URL as well.

If you have an SSL certificate installed for your domain, you can make your Flash embed work for https users as well, by simply adding the following meta tag:

<meta property="og:video:secure_url" property="https://example.com/your-player.swf?param=value&otherparam=othervalue">

If you need help setting up SSL, you can consult Linode’s library, they have a lot of useful documentation.

• Obtaining a Commercial SSL certificate explains how to do the server-side portion of setting up your certificate and key.
• SSL certificates with Nginx explains that too, as well as how to use it with your Nginx configurations.
• Apache SSL Guides lists articles for various operating systems, on how to set SSL up with Apache.

I hope that makes it a bit easier for people who want to get this stuff implemented in the future. I definitely had a hard time googling it all together.

Before diving into specifics, let’s talk about just what I mean.

Loose coupling

When the code base for a project gets sizeable, one thing that can make it a nightmare to work with is tight coupling. When modules are tightly coupled in a project, it means that changing one method in module A may require you to change the way certain things are implemented in module D, F and G. In order to make any modifications, you need to be well aware of how other modules rely on the module you wish to modify.

Since having a single module in your head can be taxing enough for the mind, considering basically the whole project when making a local change is awful; oversights are bound to occur.

To ensure you do not need to wrap your head around the entire code base at all time, you’ll want to make sure your modules are loosely coupled. You can safely change the modules’ internals without having to worry about how other modules have to interact with this module. You need to consciously engineer your modules to be entirely agnostic of the inner workings of others.

You’ll find that employing this method makes it much less of a daunting task to change some functionality around.

Bring on event-driven programming

Event-driven programming is a fairly simple pattern where component subscribe to events and trigger them. A variant of the pattern is the observer pattern; the difference however lies in where the event dispatching happens.

In an observer pattern, you can register observers (subscribers) to event a certain module emits. This way you can subscribe to, for example, an after-save event, which is emitted every time an object’s data is saved. The observer subscribing to this event will be triggered every time that happens, and a function can then be run.

In this case, we move the subscribing facilities away from the modules to a dedicated event dispatcher module. This provides one central location where modules sign up to be notified when a certain event occurs, as well as where modules go to broadcast an event they want to make the application aware of.

Doing this, all each module is concerned with if it comes to communicating with the rest of the application is 2 uniform things: Emitting events and responding to events emitted elsewhere. The modules do their thing, throw out some information whenever there is something that may concern the rest of the application, and they remain alert for external events pertaining to the module in question.

Responsibilities of the event dispatcher

The event dispatcher module that drives this whole pattern has only few responsibilities:

• Keeping track of event subscriptions
• Dispatching incoming events to all the subscribers of that event

Implementing an event dispatcher in JavaScript

A really useful feature of JavaScript is that functions are objects, which can be passed around like any other object can. You can therefore pass functions as parameters to other functions, often referred to as callback functions.

Callback functions are functions that will be called after certain execution is finished. In this case, we will be calling back functions when certain events occur.

Our event dispatcher object will need at least two publicly accessible functions: subscribe(eventName, callback) and trigger(eventName, data).

These subscribe and trigger functions will work with a shared subscribers object, which will be a hash of event names and arrays with callback functions. A subscription list could look like this:

{
	"PostSaved": [
		callbackFunction,
		callbackFunction,
		callbackFunction
	],

	"PostDeleted": [
		callbackFunction
	]
}

The subscribe function takes an event name and a callback function. It will have to first find out whether or not there are any existing subscribers for this event, or if it needs to start a new list to add to. Then the callback function gets added to the array associated with the event name.

eventSubscriptions is an object like the example above, declared outside the subscribe function.

function subscribe(eventName, callback) {
  // Retrieve a list of current subscribers for eventName (if any)
  var subscribers = eventSubscriptions[eventName];

  if (typeof subscribers === 'undefined') {
    // If no subscribers for this event were found,
    // initialize a new empty array
    subscribers = eventSubscriptions[eventName] = [];
  }

  // Add the given callback function to the end of the array with
  // eventSubscriptions for this event.
  subscribers.push(callback);

}

Comparing the type of eventSubscribtions[eventName] (subscribers) with undefined lets us find out whether this event was subscribed to before. If that isn’t the case, a new array is created at this location, with the [] syntax.

Then we simply push the function callback onto the end of this array.

The trigger function will iterate over this array of callbacks, and call each function with passed data as arguments:

function trigger(eventName, data, context) {
  var
    // Retrieve a list of subscribers for the event being triggered
    subscribers = eventSubscriptions[eventName],
    i, iMax;

  if (typeof subscribers === 'undefined') {
    // No list found for this event, return early to abort execution
    return;
  }

  // Ensure data is an array or is wrapped in an array,
  // for Function.prototype.apply use
  data = (data instanceof Array) ? data : [data];

  // Set a default value for `this` in the callback
  context = context || App;

  for (i = 0; iMax = subscribers.length; i += 1) {
    subscribers[i].apply(context, data);
  }
}

Once again we check whether there are any subscribers for this particular event. If there are none, execution of trigger is halted through an early return.

For the Function.prototype.apply function, we need our data to be an array. The value is either wrapped in an array, or left as is, if it already was an array.

Function.prototype.apply allows passing an object to be bound to this inside the callback function. This is referred to as context in the parameters of trigger. The parameter is made optional by defaulting to App, which is an object declared outside this function’s scope. I use App as the general namespace for my application, which will be clearer in the full example.

After that preparation is done, we iterate over the subscribers list with a simple for loop, and apply the context (this) and data parameter to every callback function that was subscribed to this event.

The end result could look something like this, as an object in the App namespace:

(function (App) {
  "use strict";

  var eventSubscriptions = {};

  App.eventDispatcher = {

    subscribe: function (eventName, callback) {
      // Retrieve a list of current subscribers for eventName (if any)
      var subscribers = eventSubscriptions[eventName];

      if (typeof subscribers === 'undefined') {
        // If no subscribers for this event were found,
        // initialize a new empty array
        subscribers = eventSubscriptions[eventName] = [];
      }

      // Add the given callback function to the end of the array with
      // eventSubscriptions for this event.
      subscribers.push(callback);
    },

    trigger: function (eventName, data, context) {

      var
        // Retrieve a list of subscribers for the event being triggered
        subscribers = eventSubscriptions[eventName],
        i, iMax;

      if (typeof subscribers === 'undefined') {
        // No list found for this event, return early to abort execution
        return;
      }

      // Ensure data is an array or is wrapped in an array,
      // for Function.prototype.apply use
      data = (data instanceof Array) ? data : [data];

      // Set a default value for `this` in the callback
      context = context || App;

      for (i = 0; iMax = subscribers.length; i += 1) {
        subscribers[i].apply(context, data);
      }
    }
  };
}(this.AppNamespace));

Assuming every module in your App has a similar closure wrapped around it, you can then access the event dispatcher from anywhere through App.eventDispatcher.

Implementing the event dispatcher in your modules

I start the closure of a module with a shorthand reference to the event dispatcher, usually simply events. I make a habit of grouping the subscribe calls together on bottom of the module, after all internal functions have been declared and whatnot. This gives you a single point of control to manage the event subscriptions in the module.

Event triggers, however, will be strewn through the functionality of the module, wherever they’re appropriate. It helps to add a @triggers eventName to the doc-blocks of your functions to more easily see what events are being triggered in them.

A quick example will make this much clearer:

// Transport UI module for a music player
(function (App) {
  "use strict";

  // Local reference to the dispatcher
  var events = App.eventDispatcher;

  function playStarted() {
    // Update the UI to indicate the player is playing
  }

  function stopped() {
    // Update UI to indicate player is stopped
  }

  /**
   * Skip the current track and play the next one
   * @triggers UI.Transport.SkipTrack
   */
  function skipTrack() {
    events.trigger('UI.Transport.SkipTrack');
  }

  /**
   * Volume was changed through the interface, trigger event
   * @triggers UI.Transport.SetVolume
   */
  function setVolume(vol) {
    events.trigger('UI.Transport.SetVolume', vol);
  }

  // Subscribe to external events
  events.subscribe('Player.PlayStarted', playStarted);
  events.subscribe('Player.Stopped', stopped);

}(this.AppNamespace));

As you can see, it’s rather simple to work with. For passing callback functions, I’ve simply specified the name of functions declared earlier, however, you can of course write them as anonymous functions right in the subscribe call:

events.subscribe('UI.Transport.SetVolume', function (newVolume) {
  // Code to set the volume in the core player
});

Stupidly simple and effective debugging

If an application does all its inter-module communication through this event dispatcher object, it becomes very easy to debug. When I was working on my project, I found that most of the bugs I encountered were related to inter-module communication, as I could properly focus on what happened inside each module. After adding some simple logging facilities to the event dispatcher I could easily trace the majority of bugs back to miss-spelling an event name and forgetting to trigger events some modules were subscribed to.

I added some simple logging to the trigger function; it lets me know whenever an event is triggered, and to how many callback functions it is being dispatched. The clever part here is that it can also let you know if there are no subscribers for the event being triggered.

If a tree falls in a forest and no one is around to hear it, does it make a sound? Spoiler: It doesn’t, since the definition of sound specifies that it isn’t considered sound if no-one’s around to hear it.

I digress. With this logging, an event with no subscribers will still make a sound in your console, and it will let you easily correct the problem.

The new trigger function will look something like this:

function trigger(eventName, data, context) {
  var
    subscribers = eventSubscriptions[eventName],
    i, iMax;

  if (typeof subscribers === 'undefined') {
    // No list found for this event, return early to abort execution
    console.log('[EventDispatcher] trigger: no subscribers for event "' + eventName + '"');
    return;
  }

  data = (data instanceof Array) ? data : [data];
  context = context || App;

  for (i = 0; iMax = subscribers.length; i += 1) {
    subscribers[i].apply(context, data);
  }
  console.log('[EventDispatcher] trigger: event "' + eventName + '" dispatched to ' + subscribers.length + ' subscribers, with data: ', data);
}

This is a simplified version of what I actually used, as the real version includes checking whether console.log is available or not. My module also allowed toggling logging on or off, as well as excluding arbitrary events from logging. My application had certain events that were triggered very frequently, so it would be hard to see the events I was interested in through the stream of other events.

Conclusion

If you’re interested in my final implementation, you can view the file in my step-sequencer repository. It also makes use of a priority sorting, which has only been briefly mentioned in this post. Another new thing in that version of the dispatcher is the ability to subscribe to any number of events in one subscribe call.

I started employing this pattern as a bit of an experiment at first, but as I progressed through the project, I was time after time just delighted by how easy it made things. I’m pretty sure the logging has saved me many hours of hunting down bugs. Let me know how you’re implementing it, and do let me know of any improvements you can think of.

I intended to do something about this whole problem, in the form of a side project: a todo-list managing web application where you could label todo items for priority, assign people, and so forth. I was pretty far into the website design and initial front-end coding when I first heard about Trello. It took me only a few days to realize that the people behind Trello had done a much better job of it than I ever would. I abandoned my own project shortly after.

So what is Trello?

Trello lets you organize “cards” in “lists”, on “boards”; that may sound a little bit abstract, so let’s expand a bit on that.

A board on Trello consists of one or more named lists. It is an environment where you keep track of a certain thing, collect information on a certain thing, or simply where you manage something. Where you keep something organized.

A “list” is no more than a named column where you keep a bunch of cards. Such a list can indicate the progress status of the items within, or it can be treated as a  category. The purpose of a list depends entirely on what you are organizing.

A “card” can be anything you want it to be: a feature for a piece of software you’re working on, a book you want to read, a holiday destination you’re considering, you can come up with plenty more, I’m sure.

This screenshot gives a bit of an overview (full size):

Trello’s interface lets you easily create new cards and move them around, effectively making organization a painless experience. It is filled with very useful features that just makes management more effective. Examples include checklists on cards, the ability to attach files to cards, custom color-coded labels, due dates, I could go on.

While it is great for personal use, a lot of Trello’s power is in the way you can have multiple people being part of a board. This lets you assign people to cards to indicate they are involved with a certain thing. More importantly, you can leave comments on cards, allowing for discussion on the exact topic at hand, which is described in the top area of the card. When a card is moved around, all relevant discussion just stays with it wherever it goes.

Use cases

Keeping a reading list

A simple use case is keeping track of books you want to read, are reading, and have read. In my case, I keep a reading list with a friend of mine. We regularly recommend books to each other in the “To read” list. For each book we create a new card, and usually include an Amazon link where the book can be purchased. We then assign each other to these books to indicate “you should read this”. It works pretty well for me when finishing a book; “what shall I read next” is simply answered by having a look at the board.

Any sort of simple “to do”

The reading list is really just a variation of the to do theme, which is probably the most common use case too. The developers certainly seem to think so, as the default layout for a board is To do, Doing, Done. I keep a board named “Creative”, where I line up ideas for blog posts, as well as music to write. I also have a “Development/Hack ideas” board, which slightly expands on the to do format: it consists of Ideas, Investigating, Doing, and Done.

Howtos

A recent use case I came up with is collecting little howtos. Things you infrequently have to do, and could do with reminded for their procedures go here. (My use case was setting up an email forwarder on my VPS). You can create a few categories as lists, name your howtos well in the card title, and add the instructions in the description. That way your set of instructions is just a few clicks away next time.

Software development

The biggest use case I can think of is software development. At Digitally Imported we make heavy use of the tool (and that’s still an understatement). We use a number of boards for our process: Development, user story preparation, defect triage, and roadmap.

Development is the most active one which we discuss in a Skype meeting every day. Every feature, bug to fix, piece of design work or what have you goes through 5 stages: Ready, Building, Accepting, Ready to deploy and Released.

In Ready, items are ready to be picked by a team member when they have space for it, that is, time to work on a new item. That team member then moves the card from Ready to Building, where it stays until all acceptance criteria of the item have been met. It then moves to Accepting, where other team members test and scrutinize the work completed, discussing any further changes required for it to be considered done.

From accepting the item moves, if applicable, to Ready to deploy, where it stays until it gets deployed to the target environment (which is usually one of the websites or a mobile app market). Once it is deployed to its target environment, the card retires to Released. The item is then considered to be done.

In User story preparation, items are prepared and fleshed out (specified if you will). They progress from simple ideas to properly outlined features / changes, before getting moved on to Ready on the Development board.

In Defect triage, any bugs come in, either from users, or from the team. They go from Inbox to Investigating (which speaks for itself), get a proper priority label, and then move on to Accepting/On hold, or in high priority cases, go straight to the Development board.

On the roadmap, the larger scale company projects are organized, and feature sets collected to give a broader overview of progress.

It’s free!

One of the most awesome parts of Trello that almost makes it too good to be true is that the whole thing is completely free for anyone to use. There are no premium features or limitations for free users, you simply get to use this product for free. No begging for donations or plastering everything with adverts either. It’s simply an un-monetized product by an awesome company. Fog Creek Software make their money through other venues, which allows them to invest in this tool they heavily use themselves, while making it available for free for everyone else.

In conclusion: Trello is pretty friggin’ awesome, making organizing just about anything you can think of a breeze. If you’re trying to get anything done or want to get more structure in your life, I suggest you go give it a try right now. You will not be disappointed, and you will get your stuff done.

There are some tracks which have the amazing quality to completely take over your awareness as you really get into them. Here are some that do that for me. They range from old hits to obscure stuff, from chill-out to hard rock, and are in no particular order.

1. The Extreme – Daydream

This wonderful chill-out tune has a deep bass-line that instantly drew me in the first time I heard it on Digitally Imported’s Chill-out channel channel. The lush instrumentation accompanied by a perfectly fitting break beat later on takes you through a dreamland of relaxation. It is all over the place in a big mess of harmony.

2. Phil Collins – In the Air Tonight

In the Air Tonight [sadly only 240p quality for the studio version I want to showcase] is more of a classic. It carries on slowly and gives the impression that something’s going to happen, which is the case near the end of the song. It just has this sublime pad and soft drum work going on throughout, along with subtle spacial effects on the vocals. The cool part about this track is that you tend to turn it up because the longest first part is relatively quiet. Since the song isn’t overly compressed as a lot of more recent music is, when the drums come in, they are rather hard-hitting. Also, after a few listens, you will find yourself air-drumming when that part kicks in.

3. Drugstore – Old Shoes

I have not heard the original of this Tom Waits cover, but this version I found on one of my parents’ CDs years ago is certainly a jewel. It morphs from very calm parts with light re-verb-y guitars into heavy parts with distorted shoegaze-like guitar work. The kick-off is usually paired with a little drum fill-in, after which all the guitars break loose again. The result is a wall of a sound which leaves no room for any other thoughts if you’re playing it loud enough.

4. The Cranberries – Zombie

This classic massive hit still manages to give me goosebumps after all the times I’ve listened to it. Somewhat similarly to Old Shoes, it has sections with guitar and bass all over the place, blowing you away. This, paired with a powerful voice and equally powerful instrumental parts, just works. The transition to the last part is really smooth and finishes it off beautifully.

5. Papa Roach – Between Angels and Insects

While this hard rock song by Papa Roach has (explicit) laden lyrics about money and materialism, that’s not the reason I listed it here. I have difficulty describing the part when it kicks in. It just take you over. It’s as if the full sound spectrum is being pumped in your ears, in a good way. Definitely the heaviest one of the bunch.

6. The Me in You – Low Battery

It’s a shame that the album version of Low Battery is not available on Youtube, as that one has a longer outro with more of the light guitar and piano goodness. The Me in You are a very new Belgian band. I got their debut album “Forgotten Clothes” as a birthday gift, and I’ve played through it many, many times since. The whole album is absolutely great, but this one is my favourite of the bunch. It’s a very mellow sounding track which takse a few listens to really appreciate the attention to detail, and how well everything works together. I suggest you go buy the album, it’s more than worth it.

There are probably more tracks I can list here, but these are the ones I recently got into again. I will probably write some more posts about music I particularly love in the future.

It works with a callback function that takes index/key and value as parameters. This callback function is executed for every item in the collection passed.

The benefit of using this is that you have very readable code; most programmers will intuitively know how it works because of the familiar collection, index and value interface.

To the code!

Preparation and parameter checking

We start, as we should, by declaring the local variables. i, iMax and key are used in the iteration later on, collectionType stores what we’re dealing with.

Validating the callBack parameter

We check whether callBack is an actual function, as this whole function is useless if nothing can be done while iterating.

Validating the collection

The first switch construct determines what type of collection we are dealing with. Normally you would use typeof collection here, but JavaScript reports ‘object’ when collection is an array (because arrays are objects). As a result, we have no way to differentiate between objects and arrays through typeof.

To get around this, we use toString, from the Object prototype. We use Object’s toString method specifically, because it’s only one that actually gives us the information we need; if we were to use collection.toString(), we’d get “[object Object]” for an object, “a,b,c” for an array, and “hello world” for a string—not very helpful.

Object’s toString yields “[object Object]“, “[object Array]” and “[object String]” for the aforementioned examples; definitely useful for what we’re trying to achieve. To call Object’s toString method on non-Object variables, we use Object.prototype.toString.call(collection)

If through all that it turns out collection is neither Object, Array or String, an error is thrown, and the function execution terminated.

The iteration

Based on collectionType we just determined, we now iterate over collection. Again we use the readable switch statement.

Array and String

Arrays and strings behave much the same as far as iterating them goes. As you access an element at index i in an array using myArray[i], you access the character at index i in a string through myString[i]. Because of this, we can use the exact same for loop to iterate an array and a string, hence the fall-through in the switch construct.

EDIT: People on IRC and Reddit have pointed out that string[index] is not supported belwo IE7 or IE8, so I’ve updated the gist to use string.charAt(index) instead, and removed the switch fall-through.

For every item or character in that array or string, callBack is executed with the index and value paramaters.

A note on for loops

There is a tiny note-worthy bit in the for loop code. I believe most people would initialise their for loops like this (at least I’ve done it this way for years):

var i = 0; 

for (i = 0; i < collection.length; i += 1) {
    // ... code ...
}

There is something sub-optimal about that approach; every time the condition (i < collection.length) is checked—before every iteration, the length property of collection is accessed. This can be a performance bottleneck, as the length needs to be recounted every time, since it is possible that it has changed since the last iteration.

Instead, store the length is another variable on initialisation, then just compare to the variable in the condition, like this:

var
    i,
    iMax = 0;

for (i = 0, iMax = collection.length; i < iMax; i += 1) {
    // ... code ...
}

Objects

Iterating over the key/value pairs in an object is another story. The for...in loop is available, but there is a little caveat to it. Objects inherit properties and methods from the prototype chain. Prototypes are a whole other story, but suffice to say that we don’t want to include those properties and methods in our iteration.

Luckily, there is a function in the Object prototype that lets us figure out whether a property or method is part of that object itself or part of its prototype chain. As you can see, all we have to set up is a for...in loop, then in that loop check whether the object owns the property by name key. If that is the case, callBack is called with key and value parameters.

Return

Since the function does all its magic through the callBack function, it does not need to return anything. Hence, we return null.

Examples

The code above includes a few examples. I’ll add some other examples to show what each forEach use is equivalent to using regular loops.

Array example

Using forEach:

var myArray = ["a", "b", "c"]; 

forEach(myArray, function (value, index) {
    console.log(key + ": " + value);
});

Output:

0: a
1: b
2: c

Using normal for loop:

var
    myArray = ["a", "b", "c"],
    i = 0,
    iMax = 0;

for (i = 0, iMax = myArray.length; i < iMax; i += 1) {
    console.log(i + ": " + myArray[i]);
}

Output:

0: a
1: b
2: c

Object example

Using forEach:

var myObject = {
    "Douglas": "Adams",
    "Robert": "Heinlein",
    "Isaac": "Asimov"
}; 

forEach(myObject, function (value, key) {
    console.log(key + ": " + value);
});

Output:

Douglas: Adams
Robert: Heinlein
Isaac: Asimov

Using for...in and hasOwnProperty:

var
    myObject = {
        "Douglas": "Adams",
        "Robert": "Heinlein",
        "Isaac": "Asimov"
    },
    key = '';

for (key in myObject) {
    if (myObject.hasOwnProperty(key)) {
        console.log(key + ": " + myObject[key]);
    }
}

Output:

Douglas: Adams
Robert: Heinlein
Isaac: Asimov

Beware of HTMLCollections

I’ve written this to be environment-agnostic (save for the console.log calls in examples). If you want to use this with results from document.getElementsByTagName(), it won’t work as it is, reason being that getElements… returns not an [object Object], array or string, instead it returns [object HTMLCollection], which is not catered for. You can adapt forEach to also work with HTMLCollections, or you can convert your HTMLCollections to arrays. I hope that saves some people headaches.

Update (same day)

People on IRC and Reddit have pointed out the standard value, index array order from the spec, so I’ve updated the code to use that order instead. They have also pointed out that < IE7/IE8 does not support string[index], so that’s been updated to use string.charAt(index) instead.

Here’s a quick list of those that I’m aware of—in no particular order.

• SelectBoxIt - Github
  Requires jQuery 1.6.1+ and jQueryUI Widget Factory 1.8.19+
• jQuery SelectBox plugin – Github
  (Obviously) requires jQuery, minimum version not listed.
  Has events you can tap into with callback functions
• Chosen – Github
  Requires jQuery 1.4+ or Prototype 1.7+
  Neat features like search input for long lists
• jQuery UI Autocomplete (combobox)
  Included in jQuery UI
  Focussed on searching rather than the dropdown

This post is mostly as a reference, so I don’t need to look up all the options (no pun intended) every time this situation arises. I hope it can help you quickly select (pun definitely intended this time) which one’s best for you.

Michhimself.com used to be hosted by one.com, the first web host I ever paid for, which I registered with in 2009. Back then, the simple PHP/MySQL hosting with FTP access was great, but I’ve since moved on.  Since it was so-called ‘shared hosting’, it meant that multiple websites would run on the same server; meaning that the performance of my site would depend on the load caused by others.

Now I’ve moved on to a VPS (Virtual Private Server) at linode.com, where I get full root access over the machine. You know what that means: a LOT more freedom to play with. I got to install the web server software myself, as well as PHP, MySQL and a bunch of other things. I’m even running an IRC bot on the thing. Needless to say, I no longer need to use FTP to access the files on this server; I just use SSH, which is more secure, and seemingly faster as well. Have I mentioned that Linode is fabulous?

Last week however, I purchased my first DSLR after trying and getting outbid on ebay for about a week. I now have a Nikon D40 with the kit 18-55mm lens, and I’m loving it. Compared to the Coolpix 8700, it is orders of magnitude better at guessing settings for correct exposures.  Since it doesn’t have to move out a lens on start-up, it’s instantly ready to shoot, and doesn’t waste energy on motors (other than the auto-focus motor in the lens). I love how it takes your photo the moment you press the shutter button down, rather than half a second after. It makes me feel much more confident to go for certain shots than I normally would be.

The camera automatically goes in stand-by mode if you’re idle for a while, but is instantly ready to go for it again. This makes it fun to walk through the city with the camera just on all the time, ready to shoot anything you see.

In conclusion, it seems like I’m going to have a lot of fun experimenting with what this camera will let me do. Eventually I’ll most likely try some other lenses as well, which is something I’ve been looking forward to with this kind of cameras.

Here’s a little set of photos I’ve taken around Southampton, by day and by night.

You can view the full set on Flickr.

Form fields can usually do with some more information on what you are supposed to fill in. Examples include valid user name rules, desired date/time format.

The problem

On one hand, you want your users to know what they’re supposed to do, as confusing your visitors easily leads to a dramatically decreased conversion rate. On the other hand, you want your forms to look clean and minimal, so your visitors are not bombarded with information. If you show information by every field on your form, it quickly gets cluttered, and that’s exactly what we want to avoid.

The solution

Simply hide the elements containing the help text until they are needed. When a user focuses on a field, the relevant information shows up. This may sound like something you would solve with the onfocus and onblur events, but you can actually accomplish it with CSS.

Assuming you have an element with an info class right after the input element, you just use the :focus pseudo-selector in an adjacent sibling selector.

Example

For the example, I’ve come up with a simple sign-up form:

<form action="/user/signup" method="post">
    <fieldset>
        <div>
            <label for="form_username">Username</label>
            <input type="text" id="form_username" name="username">
            <div class="info">A valid username consists of letters (a-z) and/or numbers (0-9).</div>
        </div>
        <div>
            <label for="form_email">Email</label>
            <input type="text" id ="form_email" name="email">
            <div class="info">We will send you an email to validate your account.</div>
        </div>
        <div>
            <label for="form_password">Password</label>
            <input type="password" id ="form_password" name="password">
            <div class="info">Your password should be at least 6 characters long.</div>
        </div>
        <div>
            <label for="form_passwordretype">Repeat Password</label>
            <input type="password" id ="form_passwordretype" name="passwordretype">
            <div class="info">Please repeat your password to ensure you haven't made any mistakes.</div>
        </div>
    </fieldset>
</form>

To which we add this little bit of CSS that makes it all work:

div.info {
    display: none;
    /* Make sure the info element is initially hidden */
    color: #777;
    font-size: 12px;
    margin: 2px 0;
    text-indent: 1em;
}
input:focus + div.info {
    /* This selector selects the div.info that comes right after the focused input */
    display:block;
   /* Make the element visible */
}

With some minor CSS additions that gets you this (Try clicking the input fields or tab through them)

(View on JsFiddle)

Now get creative!

The example shown above is the most basic form of this technique. With some fancy CSS positioning, you could use a sidebar to display the info of the currently focused input, and that’s just one idea.

I hope this can help some folks create more attractive forms. Be sure to show me your implementations of this technique, and as always, if you have any questions, don’t hesitate to ask.

The MVC way to go for this would be having a controller that gets called when the URL for viewing a thread is requested. The controller would get an instance of a ForumThread Model. The Model describes the properties of a ForumThread and deals with related data (Forum posts, which would be another Model), and database operations, plus any additional behaviours. The data retrieved from the Model instance then gets passed on to a View, which takes care of sticking all the data in HTML. This way interpreting the request, dealing with data and displaying data is nicely separated.

Frameworks (FuelPHP)

This whole design pattern is all a very beautiful way to structure your web applications, however, if you have to set that all up from scratch, it would get very tiresome to get right. That’s where frameworks come in. The first PHP framework I got in touch with is FuelPHP, a quite young framework running on PHP 5.3+. According to their front page, it is based on the best ideas of other frameworks, with a fresh start. As this is the first framework I’ve used, I can’t really judge that former part, but by googling certain concepts used, I’ve found out that many of them are quite commonly accepted ones.

In my experience, it’s very simple to set up some new models and relate them, to quickly get going without all the design hassle you’d normally have. For the most part, you don’t get to write the database queries yourself, which is a good thing.

Validation

An unrelated part of FuelPHP (as in, it doesn’t really have anything to do with MVC) is its validation functionality. FuelPHP makes it really smooth to validate input. There are multiple ways to go for it, but my preferred way is to actually specify the validation rules in a Model’s properties array, then setting up a Validation Observer before save.

If that sounded confusing: An observer is a class that has a number of event-named methods. In a Model you can refer to an observer class and tell it which events to observe. FuelPHP takes care of the rest: When you let your model save its data to the database, any observers with ‘before_save’ enabled will be executed first. In the case of a Validation observer this will first run all the validation rules specified in the properties set-up, and throw an error (preventing the actual database save) in the case that some data does not validate.

Having gone through setting up a whole bunch of nested ifs for data validation in the past (Believe me, it’s tiresome and not elegant at all), I find this way of setting up validation simply beautiful. It’s all down to adding a few strings to an array, and it’ll validate. The way the framework is built allows for easy adding of your own validation functions too, so other than elegant, it’s very flexible.

Adopt FuelPHP!

Currently, the community surrounding FuelPHP is still fairly small, which means it’s often quite hard to google FuelPHP-related things. I would very much like the community for this framework to grow, as I feel it has a lot of potential. Their website (mostly docs section) is still quite incomplete in places, but that should improve as the community grows.

More information

I’ve only briefly touched upon many subjects in this post, so if I sparked your interest, these couple of links should get your started.

• Wikipedia article on Model-View-Controller
• FuelPHP homepage
• FuelPHP documentation
• Creating a Model in FuelPHP
• Using Observers in FuelPHP

Obviously, if you are really interested in trying it out, I suggest downloading it and playing with it! You can get support on their forum and in their IRC channel.