A fancy new one-page website has been circulating Twitter and Reddit of late, serving as an easy into to Git. Git: The Simple Guide helps you install the software, create a repository on your local computer or check out an existing remote one, and start using Git.

It’s a good tutorial, and the design looks great. I like the differently-colored segments with the large text and rounded styling on the <code> elements. (The page is actually hosted on GitHub Pages, which seems fitting, given the subject.)

While it does make sense to pay for a tool if you use it extensively for commercial purposes, you may not be ready to if you’re an indie developer just beginning a project that won’t hit the shelves for awhile. Also, if you’re using it for versioning and deploying websites, you may not want to have all of your source be public.

GitHub’s business model is primarily the sale of premium accounts with varying numbers of allowed private repositories, starting at $7/month for five private repositories and up to one collaborator. It’s not a bad deal at all, as GitHub is by and large open source projects, but you may still want to find a better offer. Fortunately, there are a couple of solid competitors.

BitBucket

BitBucket is very much like GitHub, functionally. It has the same sort of social collaboration tools, and most of the same features. But that’s where the differences end. Their pricing scheme is to give you all of the repositories you could possibly want, both public and private, while charging to add extra collaborators to your private repositories. You get five for free, and can upgrade to ten for $10/month, twenty-five for $20/month, etc.. Oh, and they support both Git and Mercurial.

I’ve been using BitBucket lately for some of my projects, and it’s been great so far.

Beanstalk

Beanstalk only does private repositories, offering plans limited by disk space and the number of repositories, as well as the number of authorized users. Aside from their 100MB single-repository trial plan, their offerings start at $15/month for 3GB of space, 10 repositories and 5 users. One of their unique selling points is their integration with tools like Basecamp and Lighthouse. They also have quite a few corporate customers.

This is great for two scenarios. You can use it to experiment with a bit of CSS or JavaScript for brainstorming purposes, or you can use it if you need to ask someone for help. (It’s a lot easier to figure out what’s going wrong with someone’s code or markup if you can jump right in and start messing with the code.) Chris Coyier (of CSS-Tricks) uses it all the time to show off CSS experiments that will likely be used in future posts of his.

<a href="https://twitter.com/share" data-count="vertical" data-via="redwall_hp">Tweet</a>
<script type="text/javascript" src="//platform.twitter.com/widgets.js"></script>

I did too, and after a bit of Google searching, I found a post by John Resig (the creator of jQuery) that explains that they’re something called data attributes.

A new feature in HTML5, they provide a way to embed data in an element and access it from a script. (An accompanying JavaScript API makes it very easy to retrieve the data.)

HTML 5 data- Attributes [John Resig]

But what if the servers Google has hosting it went down for some reason? Given Google’s track record, it’s not likely to be an issue, but it’s a good point. Fortunately, you can easily reference a backup. You can have a copy of jQuery on your server, and use a little bit of JavaScript to load it only if the Google one doesn’t load for some reason.

This little snippet, found in HTML5 Boilerplate, will do just that:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/libs/jquery-1.6.4.min.js"><\/script>')</script>

This should even work with WordPress, if you put the second script line right before the </head> tag in your theme.

Getting Started

First, create a new View-based application. Give it a memorable name like “TwitterXML.”

Now that you have a clean slate to work off, let’s rename some classes. I find Xcode’s default naming scheme a bit silly, with the way it prepends the project name to each file. I think the Application Delegate should be called, simply, AppDelegate.m instead of the needlessly long TwitterXMLAppDelegate.m. However, you can’t just rename the file to whatever your preference is, as that would break things.

You can rename a class project-wide, file and all, by using the Refactoring tool. You can call it up by right-clicking on the class name in the implementation file and choosing “Refactoring” from the resulting menu.

This renaming business is entirely optional as far as this tutorial goes, but it’s worth know how to do. Imagine if you made a typo in a class name and didn’t realize it until after you had already referenced it in a few places. It’s nice to have an automated fix.

Setting Up the Header File

Most of our code is going to go in the View controller, named TweetViewController in my case. Switch to the corresponding .h file and we can start setting up properties and whatnot.

First, we need to implement the NSXMLParserDelegate protocol so our class can respond to NSXMLParser delegate methods. This is easily done by adding NSXMLParserDelegate to the @interface line, like so:

@interface TweetViewController : UIViewController <NSXMLParserDelegate> {

Now we need to declare some variables and other objects in the interface block. We need a string to hold the name of the Twitter user whose profile we will be accessing, a mutable array to hold the statuses we’ve pulled from the parser and a few that are used to hold data temporarily during the parsing process. Also, we need a few IBOutlets so we can update the View once we finish reading the XML data.

@interface TweetViewController : UIViewController <NSXMLParserDelegate> {
NSString *twitterUser;
NSMutableArray *statuses;
NSString *currentElement;
NSMutableDictionary *currentElementData;
NSMutableString *currentElementString;
IBOutlet UIImageView *backgroundImage;
IBOutlet UILabel *tweetLabel;
IBOutlet UIImageView *avatar;
}

Of course, we need to make these objects into properties. This means adding a few property declarations after the interface block ends.

@property (nonatomic, retain) NSString *twitterUser;
@property (nonatomic, retain) NSMutableArray *statuses;
@property (nonatomic, retain) NSString *currentElement;
@property (nonatomic, retain) NSMutableDictionary *currentElementData;
@property (nonatomic, retain) NSMutableString *currentElementString;
@property (nonatomic, retain) UIImageView *backgroundImage;
@property (nonatomic, retain) UILabel *tweetLabel;
@property (nonatomic, retain) UIImageView *avatar;

And then you need to synthesize them in the .m file by adding the following line right after the @implementation line:

@synthesize twitterUser, statuses, currentElement, currentElementData, currentElementString, backgroundImage, tweetLabel, avatar;

Now that that’s out of the way, we can get to the interesting part.

Setting Up the Parser

The first method in the View controller is <em>viewDidLoad</em>, which fires as soon as the View as loaded. (Subtle, isn’t it?) We will be putting our initialization stuff in there. Basically, we just need to ready our properties, set the Twitter username and start the parser.

- (void)viewDidLoad {
[super viewDidLoad];
statuses = [[NSMutableArray alloc] init];
currentElement = [[NSString alloc] init];
currentElementData = [[NSMutableDictionary alloc] init];
currentElementString = [[NSMutableString alloc] init];
twitterUser = [NSString stringWithString:@"collis"];
[self parseXMLForUser:twitterUser];
}

After the first arrays and dictionaries are initialized, the twitterUser string is set to the username of the Twitter account we want the app to pull the latest statuses from. I’m using Collis, one of the co-founders of Envato, as an example. You could put any user you want there, so long as they have a cool-looking background on their profile!

The last line calls the parseXMLForUser: method and passes the twitterUser string along with it. We will work on that part next.

The parseXMLForUser: method is responsible for setting up the parser, as well as building the Twitter API URL.

- (void)parseXMLForUser:(NSString *)user {

//Build the Twitter API URL by combining the user with the rest of the URL
NSString *urlString = [NSString stringWithFormat:@"http://twitter.com/statuses/user_timeline/%@.xml?count=3", user];
NSURL *url = [NSURL URLWithString:urlString];

//Create an instance of NSXMLParser and download the XML data from the URL
NSXMLParser *parser = [[NSXMLParser alloc] initWithContentsOfURL:url];

//Set this class as its own delegate so we can process NSXMLParser callbacks
[parser setDelegate:self];

//Disable namespace support and other things we don't really need
[parser setShouldProcessNamespaces:NO];
[parser setShouldReportNamespacePrefixes:NO];
[parser setShouldResolveExternalEntities:NO];

[parser parse]; //Go go gadget XML parser...

[parser release];

}

The first part of the method should look familiar to anyone who has worked with C or Java before. It takes our user argument (which contains the text of twitterUser) and splices it into the URL string, just before the .xml part. Cocoa expects URLs to be of the NSURL object type, we create a new one of those and pass it urlString.

After that is done, we create a new instance of the NSXMLParser class and nickname it “parser.” We also pass it the new URL object, which it will use to download the contents it finds there at runtime. Next we set the parser’s delegate to self, or the current class. The next three lines turn off some features we don’t really need. Finally, we kick the parser into action and leave a [parser release] command to clean up after it’s done.

That was simple, wasn’t it? Sadly, that was only the beginning. In order for the parser to, well, parse we still need to implement the delegate methods for NSXMLParser. And we need to make a spiffy UI.

Building the Parser

NSXMLParser is what is called an event-based parser. This means it loops around, searching a document for anything that looks like an XML tag. When it finds one, it raises an event. Basically it says “I found an opening tag named ‘something’” and leaves you to deal with it. The parser does the same thing with ending tags and the text between them. We have to implement delegate methods to handle these events and save the data they find.

Let’s start with a couple of simple ones.

- (void)parserDidStartDocument:(NSXMLParser *)parser {
NSLog(@"The XML document is now being parsed.");
}

- (void)parser:(NSXMLParser *)parser parseErrorOccurred:(NSError *)parseError {
NSLog(@"Parse error: %d", [parseError code]);
}

The first method fires when NSXMLParser starts to parse the document. For this application, there isn’t really anything that we need to do at that point. Putting an NSLog there is great for debugging, though. (If your app is crashing, it’s helpful to know whether it’s getting to that step or not.) I’m sure you can guess what the parseErrorOccurred method does. (It logs an error code if the XML document is malformed or if, for some other reason, the parser could not process it.)

Moving on, we have a method that is called when the parser finds an opening XML tag.

- (void)parser:(NSXMLParser *)parser didStartElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName attributes:(NSDictionary *)attributeDict {

//Store the name of the element currently being parsed.
currentElement = [elementName copy];

//Create an empty mutable string to hold the contents of elements
currentElementString = [NSMutableString stringWithString:@""];

//Empty the dictionary if we're parsing a new status element
if ([elementName isEqualToString:@"status"]) {
[currentElementData removeAllObjects];
}

}

This one is a bit more complicated. When it’s called, its arguments are populated with information that the parser found out about the element currently being parsed. It’s name is what we care about, primarily. Using the properties we created earlier, the method keeps track of the element currently being parsed (we need to know its name in other methods) and whatever is inside the element (between the opening and closing tag). The conditional statement at the end empties our dictionary every time the parser moves on to a new <status> element, as we will have already copied its contents to the statuses array.

The next delegate method takes any characters found inside an XML element and stores it in the currentElementString property for later.

- (void)parser:(NSXMLParser *)parser foundCharacters:(NSString *)string {
//Take the string inside an element (e.g. <tag>string</tag>) and save it in a property
[currentElementString appendString:string];
}

And finally, the penultimate method. This one contains the real meat of the parser. It is called whenever NSXMLParser comes across a closing XML tag. And so, it serves as a good place to put most of the data-saving logic.

- (void)parser:(NSXMLParser *)parser didEndElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName {

//If we've hit the </status> tag, store the data in the statuses array
if ([elementName isEqualToString:@"status"]) {
[statuses addObject:[currentElementData copy]];
}

//Trim any extra spaces and newline characters from around currentElementString
NSString *string = [currentElementString stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceAndNewlineCharacterSet]];

//Store the status data in the currentElementData dictionary
if ([currentElement isEqualToString:@"created_at"]) {
[currentElementData setObject:string forKey:@"created_at"];
} else if ([currentElement isEqualToString:@"text"]) {
[currentElementData setObject:string forKey:@"text"];
} else if ([currentElement isEqualToString:@"retweeted"]) {
[currentElementData setObject:string forKey:@"retweeted"];
} else if ([currentElement isEqualToString:@"id"]) {
[currentElementData setObject:string forKey:@"id"];
} else if ([currentElement isEqualToString:@"profile_image_url"]) {
[currentElementData setObject:string forKey:@"profile_image_url"];
} else if ([currentElement isEqualToString:@"profile_background_image_url"]) {
[currentElementData setObject:string forKey:@"profile_background_image_url"];
} else if ([currentElement isEqualToString:@"profile_link_color"]) {
[currentElementData setObject:string forKey:@"profile_link_color"];
}

}

The first code chunk saves the contents of the currentElementData dictionary to the statuses array if, and only if, the ending tag being processed currently is </status>. If you remember from before, currentElementData will be emptied the next time the didStartElement method is called. Otherwise, the block will be skipped and the application will handle the tasks it needs to run for child elements of <status>.

After stripping out extraneous spaces and newline characters from either side of currentElementString, so we don’t end up with weird output, we have a rather long if/else if block. This checks whether the element being parsed is one we want to save (e.g. “text” or “profile_image_url”) and if it is, it adds it to the element data dictionary.

The code may seem a bit strange at first, but it should make more sense after you become more familiar with it.

And now, for the last delegate method. This one fires when the document has finished parsing. This is the place to launch any operations we want to be started after we have our data. As you can see below, logging the statuses array to the console and then calling a method to display that data is what we will be doing here.

- (void)parserDidEndDocument:(NSXMLParser *)parser {
//Document has been parsed. It's time to fire some new methods off!
NSLog(@"%@", statuses);
[self updateView];
}

The View

After all that code, let’s work on the interface. Double-click the TweetViewController.xib file (or whatever your View XIB is called) in the Xcode sidebar to open it in Interface Builder. Now that your screen is sufficiently cluttered with windows, you want to drag a UIImageView from the Library window into your View canvas. Make sure that it is sized to fit the whole available area.

Of course, the Image View won’t be much use to us unless we link it with the controller. Right-click on the File’s Owner icon and drag the little rubberband/wire thing from the backgroundImage Outlet over to the UIImageView and drop it. The File’s Owner overlay window should update to show the Image View as being connected to backgroundImage.

I think this app would be better if it used a horizontal orientation, don’t you? Click the little arrow icon in the upper right corner of the View canvas. Interface Builder should automagically resize the Image View inside it to still fill the View. Save the XIB file out and switch back to Xcode. Now we have to configure the application to use a landscape orientation instead of the default portrait one.

Inside your controller class there should be a method called shouldAutorotateToInterfaceOrientation. It’s commented out by default. Uncomment it and change the interfaceOrientation to UIInterfaceOrientationLandscapeLeft. It should look like this:

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation {
return (interfaceOrientation == UIInterfaceOrientationLandscapeLeft);
}

Back in Interface Builder, drop in a new UIImageView. We won’t be hooking this one up to an IBOutlet. Instead, we will set the image to the word bubble image I made (it’s in the project file), resize the view to be the same point-width as the image (375×208) and position it neatly over the background image view. I also lowered the opacity a bit, just because I liked the effect.

Now we need a way to display the contents of the latest tweet. So drag a UILabel onto the View canvas and resize it to fit nicely over the word bubble graphic. Turn the “# Lines” setting up to five or so, set the font size to something that looks legible and change the “Line Breaks” option to “Word Wrap. Then wire it up to the tweetLabel IBOutlet, like you did with the UIImageView.

Ready to tie everything together? Switch back to Xcode and add one last method to the controller class.

- (void)updateView {

//Select the latest tweet
NSDictionary *latestTweet = [statuses objectAtIndex:0];

//Set the tweet label
[tweetLabel setText:[latestTweet objectForKey:@"text"]];

//Set the background image after downloading it.
NSString *urlString = [latestTweet objectForKey:@"profile_background_image_url"];
NSURL *url = [NSURL URLWithString:urlString];
NSData *data = [NSData dataWithContentsOfURL:url];
UIImage *background = [[UIImage alloc] initWithData:data];
[backgroundImage setImage:background];
backgroundImage.contentMode = UIViewContentModeScaleAspectFill;

}

While it looks nearly as intimidating as the NSXMLParser didEndElement delegate method, it’s actually quite a bit simpler. The first line gets the newest tweet from the statuses array, the =[tweetLabel setText:...]= line updates the UILabel with the text of the message, and the last part changes the background image behind the word bubble to be the same as the Twitter user’s profile background.

That last part needs the most explanation. Before we can display the image (which is what the setImage line does) we have to download it first. Taking the urlString, which of course is a string containing the web address where the image can be found, we convert it to a NSURL object, which is named url. We create a new NSData object and use it’s dataWithContentsOfURL method to download the image. (Cocoa requires that URLs used with it’s objects be of the NSURL class.) Next we initialize a UIImage object with the NSData object and set it as the image in the UIImageView named backgroundImage. Oh, and we set the content mode to UIViewContentModeScaleAspectFill so it’s not squished funny.

Now if you build and run the app, you should get something like this:

Before we free up our allocated memory and finish the app up, let’s add one more thing: an avatar field! Switch back to Interface Builder and add a new UIImageView. Resize it to 52×52 or so and wire it up to the “avatar” IBOutlet. Re-using the code from the background image bit, we can quickly modify it for the avatar.

//Set the avatar image after downloading it.
NSString *avatarUrlString = [latestTweet objectForKey:@"profile_image_url"];
NSURL *avatarUrl = [NSURL URLWithString:avatarUrlString];
NSData *avatarData = [NSData dataWithContentsOfURL:avatarUrl];
UIImage *avatarImage = [[UIImage alloc] initWithData:avatarData];
[avatar setImage:avatarImage];
avatar.contentMode = UIViewContentModeScaleAspectFill;

That goes in the updateView method, after everything else.

Now, before we can say the application is finished, there is one thing that needs to be done. Any memory we specifically allocated should be released. It’s not a huge deal in a single-view app, as it will be forcefully freed up on exit, but it’s a good habit to get into. (In more complicated applications, you can expect to see frequent crashes if you don’t release objects when you’re done with them.) It’s easy to do. For every object we explicitely alloc or retain, we have to release somewhere. The dealloc method is called when the application quits in this case, so we put most of our release statements there.

You can learn more about iOS memory management in this screencast.

- (void)dealloc {
[twitterUser release];
[statuses release];
[currentElement release];
[currentElementData release];
[currentElementString release];
[backgroundImage release];
[tweetLabel release];
[avatar release];
[super dealloc];
}

And we’re done!

Additional Challenge

Want to add to this sample application? Try making the following change: Use an NSTimer to cycle through the items in the statuses array and update the View accordingly. Most of the groundwork has been laid for you already.

When Rasmus Lerdorf first put PHP together, he – quite sensibly, despite his heritage – chose not to write it in Greenlandic or Danish. Good job too – that would have been rather unpleasant to work with. He opted instead, being in Canada at the time, for the local tongue. No, not French – that bastard dialect of the Queen’s English commonly referred to as “US English”.

PHP developers in Britain have been grumpy about this ever since. What was he thinking? And more importantly, how do we undo this travesty?

The rest of the post is a series of suggested “improvements” to PHP, which give it a more “British” feel. I won’t spoil them for you, as a few of them a hilarious.

If PHP Were British [Added Bytes]

I’m going to recommend PDO over MySQLi simply because it’s available on more systems, and it’s syntax may be a little bit easier to learn for newbies. PDO has been bundled with the main PHP distribution since PHP 5.1, and has been in PECL even longer, while MySQLi has only been included since 5.3. Whichever you use is up to personal preference and project requirements of course, but I will be sticking with PDO for the duration of this tutorial.

Suppose you have a simple bit of PHP that executes a MySQL query and ouputs a list of items to screen. It might look something like this:

    $db = mysql_connect("localhost", "username", "password");
    mysql_select_db("database", $db);

    $string = mysql_real_escape_string($string, $db);
    $query = "SELECT * FROM my_table WHERE item_cat='".$string."' ORDER BY item_date DESC LIMIT 5";
    $result = mysql_query($query);

    if ( mysql_num_rows($result) > 0 ) {
        while ( $row = mysql_fetch_assoc($result) ) {
            echo $row['item_title'] . '<br />';
        }
    }

You’re escaping any input from a third party with mysql_real_escape_string() to prevent injection attacks, I hope. SQL injection is one of the most common ways data is stolen or destroyed by attackers, and it’s also fairly easy to discourage. Escaping input, while not necessarily 100% effective, should prevent most injection attacks. (And it’s pretty much your only choice with the old MySQL extension.) A better solution is parameterized statements, which we’ll get to later.

If your server has PDO installed (which is probably the case if you have PHP 5.1 or greater), migrating is fairly easy. The basic principles are the same, though the syntax differs just a bit. It’s actually a bit cleaner and more object-oriented.

The example above would look something like this:

$db = new pdo("mysql:host=localhost;dbname=database_name", "username", "password");
$string = $db->quote($string);
$query = "SELECT * FROM my_table WHERE item_cat=$string ORDER BY item_date DESC LIMIT 5";
$result = $db->query($query);

if ($result != false) {
    while ( $row = $result->fetch(PDO::FETCH_ASSOC) ) {
        echo $row['item_title'] . '<br />';
    }
}

$result  = null;

Doesn’t that look nicer? Feel free to take a moment to appreciate the object-oriented goodness.

The biggest difference is probably the connection line. The “DSN” syntax used to connect to the database might look a bit strange at first, but it’s an important part of PDO. Since PDO can connect to other types of databases besides MySQL (e.g. PostgreSQL and SQLite), it uses a fairly standard connection string that specifies the server type besides the database name.

Escaping strings works essentially the same, but the syntax is slightly different. You need to remember to not put quotes around the variable in your SQL string, as the PDO::quote() method will do it for you. If you compare the SQL statements in the two examples, you’ll see the lack of quotations in the PDO example.

One gotcha to be aware of with PDO is that you need to set your $result variable to null if you intend to reuse it later on in the same script. You can end up with some weird results if you don’t. So just get in the habit of setting it to null or using unset() on it.

Now how about those parameterized statement things? They’re a way of ensuring that your code will be immune to SQL injection. Instead of mashing PHP strings together and passing the resulting query to the database engine, you keep the query and the potentially dangerous data separate. Placeholders are put in the query, and the data assigned to those placeholders is sent along with it.

$db = new pdo("mysql:host=localhost;dbname=database_name", "username", "password");

$sql = "SELECT * FROM my_table WHERE item_cat= :mystring ORDER BY item_date DESC LIMIT 5";
$statement = $db->prepare($sql);

$statement->execute(array(
    ':mystring' => $my_string
));

$result = $statement->fetchAll();

if ($result != false) {
    while ( $row = $result->fetch(PDO::FETCH_ASSOC) ) {
        echo $row['item_title'] . '<br />';
    }
}

$result  = null;

Parameterized queries may have some performance issues on MySQL versions prior to 5.1, but they shouldn’t have any significant disadvantages on more modern systems. Security-wise, they’re considered to be better than simply escaping strings.

I hope this little guide has been sufficient to get you started with PDO. You will probably want to check out the documentation to see what else it can do. While you don’t necessarily need to go out and update your old code right away—the PHP devs aren’t going to drop support for the old ext/mysql extension for quite a long time, if they ever get rid of it completely—but you should definitely familiarize yourself with the newer techniques and use them in new projects.

There’s probably sufficient documentation on how to implement this sort of thing with Twitter, so let’s try something a bit different. How about those new Google +1 buttons?

The +1 button has a convenient JavaScript callback that could be used for all sorts of fun things, such as un-hiding content on the page.

First, you need to put the button markup on your page, as well as the content you wish to hide until said button is clicked. The DIV holding the content should of course be hidden by default. Be sure to set the callback parameter of the button.

<div id="plusonebutton">
 <g:plusone callback="plusone_callback" href="http://www.webmaster-source.com"></g:plusone>
</div>

<div id="plusonecontent" style="display:none">
 <p><strong>The user has clicked the +1 button.</strong> Here's some content that was not previously visible. Lorem ipsum dolor sit amet.</p>
</div>

Next, you want to include the +1 script and jQuery in your page header. After you’ve taken care of that, you need to write your callback function. The function fires when the button is clicked (assuming the name matches the one specified in the button parameter) and passes a JSON object containing the button state, among other things.

<script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js"></script>

<script type="text/javascript">
 function plusone_callback(response) {
 if (response.state == 'on') {
 $("#plusonecontent").fadeIn();
 $("#plusonebutton").fadeOut();
 }
 }
</script>

The callback should check the JSON object to see whether the state is set to “on” rather than “off,” and replace the button with your hidden content if that is the case.

You can see a demo of the finished page here.

I don’t know whether Google frowns upon this sort of thing or not, but it would be a great way to provide a surprise bonus (e.g. an ebook or song download) when someone likes one of your pages. So, just don’t use it for anything spammy or deceptive and you should probably be fine.

Update: It has come to my attention that this could be used in many crappy ways, such as those irritating people who force you to Like a video on Facebook before they let you watch it. (Which is completely against the spirit of the concept, as well as social media.) Don’t do stuff like that. Seriously.

Microjs.com is a directory of “micro-libraries,” single-purpose JavaScript libraries with a small footprint. You can load up one or two for only a fraction of the file size of a larger framework. Need to make AJAX requests? Try microajax. Templating? Use Tempo.

Sure, we all love our favorite monolithic frameworks, and sometimes we even use them fully. But how often do we reach for the ride-on John Deere tractor with air conditioning and six-speaker sound system, when a judiciously applied pocketknife would do the trick better, faster, slicker?