Technorati Token
Just an administrative post to verify the site with Technorati, apparently I have to put this token: DKB8NZDEXUAX somewhere in my feed – done.
Check back soon.
Just an administrative post to verify the site with Technorati, apparently I have to put this token: DKB8NZDEXUAX somewhere in my feed – done.
Check back soon.
Disclaimer: This blog post may seem a little outdated, after all the term RIA seems to be slowly dropping out of the hype-o-sphere and been replaced with the “cloud”, however, rich internet applications are still the cutting edge of many an enterprise implementation, hence this blog post.
The internet is changing, connections are getting faster, web browsers are getting more advanced and the technologies behind the internet are being constantly improved & updated. Due to this rapid evolution more and more companies are offering services that run on the cloud, accessible anywhere, anytime, anyplace.
Virtually every application that an average use would expect to find on their desktop computer can now be found somewhere on the internet. These are the rich internet applications, applications that finally break free of the desktop into the word of infinite storage and always on availability. This blog post aims to discuss the factors that are required (in my opinion) to produce a rich internet application.
According to David Mendels (one of the group that coined the phrase ‘rich internet application’ at Macromedia) the most basic definition of an RIA is ‘no page refresh’ (or ‘single screen’ depending on your interpretation). But he himself admits that this was the definition ‘at the time’. [Based on a comment by David at RedMonk].
In the current web-sphere many websites appear to classify themselves as RIAs, this probably due, in part, to the rise of the term ‘rich internet application’ as a buzz-phrase among developers and technology publications. Many technologists involved with RIAs now argue that any website that requires some form of browser-based plugin can be categorised as a RIA, but in the a world of desktop-replacement web applications does the term still apply to websites that simply include a flash video or make extensive use of AJAX to prevent page reloading?
After trawling through many of the different websites that consider themselves rich internet applications I fully agree with the original definition that an RIA must have no (or very little) page refresh, this is one of the factors that makes an RIA more like a desktop application in terms of user experience, you wouldn’t expect the application window in Excel to completely re-draw itself every time you switch work books would you, so why put up with it in web applications that you use.
Every website I came across that I would consider to be an RIA also shared another common attribute, the lack of full page scroll bars. Many of them contained scroll bars to navigate through subsections of content but none ever forced me to trawl through large pages and lose access to key navigational features. Again, this is reminiscent of most, if not all, desktop applications. A desktop application will nearly always retain placement of navigational features the most obvious of these being the menu bar at the top of a window (or screen).
The use of browser plugins and ‘rich media’ however were not present in the RIAs that I came across. Many created a more than optimal user experience through the use of JavaScript, HTML and a few images, features available in all modern web-browsers.
Personally I believe that the only websites that should be considered ‘rich internet applications’, the key word being ‘applications’ are those that most effectively simulate the desktop application user experience; this does not however mean that RIAs should only be limited to the functionality that a desktop application can provide. The World Wide Web offers far greater scope in terms of storage, processing, scalability, accessibility and social interaction, features which should be embraced in the creation of rich internet applications and can only serve to augment the user experience.
In this blog post I have discussed in very simplistic terms, what, in my opinion, makes a RIA. It isn’t the inclusion of media heavy content, or the ability to load content without re-loading the whole page. It is the ability of a website to simulate a desktop user experience, effectively allowing the user to easily replace any desktop application with a browser-based clone.
In the context of modern rich internet applications the browser should be seen, not as a way of ‘browsing the internet’, but as a shell that provides a user with access to the applications which they use every day. The web browser is the operating system of the RIA world.
Check back soon.
As you may or may not be aware digital:pardoe has, for the past 4 years, been running atop a custom blogging engine that I developed as way to learn Ruby on Rails. Whilst the system has (nearly) always been stable and (nearly) always fast I felt it was time to retire it, from everyday use at least.
When using the digital:pardoe blogging engine the ‘blogging’ always felt secondary to the actual development of the blog, I was always found myself doing far more of the ‘adding new features’ than the ‘adding new posts’ which, at least in recent months, is not what I intended to happen.
Unfortunately, the loss of my bespoke blogging engine also means a loss of some of the bespoke features I added to the website. The downloads (previously ‘software’) area is now very cut down – everything is still available as before though. The ‘photo’ section has now disappeared completely, if you want to see my photographs you’ll have to visit my Flickr account instead. I’ve made every effort to redirect old pages to their new location but if you find a page that is missing please contact me so I can fix the problem.
In the near future I intend to release the digital:pardoe blogging engine source code (once I’ve cleaned it up of course) as it may be a useful reference to other new RoR developers. Don’t expect the default Typo theme to stick around for long either, I’m currently in the process of porting a digital:pardoe theme to Typo.
And, if you hadn’t guessed already, digital:pardoe is now Typo powered.
Check back soon.
A friend reminded me of how nice it would be to merge all the windows in Safari back together using LaunchBar (or QuickSilver for that matter). So I wrote a quick AppleScript to accomplish the task;
on gui_scripting_status()
tell application "System Events"
set ui_enabled to UI elements enabled
end tell
if ui_enabled is false then
tell application "System Preferences"
activate
set current pane to pane id "com.apple.preference.universalaccess"
display dialog "The GUI scripting architecture of Mac OS X is currently disabled." & return & return & "To activate GUI Scripting select the checkbox \"Enable access for assistive devices\" in the Universal Access preference pane." with icon 1 buttons {"Okay"} default button 1
end tell
end if
return ui_enabled
end gui_scripting_status
on click_menu(app_name, menu_name, menu_item)
try
tell application app_name
activate
end tell
tell application "System Events"
click menu item menu_item of menu menu_name of menu bar 1 of process app_name
end tell
return true
on error error_message
return false
end try
end click_menu
if gui_scripting_status() then
click_menu("Safari", "Window", "Merge All Windows")
end ifThe ‘gui_scripting_status()’ routine is taken and modified from code that can be found here: http://www.macosxautomation.com/applescript/uiscripting/index.html.
Check back soon.
I’ve finally gotten round to updating iSyncIt and Set Icon for Snow Leopard, as always you can download iSyncIt here and Set Icon here.
The new release of iSyncIt fixes the only bug I could find under Snow Leopard – the icon not changing correctly under bluetooth on / off conditions.
The Set Icon release fixes the problem of the application not performing it’s one and only function – setting a drive icon. Along with the bug fix I modified the image conversion to prevent the (frankly awful) stretching of non-square images to fill a 512×512 icon, images now scale nicely. I also removed the terrible tool-tips that show up when you start the application I used to think they were ‘cool’ but soon realised the error of my ways. However, in place of this I added some ‘brilliant’ window resizing when you remove an icon – we’ll see how long that lasts. Oh, the application will also run as a 64 bit application now – not that that makes any difference what-so-ever, I just did it because I could.
Check back soon.

A while ago I started setting up my websites to use ActiveRecord as a session store, this means that the session information for all the visitors to my website is placed in a table in my database. It may or may not be the best way to store sessions but it’s certainly faster than the filesystem and my VPS doesn’t really have the memory capacity for an ‘in memory’ store.
Anyway, one day I decided to perform some DB maintenance, check tables where okay etc, upon logging into the DB I noticed that my sessions table had grown quite large, almost 125,000 records, little did I realize that the sessions are persisted forever in the DB.
I didn’t think it was the best idea to keep all the session data so wrote the following script and put it in ‘lib/tasks/session.rake’;
namespace :session do
desc "Prune old session data"
task :prune => :environment do
sql = ActiveRecord::Base.connection()
sql.execute "SET autocommit=0"
sql.begin_db_transaction
response = sql.execute("DELETE FROM sessions WHERE `updated_at` < DATE_SUB(CURDATE(), INTERVAL 1 DAY)");
sql.commit_db_transaction
end
endThis gave me a ‘session:prune’ rake task. The task removes all sessions older than 1 day from the sessions table. I then added a CRON job for in the following format;
0 0 * * * cd /home/user/railsapp && rake RAILS_ENV=production session:prune > /dev/null 2>&1
The job above basically calls the ‘session:prune’ rake task at midnight every night.
The code in the task in MySQL specific but without a model representing the session table I couldn’t (or at least couldn’t think of a way) to make the code any more ruby-fied. In the event that you do have, or decide to create a session model the following code may work in your task (warning: untested);
Session.destroy_all("created_at" < (Time.now - 1.day))Hope the above snippet solves at least one of your ActiveRecord session woes.
Check back soon.

Assuming you’ve followed the Caching Your Photographs tutorial at some point, you’ll probably have had a lot of fun either deleting the cache every time you upload a new photo or you’ve written your own automated method by now. For those of you that haven’t written your own method of dumping the cache yet, here’s how I do it.
First of all, I created a ‘lib/actions’ folder in the root of my rails project. Inside this folder I created the file ‘photography_action.rb’ with the following contents;
class PhotographyAction
def self.clear_cache
ActionController::Base.new.expire_fragment(%r{photography.cache})
end
endThe above fragment naming assumes that your photos are on a page called ‘photography’ if they are elsewhere, change the fragment to expire that page instead.
Fairly simple I think you’ll agree, you may also be asking yourself ‘why the extra file?’, the main reason for the new file is so that the cache clearing can be executed from a new rake task that doesn’t remove all your cached pages or from an admin page on the website.
You’ll also need to update your ‘config.load_paths’ in ‘environment.rb’. After updating, mine looks like this;
config.load_paths += %W( #{RAILS_ROOT}/app/sweepers #{RAILS_ROOT}/lib/actions )Inside some action in some, preferably protected, controller somewhere, add the following (redirecting to anywhere you fancy);
PhotographyAction.clear_cache
redirect_to :action => 'index'Now for the rake task. Inside the directory ‘lib/tasks’ (create it if it doesn’t exists) create the file ‘photography.rake’ then put the following code inside the file;
namespace :photo do
namespace :cache do
desc "Clear out photography cache"
task :clear => :environment do
PhotographyAction.clear_cache
end
end
endYou should then be able to run;
rake photo:cache:clear
From the base of your project in order to clear the cache.
Bear in mind, the code above is literally just a convenient way of clearing out the fragment cache so new photos show up on your photo page, it does not delete photos, nor does it perform a refresh automatically, although, you could add it to a CRON job.
When I get chance, I intend to automate this process and build it into rFlickr along with a new, improved, caching mechanism. I’m sure the above will tide you over for now though.
Check back soon.

After I started to use the rFlickr gem it didn’t take me long to realize that development of the gem had all but halted, yes it worked, which was more than the original Flickr gem did, but it was still a little bit out of date and in the end, a little bit broken.
In one of my older posts I documented a fix for the gem and provided a download to unzip into your plugins folder, however, with the advent of the wonderful GitHub and it’s marvelous gem support I’ve decided to move the project onto GitHub.
I have preserved the original gem’s GPL license and copied the source code from it’s original repository on RubyForge to a new, public, GitHub repository. In the process of the move I have dropped old code from the project, updated the readme & license information and generally performed a little house-keeping.
You can find the project at: http://github.com/digitalpardoe/rflickr/. You can install the gem using one of the following methods. First involves adding GitHub as a gem source (always a good idea) and installing the gem:
$ gem sources -a http://gems.github.com $ sudo gem install digitalpardoe-rflickr
The second method it to add the gem as a gem dependency to the environment.rb of your Rails project:
config.gem 'digitalpardoe-rflickr', :lib => 'flickr', :source => 'http://gems.github.com'And run a rake task to install the gem:
$ sudo rake gems:install
Whilst performing the code migration I also added the fix that was documented in my original post and implemented support for the (not so) new ‘farm’ based Flickr URLs for images (which should make things easier to implement).
The future plans for rFlickr include new tests, improved usage examples, updated readme / documentation and implementation of missing API methods, time permitting of course.
Until the readme is updated please refer to the original post for information on how to use rFlickr.
That’s all for now, enjoy the new gem and as they say, if you don’t like it, fork it.
As you may have noticed, it’s been a long time since my last post. There isn’t really any good reason for this. Plenty has happened, I just haven’t got round to writing any of it down.
First off I’d like to mention the website, it went through a fairly radical redesign a few months ago and I mentioned nothing about it. For some reason it’s not in my nature to be happy with what I make hence the many faces and iterations of the website. This website, whilst being my home on the internet, is also the test bed for my RoR programming, you may get tired of hearing about it’s re-designs and re-codes but that’s part of the reason I created it. Anyway, another re-design is coming, this time it’s not visual but all back end, the main difference you will notice is that I am doing away with user accounts and having a more open comment system (I could be shooting myself in the foot with this decision, we’ll have to see how the spam bots take it). To the people that have commented on the blog already, your comments will be preserved and, when I roll out the changes, I intend to reply to all the comments I haven’t yet replied to.
The second thing I wanted to mention, again website related, is my hosting. A good proportion of my posts seem to be apologizing for the downtime of the website. I was actually getting pretty bored of this so decided to, quite literally, take matters into my own hands. The website is now hosted on a virtual private server set up and maintained by me. This again, may be a case where I’ve shot myself in the foot. For those of you interested, the VPS is provided by the wonderful folks at Bytemark Hosting.
Number three. Many of the posts of my website relate to the use of the ‘rflickr’ RubyGem. Development of this gem seems to have been at a stand still for a good while now, I’ve therefore taken the decision to clone it and try to continue development in my spare time. More on this in a later post.
Four. Any of you interested in my photography will have noticed a lack of it over the past few months, it’s not that I haven’t been taking any photographs, it’s just that I’ve not published any. To try and remedy this I uploaded a batch of photos today that have been sitting on my computer for a while. You can take a look at them on the photo page of the website or on my Flickr page.
Apologies to anyone that has visited the website in the last couple of days, it would appear that there has been a fairly large amount of downtime. Everything is back up and operational again. I will be keeping a closer eye on the status of the website from now on to try and prevent this type of situation arising again. Thanks for your understanding.
Check back soon.
Update: It would also appear that the category browsing is currently broken, I am working on a fix and will push it out shortly.