iMatt :: The Blog of Matt Clare

I’ve been listening to and reading about the aftermath of the Vancouver riots and I still can’t muster up any sympathy for those outed as suspects in the rampage “by the internet”.

The specific example of Nathan Kotylak is the most interesting at the moment. He appears to have paid the highest cost for his actions so far.

No one should be making threats towards the Kotylak family, no one but the courts can judge his guilt or apply a penalty and I appreciate Nathan’s apology – but I’m still not willing to excuse a teen learning publicly that there a consequences to public violence.

I grant that the violent destruction of [capitalist] property is how some choose to express themselves politically or otherwise. But I’m no fan of violence, and I don’t think it’s a meaningful way to make one’s point.

Black bloc or Canuck bloc individuals engaging in these activities know the consequences of their actions. Their intent not to get caught only mitigates their liability in their own minds; not the victims’, other citizens’ or in the justice system.

People need to learn that committing violence in public and assuming it won’t be made public is like assuming you can swim and not get wet: it’s impossible unless you wear a full body suite!

I had a great time at the Sakai Conference 2011 in Los Angeles.

My presentation this year was titled LMS-Based Teaching Hacks: A Collection of Simple Ideas to Tweak Your Teaching Within an LMS. It was well received and the room was standing room only.

Much as the development community would use the term, these teaching hacks were intended to be pragmatics solutions about using a resource not as it was originally intended to be used.

I shared a collection of simple ideas that can magnify the impact of an instructor’s teaching through the use of an LMS labelling them “Teaching Hacks”. Some of the teaching hacks addressed concerns with student attendance and communications, others with facilitating collaboration and other elements of active learning.

Not only were there a lot of good questions, but I also was given some great feedback that I’ve already incorporated.

Here’s the collection and other resources now posted at the Sakai Confluence Wiki site: confluence.sakaiproject.org/display/CONF2011/2011-16-15+LMS-Based+Teaching+Hacks

I enjoyed main of the other sessions focussing on Sakai’s future with OAE, it’s strong base with CLE.

I was able to engage in some interesting discussions that informed what I’m interested in with Isaak/Sakai at Brock University. The sessions on Turnitin integration with Assignments(2) were useful, and I think the Sakai community is close to addressing a long standing issue with its help files (although not there yet) – I promise to help.

Good conference.

The bottom line: I didn’t get your E-Mail last week, please re-send it. Sorry about that.

Here’s the story:

I’m in the process of consolidating my DNS names/services at Hover.com. Hover.com is retail side of the Canadian internet stalwart TuCows.com.

Hover offers a service for $25 for their concierge to handle DNS address transfers to Hover. I opted in, as I had previously transferred some domains and the “locking” etc. was a little tricky and with the address passnerd.com , rimcount.com , timelesstweet.com , clurko.com and lindsayclare.ca were all at A2Webhosting.com and mattclare.ca was at CanReg.com. I always knew .ca would be a problem, but I had no idea how big it would be..

I had called Hover’s toll-free number two weeks before mattclare.ca expired. It sounded like lots of time as we talked through the plan.

I sent my concierge at Hover my passwords and he changed the contact E-Mail at A2WebHosting to his own. The .com address were transferred to Hover very quickly without issue.

CanReg refused to send the transfer E-Mails to my concierge’s E-Mail address, despite appearances from their web interface to suggest everything had been changed. CanReg kept sending E-Mails to my @mattclare.ca address. We both tried, but despite a number of changes in a number of locations the transfer details were always being sent to @mattclare.ca

The transfer was started on a Friday in the early afternoon. My concierge warned me by E-Mail that he was about to start and shortly after the transfer E-Mail showed up. I wasn’t able to check my E-Mail that afternoon until 5:30 that night and even though Hover is open 8:00 to 8:00, they apparently don’t hand-off cases. My E-Mail sat in my concierge’s inbox through the Sunday expiration of my mattclare.ca domain.

CanReg put my site in “auto-renew grace” which basically told the rest of the internet that they know about mattclare.ca, but didn’t know where to direct anyone. CanReg also kept sending all of their transfer e-mails to my @mattclare.ca address, which they had taken off-line. Thanks.

By Tuesday my concierge (with my help) fully understood the challenge that now faced us. With my encouragement, my concierge got in touch of with CanReg on Tuesday. CanReg indicated that if I wanted my E-Mail changed it would require a signed and witnessed document, plus government ID, to be faxed or scanned plus E-Mailed to them.

Today I sent an “or-else” E-Mail to my concierge who suggested that if I did renew with CanReg Hover wouldn’t charge me for that domain (I assume for a year). I did renew with CanReg (at a twice the price of Hover) and that’s how I got my mattclare.ca domain back. Perhaps I should have done this last week, but I really didn’t think this would be so hard to complete.

So now CanReg’s insistence on sending transfer E-Mails to my @mattclare.ca will at least be received.

I’m pretty frustrated, but I’m not exactly sure where to direct that frustration. Here’s hoping being a Hover customer gets better from here.

Update: Tuesday June 7, 2011 10:06 AM

Hover has completed the transfer and is neither charging me for the mattclare.ca registration or their concierge fee. Seems like the best thing they could do at this point. I suppose it’s not a happy ending unless there’s some drama along the way.

If your web site is running on Apache, and almost all are, there’s a simple way to protect directories on your web server. This method can be very secure, when combined with HTTPS and some good practices on your part, but it can also be a simple way to limit access to just a few people who know a password – perhaps as an alternative to Facebook sharing.

The feature being used is Apache’s HTTP Basic Authentication module. Apache has their own How-To at their web site, but here are the basics:

You need to add two files to your web server, and it helps if you have access to a terminal/command prompt.

Here are two key files and their their contents.
.htaccess

#Force HTTPS
#RewriteEngine On
#RewriteCond %{HTTPS} !=on
#RewriteRule ^(.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

AuthType Basic
AuthName "Restricted Files"
AuthBasicProvider file
# Needs full unix file address, output of pwd command
AuthUserFile /var/www/html/examples/guest_w_pass/.htpasswd
Require valid-user

These are basic .htaccess directives, that most web servers should allow. The first segment is to force the use of HTTPS, you might want uncomment that if HTTPS is important to your application. The second section turns on basic authentication and directs the web server to where to get the password file – you can put the password file anywhere your web server can access it and it does not have to be in the same folder as the .htaccess file. You are responsible for finding the full unix path to the file, either from the pwd command or the “Get Info” option inside a file browser.

.htpasswd

guest:{SHA}K8+J8fKKKxjnREM2J4/C72Qawa4=


This file is the results of the command htpasswd -sc .htpasswd guest. The s after the – is for SHA-based password hashing and the c after the – is for create. The file can be added to or updated with the command htpasswd .htpasswd username. Run the command htpasswd --help for more information.

The password file can be generated anywhere. You can make the file through Terminal application on your own Mac or from a trusted web site like www.htaccesstools.com/htpasswd-generator/. Once you have file created you can uploaded it to the web server – if you have terminal access to your server you can of course do everything there. Only web servers configured in the worst possible way will ever disclose to the rest of the web a file or folder prepended with a . — like .htpasswd — but you may want to double-check.

And that should do it. Hopefully this will be a simple and time-tested way to limit access to content on your web server.

Here are the results you’ve been waiting for: the results of RimCount.com tracking of the Roll Up The Win Campaign from a large Canadian Coffee and Donut chain.

RimCount.com collected tweets with the hastag #rolluptherim and extracted ratios and recorded them.

The site really took off when it started tweeting back with the Twitter account twitter.com/rimcountdotcom . The site automated the awarding and notification of “badges” for different items like drinking more than one “rim” a day, or tweeting about it more than once a day. Of course the best and worst record holders were notified. I was also contacted by the author of the Facebook App “My Rollups” apps.facebook.com/myrollups to compare notes – looks like Facebook users are a little luckier.

Here they are, as unscientifically tracked on Twitter, in 2011 there were:

• 21552 rims
• 4181 wins
• 17439 losses
• 13007 tweets
• 5853 Total tweet’ers

Here’s a Wordle of the top 150 words tweeted with the hastag #rolluptherim (without that tag)

Here’s looking forward to next year!