Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Is your software teachable? (with notes)

Is your software teachable? (with notes)

For DevFest WI, 18 August 2022.

Dorothea Salo

August 18, 2022

More Decks by Dorothea Salo

Other Decks in Technology


  1. View Slide

  2. Dorothea Salo

    Distinguished Teaching Faculty III

    Information School

    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?

    View Slide

  3. 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.

    View Slide

  4. • Does your software
    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
    Why do you care? Does it matter?
    So… why would you care about whether I can teach your software in my classes? (READ SLIDE)

    View Slide

  5. Then you want me to teach it.
    If the answer to any of those questions is yes, then you might well want me to teach your software.

    View Slide

  6. Then you want me to teach it.
    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.

    View Slide

  7. • My budget for software: $0

    • My budget for server space: $0

    • 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…)
    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!

    View Slide

  8. 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!

    View Slide

  9. • If I can’t install and con
    gure it in the time and with the resources I actually
    have, I can’t teach it.

    • If I can’t
    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.

    View Slide

  10. War Story 1:

    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!”


    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

    View Slide

  11. 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
    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.

    View Slide

  12. If you say your software is
    “out of the box”

    you better mean it.
    (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!

    View Slide

  13. • 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.

    View Slide

  14. • Prior tech experience is a bimodal curve. Including in advanced classes!
    • Wide range of con
    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

    View Slide

  15. War Story 2:

    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.

    View Slide

  16. • 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)

    View Slide

  17. War Story 3:

    The Uninstallable Infosec Tool
    Okay, so this war story is about a speci
    c infosec tool, but there are SO MANY INFOSEC TOOLS it could apply to, I’m not even
    worried that y’all will
    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
    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!

    View Slide

  18. • 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!

    View Slide

  19. Actual classroom choices
    I have actually made
    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
    ts that are absolutely doing this

    View Slide

  20. • Power: Medium

    • Flexibility: Medium-to-low

    • Documentation: BRILLIANT

    • Community: Large, helpful

    • Power: High

    • Flexibility: High

    • Documentation: Incomplete and

    • Community: scattered,
    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
    ve years old on up. I use it in CS 202: Introduction to
    Computing. But it’s got some issues with power and
    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
    exibility. The sticking points were documentation
    and community — Scratch’s were just so incredibly much better. So until Snap
    xes this, or some other Scratch fork does, I’m
    sticking with Scratch.

    View Slide

  21. • Time to install: 90 minutes

    • Install docco: Horrible

    • Post-install con
    g: Essentially

    • Capacity after install: 0

    • Time to install: 90 seconds

    • Install docco: Excellent

    • Post-install con
    g: Some, but

    • 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
    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
    nitely has some.

    But yeah, Omeka is absolutely what I teach with.

    View Slide

  22. • Cost: $0

    • OSes: all (minus Chromebooks)

    • GUI: yes

    • 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
    gure a
    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

    View Slide

  23. captures.

    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.

    View Slide

  24. • 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
    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?)

    View Slide

  25. I would like to teach your software.
    No, really, I would!

    View Slide

  26. Please help me do it.

    View Slide

  27. 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).

    View Slide