The major change for this version is a switch to Facebook’s mobile pages for easier parsing. You can include this script into all sorts of wacky things.

Usage example:
perl facebook-status-2.1.pl

Sending... Done!

For those unfamiliar with the Apple Double problem, it is an old bug that exists from the early days of Mac OS X. Here’s the explanation from the Apple Knowledge Base:

Before Mac OS X, the Mac OS used ‘forked’ files, which have two components: a data fork and a resource fork. The Mac OS Standard (HFS) and Mac OS Extended (HFS Plus) disk formats support forked files. When you move these types of files to other disk formats, the resource fork can be lost.

With Mac OS X, there is a mechanism called “Apple Double” that allows the system to work with disk formats that do not have a forked file feature, such as remote NFS, SMB, WebDAV directories, or local UFS volumes. Apple Double does this by converting the file into two separate files. The first new file keeps the original name and contains the data fork of the original file. The second new file has the name of the original file prefixed by a “._ ” and contains the resource fork of the original file. If you see both files, the ._ file can be safely ignored. Sometimes when deleting a file, the ._ component will not be deleted. If this occurs you can safely delete the ._ file.

Essentially, when you’re working on files located on a network share you end up with duplicates of the file with a “._” prefix. The files are empty and are quite the annoyance. They are removed when the network share is unmounted. However, I leave my share mounted for long periods of time and the files make a mess of my Subversion status reports.

You can run the following command to clean the files up.

find . -name '._*' -exec rm '{}' ';'

You could also make this into a launchctl or cron task. Happy hacking!

I first create a PHP script that bootstraps Drupal. Here is an example of a script that will rebuild the menu router tables.

// Bootstrap
require_once('includes/bootstrap.inc');
require_once('includes/common.inc');
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
 
// Rebuild menus
menu_rebuild();
print 'Menu rebuild complete\n';

I name this script rebuild_menus.php and upload it to my Drupal directory. Then, I create a text file on my desktop that contains a list of all the Drupal websites. This is an abbreviated example:

http://example1.com
http://example2.com
http://example3.com
http://example4.com

Finally, I execute the script on all the sites by running the following command:

for url in `cat list.txt`; do echo "Running script on $url"; curl $url/rebuild_menus.php; echo; done

Fortunately, Adium has good Applescript support that can be extended via a shell script. I wrote this bash script that does exactly that. It is command line driven so I can SSH into my home or work computer and execute it.

#!/bin/sh
 
# Copyright Matt West  5/23/2009
 
#
# Usage
#
usage() {
    echo "Usage $0  [command]
 
Options
    -a account
        Account screen name
    -l
        Display the current account status and away message
    -m message
        Set account as away with a message
    -t type
        Status type: available, away, invisible, offline
"
    exit 0
}
 
#
# Grab our environment
#
. /etc/profile
 
#
# Define
#
APP="Adium"
 
#
# Get opts
#
while getopts "a:lm:t:" OPTIONS; do
  case $OPTIONS in
    a)  ACCOUNT=$OPTARG
        ID=`osascript -e 'tell application "'$APP'" to get id of accounts whose name is "'$ACCOUNT'"'`
        ;;
 
    l)  # Display the current account status
        STATUS=`osascript -e 'tell application "'$APP'" to get status type of account '$ID`
        MESSAGE=`osascript -e 'tell application "'$APP'" to get status message of account '$ID`
 
        if [[ $STATUS == 'away' ]]; then
            echo $ACCOUNT is currently away with the message \"$MESSAGE\" #"
        else
            echo $ACCOUNT is currently $STATUS
        fi
        exit 0
        ;;
 
    m)  MESSAGE=$OPTARG;;
 
    t)  STATUS=$OPTARG;;
  esac
done
 
# An account is required
if [[ -z $ACCOUNT ]]; then
    usage
else
    if [[ -z $ID ]]; then
        echo "Error: Couldn't find the account $ACCOUNT"
        exit 1
    fi
fi
 
# Set the status type
if [[ -n $STATUS ]]; then
    osascript -e 'tell application "'$APP'" to set status type of account '$ID' to '$STATUS
fi
 
# Update the away message
if [[ -n $MESSAGE ]]; then
    osascript -e 'tell application "'$APP'" to set status type of account '$ID' to away'
    osascript -e 'tell application "'$APP'" to set status message of account '$ID' to "'"$MESSAGE"'"'
fi

To use, copy and paste this code into an empty text file and name it adiumcontrol (or whatever you’d like). Then make the file executable:

chmod +x adiumcontrol

Then try it out. You control each IM account independently. In this example ‘habitcky’ is my AIM screen name:

./adiumcontrol -a habitcky -l
habitcky is currently available

Set your away message:

./adiumcontrol -a habitcky -m "I am currently unavailable"

Sign yourself offline:

./adiumcontrol -a habitcky -t offline

Sign yourself back online:

./adiumcontrol -a habitcky -t available

Here are some things to remember when writing a proposal for the Summer of Code:

Understand the organization you’re applying to work with
Before you spend any time writing a proposal you need to understand the organization, software, and problem you’re working on. Download the latest version of the code and read through some of it. Install and use it. Look at the documentation. See what the software can and can’t do and how it applies to your project.

Write a good proposal!
After you’ve looked through the code and feel you have a good understanding of the problem then you can sit down and start writing. Your proposal should include all the points of the problem, why they’re a problem, how you’re going to address the problem, and how your solution to the problem will benefit the organization.

Only write a few proposals
A good proposal takes a long time to write. You need to fully understand the problem and the organization before writing a good proposal. You may think that writing a bunch of proposals for many different organizations will increase your odds of being selected, but instead you’re just decreasing the quality of your proposals and reducing your chances of being selected.

Ask questions
Mentors are hanging out on IRC all day waiting for you to ask them questions. We’re excited to do it because we get to see the interest in our organization. We’d also be glad to look over your proposal and provide feedback before you submit it to the SoC.

To give students an example of what a proposal should look like I’m going to post my proposal from last year. Unfortunately, I can’t find the one from 2007 that I think is a little better.

Abstract

The Geeklog installation wizard makes setting up a new, or upgrading an
existing, Geeklog site a quick and painless process. However, there are
two situations where a website administrator must still perform tasks
manually: managing plugins and migrating from a backup. My proposal is
to add a plugin management utility that will be rolled into the
installation process and will allow direct control of plugins as well as
a migration utility that will give the user the ability to restore
Geeklog from a backup seamlessly.

PROJECT DETAILS – PLUGIN FEATURE

The plugin installation process will be made steamless for the user. An
“Advanced Installation Options” link will appear underneath what is
currently the install configuration options form on page 2 of the
installation and when clicked will take the user to a separate page to
manage plugins (and migration, which will be discussed in the next
section). The list of plugins will be populated by listing the contents
of Geeklog’s plugins directory. A file upload form will give the user a
simpler method of uploading the plugin, which will require the plugins
directory be write-able by the web server. By default all of the plugins
inside the plugins directory will be installed, unless the user chooses
to not install them. The plugins that are selected for install will be
sent with the rest of the form data from step 2 to step 3 of the
installation wizzard where each plugin’s installation script is executed.

The plugin installation during the upgrade process will be similar to
the new installation process described in the previous paragraph. If a
newer version of an installed plugin exists the plugin will be
automatically upgraded. The user will still be given the ability to
install new plugins during the upgrade in the same way as a fresh install.

In addition to the installation wizard, the plugin management panel
inside the administration area will be modified to add the ability to
upload a plugin which will make adding new plugins quicker.

For users who wish to create a custom Geeklog distribution with their
own favorite plugins a simple stand alone utility will be developed.
This will consist of a single PHP shell script that downloads and
decompresses the Geeklog tarball and lists the contents in the plugins
directory. The user will be have the ability to deselect and remove any
of the listed plugins and also given the ability to add additional
plugins by either copying a plugin tarball, or directory, from another
directory on the local machine or specifying a URL to the plugin tarball
on a remote server. After the user makes selects the plugins they want
the entire geeklog directory will be recompressed with the new plugins.
All the plugins in the plugins directory will be installed by default,
unless unselected by the user, during install.

PROJECT DETAILS – MIGRATION ASSISTANT FEATURE

Geeklog currently has a backup feature which creates a SQL table scheme
and data file. This file will be used as a restore point for the
migration feature.

The option to migrate from backup will be added to the “Advanced
installation options” area proposed above for plugin installation. In
this area a checkbox to “Import from backup” will appear with the option
to select an existing backup from the backups/ directory or to upload a
backup file. A message will be displayed to users to warn them about
possible timeout issues when uploading large files and that they may
want to upload their file via FTP to the backups directory instead.

Once a backup file is selected the migration process will import the
database table schema and data from the backed up SQL file. Some
additional analysis will need to be taken during this step so that large
database imports do not exceed the web server’s maximum script runtime.
A possible solution would be to perform a staggered import, where the
import process is broken into smaller pieces. Dirk has suggested a
utility called BigDump which does this for MySQL. We might be able to
simply implement that utility with a modification to allow it to also
work with MS SQL.

After the database has been imported the script will query the
‘conf_values’ table to ensure the stored paths match the new system
paths. If they do not they will be updated based on the data from the
installation form or the user will be prompted to define the path. This
is similar to a fresh installation where all paths must be set. The last
step will be any remaining checks to ensure all necessary database
information exists, that required plugins exist (if they don’t they will
be disabled in the database until the user installs them) and the
correct system files are in place.

Finally, the Geeklog upgrade documentation makes a strong recommendation
that the user backup their database before attempting to upgrade, so why
don’t we offer to do this for them? An option will be added during the
upgrade process to ask the user if they’d like us to backup their
existing installation. This will not be selected by default because of
the time it would add to an upgrade. If selected a backup of the
database will be saved to the backups directory before updates are performed.

BENEFITS

- Plugin installation steps will be reduced and will require no command
line access of file editing resulting in fewer sources of user error.
- Migration feature would give users the ability to easily and reliabily
restore from backups without remote shell access.
- Automatic backup option before performing an upgrade will create a
quick and simple restore option for users that experience a problem in
the upgrade process.

TIMELINE

Week 1: Checkout latest GL package and start evaluating the code base
Week 2: Final plugin installation and migration assistant format design
Week 3-4: Code furiously, develop unhealthy caffeine and energy drink
dependence
Week 5: Rough working plugin installation feature
Week 7: Rough working migration assistant feature
Week 8: Midterm, submit code for evaluation
Week 9: Make revisions based on any mentor suggestions
Week 11: Major work complete on plugin installation feature, submit to CVS
Week 12: Major work complete on migration assistant feature, submit to CVS
Week 13: Begin to complete documentation and testing
Week 14: Iron out final bugs
Week 15: Submit all deliverables for evaluation

DELIVERABLES

- Plugin installation/management added into installation script
- Plugin installation/management added to administration panel
- Stand alone command line utility to create custom Geeklog distributions
- Migration feature added into installation script
- Additional English localization entries
- Additional install documentation

ABOUT ME

I am a 23 year old graduate student at D’Youville College in Buffalo,
NY, USA. I enjoy programming for the web but more importantly I love
creating a rich experience for those who use my software. I have
previously worked with Geeklog in the 2007 Summer of Code program and
the experience was invaluable. I had an incredible time and hope to be a
participant again this year! I believe I am the best applicant for this
project because I wrote and am deeply familiar the current installation
wizard script.

I am excited to be mentoring the Plugin Repository project. Geeklog’s current plugin structure is very out of date and cluttered. Hopefully a student can develop a good proposal for how we can reorganize our plugins to make development, distribution, installation, and maintenance easier.

It’s getting a little out of control..

The program is currently accepting applications from open source organizations who would like to mentor students. We have submitted an application for the Geeklog project and hope to participate again this year. Other organizations can submit an application using Google’s new App Engine.

If you’re a student developer I strongly encourage you to participate in the program. I was fortunate enough to work with the Geeklog project the past two summers and the experience was invaluable. Both years I was mentored by Dirk Haun, the Geeklog project maintainer and lead developer. The software planning, design, and development skills I learned from him far surpassed my expectations. This year I’m excited to give back to the program and share what I’ve learned with a student by mentoring one of the Geeklog projects. We have a few things to finalize with Geeklog to get the project and documentation ready for new student developers but things are coming along nicely.

The application deadline for organization applications is Friday, March 13th. The list of accepted organizations and projects will be posted on Monday, March 23rd. That’s when the students get to begin writing and submitting their project proposals.

I plan on posting a guide on writing a good student project proposal soon.