University of Wisconsin-Madison Is Your Software Teachable? Hi, everybody. My name’s Dorothea, I teach in the Information School across the street, and I teach software kind of a lot. I’m hoping that helps me give you what I hope are workable answers to the question on my sketchy little whiteboard thing here today: Is Your Software Teachable?
Some stuff I teach LIS 500: Code and Power (and PHP) LIS 510: Human Factors in Information Security LIS 711: Data Management LIS 668: Digital Collections and Curation CS 202: Introduction to Computing LIS 751: Database Design/SQL LIS 640: Linked Data/RDF LIS 632: Metadata and XML LIS 351: Introduction to Digital Information Here’s an incomplete list of some of the courses I teach, or have taught relatively recently. You can see it’s quite a range, right? From CS 202 Introduction to Computing, which is a very gentle course intended for non-computer-science-majors, to data- structure-wonky stuff like XML and SQL and RDF, to more overviewy things like Digital Collections and Curation and Human Factors in Infosec.
So yeah. I teach a lot of different stuff that involves a WHOLE LOT of different kinds of software.
• Does your software fi t into one or more of my classes? • Does your software do something useful that students should learn? • Would you like to hire a new graduate who’s learned your software? Would your clients hire new graduates to work with your software? • Would you like additional mindshare or market share for your software? Why do you care? Does it matter? So… why would you care about whether I can teach your software in my classes? (READ SLIDE)
Then you want me to teach it. us Only I really should say “us,” because of course I am not the only person in the Information School who teaches courses that rely on software! Just as an example, our relational-database design courses get passed around among instructors and TAs like party snacks. So you ideally want your software to be something all of us in the department can work with pretty easily.
• Available servers dedicated to teaching: 0 • # FTE assigned to systems administration for teaching: 0 • Amount of formal education I have in sysadminning, devops, etc.: 0 • (never mind infosec; I know more than the average bear, but…) Constraints But here are some of the constraints I’m dealing with. No budget for software or servers. In the Information School, we don’t even have dedicated teaching servers or systems administrators; if we’re lucky we can beg an hour or so of the building sysadmin’s time.
And here’s your chaser: I have no formal training in systems administration, never mind securing servers. Maybe I know a little more than the average bear, but y’all would NEVER hire me to run your servers, much less secure them! I’m not actually good at this! It’s not and has never been my job!
TIME So I teach a big variety of stuff, and for a big whack of it either there aren’t really textbooks or canned projects or assignments or anything. Or the textbook might exist but be horribly expensive garbage, which happens a lot more often than I wish it did. This means that TIME is a big constraint on me. Building courses from scratch takes a WHOLE LOT of time, and that’s BEFORE I spend time on plugging software into them!
• If I can’t install and con fi gure it in the time and with the resources I actually have, I can’t teach it.
• If I can’t fi gure out how to make it do something useful, I can’t teach it. • Corollary: If my students and I can’t get unstuck using its documentation, I can’t teach it. I am all the tech support there is for specialized software in my courses.
• If I can’t build demos and assignments that help students learn it and do useful things with it, I don’t want to teach it. How pointless. Lessons: Working within constraints So here are the lessons you can take from my constraints, about whether a given software package can work in a class I teach. (READ SLIDE)
The Useless Digital Library And this may all sound obvious, but wow, do I have war stories. There’s this server-based digital-library software package that I’m not gonna name, and anyway if you’re not in the library and archives sector there’s no reason you’d have heard of it… but I wanted to use it in my Digital Curation and Collections class. This package’s website claimed that it was “out-of-the-box,” everything you’d ever need to put a digital library or archives collection online.
So I spun up a virtual machine, and I spent NINETY FREAKIN’ MINUTES getting an installation working (because the install documentation was frankly trash), and when I FINALLY declared victory, the documentation said — I kid you not — “Okay! You’re ready to go! Now you can write all the Ruby code you want to fetch your objects from the object store and display them to your end users!”
*MOST AWKWARD POSSIBLE PAUSE*
Nowhere in the documentation up to that point did it say I’d have to write Ruby code to make this thing do anything useful — it
said it was out-of-the-box! I’m a Pythonista, y’all, I don’t even DO Ruby. Never mind my students, many of whom have never written a line of code in Ruby or Python or anything else!
It gets worse. When I explained to one of the developers of this software package that this wasn’t gonna fl y in the course I was teaching, this developer told me that the problem was that we’re not teaching all our library students Ruby.
Yanno, for some reason I have never taught using this software. Can’t imagine why not.
you better mean it. Lesson: (READ SLIDE) Or perhaps better stated: be as crystal-clear as you possibly can about what your software does and doesn’t do, and what it takes to make it go!
• Do not mire me in dependency hell. I do not have time for it. • Make it work with a static IP address. Don’t mire me in FQDN hell either! • Make it installable on MAMP/WAMP, VMs, the likes of Digital Ocean, Docker, and for bonus points, CPanel/Softaculous/Installatron. • Do I really need root to install this? Really? REALLY? • Explicitly document the Minimum Necessary Con guration Changes. • Help me make it multi-user (as appropriate). Write me a shell script to add a class’s worth of login credentials with minimum hassle. Lessons: server software So here are some more lessons, for those of you who write server-based software. (READ SLIDE)
- dependency hell: there’s another digital-library package out there that (I kid you not) uses three different package managers for a basic install. What the heck.
- n.b. MAMP/WAMP is a great way to not have to deal with students remoting in to servers.
• Prior tech experience is a bimodal curve. Including in advanced classes! • Wide range of con fi dence with tech and learning tech. • Most are future “end-user programmers.” Tech in and of itself is not their intended career path.
• Collectively cross-all-the-platforms. Some on Windows, some MacOS, a very few Linux/BSD, the occasional ChromeBook (boo!). • Wide range of socioeconomic statuses. Most work; many have to! • Wide range of personal-technology age. Seven-year-old laptops? Sure. My students… But enough about me. Here’s some things I want you to know about my students. (READ SLIDE)
End-user programmers: term coined around 2006, somebody who is techier than the average bear but not a career techie. Like me, for example. I’m not a developer or sysadmin or red teamer. I’m a LIBRARIAN and an EDUCATOR who relies on tech a lot.
The XML Editor And another war story: There’s a commercial XML editor that I really wish I could use in my metadata class, because libraries and archives work with XML a lot, and this editor is the commonest one out there in the Real World. But single-user licensing for it is super-expensive, site licenses are even worse, the educational licensing is not much of an improvement, and the demo only lasts 30 days.
So I can’t use it. I just can’t. I tell my students about it and give them the option of buying it, but that’s all I can do. And that’s on the developers, not me.
• Every cent my students have to pay to license your software… • … is money they don’t have for basic needs. (Ask me why I almost never assign commercial textbooks.)
• I hope it’s obvious whom among my students this hits worst. • Please treat my students as a future market, not a current one. Thanks. • (Demo sites, educational licensing, open source… all can work.) Issues of inclusion! This year’s DevFest theme is about inclusion, so I’m going to be blunt: this is an inclusion issue. (READ SLIDE)
The Uninstallable Infosec Tool Okay, so this war story is about a speci fi c infosec tool, but there are SO MANY INFOSEC TOOLS it could apply to, I’m not even worried that y’all will fi gure it out. I was taking an infosec course over at Madison College a few years back because the tech side of infosec was new to me. We were supposed to get acquainted with this particular tool, but to use it we had to install it, and… the installation instructions quite simply did not work. They. Did. Not. Work. Part of it was a major version release that had just happened, part of it was that the class wasn’t using the Linux distro that the software expected we would be.
So the instructor ended up wasting pretty much an ENTIRE THREE-HOUR COURSE SESSION trying to fi gure out how we could get that software installed! Y’all! I don’t build that kind of slack time into my courses! Even if I could, I shouldn’t have to!
• DOCUMENT YOUR SOFTWARE. As something other than an afterthought. On every OS/distro you claim to support. • Assume less about my (students’) prior preparation. • Community support? Don’t make us hunt for your community. • Have no-@$$hole rules in your community, and enforce them. That’s another inclusion issue, folks. Include all my students. Lessons: help me help students! NAUGHTY WORD!
Actual classroom choices I have actually made So fi nally, I want to show you that I live my talk here. I really do pick software to teach based on the factors I’ve just mentioned. Here are some actual choices I have actually made, in part because I want to praise some out fi ts that are absolutely doing this right.
• Community: scattered, unreliable Scratch Snap So I teach with Scratch. A lot of you have probably encountered Scratch, it’s a combined programming language and development environment designed for brand-new programmers of almost any age, from fi ve years old on up. I use it in CS 202: Introduction to Computing. But it’s got some issues with power and fl exibility: there’s only one kind of for/while loop in Scratch, for example, and Scratch doesn’t have any concept of an associative array, or dictionary for my fellow Pythonistas.
So I looked at moving to Snap, which is a Scratch fork with more power and fl exibility. The sticking points were documentation and community — Scratch’s were just so incredibly much better. So until Snap fi xes this, or some other Scratch fork does, I’m sticking with Scratch.
• Capacity after install: Lots! Useless DL Omeka So I teach with Omeka. As I mentioned, I don’t teach with the Useless Digital Library Software. I teach with an open-source package called Omeka that has a one-click install at my webhost — I can get it up and running in ninety seconds, getting it con fi gured and adding students is maybe half an hour, and once that’s done students can go wild and do almost anything they want, within the general limitations of the software and it de fi nitely has some.
• Kewl Trix: sure, lots, go through the menus to discover them
• Sample data to play with: yes!
• Cost: usually $0, sometimes $$$$$
• OSes: only some
• GUI: nope, command-line only
• Kewl Trix: only via incomprehensible command-line incantations
• Sample data: get your own, chum(p) Wireshark™ Anything else So I teach with Wireshark. My infosec course is designed so that tech savvy isn’t a barrier. I want people to take this course who will never in their LIVES con fi gure a fi rewall or do forensics on a phone! Because folks just like them will someday have to:
budget for security and security people,
communicate about their workplace’s security posture,
write security policies — or at least approve them,
cope with regulation that makes security demands,
and all that non-technical security stuff, right?
That said, sometimes a tech demo really brings things home in a way me bloviating about them doesn’t. So I teach my infosec students to sniff packets and do extremely EXTREMELY basic packet analysis. And I do this with Wireshark, because it’s free, because it works on almost every machine my students show up to class with, because it’s got a GUI, because its menus surface a lot of Cool Tricks that I can easily show my students, and because there’s a whole wiki page full of sample packet
Sure, the real world uses tcpdump and tshark, I know that, we totally learned tcpdump at Madison College. But for ME to teach with those would take an ORDER OF MAGNITUDE more work — assignment setup work, explanation work, tech support work, sample-data work. I ain’t got time for that, so I teach with Wireshark.
• Cross-platform client GUI or GTFO. I do not have class time to teach shell to future end-user programmers, much less a programming language. • The easier and faster it is to fi nd and explain Kewl Trix with your software, the easier it is for me to teach it.
• Give me sample data, sample problems, sample work ows, sample everything! Bonus points: walk me through the work ow, soup to nuts, one step at a time. • (Good practice: many infosec capture-the- ag events do problem writeups. I adore those! Could more software sectors do them?) Lessons
Thank you! [email protected] ■ https://speakerdeck.com/dsalo This presentation is copyright 2022 by Dorothea Salo. It is available under a Creative Commons International 4.0 Attribution license (CC-BY).
dsalo
soracom
claudioed
th0x0472
mixi_engineers
devopstaiwan
opeonikute
tsujiba
ikezoemakoto
keio_smilab
senkin13
saboyutaka
picardparis
brianwarren
danielanewman
reverentgeek
quramy
samlambert
62gerente
philnash
holman
matthewcrist
eileencodes
zenorocha