I wanted to play with the new CSS transition stuff, to see what all the fuss was about. At the same time I wanted to make something useful, so I thought why not make a little site for my friend Dave, who is one bad ass photographer. I have a rough demo up and it works pretty well. It only works with Safari 4, but the good news is that it also works with Mobile Safari.

It’s really nice that the animation is defined in the CSS and you don’t need any JavaScript to move objects. It was also really simple to implement, most of the work was done in about an hour. The interaction is simple. Click a picture to zoom into it, then a full version loads, click on it and you zoom back out. You can also move the thumbnails around.

I had to violate some ui for the iPad because of the way mobile safari handles events, or more precisely, doesn’t handle events. I wanted to maintain the native gestures of but weirdly enough safari does fire any events when double tapping to zoom in, as stated in their documentation. Why?

I decided implementing my own photo uploading/managing would be too much of a pain in the ass, after all Dave isn’t paying me for this. Yes, this may come as a shock, but I’m not a total asshole. So I decided to use Flickr as a CMS. Since the API allows for a JavaScript callback, there’s no backend proxy work required.

Anyway, here’s a little taste of how it works. You need Safari 4 or iPhone OS 3. Currently, there are three different ways to load photos.

1) Load from a JSON file

Loading a JSON file, don’t pass any query terms: http://mud.mitplw.com/PhotoViewer/

The actual JSON file is: http://mud.mitplw.com/PhotoViewer/index.json

2) Load Photosets from a Flickr user

Pass a photoset=flickr_user_id query, like this (using Luis’s Flickr account)

http://mud.mitplw.com/PhotoViewer/?photoset=75903973@N00

HINT: you can look up user_ids with idGettr.

3) Load Photos from Flickr using tag search

Pass any comma delimited tags like ?drunk,punks

http://mud.mitplw.com/PhotoViewer/?drunk,punks

Finally, I’ll post the source on github when I finally finish Dave’s site. Also, maybe in the near future I’ll add some local storage and HTML5 video support…

According to Douglas Crockford it’s possible to create private variables and methods, and privileged methods (public methods with access to private variables and methods). Crockford’s article also gives us some patterns to follow which we can easily follow.

I was curious to see how this might look like in my preferred JS framework, Prototype.js. It didn’t take long before I concluded that you can’t use private variables with Class.create().

Here’s a rather useless class:

var AssetRequest = Class.create({
  initialize: function(_id, _url) {
    this.id      = _id;
    this.url     = _url;
    this.loaded  = false;
    this.content = null;
    this.request = null;
  },
  load: function() {
    if (!this.loaded) {
      this.request = new Ajax.Request(this.url, {
        onSuccess: function(transport) {
          this.loaded = true;
          this.content = transport.responseText;
          Event.fire(document, 'assetrequest:loaded', this);
        },
        onFailure: function() {
          Event.fire(document, 'assetrequest:failed', this);
        }
      });
    }
  }
});

The idea here is that you will create an AssetRequest object for an asset, say a JSON file. As you can imagine, all the members are editable. You can do something really dumb like this:

var request = new AssetRequest('req1', '/assets/asset-1.js');
request.loaded = true;
if (request.loaded) {
  alert(request.id + ' is loaded');
}

If you count on request.loaded to tell you if an asset has been loaded, it’s not reliable. So obviously we want to make this a private variable set it’s value internally, and create a privileged method that will provide access to its value. But you’ll see that this is actually not possible if we construct AssetRequest with Prototype’s Class.create.

It’s tempting to write:

var AssetRequest = Class.create((function() {
  var id,
      url,
      loaded  = false,
      content = null,
      request = null;

  return {
    initialize: function(_id, _url) {
      id  = _id;
      url = _url;
    },
    load: function() {
      if (!loaded) {
        request = new Ajax.Request(url, {
          onSuccess: function(transport) {
            loaded = true;
            content = transport.responseText;
            Event.fire(document, 'assetrequest:loaded', this);
          },
          onFailure: function() {
            Event.fire(document, 'assetrequest:failed', this);
          }
        });
      }
    },
    getURL:   function() { return url; },
    isLoaded: function() { return loaded; }
  }
})());

If you try this out, you’ll soon realize something is wrong:

var req = new AbstractRequest('1', '/request1');
alert(req.getURL());
//-> '/request'
var req2 = new AbstractRequest('2', '/request2');
alert(req2.getURL());
//-> '/request2'
alert(req.getURL());
//-> '/request2' ... this isn't good!

It seems the “private” variables that are created are not instance variables, instead they are “static” variables. I then thought the only way to create private variables would be defining the variables and all private/privileged methods inside the initialize method. But that’s where I gave up since that would be just so dirty looking.

I decided to not use Class.create and instead create my own constructor, just like the Crock style. So now our example will look like:

var AssetRequest = function(_id, _url) {
  var that    = this,
      id      = _id,
      url     = _url,
      loaded  = false,
      content = null,
      request = null;

  this.load = function() {
    if (!loaded) {
      request = new Ajax.Request(url, {
        onSuccess: function(transport) {
          loaded = true;
          content = transport.responseText;
          Event.fire(document, 'assetrequest:loaded', that);
        },
        onFailure: function() {
          Event.fire(document, 'assetrequest:failed', that);
        }
      });
    }
  };
  this.getURL   = function() { return url; };
  this.isLoaded = function() { return loaded; };
};

The problem now is that this new class can’t be extended as if it were created with Class.create. For now I only use this method for classes that don’t need to be subclassed, but hopefully in the near future, there will be an update to Prototype that will allow private variables!

The Architecture

An overview of the architecture is shown below:

A POST request from the browser is sent to a Rails Metal URL periodically (as opposed to responding to keystroke events). The Rails Metal method verifies sessions, and request parameters and forwards them over to the MudTyper Server. The MudTyper Server then sends a request to MudTyper Renderer to create either a file that is saved to disk or a base64 encoded string depending on the user’s browser. The browser receives the image as a response and includes the rendered image into the page.

Scalability

With this architecture, it is possible to scale for increased load. We can run multiple instances of MudTyper Server+Renderer, and use mod_proxy to get Apache to handle the load balancing.

Font Rendering

The new Renderer adds a lot of new support, including support for OpenType fonts with full kerning support, as well as many OTF features. For instance, we can now render Galaxie Cassiopeia’s contextual alternates, adding smooth transitions between letters.

Most of our client work involves Rails development. It seems everybody wants a website that allow them to change the content, anytime, anywhere, whenever they like. But I always tell my clients to think about how often this “change” is going to happen. It’s certainly a waste of money to pay for developing some feature that you don’t end up using.

Even with Rails, having an “admin” backend requires extra design and development time. Also, with Rails and most other web frameworks, it’s not completely trivial to deploy and maintain these sites. For the client, it most likely means they need to ditch their current hosting provider and go with someone who will support Rails. Rails support on an affordable host is a hit or miss. I’m still surprised that Dreamhost still claims that they “support” Rails. In the world of VPS, the deployment is an easy thing, but for most clients, maintaining a VPS is a responsibility they don’t want. Why can’t it just work? I agree.

But this post isn’t about Rails. Instead, it’s about revisiting an oldie and ugly [but still sometimes a goodie] friend, PHP.

I just finished programming a site for Allen Hori. His site doesn’t require many updates but he did want to update it himself whenever he needed to. Having a simple configuration file along with good old FTP to upload files was the way to go. I know there are those people that love XML and XSLT, but I’m not one of them. I hate XML — it’s hard to read, hard to edit in a text editor and it’s bloated…and I XSLT? It’s not for me, and that’s all there is to say. My choice was YAML and PHP.

I feel like I abandoned PHP long ago, but I still write it when I prototype, before going to Rails. As a language, I think PHP is ugly, inconsistent and generally something that makes me appreciate how great Ruby is. But PHP still has a lot going for it. First off, every host supports PHP. It doesn’t matter if it’s a linux, solaris or MS, they all support it. Also, it’s fast and easy to deploy. Copy the files over to the server, and it does it’s thing. No need to start a server or restart a process after your shared host restarts the server without warning.

Okay, enough with the talk, now for the technical goodies.

Configuration

Each “gallery” page is configurable. You can specify images and captions. This is easily described in YAML like this:

title: Gallery Name
path: path/to/images
images:
  - image: first.jpg
    text: |
      here's a caption for the first image.
  - image: second.jpg
    text: |
      here's a caption for the second image.

Parsing this in PHP is easy. We just google for a PHP yaml parser. I chose spyc because it comes as one file that you simply include. No installation necessary. You simply parse the yaml file like this:

$config = Spyc::YAMLLoad('config/gallery.yml');

and magically, $config becomes a hash with the contents of the yaml file. That’s pretty much it, you can then go spaghetti style and insert content wherever you need. Whenever your client needs to update content, they just need to update the yaml file and upload any new images.

And…there’s more. Remember how this is a site that doesn’t change all that often? But we also don’t know when it will be updated. But with this current setup, every request will require PHP to do the same task. So being the responsible programmer, we need to implement caching.

Caching

We don’t know when Allen will decide to update the pages. But this is easy to determine. We know there was an update to the content any time the configuration file gets updated. So we need a way to generate a cache and update that cache anytime the configuration file is updated.

How do we do this? It’s actually really simple. Everything we need is built into PHP. To generate the cache, all we do is use PHP’s output buffer. It’s surprisingly easy; 1. start the buffer, 2. generate the page, 3. open a file handler, 4. write the buffer contents, and 5. flush the buffer to the browser.

ob_start();
// generate the page here
$fp = fopen("cache_file_location", "w");
fwrite($fp, ob_get_contents());
fclose($fp);
ob_end_flush();

This will save what’s sent to the browser to a file. To decide when to use the cache and when to generate a new one, we simply compare the file modification times of the yaml file and the cache.

if (file_exists($cachefile)) {
  if (filemtime("config/gallery.yml") < filemtime($cachefile)) {
    include($cachefile);
    exit();
  }
}

This will serve the contents of the cache file if the cache is up to date. Of course this conditional needs to run with every request, it will be much faster than having to evaluate the same PHP script over and over.

The development of some buzamoto internal research projects has resulted in CVOCV: A CoreVideo-based OpenCV experimentation environment. CVOCV is an XCode-based project that provides programmers with an extremely simple way to access and experiment with OpenCV. CVOCV is clean, fast, and understandable.  If you ever wanted to learn OpenCV on OS X without much hassle, download it from the buzamoto wiki and have a look.

Today was a good day. Not only did I win Solitaire on my iPod on a train down to Providence, I fixed a mailserver issue that I’ve been struggling with for a few weeks.

I’m slowly switching over to Slicehost for all my web hosting requirements, and setting up the server (I’m running Ubuntu Hardy) so that I can get rid of all the other hosting I use (I already got rid of crappy Dreamhost). I’ve been using Pair for the last ten years and have been really happy with them, but I’m a server junkie. VPS is just too tasty. Anyway, most server stuff is pretty straight forward to set up. Pickled Onion articles and a bunch of howtoforge docs will get you started from a fresh disk image in no time. One thing that tripped me up was setting up the mail server. I wanted the standard PostfixAdmin controlled virtual user setup using MySQL to manage the users. Following this and this got everything working, except SMTP would not authenticate properly when storing passwords encrypted in the database.

Everything worked, Courier IMAP and SMTP Auth using TLS…but only if the users passwords were stored cleartext in the database. Even if connecting securely, storing passwords cleartext is a bad idea. The problem comes from Ubuntu SASL libraries not supporting password_format. I didn’t want to run the patch, since…well, I don’t really know how patching while using aptitude works (you probably have to run it every time you update), and I didn’t want to start compiling some things from source, while mostly relying on a package manager. I’ve inherited servers where some things are compiled from source and other things are managed on multiple package managers, and it is a BAD IDEA.

So, the solution. I followed the Ubuntu article and set up my database much like their example, but instead of using auxprop for pwcheck_method, I use saslauthd with PAM.

First, make sure you install libpam-mysql:

sudo aptitude install libpam-mysql


Then, in /etc/postfix/sasl/smtpd.conf:

pwcheck_method: saslauthd
mech_list: plain login


You might also want to add log_level: 7 while you are debugging. Next, create /etc/pam.d/smtp with the following:

auth required pam_mysql.so user=the_user passwd=the_password host=127.0.0.1 db=postfix table=mailbox usercolumn=username passwdcolumn=password crypt=1
account sufficient pam_mysql.so user=the_user passwd=the_password host=127.0.0.1 db=postfix table=mailbox usercolumn=username passwdcolumn=password crypt=1


Then make sure you use $CONF['encrypt'] = ’system’ for PostfixAdmin. You should observe /var/log/mail.log and /var/log/auth.log for any errors. When I first tried out PAM, I didn’t realize that I had not installed libpam-mysql, so only today when I went back and set the log_level did I actually realize I needed to install it.

Now I feel a little better not having cleartext passwords around…

ps. I am really bad at Solitaire, so it was a good day.