class Organization(models.Model):
    name = models.CharField(max_length=255)
    url = models.URLField(verify_exists=False)
    orgtype = models.ForeignKey(OrgType)

The same model class in Rails typically looks like this:

class Organization < ActiveRecord::Base
    belongs_to :OrgType
end

…and in Grails it is more specific like Django:

class Organization {
  String name
  String url
  static belongsTo = OrgType
  OrgType orgtype
}

It took me a while to remember that in Rails, parts of the model design is actually stored in the database schema instead of in the Ruby code. Peculiar don’t you think, given that everything else in a Rails app is nicely declared in Ruby code? There are of course benefits to both approaches, but I have started adding comments in the Rails model classes to be able to remember what properties they have without peeking in the Db. Typically I have a number of half-baked projects on my laptop and from time to time I forget what they do and these comments help me remember.

Check out more examples here:

• Django models
• Rails models
• Grails models

Update: This project is now deprecated and Twitter has removed basic authentication.

Custom apps have major implications for usability so I decided to roll my own. I wanted to try out Fluid, the Prism-like app to contain web apps in their own process/window, to see if it is possible to build a complete open source ad-free twitter client in a single web page only using javascript and HTML.

So, I cuiled for a jQuery twitter plugin but had to google it to find it. Some minor modifications to the code by the fine folks at SeaOfClouds and adding a method to post new status messages gave this native-looking OS X twitter client (HUD-style to the left, default style to the right and HUD avatars style below):

Thank’s to the twitter json api it was trivial to query my own friend feed and display it in Safari. Then, I used Fluid to create a self contained OSX app that displays my static HTML page. Googling a nice application icon makes it much better-looking in the taskbar. I decided to call it “Twoot”. Twoot consumes little memory and plays nice with embedded URLs (they open in a new Firefox tab).

Unfortunately, Fluid does not allow you to distribute the created app so you will have to roll your own by:

1. Download and install Fluid.
2. Create a folder called “twoot” in your home directory.
3. Download the twoot html, js and css files from github and place in the twoot folder.
4. Edit twoot.js and set your twitter username and password. (Enter credentials in the basic auth form when launching app the first time).
5. Open Fluid and create a new app by pointing to the twoot.htm file (e.g. file:///users/you/twoot/twoot.htm) and set a nice icon.
6. Save the app as “Twoot”.
7. Your new twitter client is ready! Run it and resize as required, set the window to floating, kill tabs etc. Change the twoot.css and html file to customize it further.

Simple API:s are wonderful for usability!

It is amazing how much you can improve the percieved site speed by some minor changes to your htaccess file. This site runs WordPress and I was tempted to install the WP-Super-Cache plugin but was put off by some of the incompatibility issues that were reported with the latest version of WordPress and PHP safe mode. Until then I managed to lift my YSlow site score from grade F to grade C by:

1. Removing ETag headers by adding the following lines to my htaccess file (outside the wordpress-specific rewrite area):

Header unset ETag
FileETag None

2. Setting a future expires header for static files by adding this to htaccess:

<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Expires "Thu, 15 Apr 2012 20:00:00 GMT"
</FilesMatch>

If your app/blog uses some sort of dynamic generation of images you can modify the matching rule above for a more precise selection of files (e.g. only files in the templates folder).

Presto! Two simple additions to htaccess and cached access is down to two requests (of which one is Google’s javascript file for ads):