After Ryan Bates’ really awesome Railscast I figured it was time to get delayed_job happening in my application to process asynchronous stuff – in this case, delivering email “notifications”. If you want to know more about DJ, the Railscast serves as a great starting point.

DelayedJob is awesome, and comes with a rake task that spools up and runs the jobs. What I needed was a way to have Ubuntu control DJ – in particular, to automatically start up if the system has been rebooted… and to give me a quick easy way of probing for the status… and this is where God comes in – the pure ruby monitoring system that it’s author, Tom Preston-Werner describes as “like Monit, only awesome”.

For this I’m standing on the shoulders of giants – check out the links below to the places from which I’ve learned and obtained the DJ-fu.

1. Get delayed_job happy

There’s no scope here to go through how DJ works. A good starting point is the DJ config that the github guys use. Suffice to say… if it’s all apples, you should be able to run the rake task and get it to successfully execute:

$rake jobs:work

2. Get God

$sudo gem install god

3. Get Ubuntu geared up to go for it

For this I’m massively indebted to Tim Riley’s very cool post & script.

Start with a config file – we’ll put it in Ubuntu’s preferred place: /etc/default/god. This script is insanely simple – just sets a var that God uses to find our delayed_job config.

#config for GOD - I point it to a file in my RAILS_ROOT
GOD_CONFIG=/path/to/rails/config/delayed_job.god

And then get an init script – at /etc/init.d/god. This, adapted from Tim Riley’s one (see the link above), should do the trick – it points back to our file at /etc/default/god and sticks its logs and pids in Ubuntu-friendly places:

#!/bin/sh

### BEGIN INIT INFO
# Provides: god
# Required-Start: $all
# Required-Stop: $all
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: God
### END INIT INFO

NAME=god
DESC=god

set -e

# Make sure the binary and the config file are present before proceeding
test -x /usr/bin/god || exit 0

# Create this file and put in a variable called GOD_CONFIG, pointing to
# your God configuration file
test -f /etc/default/god && . /etc/default/god
[ $GOD_CONFIG ] || exit 0

. /lib/lsb/init-functions

RETVAL=0

case "$1" in
start)
  echo -n "Starting $DESC: "
  /usr/bin/god -c $GOD_CONFIG -P /var/run/god.pid -l /var/log/god.log
  RETVAL=$?
  echo "$NAME."
  ;;
stop)
  echo -n "Stopping $DESC: "
  kill `cat /var/run/god.pid`
  RETVAL=$?
  echo "$NAME."
  ;;
restart)
  echo -n "Restarting $DESC: "
  kill `cat /var/run/god.pid`
  /usr/bin/god -c $GOD_CONFIG -P /var/run/god.pid -l /var/log/god.log
  RETVAL=$?
  echo "$NAME."
  ;;
status)
  /usr/bin/god status
  RETVAL=$?
  ;;
*)
  echo "Usage: god {start|stop|restart|status}"
  exit 1
  ;;
esac

exit $RETVAL

4. Tell Ubuntu to start using it at the default run levels.

This ensures that when the system starts up it’ll kick off our DJ task.

$sudo update-rc.d god defaults

5. Try it out – fire her up

$sudo /etc/init.d/god start
Starting god: god.

Checking the status should be equally simple.

$sudo /etc/init.d/god status
dj:
  dj-0: up

That should have you up and running. Drop me a line if you’d like to know more.

Developing sites in the late 90s, it seemed that the basic platform for the web – browsers, the HTML standard, plugins – were constantly changing. Flash was beginning to come of age as a technology; designers were excited; users loved visiting sites just to ‘play’ with the novel navigation systems; our clients all decided that they needed Flash intros, splash pages, navigation.

But the problem, of course, was that it just didn’t work – at least not in enough users’ browsers. It was all very well for Microsoft and Netscape to be releasing new browsers, and for plugin developers like Adobe (not to mention those with other, less wieldy technologies like Java Applets) to continually roll out new versions every few months, but few real sites could rely on particular tools or versions. Sites built with Flash couldn’t be bookmarked. They weren’t accessible. And of course users encountering a site without the requisite plugin couldn’t be relied upon to know how to upgrade, even if we could convince them that they needed or indeed wanted to.

A ‘baseline’ seemed to have been established. The role for a developer was to work with the technologies that our users already had. We could monitor usage, and if a cool new feature was required and available to the majority of users, they key mantra was “graceful degradation”. What it meant, in practice was that users with Windows 98SE – with IE 5, and then Windows XP with IE 6 became the lowest common denominator – the fallback for us all. The best we could hope for was a gradual movement in the baseline – from IE4 to IE5, and so on. Flash was largely out of the question.

The sites push back: the YouTube effect

In 2005, a single website changed all of the rules. It turned out that while uers couldn’t be convinced to change their browser or install a plugin to access most services, nothing would be allowed to stand in the way of them accessing videos of a middle-aged man dancing or a baby lauging

YouTube relied on video features only present in Flash Player 9, and oversaw the growth of Flash support to a staggering 99% of users.

Business as usual for browsers

But in the world of browsers, even the re-emergence of the browser wars with new entrants (Apple, the Mozilla project, Google) didn’t seem to make an impact on getting the main bulk of users to upgrade. Joe Average, it seems, didn’t even know what a browser was

Google could wax lyrical about the coolness of HTML 5 and Google Wave, but the fact remained that two-thirds of users didn’t have a browser that supported it. We would have to wait for users to throw out their old computers.

The sites push back Part II

But then this past fortnight, it seems that a number of sites decided that sitting and waiting wasn’t going to cut it.

Digg got the ball rolling, suggesting that they may start by reducing the functionality (actually removing all interactive features) for IE6 users

Next were Facebook and YouTube, who didn’t so much postulate on developer blogs, as start prompting users to move.

So what does this mean? Can we as web developers now start being aggressive in ending support for IE6? Has the need for graceful degradation been removed?

I’d suggest that there are a couple of ‘take homes’ from all of this:

1. If you’re running a site as big as YouTube, Facebook or Digg, you might be in the position to “push” your users to upgrade
2. If you’re like me and that’s not the case, there’s hope that at some point in the not-too-distant future, your users might have a decent browser with proper CCS3 support… and perhaps some day, HTML5, but that’s another story altogether.
3. If you deploy software into corporate or government environments, don’t hold your breath.

In the meantime, this is what I’m doing:

• I’m taking encouragement from the efforts of the large, social networking sites
• I’m doing my best to encourage the education, government, and corporate clients that we have to consider the cost of maintaining support for older browsers… and the value in other areas (particularly security) in running current-generation software.
• I’m making sure that I’m across efforts like Google’s HTML5 work
• I’m hoping that (although I’m unlikely to ever really use it) Windows 7 (with its baseline of IE8) is a winner.

These are certainly interesting times…

One of the great things about Rails is that of course it automatically does logging… and has different levels of logging for each environment.

Despite this, I had a couple of gripes:

1. The logger doesn’t have a formatter – i.e. in particular, it doesn’t include timestamps.
2. It doesn’t automatically rotate – and the development log can get MASSIVE (I’ve often had them 5GB+)

Additionally, I thought it’d be great if I could separate logs from ActiveRecord and ActionController.

Thankfully, Rails lets us choose the logger that we want to use. We’ll create our own and ask Rails to use it.

Step 1. Set up our logger

We’re using the default ruby Logger (see http://ruby-doc.org/core/classes/Logger.html).

In environment.rb:

active_record_logger = Logger.new(File.join(RAILS_ROOT, "log", "#{RAILS_ENV}_active_record_log.log"), 'weekly')
action_controller_logger = Logger.new(File.join(RAILS_ROOT, "log", "#{RAILS_ENV}_action_controller_log.log"), 'weekly')
active_record_logger.formatter = action_controller_logger.formatter = Logger::Formatter.new

Some notes and options here:

• We’re putting the log file in the default location (RAILS_ROOT/log/)
• This will still produce separate logs for each environment (dev, test, prod, etc)
• This will do weekly rotation – but you could easily switch to ‘daily’ or ‘monthly’
• We can also configure it to a maximum number of old logs + maximum size – see the docs for more info.

Step 2. Ask Rails to use it

In the initializer block in environment.rb…

Rails::Initializer.run do |config|
  config.active_record.logger = active_record_logger
  config.action_controller.logger = action_controller_logger

  #...
end

That should be it. Enjoy.

Being an Ubuntu user, and not a staunch advocate of one of the main text editors (Vim, Emacs), I thought I’d have a go at installing RubyMine. They’ve recently been advertising everywhere in the Ruby world (RailsEnvy, Railscasts, etc)

Installing is fairly straightforward.

1. Get the app and a trial / real installation key. The latest version when I grabbed it was v1.1

2. Unpack it, and move it to /opt/rubymine

tar -xvzf rubymine-1.1.tar.gz
(tar output... extracted a folder named rubymine952)
sudo mv rubymine942 /opt/rubymine

3. Sort out java.

sudo apt-get install sun-java6-jre sun-java6-sdk

Rubymine expects the java executable to be at /bin/java, but Ubuntu has it at /usr/bin/java

sudo ln -s /usr/bin/java /bin/java

4. Add a launcher. I’m adding it to the top panel. Right-click on the panel and choose “Add to Panel”.

There’s an icon at /opt/rubymine/bin/rubymine.png

… and the application is /opt/rubymine/bin/rubymine.sh,

Now to see if RubyMine is any good!

Last week I had the privilege of heading out to St Joseph’s College at Hunter’s Hill to talk about Moodle strategy and administration.

I was able to make use of the great notes that I had previously developed as Creative Commons license.

In case you’re interested, I’ve posted the slides here. There’s no audio of course, but drop me a line if you’d like to chat about anything in them.

At Catalyst we’ve been using Git for several years (since its infancy)… and we currently use git-submodule to install plugins for Rails, Drupal, and Moodle.

The scenario

A common path I follow goes something like this:

• Install plugin direct from a remote repo
• Work happily with it (unmodified) for a while
• Find a bug or need to modify (ARRRGH)
• Fork the original repo, patch… and switch to our fork.

This final step can be a bit of a pain to manage in git-submodule. I do something like this:

Switching over

1. Modify .gitmodules to to change the reference from old to new repo

vim .gitmodules

2. Use git submodule sync

git submodule sync

3. Get into the repo and change references in .git/config to point to new repo

cd path/to/submodule
vim .git/config #and make changes
git remote update

4. Commit any uncommitted changes and push it to your remote (I’m assuming that this is properly configured) – something like

git commit -am "fix scary bug"
git push origin master
git remote update

5. Add the old repo as a remote

git remote add upstream git://github.com/upstream_user/the_submodule.git
git remote update

6. Switch back to the main repo, add and commit .gitmodules and the actual submodule.

You’re done. Let me know if you have any hassles with it.

Back in October 2006 at the Sydney MoodleMoot, Martin Langhoff introduced me to Git. Martin had just started using Git to track Moodle’s CVS… and was hosting it at Catalyst at http://git.catalyst.net.nz

Since then, Catalyst’s repo has become the source for many in Moodle:

• MoodleDocs
• Forum Posts
  • Tracking Moodle CVS with git
  • Tracking Moodle CVS with git
  • Merging Custom Moodle Code With Stable Releases
  • Moving to git, need serious help
  • The continuing story of moving Moodle towards Git

This week, Catalyst’s Francois helped the Moodle.org guys take it a step further … and there’s now an official (read-only) Moodle Git repo: http://git.moodle.org

Hopefully it won’t be long until CVS is just a distant, scary memory.

Setting up a new machine for some pairs programming today gave me the ideal opportunity to look at what’s required now for a barebones installation of Ruby & Rails for Ubuntu

[UPDATED 2009-06-29: Switched from local mongrel to passenger)]

Get Ruby AND RUBYGEMS from apt-get (I’ve always previously compliled rubygems from source on Ubuntu)

sudo apt-get install ruby libopenssl-ruby libruby1.8 libreadline-ruby1.8 ruby1.8-dev build-essential

Get Rubygems – the latest from rubyforge.

wget http://rubyforge.org/frs/download.php/57643/rubygems-1.3.4.tgz
tar -xvzf rubygems-1.3.4.tgz
(tar output)
cd rubygems-1.3.4
ruby setup.rb

I’m now using Passenger in production – let’s get that and Rails

sudo apt-get install apache2-mpm-prefork apache2-mpm-prefork-dev
sudo gem install rails rake passenger

Then the installer for apache2

sudo passenger-install-apache2-module

Follow the Passenger installation instructions. I’ve put the config settings in the recommended location (/etc/apache2/conf.d/passenger)

LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.2.4/ext/apache2/mod_passenger.so
 PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.2.4
 PassengerRuby /usr/bin/ruby1.8

I’m assuming that you know how to configure Apache virtual hosts. Here’s a summary of what I’ve done:

1. Add an entry in /etc/hosts for each local site
2. Add a virtualhost for each site… something like:

<VirtualHost *:80>
ServerName mysite
DocumentRoot /home/me/git/mysite/public
</VirtualHost>

If that wasn’t the path to an actual rails site… put one there

cd /home/me/git/
rails mysite

Check we’re up and running – fire up a browser and go to http://mysite Working? Great!

firefox mysite

Now to get a database running. Here’s the ‘real’ database (postgres)

sudo apt-get install postgresql-8.3 postgresql-client-8.3
sudo apt-get install libpq-dev
sudo gem install pg

…and for sqlite

sudo apt-get install libsqlite3-dev
sudo gem install sqlite3-ruby

If if you’ve got an existing site… there’ll be a bunch of required gems – use the rake task to grab ’em

sudo rake gems:install

After that… it’s time to get cracking with some Rails dev!

For quite some time, the main bulk of my media files have been stored on a networked file server. It gives me ultimate flexibility in terms of how and where I access them: remotely (via ssh) or across the home network to any of a number of devices. Every now and then, however, I need to return them to DVD for playing on a conventional DVD player. It’s really easy to do at the shell (command line).

1. Get the bits of software you’ll need

sudo apt-get install ffmpeg dvdauthor growisofs

2. Convert the avi to a DVD-friendly MPEG2 (it’ll probably be huge in comparison to your avi, so be careful!)

ffmpeg -i my_favourite_xvid.avi -target pal-dvd my_favourite_xvid.mpg

NB. I’m in Australia, so we use PAL-formatted DVD. You could use ‘dvd’ instead of ‘pal-dvd’ if you want NTSC. ffmpeg is a very powerful application – check out the manpage for more.

3. Set up some chapter information.
dvdauthor uses a very simple xml format. You can get away with a very minimal setup like this

…and get it ready with dvdauthor

dvdauthor -x my_favourite_vid.xml

4. Burn it to a DVD
That previous example sticks the VOBs etc in a folder called DVD. Assuming that your dvd burner is at /dev/dvd (it probably is)…

growisofs -Z /dev/dvd -dvd-video DVD/

… and it’s good to go!

I posted a response on this issue on the MITIE Forums and thought I’d tweak and include it here.

Contrary to many common perceptions (and my own feelings on the topic) not impossible to run Moodle in a fairly stable way for a largeish Windows installation. In my experience, you want a team to be confident doing things like:

• merging core Moodle code with your own and community-contributed modules
• executing backup and restore operations (of moodledata files and db dumps)
• performance tuning and tweaking of each element in the system
• understanding and ensuring the security of each component, as well as the whole system
• configuring SSL (if req’d) etc
• quickly building and configuring testing & staging sites (ensuring, for example, that those updates from CVS or Git aren’t going to break your site)
• managing and monitoring logs, scheduled tasks, etc

If you’re keen to support the infrastructure yourself, I’d suggest reading the documentation (http://docs.moodle.org/en/Administrator_documentation) and subscribing to the Moodle.org “Windows-based Servers” forum (http://moodle.org/mod/forum/view.php?id=6799). From some careful searching or from just watching the flow of discussion I’d look to gauge the community’s feelings on the best choices.

Although our team would only use and recommend Linux for the several hundred Moodle sites (with anywhere from 200 – 45 000 users per site) that we support, I personally have run Moodle on IIS (with PHP as ISAPI and then later as FastCGI – NB this discussion on ISAPI being discontinued from php 5.3 onwards ), with DBs in MySQL and (with less success) MSSQL. If your team has great IIS skills and experience and you’ve access to someone with really good MSSQL knowledge, then this could be an option.

Keep in mind too, that running Moodle on Linux doesn’t prevent you from things like: connecting to a MS SQLServer to do automated student enrolment; using AD for authentication and single sign-on, etc

Some other things (like spellcheck, some of the integrated tools like zip, du. etc) are either difficult or impossible to configure.

If you’re self-supporting with Moodle, I think it’s probably wise to make the decision based on:

1. The current and intended future skillsets of your team. This includes all components of the system (the OS, web server, PHP, DB server, etc) in performing the list of activities I outlined above
2. The known stability, performance, security and reliability of Moodle and its core components (web server, PHP, DB server) under each platform
3. The strength of community support for Moodle (and other similar PHP apps) on the platform.

All the best for great Moodling!

After the core process of adding students and faculty, many K12 institutions are keen to add parents to their Moodle site. There are generally two levels at which this can occur:

1. Adding parents to courses
2. Assigning parents to their children – to view their profile, activity reports, grades, etc.

While the first of these two is relatively simple using existing functionality – either manually (eek) via Assign Roles, or automatically, using a Moodle enrolment plugin, the second is a little more tricky. For a while, it has been possible to add parents to a Moodle site, using the “Assign Roles in User” functionality to effectively “enrol” users in other users.

This is outlined in the MoodleDocs… and is profiled in various articles and videos, including this great one by Julian. The issue, however is that it isn’t really possible to do this en masse, i.e. to make it automatic. Discussions such as that at http://moodle.org/mod/forum/discuss.php?d=70539 highlight some approaches, but they’re generally too hacky to use in production.

At Catalyst we recently completed a project for a corporate client in Australia & New Zealand where we needed to automate the process – with a specially crafted Moodle enrolment plugin. As part of that, Catalyst agreed to release the amazing work the developer, Penny Leach to the user contributed (“contrib”) area of Moodle: http://cvs.moodle.org/contrib/plugins/enrol/dbuserrel/

This is how I’ve gone about adding this capability to the Moodle sites at NBCS

Getting the plugin

There are (at least) three ways to get the plugin, and install it in /enrol/ :

1. Download the zip and unpack so it’s in /enrol/dbuserrel
2. Add to a CVS-managed site
3. Transfer from CVS to Git and add as a submodule

Downloading as a zip

As (from what I could see) the plugin hasn’t been profiled in the Modules and Plugins database, there’s no direct link for it… but Moodle’s packaging scripts automatically build it – I guessed the URL at http://download.moodle.org/download.php/plugins19/enrol/dbuserrel.zip

You can grab it and unzip it… and away you go.

Managing with CVS

If you want to get it from CVS, you can, with (for the latest Moodle 1.9 version):

cvs -z3 -d:pserver:anonymous@SERVER.cvs.moodle.org:/cvsroot/moodle co -r MOODLE_19_STABLE contrib

replacing SERVER with your local mirror. E.g.

cvs -z3 -d:pserver:anonymous@uk.cvs.moodle.org:/cvsroot/moodle co -r MOODLE_19_STABLE contrib

Tracking with Git

Adapting the process from Dan P’s Docs page http://docs.moodle.org/en/Development:Importing_Moodle_CVS_history_into_git

#!/bin/bash
CVSROOT=:pserver:anonymous@uk.cvs.moodle.org:/cvsroot/moodle
MODULE=contrib/plugins/enrol/dbuserrel
INSTALLDIR=dbuserrel
git-cvsimport -p x -v -k -o cvshead -d $CVSROOT -C $INSTALLDIR $MODULE &> cvsimport.log

Let’s get a branch to work on – we want to track the 1.9 stable branch. If you’ve already got a local branch (i.e. with your regular customisations, themes, etc) then you’ll of course want to branch from that for this test.

git checkout -b mdl19-parent-test origin/MOODLE_19_STABLE

We’ll add the submodule

git submodule add /path/to/my/contrib_module enrol/dbuserrel

git submodule init
git submodule update

git status

shows

new file:   .gitmodules
new file:   enrol/dbuserrel

let’s commit the changes to this branch

git commit -am "enrol/dbuserrel: added local git repo as submodule"

Updating to keep track of upstream changes is a matter of

1. running our import script again (to do CVS > GIT)
2. switching to our git branch and running
   

   git submodule update
   

The code is now in my repository, and ready to deploy with my moodle code. Hold on just a tick, and I’ll be back with another post on the user end of things – i.e. how to enable and configure it in the browser.

At Catalyst, we’re doing some work as part of a larger project for the NZ Ministry of Education, helping to make Moodle easier for K12 (school) settings.

We’re looking to put together a special K12 blend of Moodle that:

• is easy for school system administrators to install & configure
• is already configured for typical K12 structures
• gives teachers a bit of a ‘leg-up’ to get moving quickly.

These suggestions are designed to guide and inform thinking about such a development

A special support site.

The Moodle.org forums, particularly the Moodle in K12 Schools forum, are particularly helpful, but they address an international audience, and (with the exception of that K12 forum) are predominantly geared towards large-scale university or corporate installations of Moodle. A support site will be created and managed with the goal of providing:

• Aggregations of content from existing sites (Moodle.org, MITIE (in Australia), and others.
• Specific community-driven content that is local to the Australian and NZ contexts
• Downloads of our ‘K12 special blend’ Moodle and possibly some special tools, themes, etc.

It would aim to be predominantly teacher-centered, with additional focus on school system administrators as well as school Principals and key decision-makers – enabling informed decisions to be made regarding the selection, adoption and support of Moodle. It is intended that this would augment not replace, the Moodle.org site.

Getting up and running (Installation and Configuration)

In K12 environments, the installers and managers of Moodle sites are often either teacher enthusiasts, or system administrators with little or no experience installing, configuring, securing and performance tuning web applications. Furthermore, system administrators are often working in Microsoft Windows™ environments, without experience working with the main, preferred building blocks of Moodle: Linux, Apache, PHP and open source databases like PostgreSQL and MySQL.

Suggested changes include:

1. The installation process could be modified to make it easier to choose sane/typical settings for schools (e.g. ’messaging disabled, self-registration disabled, etc.).
2. Many of the activity modules and filters useful for schools could be pre-selected, and possibly ‘bundled’ (subject to licensing). E.g. (Feedback and/or Questionnaire modules, Multimedia filters enabled).
3. Enrolment is a typical bug-bear of Administrators in schools. Key tasks here will be to (A) identify common systems of use in Australia & NZ and provide guidelines for how to automate enrolment and/or (B) to work on a flexible enrolment management tool to simplify integration and automated enrolment (more to come on this idea later). It may also be advantageous here to provide information on the Support site about which existing student information systems provide “out of the box” integration with Moodle.

Making Moodle more familiar for teachers and students

Often the presentation of Moodle sites (wording, sequencing, etc. is not that of the typical (is there such a thing) school setting.

Suggested changes include:

1. Change the terminology with specific language packs. The language of Moodle is often not intuitive for teachers. Customizations of the language pack could help make this clearer. E.g. (‘courses’ become ‘classes’, ‘Assign roles’ becomes ‘Class enrolment’ or ‘Class members’).
2. Develop / package some themes. Many standard Moodle themes are particularly formal and text-heavy. A further set of themes, specifically developed and/or licensed for distribution in schools, could be packaged, allowing for simple(?) customisation for schools. This could be incorporated together with the ‘course logo’ idea, outlined below. The “PETE” (Primary Education Through E-learning) theme at Sydney’s Northern Beaches Christian School is a great example of this.
3. Customise the course list pages to allow for a class ‘logo/icon’. One drawback of the standard lists of Moodle courses is the heavy reliance on text. One treatment for this is the development of a feature to allow a teacher to specify a class logo or icon image. This could be displayed in addition to the name when students are looking at lists of courses.
4. A class ‘default’ page. Particularly in the Primary / Elementary school level, students have a single class that forms the basis for all or most of their study. In such a context, the usual process of logging into a homepage and then either navigating the course/category hierarchy or selecting a course from the ‘My Courses’ block is of little use. A customisation to this could enable students to specify (of have specified for them) a ‘default’ or ‘home’ course – to which they are directed after login (unless of course they have arrived at the site by visiting a specific, deep link to particular Moodle content).
5. A new Course Format. From my post at http://moodle.org/mod/forum/discuss.php?d=120087:
   “I’ve worked in many K12 schools as a teacher and Moodle admin… and have found that the StudyCalendar course format (http://docs.moodle.org/en/Study_calendar_course_format) from Sam Marshall / the OU is almost right for what many teachers need… and similar to what’s being described here:

1. just shows the ‘current’ topic (e.g. ‘this lesson’) 2. allows teachers to ‘group’ together topics (into what we’d actually call topics). “What I’d like to see is this idea expanded to allow something a little more granular – where a ‘topic’ or ‘week’ is instead a ‘lesson’/‘class’… and could have a date/time attached to it. These could then be grouped together so that a student could see how or where this lesson fits into the current flow… but could look ahead (if it has been prepared) or back in time along the timeline to see upcoming or previous ‘classes’. Having AJAXy up/down scrollability of this would be VERY valuable…”

Further thoughts – E-Portfolio systems

One item under consideration is the simpler packaging of Moodle with the Mahara e-portfolio system. Whereas Moodle is predominantly centred on the classroom or ‘course’, Mahara provides an individualised learning environment, where students construct a personal space by bringing together items from the web, their classroom files, and their own profile. Mahara and Moodle already support tight integration, however this can be significantly simplified by either:

1. Providing simpler, step-by-step instructions that make more assumptions about how schools will configure the relationships between systems or (preferably)
2. Pre-configured, packaged installation (a “1-click” installer?) incorporating those assumptions. For example, an initial set of keys generated; Options for trust between systems pre-selected.

Last month I saw toolmantim’s cool presso on Sinatra… and thought I’d have a go at a site… and this is it.

This little site/app is very much inspired by that site.

The basics are:

• No database – all articles stored as HAML
• No comments (a bit of a Calacanis thing there)
• An opportunity to learn Sinatra, HAML and SASS

Thinking now about the next step (and keen to get old blog posts in here too of course)...

At TBS, Dann and I have Google Apps Premier Edition. Like all Gmail users, I’d noticed at least one of their recent outages, but was pleasantly surprised to see their direct acknowledgement of the outages, and now their specific solution to the problem (via email). Imagine if our Aussie telcos took responsibility for the provision of their services like this!

We’re committed to making Google Apps Premier Edition a service on which your organization can depend. During the first half of August, we didn’t do this as well as we should have. We had three outages – on August 6, August 11, and August 15. The August 11 outage was experienced by nearly all Google Apps Premier users while the August 6 and 15 outages were minor and affected a very small number of Google Apps Premier users. As is typical of things associated with Google, these outages were the subject of much public commentary.
Through this note, we want to assure you that system reliability is a top priority at Google. When outages occur, Google engineers around the world are immediately mobilized to resolve the issue. We made mistakes in August, and we’re sorry. While we’re passionate about excellence, we can’t promise you a future that’s completely free of system interruptions. Instead, we promise you rapid resolution of any production problem; and more importantly, we promise you focused discipline on preventing recurrence of the same problem.

We’ve also heard your guidance around the need for better communication when outages occur. Here are three things that we’re doing to make things better:

1. We’re building a dashboard to provide you with system status information. This dashboard, which we aim to make available in a few months, will enable us to share the following information during an outage:
   
   • A description of the problem, with emphasis on user impact. Our belief is during the course of an outage, we should be singularly focused on solving the problem. Solving production problems involves an investigative process that’s iterative. Until the problem is solved, we don’t have accurate information around root cause, much less corrective action, that will be particularly useful to you. Given this practical reality, we believe that informing you that a problem exists and assuring you that we’re working on resolving it is the useful thing to do.
   • A continuously updated estimated time-to-resolution. Many of you have told us that it’s important to let you know when the problem will be solved. Once again, the answer is not always immediately known. In this case, we’ll provide regular updates to you as we progress through the troubleshooting process.
2. In cases where your business requires more detailed information, we’ll provide a formal incident report within 48 hours of problem resolution. This incident report will contain the following information:

   1. business description of the problem, with emphasis on user impact;
   2. technical description of the problem, with emphasis on root cause;
   3. actions taken to solve the problem;
   4. actions taken or to be taken to prevent recurrence of the problem; and
   5. time line of the outage.

1. In cases where your business requires an in-depth dialogue about the outage, we’ll support your internal communication process through participation in post-mortem calls with you and your management team.

Once again, thanks for your continued support and understanding.

Sincerely,

The Google Apps Team

DHH announced today that the Rails team is moving to Git. Although this was met with howls of protest from some SVN-loving Windows users (see the comments to David’s post), this can only be a good thing in the longer term.

At TBS, we’ve recently moved to Git for managing our own projects. DHH’s move is definitely a positive step. There are already a stack of resources around to help Rails developers with the transition, my favourite being Scott Chacon’s screencast. Hopefully the days of dodgy, centralised source code management are over! Next task is to get my trusty design buddy over to using MSysGit (Git for Windows users).