Falling Around

An easy way to change the settings of an S3 Bucket’s files (in Ruby)

I recently needed to go back and change the settings of the files in an S3 bucket. I wanted to set the permissions to “pubic read” and also set a cache control header so that the images would be cached in browsers approparitely. After a bit of Googling, I wasn’t able to find anything particularly simple and straightforward. It’s really a pretty easy task, though. The one “gotcha” is that S3 will only return up to 1,000 keys for a given bucket at a time, so you have to be sure to loop through until you get them all. Here’s what I came up with:

nolantjones:

I once tried to make several webcomics with friends.  It went approximately no where, but it was an interesting learning experience.  I actually drew this strip— which is interesting as I have no business drawing. 

I’ll probably show more of this sort of thing as we move along here. 

I was one of those “friends.”

Collapsable/Expandable Table View Rows in Titanium Mobile

I recently needed to be able to have a quick and easy way to create collapsable/expandable TableView Rows in Titanium Mobile. Here’s what I came up with:

It’s nothing fancy, and it still needs a lot of work (adding an indicator image for if the parent row is collapsed/expanded, for one thing), but I thought I would share it for anyone out there who, like me, did a Google search and came up empty. At least it’s a starting point!

SVProgressHUD for Titanium Mobile →

I’ve recently begun creating iPhone applications utilizing Titanium Mobile. However, one of the problems with using Titanium Mobile is that you can’t readily use existing open source iOS libraries without first turning them into modules. As I create these modules for use in my own projects, I plan on releasing them to continue the spirit of open source in which they were created.

The first module I have “converted” is the simple but elegant SVProgressHUD, a great progress indication widget. It’s about 90% complete, at this point I just need to figure out how to get the images to work with TI’s module assets system (not much documentation out there on that bit). 

Fork it on github »

Ash Mokhberi: "I did a Bad Job" →

ashmokhberi:

The other day I was talking to a friend. We were casually chatting about one of his startups, which he has let take a back seat, while he focuses on building something that can sustain him.

He was talking about how excited he was to get back working on it. We got onto the topic of growth,…

Exchange Web Services for PHP →

I recently needed to do some basic tasks (get email from the Inbox, send an email message, etc.) for accounts on our Exchange 2007 server. Exchange Web Services seems to be the way to go, but (of course) Microsoft only provides a complicated SOAP API, and a simple .NET API, which is no good for us PHP folks. Other solutions to bridge the gap exist, but they’re really nothing more than thin wrappers around the complicated SOAP API.

I started to create a new PHP class that abstracts out some basic functionality (e.g. send a message) to simple functions, so that the end user doesn’t really need to mess with the SOAP API directly at all. I’ve decided to open-source that code, and it can be found at the link above. I will be adding more features as I need them for my current project at work.

jQuery Templates vs jQote 2: A Followup (a.k.a the fastest way to use jQuery Templates)

My original post regarding a speed comparison between jQote2 and the new jQuery Templates plugin has generated more interest than I originally expected. In fact, several members of the jQuery Templates team have written to me either with questions or with suggestions about how to improve the benchmark to make it a more “apples to apples” comparison. To understand why the first benchmark wasn’t necessarily as fair as I had originally assumed, we have to dig a little deeper into the way the two plugins work.

The original jQote plugin worked very similarly to the way that I was apparently using the jQuery Templates plugin (and it was much slower than jQote 2). Both jQote 1 and the .tmpl() function of the jQuery Templates plugin apparently process the template and then create an unparented DOM fragment that is ready for insertion into the page. The jQote2 plugin, on the other hand, simply generates a string from the template. The overhead associated with creating the DOM fragment is apparently very high, and explained a great deal of the slow down in the jQuery Templates plugin benchmark.

Boris Rivers-Moore, the principal developer on the jQuery Templates plugin, was kind enough to write me an email explaining this, and offered a suggestion on how to improve the benchmark. Apparently, there is a different way of going about using the plugin, with the following method:

template_object($, payload).join("");

This way of doing things works the same as the jQote2 plugin, generating a string from the template, rather than the unparented DOM object. It is also much faster.

He also pointed out that the jQuery Templates plugin automatically HTML encodes during the variable insertion, and offered a different set of tags for the template that would remove this functionality, again providing a better comparison for a benchmark.

Here is an updated benchmark, using this new method and with the template tag changes (time to render in milliseconds; lower bars are better):

Average time for jQote2 was 11ms, for jQuery Templates 25ms. As you can see, the jQuery Templates plugin is now much, much more competitive in terms of speed compared to the jQote plugin. 

However, this got me thinking; the benchmark could really be considered rather synthetic at this point, because although it does measure the time to go from template + payload to HTML string, it doesn’t actually take into account doing anything with the resulting string. So, I added on some additional functionality to the benchmark, where the resulting string is appended to the DOM object (in this case, a <div> tag hidden by CSS). Something along these lines:

$("#div").append(template_object($, payload).join("")); //jQuery Templates

$("#div").append($.jqote(template_object, payload)); //jQote2

Here are the results of this adjustment:

Average time for jQote2 was 66ms, for jQuery Templating, 76ms. As you can see, some time is added on by adding the string to the DOM, but not much, and again the plugins are very close in speed. This, however, led to one further thought: if adding the string to the DOM is so cheap, then why bother with using .tmpl() and creating the unparented DOM fragment?

As a comparison, I again modified the benchmark, this time to use the .tmpl() call from the jQuery Templates plugin, instead of the function which creates a string. Keep in mind that this is the “officially documented” way of using the plugin, and the way that all of the new tutorials being created out there seem to be using. The code was something like this (similar to what was used in the original benchmark):

$.tmpl(template_object, payload).appendTo("#div");

And here were the results:

Average time was 480ms. Over 6 times slower. From a very speedy 76ms, to a page-halting 480ms. 

I understand that having an unparented DOM object can have its advantages. For example, it allows you to chain together a series of statements, and work with the resulting object directly in jQuery if you need to do further processing. However, the vast majority of tutorials, and even the official documentation on the jQuery site, is simply taking this unparented DOM object and appending it to some other object on the page (as does the benchmark). It’s apparent from these results (as near as I can tell, anyway), that it would be much, much faster to simply create the string, and then append that string to the DOM (which I assume is why jQote2 switched to this as its primary modus operandi, instead of the DOM fragment functionality of jQote 1).

Conclusions

When doing a better, apples-to-apples comparison, it does become clear that the jQuery Templates plugin certainly can hold its own ground against the existing field of jQuery templating plugins, including jQote2. However, the majority of material that I have read about the new plugin (including the official documentation) uses a method which is apparently many times slower than it needs to be. I looked through the official jQuery documentation for any mention of the faster “string” method of using the plugin, and I was unable to find any. It is possible that I missed it, but I hope that these findings will encourage the jQuery Templates team to better publicize the faster method. Again, while the .tmpl() function may be useful if chaining or further processing is required, if your only goal is to get the resulting template into the DOM, the string method is much, much faster.

On the other hand, I should point out that each benchmark here is doing 1,000 template executions, so perhaps this is an unfair comparison of using the .tmpl() function. One could argue that if you needed to loop through 1,000 items, you would do so inside the template, and depending on how the .tmpl() function handles internal loops (I honestly have not looked), it might cut down significantly on the overhead, since it would only be presumably building one fragment instead of 1,000. But, to be on the safe side, it seems that if you just want to process the template and then insert the the result as a whole without any further processing, the string method seems to be the best bet.

Boris also took the time to point out a few other features that jQuery Templates has that I was unaware of:

The jQuery Templates does include a number of other features in addition to encoding which may not be part of the other template engines. One is using with() so that you can say {{html name}} rather than {{html this.name}} as in jQote. Also, we test for whether fields are defined, so that we can accept ‘jagged’ arrays, where a field may be defined on some items and not on others. And we test for whether foo (in {{html foo}} or ${foo} ) is of type function, and if so, we call the function. And so on. These features impact the perf [sic] slightly.

Thanks to Boris Rivers-Moore and Marcus Tucker for taking the time to read my original post and respond. Keep up the good work!

Here is the jqote.benchmark.htm file that I ended up with (for the last benchmark): http://pastebin.org/164550

jQuery Templates vs jQote 2

View the followup to this post: http://rileydutton.com/post/1303173205/jquery-templates-vs-jqote-2-a-followup-a-k-a-the

The jQuery team recently released an “official” jQuery plugin called Templates to address the increasing need for client-side templating when working with web applications. I have been using this technique for quite some time in my own projects through a different jQuery plugin called jQote2. Of course, the first thought that came to my mind was, “should I switch?”. For me, at least, the two primary concerns are feature set and speed.

Feature Set

The feature sets of the two plugins are pretty similar at first glance. Both offer you the basic ability to use Javascript variables inside of an HTML template stored in a <script> tag. The syntax is a little different ( ${varname} vs <%=varname%>), but honestly that’s a pretty minor difference, and it’s really going to become second nature depending on which plugin you end up using. It does meant that I would have to re-write my existing templates to make the switch, though.

Both plugins offer the ability to pre-compile templates at page load so that there is minimal overhead associated with using a template over and over again on a single page. This compiling feature is also very important for those of us who work with Adobe AIR, as without the ability to compile, AIR’s eval() after onload restriction makes templating impossible.

So, as far as feature sets go, at least in my eyes it’s pretty much a tie, with a slight edge to jQote for my own purposes since there’s no point in converting all my existing templates to a new syntax if I don’t gain any new features.

Speed

The official jQote site has an interesting grouping of benchmarks published, and the author of the plugin was kind enough to post this benchmark page on Github. However, I noticed it had not been updated to include the newly-released official templating plugin, and instead includes a much older version of the plugin. I downloaded and modified the benchmark to include the latest version of the Templates plugin found on Github. 

The benchmark works by pre-compiling two templates (a simple template with a few variable insertions, and a more complicated template featuring a for loop) for all the tested plugins (it includes a number of other plugins besides just jQote and the official Templates plugin, which I have also included for consistency’s sake). It then passes two payloads to each templating system 1,000 times for a single benchmark, and this benchmark is repeated 25 times. It should be noted that by precompiling the templates, the actual compilation time is not taken into account in these benchmarks — this is strictly a test of the processing time it takes to process a payload into a pre-compiled template.

I ran the benchmark on Chrome 6.0.472.63 on Mac OS X Snow Leopard 10.6.3. Here are the results (average time to render, in milliseconds; lower bars are better):

For reference, jQote2 had an average time of 11ms, maximum time of 15 ms. The official jQuery Templates plugin had an average time of 510ms, with a maximum time of 560ms.

The official plugin is off the charts. It is incredibly slow. For reference, here is the benchmark as it originally appears on the jQote site…here “jQuery Templating” refers to a very old version of the jQuery Templates plugin (which at the top reads “for demonstration purposes only”):

So at some point in the development of the plugin, things got incredibly slow. Just to be sure, I re-ran these benchmarks on Safari and Firefox (both on Mac), and found similar results (the overall time of all the plugins actually increased since the Javascript engines in those browsers are currently slower than the one in Chrome on Mac, but the relative results were the same).

Conclusions

Of course, the new official Templates plugin for jQuery is still beta software, and I expect as they continue to develop it, the speed increases will come. However, as of right now, I will most definitely be sticking with jQote2 for all current and future websites, until the software has more time to mature. It is good to know, though, that the feature sets are very similar, as is the syntax, so that if a time comes in the future that the Templates plugin surpasses jQote in speed, it won’t be too terribly difficult to switch.

Small Rant

I am left to wonder, however, why the jQuery team decided to create their own templating code from scratch when there were already so many other jQuery templating plugins out there, including one such as jQote which already does everything they want their plugin to do, and faster to boot. Why reinvent the wheel? I am sure that since it is the official implementation, the Templates plugin will get a lot of use, have many tutorials incorporate it, be used in other plugins, etc. Which just drives home the point further that the jQuery community as a whole might have been better served by using a better, more mature implementation of this feature, rather than starting from scratch.

For transparency, reference, and ease of duplication of these results, here is the jqote.benchmark.htm file as I modified it:

http://pastebin.org/115536

View the followup to this post: http://rileydutton.com/post/1303173205/jquery-templates-vs-jqote-2-a-followup-a-k-a-the

Getting MSSQL to work with PHP on Ubuntu 10.0.4 →

After about 2 hours of Googling, I finally found this gem showing you how to get the MSSQL module installed on Ubuntu for PHP. Take my advice, DON’T go the ODBC route — it’s frought with peril. 

The only thing that seems to have changed between that post and 10.0.4 is that sudo apt-get source php5 put the php5 source in my home directory (~) instead of the a system directory. I also had to install php5-dev in order to get access to phpize. Everything else was a breeze!

Just in case it should ever go away, here’s the exact steps I took to install on Ubuntu 10.0.4:

sudo apt-get install php5-dev
sudo apt-get source php5
cd ~/php5-5.3.2/ext/mssql
sudo phpize
sudo ./configure
sudo make
sudo make install

Viola!

Social Media Affects Big Brands →

A great example of why in today’s Internet-connected world, businesses can no longer hide behind millions of dollars of advertising.