tryGit: it’s the teach, not the tech.

I picked up a link to a free online course from a recent Linux Voice podcast. I tried the course and wasn’t really impressed with it. The interface is nice, with an embedded virtual terminal to let you practice typing in the commands but the pedagogy is pretty weak. There’s nothing in the presentation that indicates that the designers understand how to construct understanding: all this lovely bit of code is doing is rehearsing a list of commands (and there’s even a click-once shortcut if you can’t be bothered actually typing). It’s more of a checklist than a course. It would be easy to turn it into a really effective bit of online learning with the addition of some better structure and graphics, and maybe a little assessment for learning. A shame, really, as it is clearly a loss leader to sell the Code School itself: I am in the market for some good quality online learning in their area, but I’m not likely to look any further at their catalogue.

ownCloud installation on Centos 7

For some time, I’ve wanted to have a calendaring tool independent of Google Calendar, which has become a central tool to my productivity and a source of concern as to how much data profiling results from it.

This afternoon, I installed the open source ownCloud file storage, calendar and contacts suite on my Centos VPS. It was a straightforward exercise:

  • Create a subdomain on the server and switch it to use PHP 5.6. Add /dev/urandom to open_basedir in php settings.
  • Make a data folder behind the web root, chowned to the web user.
  • Create a MySQL database for the ownCloud service.
  • In the web root folder, get the software:

curl -O https://download.owncloud.org/community/owncloud-10.0.3.tar.bz2

  • Check the MD5 hash, chown and extract. Copy the extracted files into the root folder (be careful to include dotfiles, e.g. cp owncloud/* . and cp owncloud/.* .)
  • Visit the domain to configure the installation.

What this server now provides is an independent calendar service, contacts, and secure file storage, at no additional cost and under my own secure control.

Migrating from AudioBoom

I’ve been podcasting using Audioboo (now Audioboom) since 2011 and supported the service by paying for a podcaster subscription for much of that time. Audioboom introduced a new pricing structure that I can’t sustain so I need to migrate to a new solution.
Using my LAMP server, which has bandwidth capacity for my podcasts, I set up a new subdomain on http://podcast.cullaloe.net and installed podcastgenerator 2.6. I uploaded a selection of episodes over FTP and used the import function in the admin interface (I had to change the timestamp using touch -t yymmddhhmm.ss filename.mp3 for each episode to get them into the right time order) finally editing in the description for each show.
For the most part, my episodes had embedded images in the mp3 file, but where they did not, I thought about having to edit the ID3 tags. I read about a method for avoiding this which includes posting an image (say, 300×300) for each track within the long description field in the admin interface of the new software, but this doesn’t seem to work. There’s a command line way to pull an image into an .mp3 file which sometimes works as an alternative:
ffmpeg -i input.mp3 -i cover.png -map 0:0 -map 1:0 -c copy -id3v2_version 3 -metadata:s:v title="Album cover" -metadata:s:v comment="Cover (Front)" out.mp3
If that doesn’t work, you can just drop an appropriate jpg/png in the images folder of the same name as the episode audio file.
The iTunes podcast feed was easily updated by visiting https://podcastsconnect.apple.com/  and pointing to the new feed. Note that podcast artwork must now be between 1400 x 1400 and 3000 x 3000 pixels, JPG or PNG, in RGB color space, and hosted on a server that allows HTTP head requests. The iTunes podcast updated overnight without any difficulty.
Finally, I emailed audioboom to request they apply a 301 or iTunes <itunes:new-feed-url/> redirect to the old feed (pointing to the new one).