Two Predications about the Future of Apple Software

Now that the Mac OS operating system updates are free, and the development cycle for that OS is so stable, I think this is leading to the inevitable conclusion:

One day major dot-number OS updates (iOS, and Mac) and iWork updates are going to be automatic, even required.

As it is, Apple already enjoys a very rapid rate of adoption by its users, and not updating immediately seems counter-intuitive. At our school now, we are in the position of asking users to not update which rings hallow when you consider just how few issues there actually are. The real issue is really all about time management: We don’t want to overwhelm our users with things like “update to the latest and figure out how to use it”, but still… it’s so easy now all it does is take the fun out of it all.

The only real technical issue with the Mavericks update is actually with the new iWork suite: The new format is fundamentally incompatible with the old one, and vice versa, and I think I know why. The new format encompasses changes required if the software is going to be sharing documents online as well. The old format used XML which has to be uploaded and downloaded in one swoop; but not so with the new Google Docs-style of breaking everything down into small chunks so that it is network-friendly. That’s a fundamental change to the architecture that requires breaking with the past.

So, the whole reason to make it backwards-incompatible is so that you can have Pages for Mac, iOS, and the web.

Which brings me to another prediction:

A future XCode is going to be a development environment that allows devs to write Mac and iOS and web-based software with the same codebase.

If it sounds complicated, it is. Apple is going to need a way to make sure users are using the same operating system everywhere, to make that sort of system sustainable, hence why this prediction is predicated by the first one.

Okay, one more prediction, which is also actually more like deduction:

Future Software updates will always be backwards-compatible

Low Standards in Educational Software

Follett Destiny is synonymous with Library software where I come from, where I am now, and where I’m going. It’s ubiquitous. There are hundreds of thousands of districts and schools using it. It does Library catalogues, maintains check-outs, and stuff like that.

Which is pretty amazing when you think about it, because apparently all these school districts and schools all don’t mind having the same ugly green color throughout the user interface. Because, you know what, you can’t change that ugly green color.

Screen Shot 2013-10-26 at 11.32.17 AM

I wrote to the support people myself. Can’t I just change that green to our school colors. Nope. You’re kidding me, right? Nope.

This is what really irks me about software intended for schools. It intentionally goes against the grain of best practice. Colors of a website are so ridiculously easy to change and adjust, it’s not even funny. It does not require extensive understanding of any technology, it’s just a color!

It’s almost as if companies and software packages that are completely uncustomizable are built that way to protect the school from itself, because they aren’t competent enough to maintain something that can be changed or readjusted.

I have to wonder about the standards of those that are choosing to use such software, too, because they obviously don’t mind any of it.

It’s an insult to our collective intelligence.


Can you believe that the operating system produced by Microsoft has such atrocious battery life. Truly a sinking ship.

US going into default is extension of the Civil War

Bruce Bartlett’s piece is practically an academic journal-esque article offering documentary proof that defaulting is just the latest round in the on-again-off-again Confederacy uprising. He outlines how there are more than just indirect connections. It really is a must-read.

And if those facts don’t convince you that defaulting is really just an extension of the Civil War, how about this nugget:

The election of Barack Obama in 2008 caused a big jump in debt default advocacy among those on the right.

Mr Obama, remember, is black.

Never use template files for a workflow

Report writing season is coming soon, and it’s also the season when I want to point out something about what an effective report-writing workflow looks like.

I once worked in a school that tried its damn-dest to make a fool-proof Word template file, and give that to the teachers to use to write the school reports. As long as you got the template file right the first time, it would all work out just fine. The teachers would hand in the documents, and head straight to the printer (after someone edited it for clarity and grammar).

Nice theory.

The problem, though, is that you simply cannot trust the fact that any template is fool-proof. The user will find a way to challenge your assumptions, break the mold, or, perhaps more likely, the guy who put the template file together didn’t think it all the way through. Twice now I witnessed someone deciding to use an Excel file for the template, and locked various things like editing the size of fields and whatnot with a password, only to be forced to give out the password that promised to make the workflow better… because the template file wasn’t working out well.

The way that any report-writing workflow for a school is that the teachers should just input the damn report content into some blankety-blank form. Not to worry about the formatting at all, just put the information into something, somewhere, that simply swallows up the details about what the teacher wants to say about the kid.

Then, using that raw data, a template can be created that brings in that stuff into whatever desired format.

The best part about this is that there are two steps to it. Step 1: Input the info; Step 2: Format the info. Because, between the first and second step, there is the half-step of having some administrator or editor look over the raw data and look for patterns that might affect the formatting stage. This one student has more classes, making the items misalign or something, and so the font sizes need to be smaller, or whatever.

The other nice thing is that if you screw up the formatting stage (which is likely, by the way, since formatting needs a human touch, and anything can go wrong with that!) you can simply go back and try it again. Just take the raw data and run it again.

In tech speak, this is known as “separate the content from the layout“.

And that’s exactly how web sites are designed, too.

Great stories are contagious

I read this at work and it literally made my day. So great.

I have been asked to tell the following story many times, and it became so famous that I was even asked to record it for NPR.

I worked for a high-tech company when high-tech was just starting to make an impact on the world. This was before the internet, even before everyone had PCs. We had one IBM PC for the entire department and it was a thrill to use it. I say this just to give an impression of how things have changed since then.

Our company made high speed modems, but the fastest anyone could do in those days was 9600bps…

Read the whole thing.

Conventional wisdom

This has been true for a long time now, basically since the Bush presidency, but the showdown shutdown brings this to bear:

The conventional wisdom in American politics used to be that Republicans followed their leaders while Democrats were barely unified enough to be considered an organized political party. Today, the reverse is true. Democrats largely follow their leaders while Republicans have splintered into two distinct political groups that uneasily share a single party.

Get yourself globstar, bash 4 for your Mac terminal

So how many times have you wanted a simple, easy-to-remember command that will do a pattern search for files with a certain name in a directory while using Mac? Even Spotlight is annoying to do something like that. I do this all the time, as I want to find any file that has a .txt extension or maybe a .pages extension. I’m going to show you how to do this with some of the blackest magic you can find.

First of all, though, you really don’t have to do this. There is always the trusty find command that’s been available in bash since forever. However, with the advent of bash 4, there is this really-great-oh-my-god feature that is so worth having, it’s down as globstar. To show you how cool this is, we’re going to count line numbers of every python file in the current directory using two command, the swiss-army knife find command, and using the globstar. See which one is easier on the eyes (and head):

find . -type f -name "*.py" -print0 | xargs -0 cat | wc -l

You have got to be kidding me, right. Here’s the equivalent command with our freaking-awesome globstar:

wc **/*.py -l

Two stars next to each other = globstar…

Okay, well it’s still pretty esoteric. But the second one is so much clearer. Both utilize the “wc” command (word count) with “option l” which means count the lines. (Why isn’t there a “lc” command for this, oh well, easy enough to make an alias for that…) The second one works simply because two globs next to each other makes it recursive, a feature found in bash 4. Here’s how to get it installed on the Mac.

Enable globstar on Mac

First you have to install bash 4, which you do thusly:

brew install bash

This doesn’t actually override your current bash, it installs into a completely different location. You can check where by using this:

brew ls bash

Look for the line that ends with /bin/bash, you’ll want to copy that line, and insert it at the end of the file /etc/shells, which provides the operating system with its available choices for shells. Now tell the operating system that you want to use that shiny-new bash as the default:

chsh -s /usr/local/bin/bash YOUR_USER_NAME

Confirm with:


Now you have to turn on the globstar, which you do with

shopt -s globstar

To make that permanent, do this:

echo "shopt -s globstar" >> ~/.bash_profile

There are loads of other features for the command-line savvy, which you can read about here.

Get Python in your Terminal on the Mac

Twice in the last two weeks I helped someone with getting started with Python in the command line on the Mac. You could just download it from and use the built-in IDE, but that’s just not quite powerful enough for many needs. Besides, having some success with the command line is sort of like a badge of honor if you’re a geek, so why not have a fiddle?

The interesting thing about installing python on the Mac is that there are actually two pythons. The most up-to-date one is Python3, which is backwards-incompatible with previous incarnations, and is the recommended one if you’re just getting started. However, regular old Python still rears its head in a lot of different places. Most things just haven’t been updated for Python3 yet, for example Mediacore and the NLTK.

The other interesting thing is that every Mac already does have a system python, which is installed in /usr/local/bin. But we don’t want to use that. For one thing, you don’t want to screw up the system python. You probably won’t screw it up, but just in case. And for another thing, Apple Python is customized, it isn’t documented anywhere how it’s customized, and on top of that it doesn’t include the latest version. So we’ll want to put in a fresh copy of two pythons, then.


First we’ll started by first installing Python3.

brew install python3

Wait, you do have brew, don’t you? If not, stop what you are doing and get that. Oh, you’ll need to have XCode installed, or, more specifically, the command line tools that come with it. If you’re a dev, though, you already got that, right? Easiest way to check if you’re good is to type at the terminal:

which cc

If you get /usr/bin/cc as a response, you have it. If you get nothing back, you don’t have it. After brew has done its work, check that python3 is installed:

which python3

That will spit back its location, which tells you that it’s installed and working. We’re not done though. What we’re going to do is set up a virtual environment of python3 so that we can install all kinds of crap in there and won’t affect anything else. We want to install virtualenv globally, which means we can use pip or easy_install:

pip install virtualenv    #or 
easy_install virtualenv

This gives us access to a command that makes a new virtual environment. I always put them into the ~/env folder, where each environment is represented by a folder inside there. So let’s make one now.

virtualenv -p python3 ~/env/first

The -p option tells virtualenv which python to use, and since we know from above that python3 leads to our recent install, it’ll use that and make a new environment. Now we have to activate it, which we do by sourcing a special command that’s installed.

source ~/env/first/bin/activate

After that, we have a new command line prompt to remind us that we are now in a virtual environment. If we type

which python

The location that spits back at us is the local virtual environment. Did you notice that I didn’t type python3? It’s just python now.

Python 2

The procedure for regular Python is a bit more involved. After doing this:

brew install python

when we type

which python

We’re supposed to be given the new python that we just installed, right? Oh no, we’re given the Apple-installed version, which is not what we want. This is because brew isn’t about to change things automatically so that everything starts using the new python that was just installed. It’s okay for users like yourself to use them, no problem. Question is, how do we tell the computer to start using it?

We need to adjust the PATH variable so that we, as the user, when we type “python” it seems the brew version. So, where’s the brew version. This command will find it for us:

brew ls python | 
    grep 'python$' | 
    grep -v 'Frameworks' | 
    sed 's/\/python$//'`

What that does is uses brew to output all the files that our installation put in, and then uses a bit of searching and replacing to get the required data. Copy the data that spits out after the command. Now, let’s adjust your PATH variable:

nano ~/.bash_profile

And then in the last line enter this:


Note, the X.X.X is going to be whatever version is correct for you, which at the time of writing was 2.7.3. Now, if we source that .bash_profile file, or open a new terminal window, we should see the brew installed version of python available to us upon executing the “which python” command.

Let’s start installing stuff. Create a virtualenv:

virtualenv -p python ~/env/nltk
source ~/env/nltk/bin/activate
pip install nltk
pip install IPython

And now we’ve got a wonderful, nice little place for us to play around in.

How I got a portal-like interface with Moodle

Out-of-the-box, Moodle’s default user interface is pretty gregorian, and by that I mean old-fashioned. As soon as you log in, no matter what kind of user you are, you see the same thing: A list of the courses that you are enrolled in. That’s the only power that Moodle gives the front page: You only see the courses that only you are enrolled in.

In this day and age of using websites for content management, that’s sort of like booting up your computer and being met with the command line instead of a desktop. So from the get-go I set out to change all that, instead of simply making the different courses you’re enrolled in the default “view” when you log in to Moodle, instead you are presented with some text that indicates your role at the school (e.g. “Secondary teacher”, “High School Student”) and be presented with portal-like links to commonly used tools and features, like so:

Screen Shot 2013-09-29 at 4.54.05 PM

First, the menus

To get to that point, though, the first thing to solve is what to do about the list of courses, because users will very, very often have to get themselves there. In the portal image above, they could opt to click “My DragonNet” which is just the “My Moodle” feature, and by default they get a list of courses that they can click on. However, I also wanted to provide a menu that followed them everywhere they went. Hence, a menu called “Teaching & Learning”:

 Screen Shot 2013-09-29 at 5.07.50 PM

Notice how the “Teaching & Learning” menu contains the list of courses? Also notice that there are other menus, like “Navigate,” “Activities” and so on? That’s because we’re using Moodle beyond just providing a Learning Management System, we’re also using it for managing content, and providing some administrative functions. In other words, the traditional use of Moodle, which gives users a bunch of classes to participate in, has been codified into a single menu, which, combined with the portal-like buttons, provides a very different impression when the user logs in:

Screen Shot 2013-09-29 at 5.11.46 PM

The only part of that front page that I have yet to point out is the notification box sitting between the header and the buttons, which I elaborate upon in the last section below. What’s most notable about that, though, is we can put up announcements, either for everyone, or just for secondary teachers, by adding the appropriate content. Sweet.


So, getting back to the whole implementing the portal thing… how did I get it so that users are presented with different things upon login. Did I rework the Moodle codebase, adjust the database, or some other black magic? No, I went with the simplest and most obvious solution.

I just wrote a few if statements in


code that checks to see what cohorts the user is logged into, and throws them to the right course. In other words, there are courses set up just for log in purposes, and Moodle redirects them to the right place, depending on which site-wide group they have been enrolled in.

First I set up the variables I need:

$sec_teacher_cohort = $DB->get_record('cohort', 
$frontpage_course_id = 1395;  // DragonNet Frontpage

I do that after all of the Moodle-defined checks for updates, which for Moodle 2.5 at the time of writing means I start this code at line 72. Now, you could set it so that each kind of user has its own course, which is actually what I did in the first iteration. But then I realized that what I really wanted was for them to be redirected to a different sub-section of the same course. So, using topic format, I can simply pass the redirect function a section identifier, like so:

if (cohort_is_member($sec_teacher_cohort, 
                  $USER->id)) {
    redirect($CFG->wwwroot . 

This works like a charm, assuming that you have your users enrolled into the right cohorts, right? Probably shouldn’t assume that without some thought to it. So, we should check to ensure that the user has access to the course it’s about to redirect to, but I decided against that. For one thing, I didn’t enjoy the thought of hitting the database that hard for a simple redirect. Besides — and this is the main thing —behind the scene, I’ve guaranteed that users are enrolled into the right cohorts with a script that I’ve prepared behind the scenes that does all the hard work. I’ll have to explain that bit in a subsequent article.

So, all that’s left is to define the cohorts, which is a simple matter of using the Cohorts GUI provided in Moodle’s through-the-web administration.

Last bits

What about the buttons? That part is really easy. I just use html buttons, for the icons, and a bit of CSS I’ve defined in the theme.

As for the notification system, those also deploy a bit of CSS:

.dnet-notification {
    padding: 15px 20px 15px 20px; 
    background-color: #fff; 
    border-top: 2px solid #4D63A3; 
    border-bottom: 2px solid #4D63A3;

What is not so obvious, though, is what to do about the “Frontpage” course that I’ve created. I don’t want that course to appear in the menus system, so much, because “Home” is what they ought to think of it as being, and not “Dragonnet Frontpage” or whatever. So, what I did was make an “Invisible” course category, and my theme skips it whenever it encounters a menu with that name. Funnily enough, I use the Invisible menu for loads of things that I want to hide from the user.

Speaking of making the Frontpage function as “Home”, we have to take a close look at the breadcrumbs. Without further modification, when the user finds himself at the front page, the breadcrumb will state “Home -> Frontpage”. Overriding the navbar function in the theme, and putting the appropriate line to skip it, does the trick nicely:

if ($item->title === 'DragonNet Frontpage') { continue; }

Voila, we have a fully functional portal system set up for Moodle. When users log in, they jump to a page that is formatted just for them. To get to their courses, they have two ways, a la the menu or the big juicy button system.