When the Web Does Your Coursework

In my software engineering class, at one point they have to refactor their command line app (in Python) from handling all argument handling by hand given nothing but a list derived from the invocation string to using the built in library argparse. They then have to write an essay comparing the two and providing a technical recommendation. It’s a great set of interlocking coursework (and lectures).

Kyle Purdon has a really nice blog post comparing Python command line libraries. (There are others!) Of course, it’s not exactly my essay assignment because I saw Kyle’s post (and others like it) and was worried about confusion and academic malpractice. But perhaps I overthought it? Maybe I could find a library not covered and ask them to extend the analysis?

Most of my students, I’m guessing, don’t look for stuff like this anyway.

Perhaps I should keep my essay the way it is, point them to Kyle’s post, and then have them revise it?

This is a very complex era to design coursework in.


More Spilled Ink

I’ve made some progress playing with ink since my first post on it. The inky editor is pretty ok for small things (thus far). Freb wrote a story in the soon-to-be-defunct inklewriter which they graciously let me port over to ink and mangle in a bunch of ways. (Inklewriter does not export to ink, thank you very much.) (Oh, the compile cycle with inky is…not terrific.)

ANYWAY, I managed to try a few different features including variables, conditional text, random text, etc. (see this version). I planned to port that to a few other IF systems for a head to head comparison but I decided that it would be better to write a series of versions gradually introducing new features. That way, I’d have fodder for a tutorial and I could port simpler things as I learned the new system. Check out the Github repo. I need to get CI with publishing to Github pages working. There are a ton of finicky bits!

The Ink Programming Language

Ink is a programming language for interactive fiction type games with a strong default for “choose your own adventure” type games. It was invented by a game studio (Inkle) and they eat their own dog food. Games can be published on the web or integrated with the Unity game engine and development platform to add graphics (and other stuff, I’d guess).

The writing tutorial starts ok but quickly gets sort of reference/language toury like. There isn’t a real running example and the features aren’t built up organically. By the time you get to the tower of Hanoi example you’re pretty well lost. There’s some hand waving about some design choices (“it’s ok to use global variables all over the place because it’s a story!”) which is a bit annoying. I don’t know what writing a game with 50,000 words would be like or at all how to structure it.

Indeed, writing interactive fiction is at least as hard as writing any other sort of fiction! (Victoria Smith has a cool post about fighting tools when making IF like games which hints at the space of tools that Ink is competing with.)

Ink seems so easy to get into and publish for basic stuff, it seems a good platform for exploring educational uses. You could explore complex case studies (perhaps) in a more manageable for many readers way. Not only more manageable but more active learning like. Just as with lectures, it’s clear that many students treat reading as something fairly passive. They don’t question, anticipate, backtrack, jump up and down levels, interrogate structure, etc while reading. Like with light weight clicker use, an interactive text approach might incline them to be at least a little active.

“Actively Maintained” Claims Need Active Maintainence

Software is hard. Free (both as in speech and as in beer) software is hard and often not well compensated. I’m going to whine a bit about very free libraries which tends I bad form. I first want to sincerely thank the people who work on these libraries! You have my admiration and appreciation even as I criticize.

My learning experience on iOS (and specifically iPhone) based python development is extracting the results of the Twitter searches around “The President Sang Amazing Grace” and, I was hoping, to do some simple analytics. Maybe eventually do some sentiment analysis. In principle, you’d think the interesting bit, even moderately challenging part, is in the analyses. Per usual, just getting things up and going is a big PITA.

Out of the four libraries I found with a quick search, I settled on Twython, in spite of the name, because it had the nicest (still not complete) discussion of authentication. In particular, they clearly demonstrate the principle of least privilege by emphasizing the auth level sufficient for read only access. Since this is a large class of Twitter apps, I think it’s important to be emphasized. Yay! It also says that it’s actively maintained! Yay! Unlike those other loser libraries, I guess!

But searching Twitter is a pain. If you have a large number of Tweets in the results, you have to paginate. Furthermore, there’s a question as to how far back you can go (some search specific libs say 7-10 days is it, but the Twitter api seems to have some date range functionality).

In any case, Twython, like other high level libraries, provides a cursor abstraction. But the docs don’t say exactly what it abstracts over! Will it get the next page transparently? Do you need to be in page mode?

But worse, we have a bug of many years standing (with a stale pull request!) which causes a cursor to freaking loop on search results under some conditions. Well that seems to make cursors utterly useless (maybe they are useful out of box in some cases I don’t know, or maybe everyone writes loop detection code in their cursor loops).

Regardless, it makes the “actively maintained” claim…less than true. At the very least a note in the documentation is required but really this bug should be addressed if “actively maintained” is to have any meaning.

(It goes to show that one really REALLY has to work through any coursework one hopes to give. Reading the documentation is not sufficient!)

Demoing YAGNI with FizzBuzz

I use FizzBuzz as a warm up lab and as a key lecture. Tom Dalling has an excellent blog post where they iterate the implementation of FizzBuzz into a fully packaged, fully parameterized with sensible defaults, fully documented module. Which is horrific…completely larded with unnecessary complexity. And the punchline is “The Aristocrats”…er “You Ain’t Gonna Need It”.

I’m wondering if this would work as a lecture or even if it makes sense. Each step is supposed to be inevitable or at least sensible but there’s something made up about it. OTOH, it might go too far toward suspicion of abstraction.

It could but fun if the build was right. Perhaps it would be great if it also made clear when those moves made sense. Right now, it’s only negative. But a lot of those moves are good ones in some contexts.

The Viz Fallacy

Taxonomies are fun and usually treeshaped. Trees are “easy” to visualize. When people have a taxonomy they often like to visualize them.

But the results aren’t always so nice. Given that this is a taxonomies of fallacies, I found their misuse of a visualization highly amusing. It is also reminiscent of one of my thesis topics (non logical reductios).

mc et al called this the pathetic fallacy (of RDF).

The Web is (Holy Crap) Insecure

Blame Javascript. And browsers. And the W3C.

77% of 433,000 Sites Use Vulnerable JavaScript Libraries. I’ll bet that various random webpages I put up are vulnerable. Who updates random pages?! Not me!

Of course, my random, unvisited experimental pages are probably not a big problem, but still. Yeek.

Oh my god, SVG is a mess (read the paper). Short answer: It’s almost impossible to use SVG safely. And almost no one is trying.

Something’s going to break in a big way some day.