Contraterrene – Tony Hursh

Google Web Fonts is a very large collection of freely-distributable fonts (some great, some not so great ). They provide a variety of methods for using these in your web pages, which are all fine if you need just a couple of them. Unfortunately a recent project requires several hundred of them. Loading them over the web at runtime is a non-starter — it’s just too slow (I need to load every font so I can display the full collection as type samples). You could download the fonts one at a time, but I’m way too lazy for that. Ruby to the rescue!

Update: I see that WordPress (or at least this theme) eats indentation even if you wrap the code in <code></code> tags. Fail. Oh, well. If you have a use for this, I’d bet money that your editor will handle reindenting the code for you. Heh.


# Font downloader for Google Web Fonts.
# Puts the fonts in a file called "Fontname.ttf" (spaces in the font name are removed)
# and outputs the CSS code to load the fonts.
# Run with something like ruby snagfonts.rb > fontloader.css to get the CSS font directives in a nice file.
# Copyright 2012 by Contraterrene eLearning Group, LLC
# MIT License or Ruby License, your choice.

This little script will download all the fonts you’ve listed in the array, and output the correct CSS to load them. As written, the fonts will be saved in the fonts/ directory (which you must create ahead of time), while the CSS goes to standard output (which you can redirect to a file). It should be simple enough to mod if you want something else.

Sample CSS output:

@font-face {
font-family: 'Aclonica';
font-style: normal;
font-weight: normal;
src: local('Aclonica'), local('Aclonica-Regular'), url('fonts/Aclonica.ttf') format('truetype');
}
@font-face {
font-family: 'Annie Use Your Telescope';
font-style: normal;
font-weight: normal;
src: local('Annie Use Your Telescope'), local('AnnieUseYourTelescope'), url('fonts/AnnieUseYourTelescope.ttf') format('truetype');
}
@font-face {
font-family: 'Anonymous Pro';
font-style: normal;
font-weight: normal;
src: local('Anonymous Pro'), local('AnonymousPro'), url('fonts/AnonymousPro.ttf') format('truetype');
}
@font-face {
font-family: 'Allerta Stencil';
font-style: normal;
font-weight: normal;
src: local('Allerta Stencil Regular'), local('AllertaStencil-Regular'), url('fonts/AllertaStencil.ttf') format('truetype');
}
@font-face {
font-family: 'Allerta';
font-style: normal;
font-weight: normal;
src: local('Allerta Regular'), local('Allerta-Regular'), url('fonts/Allerta.ttf') format('truetype');
}
@font-face {
font-family: 'Amaranth';
font-style: normal;
font-weight: normal;
src: local('Amaranth'), url('fonts/Amaranth.ttf') format('truetype');
}

Touch/mobile-friendly. No Flash. No external images. No reliance on external frameworks (such as jQuery). No CSS (style to suit yourself). Self-contained JavaScript object (should work without interfering with any framework you’re using).

Enjoy.

This snippet illustrates how to generate and parse CSS dynamically.

You can now build your own installable web apps for iPhone, iPad, and Android  at: https://mobimorphic.com/ (update: the web apps will also work in the Kindle Fire browser, but as yet I haven’t found a way to install them to the home screen).

Note that you DON’T need to be a programmer to build one of these — that was the design goal. If you can use Google Reader or set up a Google Calendar or Flickr album you can use this. Conversely, if you are a programmer you can use the External Code block and go as far as your imagination and skills can take you.

I’ve been working on this stuff for about a month, and I think it’s time to let other people start beating on it. It definitely needs more extensive testing on Android — works fine on my cheapie Android phone and on my Kindle Fire, but there are about a billion different configurations of Android out there. Let me know if something breaks. Note that there are two links on that page — the first goes to a sample app that needs to run on a mobile device to be fully functional. The second is to the self-service app builder, which needs to run on a desktop or notebook using Google Chrome or Safari (no Firefox or IE support, sorry).

Supported resource types at present: Web feed (RSS and Atom), Twitter feed, Flickr photo sets, podcasts (both audio and video), YouTube channels, Google Maps, user-entered HTML (includes a WYSIWYG editor), external code, external site, phone dialer, SMS text message, iTunes store, email, Google Calendar, and Facebook.

Next steps: performance optimization, more themes, and better docs. I also have some ideas for cool new blocks, and want to make Facebook an internal resource (like Twitter) rather than an external link.

In this post, Mark Guzdial brings up an issue that’s generated a fair amount of interest in recent years.  The old-school personal computers — Apple II, Atari, Commodore — all came with a free, and built-in, BASIC interpreter. BASIC even came with PC-DOS/MS-DOS.  This onboard BASIC was the first exposure to programming for many (I’m tempted to say most) of today’s programmers.

Now, no one would argue that BASIC is a great language. It was, however, free and ubiquitous – there were problems if you wanted to share your Atari BASIC program with someone who had an Apple II, but often you could make the code work with a little bit of ingenuity.

Where do modern kids get that experience?  Are we creating a generation of appliance users who (if they’re exposed to programming at all) get their first experience in a behemoth like Java?

So there’s no confusion here: I like Java (well, I like the JVM anyway ), and have written more than my share of it. However, it doesn’t exactly lend itself to casual tinkering.  Compare:

10 PRINT "Hello, world!"

1 line, 11 characters of overhead, what the code does is obvious at a glance, even to someone who doesn’t know programming (they might wonder about the 10, but that’s about it).

to:

public class HelloWorld {

     public static void main(String[] args) {
          System.out.println("Hello, World!");
     }

}

6 lines, 112 characters of overhead — plus you have to compile it, maybe set up your CLASSPATH, and perhaps perform other chores that stand in the way of instant gratification. Also, the code is largely opaque to a programming-naive reader. “public class”? “static”? “void”? Say what?

There have been many attempts to fix this. Scratch from MIT, Alice from Carnegie Mellon, indie projects such as Hackety Hack from why the lucky stiff (please come back, _why! We miss you!), special purpose scripting languages such as LSL, and several others.

With the exception of LSL, most of them are excellent (Cory Ondrejka, author of LSL:  “[N]ote to self, next time spend more than one night designing language.” ).  I’ve had good luck teaching this type of language to an audience of K-12 teachers, most of whom had no background in programming.

Where they come up short is ubiquity. They’re almost all free, which is great, but they have to be installed, which is not so great. Most school computers are locked down extremely tightly (an interesting topic its own right). In fact, one of my students was reprimanded for installing Scratch on her classroom machines.

Even if you are permitted to install the software, the installation step still creates a barrier for sharing your creation with your friends, since they in turn have to install something before they can run your code.

MIT has worked around this to some degree with their Java (and now Flash) web-based Scratch players, but Java and Flash present their own issues (school firewalls or other security software may block Java and Flash, Windows machines, and starting with OS X Lion, Macs, no longer come with Java installed, Flash doesn’t work at all on iPhone/iPad, and doesn’t work very well on Android).

So… what to do?

I would argue that JavaScript is the modern equivalent of BASIC; it’s free, ubiquitous, and has the requisite nasty, nasty syntax.   Any kid with a web browser and a text editor can write and run JavaScript without installing anything. HTML 5 opens up the possibility for impressive visual and sound effects that can be shared with anyone else on the planet who has a modern browser.

Even with the ugly syntax, JavaScript is a much better language than old-school BASIC. Closures, anonymous functions, objects — there are a lot of Big Ideas in there.

Besides the syntax, the other drawbacks of JavaScript include performance and the sandbox model (sandboxing is essential when you’re running arbitrary code from random web sites, but extremely inconvenient when you’re running your own trusted code).

There are workarounds. There are new packages that let you use better syntax (e.g., CoffeeScript, which gives you Ruby-like syntax, the experimental ClojureScript, which gives you Lisp, and many others).

With respect to speed, Google has invested major effort in their V8 JavaScript compiler, which gives you near-native code performance. It’s much, much faster than classic JavaScript.

There are also several options for those who chafe at the sandbox.

Node.js lets you access the file system, write servers, and similar stuff.

Packages such as PhoneGap and Appcelerator Titanium let you write JavaScript applications that run on phones and other mobile platforms. In both cases, the code has direct access to phone features such as the camera, microphone, contact list, geolocation, accelerometers, and so on. PhoneGap works by calling native routines from interpreted JavaScript, while  Titanium precompiles the JavaScript to native code.

While I have no data, I would wager that the ability to do cool things on their phones, and share those cool things with their friends*, would be an extremely powerful motivator for today’s students.

* The biggest barriers to doing phone stuff are bureaucratic rather than technical — there are some issues involved with distributing your creation.  For iOS,  the best option right now (on a school level)  appears to be Apple’s Enterprise Distribution mechanism, which isn’t particularly transparent, cheap, or low-friction. For individuals (or if you want wider distribution through the App Store) you’ll need to buy a seat in the standard iOS developer program. I’d really like to see Apple set up some kind of low-cost student program — perhaps it could include the standard developer package’s ability to distribute to a limited number of devices on an ad hoc basis,  but not include the commercial features (e.g., distribution through the App Store). Android is much more lenient in this respect.

There’s a long-running joke that the process of getting a PhD requires that you know more and more about less and less, until eventually you know everything about nothing.

When I was in CS grad school, some of my fellow underpaid teaching slaves colleagues and I spent some time thinking about all the different types of nothing there were in the world. We wound up with a long list on the whiteboard, among them:

Zero (integer)
Zero (floating point/real)
Zero vector
Zero matrix (we decided somewhat arbitrarily that matrices and vectors were different for the purpose of this discussion)
Null pointer (points to nothing)
Void pointer (may point to something, but you can’t tell without further information)
Empty string
Identity function
Fixed-point combinators (considered different from identity functions for similar reasons to vectors and matrices)
Nil (in the Lisp sense)
Blank storage media (have capacity but no content)
Vacuum (has extent but no content, esoteric physics theories about vacuum energy aside)
Empty database tables (have structure but no content… arguably similar to null vectors/matrices)
Code segment that has no effect (similar to identity functions, but not quite the same)

I’m sure there are others. Feel free to add suggestions in the comments.

Update: Chip suggests the addition of Seinfeld plots.

Apple U / Cisco U / Google U / Microsoft U

This article from Inside Higher Ed discusses some scenarios for universities sponsored and operated by technology companies. As disquieting as that idea might be, I think it’s plausible.

I’m surprised that Amazon wasn’t mentioned, though. They certainly have the funding and technical chops, and they have something the others don’t: serious clout with publishers.

They also have the Kindle, which gives them a preexisting large scale sales and distribution channel, and a technology that runs on mobile devices from many different manufacturers as well as their own hardware.