It's December Days time again. This year, I have decided that I'm going to talk about skills and applications thereof, if for no other reason than because I am prone to both the fixed mindset and the downplaying of any skills that I might have obtained as not "real" skills because they do not fit some form of ideal.

15: Chalk Mark

Comments to earlier entries in the series, and many of the other times that I talk about my (lack of) technical skills or l33t coding ability, and with regard to cooking by recipe, as well, have pushed back on the still persistent conception I have that recipe following is not doing the thing, and that there is no great skill in executing someone else's code to create something that works (or something delicious.)

Thank you for doing so. I know it is a weasel-thought, and yet I have trouble keeping it away from myself. I cannot see what it looks like from the outside, only from the inside. I know all the things that I have at my disposal, and I have used them enough that they no longer appear to be special to me.

A regular part of my job is troubleshooting. Most of it is what I would consider the simple stuff, where I have seen the error message sufficient numbers of times to know what the likely process should be to fix the problem, or it's clear that someone has gone astray from the established process and needs to be guided back to the way that will work, or to be taught the thing that they actually want, instead of the thing they said they wanted, when it becomes clear the thing they said they wanted was not actually what they wanted. As I have said before, a large amount of the training I have as an information professional is not extensive knowledge of the specifics of any one implementation, but a good dose of the general concepts behind them, and a confidence that when encountering a specific situation, that general knowledge will be enough to get to a specific solution. Or at least enough key phrases to toss into a search engine and read a good candidate page for the specifics of how to get something done. It makes me seem like I know much more about what I'm doing than I actually do. And knowing that there's the undo command available in most places means experimentation is much more possible than if it were not. I still sometimes have to work through people's anxiety or anger about the machine and what it will do to their material, but for the most part, I can get people to click and/or type in the places I would like them to so they get the desired result that we're both looking for.

If I can't actually succeed at getting something to work, I try to send along as detailed of bug reports as I can when there are inevitably tickets filed for things that are out of my control or I need to call in the people with the specialized skill set and knowledge base to fix things. (Learning how to file a good ticket is something I wish they taught everyone who works in libraries, and plenty of other places, too. It makes everyone's job easier when they have a handle of what the issue is, or when there's information in error messages being conveyed to help zero in on the problem.)

However, because I can manage to obtain and wield knowledge at an quick rate for helping people, I've also developed a little bit of a reputation for being good with machines, or manifesting beneficial supernatural auras around them, or being able to work through what the problem is that we're facing and find a solution to it. So I sometimes get or find on my own some of the more esoteric issues that show up. And sometimes I get to laugh my ass off when the solution presents itself. Observe:

The problem: Someone couldn't get to Google after signing in to the library's computer. That's not usually a thing, because, well, Google. So I observe the attempt and get to read the error message.

The error message: "Tunnel connection failed."

Hrm. While I'm not an expert in networking, running a quick search on that error message has the results come back and suggest there's something gone wrong with a proxy of some sort. Let's see if we can figure out what's going on here.

• First check: we're not having a widespread network outage. Other computers are still going fine, so that's not the case.


• Second check: Yep, all the cabling is plugged in at both ends, so that's not it.


• Third check: Do websites other than Google load? Yes, they do, so the problem is not that all connections are being denied by whatever the proxy error is, just the one to Google. (Or to Google and some unknown number of other websites.)


• Fourth check: Is it just this machine that's having trouble getting to Google?
  
  I grab the next public computer over, and check the following:
  
  • Can I get to Google if I use the secret superuser login? Yes.
  
  
  • Can I get to Google using my own library card and selecting the "unfiltered" Internet access option? Yes.
  
  
  • Can I get to Google using my own library card and selecting the "filtered" Internet access option?
    
    Nope! And the error message that I get back matches the error message I first saw when I started investigating.

We have a winner! Now I have an idea of what happened, and what the proxy server was that caused the problem.

So I ask what setting the user chose when logging in. The user confirms to me that they chose the "filtered" option when logging in. So I had to explain that to get to Google at this particular moment in time, they'd have to log out and choose the other option from whatever they chose this time around. The user might have been embarrassed about this happening to them. I wonder if they thought that engaging the filters would make them less likely to receive advertisements or spam or other kinds of things like that, and especially on topics they might not be interested in. Sadly, that's not the case, and while I have lobbied regularly to have proper extensions installed on the public machines that will do most of that malvertising and ad-blocking as a default, IT has not yet seen fit to include it in their deployment. (And they also have settled on Edge and Chrome as the browsers we offer, and Chrome nerfed the effective ad-blockers earlier this year because Alphabet is fundamentally an ad company that has some other software tools they offer.)

[Diversion: I don't particularly like filtering software. I think it causes more problems than it solves, and frankly, I would rather we didn't have to deal with it at all, but Congress, in their lack of wisdom, decided to tie federal e-rate discounts and funding to ensuring we have "technology prevention measures" in place to prevent the minors from looking at age-restricted material in the Children's Internet Protection Act (CIPA). CIPA should qualify as a four-letter word in my profession. So, to actually provide services for our users at a rate that will not be disastrous, we have to implement the filters, since that's the easiest way of ensuring compliance with the law.

The other problem I have with filters is that they tend to be things created with the idea of a parent that wants no information about the world outside to make it to their child's computer as their primary customer and who they set the defaults for. This almost always results in over-filtering, because the defaults are tuned to the parent that wants no pornography, and also no sexualities other than straight, and no gender identities other than cis, and no way of communicating with the outside world, and so forth. And the people most affected by this, our kids and teenagers, are the ones who are least likely to tell a library staff person, "Hey, this site is informative and not explicit, and yet you have blocked it with your filters. Please unblock it." Because that creates the possibility of a paper trail. The kids are more likely to find some method of circumventing the filters entirely rather than asking for them to be more appropriately tuned.]

I am not trying to show that I am having a right and proper laugh that our filtering software is now blocking Google, even on Google's own browser, because that could be interpreted as laughing at the plight or embarrassment of the user, and that's not acceptable behavior. But I do go and file a ticket about the fact that the filters are apparently now blocking Google, and we should probably fix that, since our landing page for public machines points at GMail as one of its major outbound links. Turns out things were going rather haywire with the filters in their entirety, and the whole thing needed to be wrestled back into the intended effects instead of what had happened to all of us, according to the ticket update. I can imagine how many other users were particularly nonplussed about this as well. And I wonder how many of our under-17 users, the ones who have filters automatically chosen for them, had a time with filters gone off the rails.

At the end of the story, even at the time it was happening to me, I also must once again grudgingly admit that I am a computer toucher who sometimes can solve problems as if I had magic. This is because of long experience in knowing where to put the chalk mark so that someone else can wallop it with a mallet later. (As the joke goes, an engineer is called in to fix a piece of malfunctioning machinery. He examines it, draws an X on a particular part of the machine, and then smacks it, bringing the machine back to full functionality. Later, the company receives a bill for $5000, an absurd amount of money, and demands the engineer itemize the expenses. He does so: "Chalk: $1. Knowing where to put it: $4,999.")

To drive the point home that week, a few days later, I had another instance of supposed computer magic. Someone was having trouble finding a thing they were sure they had saved to a personal OneDrive account they had signed into.

I could see the save on the local storage of the computer, and the folders that were on the signed-in OneDrive, but the file on the signed-in drive was not present.

• Check one: "Would you save the file again, so I can see what's happening?"

After watching them go through the process of how they were saving, I realized that the shortcut in the saving menu, despite saying "OneDrive," and Microsoft Word assuring the user they were signed into OneDrive correctly, was diverting itself to the OneDrive that would be associated with the Windows account on the computer itself. Instead of the signed-into personal OneDrive, the "OneDrive" shortcut in Word was for our Windows account used to sign in to the machine and run the program for user control through library cards and guest passes.

Cue massive eyeroll from me, and perhaps a choice comment about how computers are remarkably stupid, because they do what we tell them to do, and sometimes because they make assumptions and have defaults that are not correct. If this weren't in a user-facing context, I might have peppered my response with a few four-letter words of my own.

Now that I had an idea of what was going on, I could explaining what was happening to the user, and from there, assist them through the save menus to get to the correct and proper OneDrive folder. Lo, and behold, the file promptly appeared after Word had been told where the correct path to save to. We made sure that the recently-saved document could be opened again, with the changes properly inserted, and, with the remaining time available to the session (I didn't mention it until now, but this was working under time pressure, both because an assignment was due and because the library computers were about to shut doen and restart, no time extensions possible.), figured out how to get a different document properly into edit mode so it could be then changed, saved, and uploaded for an assignment. The second upload happened with about 90 seconds left on the computer session, so you can probably also append a certain amount of "does excellent computer touching and calm instruction under pressure" to my skill list. (There have been more than a few times where I'm being called in at the last minute or something close to it and I have to manage to both create the save and get it off the local machine into something more permanent before the session expires. This is not fun, but I have several successes at this, including directing people through the process while they're panicking about losing all their work.)

I think of these things as something that any information worker could do, if they had the same knowledge base as I do to draw from. I may be faster at it, and possibly able to detect and error correct from a wider range of possibilities due to my experience at what commonly shows up in these situations, but, as with most of the things that I do and get paid for, I maintain that it is not rocket science, computer science, or magic. And, because it's not something like having to learn to program in a language, or to diagnose and fix things like the workings of a passenger vehicle, or to do whatever the hell it is that Chocolate Guy is up to right now, all of which seem to require a specialized body of knowledge and a large experience base, I think of it as easier to pick up, comparatively. I suspect a fair number of you, a strong amount of my coworkers, and a great number of my users that I have pulled through a potential panic situation, would strenuously object to the idea of it being "easier," even with me accounting for the amount of practice that I have at making things look easier than they actually are. As I mentioned at the top of the post, I see from backstage, rather than from the audience, and therefore I am very likely to need irrefutable proof that "no…no—no, that is not the kind of thing that anyone can just pull out of their hat on a moment's notice!" Supposedly, a grandparent on one side was reputed to have the lack of skill at cooking to burn water, so the ability to follow recipe is a significant improvement there.

And while I'm bashing my head against a computer problem for a game at this point and feeling very foolish about my inability to explain to a computer what's intuitive to me as a human, I have to remember that everything that I've accomplished so far is still pretty cool, even if it's not optimized, golfed, or doing things the "right" way all the time.

(It's a real pain in the ass, and the people who have been helping me with other problems freely admit it's a pain in the ass, because it's trying to do something with incomplete and possibly fuzzy information. I have to figure out how to get a computer to perform a sum of the values at particular indices of an array, and then, when that solution inevitably turns out to be wrong, to move one of the indicies up or down one and run the sum again, and if that doesn't work, to do it again until the correct sum is reached. The potential problem space is too large to brute-force efficiently, and there are imprecise hints about where to plant your initial guess and make small adjustments from.

Once I can get the computer to do the adjustments until it reaches a solution, I have to figure out how, when the values of the problem space change due to other actions, to recalculate the sum based on the index pair that I already know is right, because that shouldn't change over the course of an attempted solve, even if the imprecise hints do change, because while the indices of the hints haven't changed, the values those indices refer to have, and so the correct solution has changed as well.)

So we all have our strengths and weaknesses, and our specialized body of knowledge to apply to any given situation. I will marvel at your skills from the audience, while I shrug at my own, since I see and use them so much. I see chalk marks as the thing I'm doing, and the thing that people ascribe value to, and not necessarily knowing where to put them.

It's December Days time again. This year, I have decided that I'm going to talk about skills and applications thereof, if for no other reason than because I am prone to both the fixed mindset and the downplaying of any skills that I might have obtained as not "real" skills because they do not fit some form of ideal.

14: Terminal

Being a child of DOS sometimes gives me an advantage and a bit of comfort whenever a project or a task that I have to do involves the command line. I still love a good Graphical User Interface (GUI), and I firmly believe that most applications these days are well-suited to having a GUI, even if it's basically a visual wrapper for three command line applications dressed in a trenchcoat. Having a GUI makes your application more accessible to the person who does not feel at home running cryptic commands and not understanding what they will do. I especially like the people who provide the GUI in a terminal (a TUI) when it makes the most sense for their application to be run from the command line and manipulated in such a way.

Others extol the terminal and the command line as the superior option for all things, because the terminal runs faster than the GUI does, needs smaller files to produce the same outputs, requires less clicking and typing, and because being able to run a thing from the terminal generally means it can run on a much wider variety of things, instead of being locked to those things that have enough horsepower behind them to run graphical environments.

Still others, the people who get the side-eye, say that the terminal is the superior option for all because it functions as a skill gate. People who cling to their GUIs are still n00bs and lusers who have not demonstrated sufficient computer touchery and geekery to be allowed access to this particular tool, and therefore anyone who wants to use this jewel has to git gud. Snobbery is not a good look on anyone, but technological snobbery can be particularly vicious, and there are more people than we'd like to admit who fall into the third category of "people who don't want the less technical 'polluting' their spaces with demands for things like accessibility or an easier-to-use interface or syntax."

It is a potentially scary thing to type in a command that someone has put on the Internet, or in a script, or to run as an executable, and hope that it doesn't do something awful to your machine. And even scarier when the potential for malice is not embedded in an executable program, but instead a script inside an innocuous-looking document, or even as things that may or may not require someone to do anything before their system is compromised. And unlike many GUI programs, the command line is a place where the assumption is that you know what you're doing when you type the command and press enter. Great power, great responsibility, great potential for disaster. Not everyone necessarily wants to learn how the syntax of the command works, what it does and any tertiary pieces of knowledge that go along with it, like how to construct regular expressions, how to pipe the output from one program as input into another for further manipulation, or how to construct Boolean logic to capture all the possible conditions and find the correct one for the situation. These people are still valid users and they should have access to tools just as much as the people who want to run everything through the terminal.

Some of the most common situations I had for working with the command line as a youngling were, naturally, in pursuit of playing games. As described in the first post, once I left the comforts and constraints of Automenu, I learned how to navigate around in DOS and do things with it. As games progressed and started taking up more and more memory, there had to be some tricks involved to ensure there was enough available memory for the game to successfully run. DOS in those days had what they called "TSR" programs (no relation to the company that developed Dungeons and Dragons) - Terminate and Stay Resident. Most of the time, these TSRs were drivers so that hardware attached to the system would function properly. Others might be ways of taking advantage of greater amounts of system memory, and setting things up for something like bank switching, so that from the "conventional" memory space, you could still address, store, and retrieve things from "high" memory or "upper" memory that wasn't subject to the 640k limitations of "conventional" memory. (The deep dive into how to store and retrieve information from a Game Boy cartridge was intensely fascinating, and also helped me understand a little more about clever solutions used in limited circumstances.) The difficulty with TSRs is that they had to stay in the "conventional" memory space, and while there were all kinds of solutions and methods to access and use the higher memory spaces, many of them relied on there being enough conventional memory space available in the right places to implement their tricks. So, as time went on, while there may have been enough available RAM and processing power to run Sierra family games, the setup wasn't distributed properly to work.

Thus, the boot disk. From the TUI of the game installer, there was always an option of creating a "boot disk." In those days and times, DOS progressed through the various drives available to determine what to boot from, and the floppy disk drives were always assigned letters earlier in the alphabet than hard disk drives., so they would always be earlier in the boot order than the hard disks. By sacrificing a floppy to the installer, it would craft a DOS boot environment where the bare minimum of TSRs would be loaded to make playing the game functional, with the assumption that after using the boot disk to load the correct environment, you'd then proceed through the directory structure to the hard disk and load the game that way. And they worked very well, loading the drivers for keyboard, mouse, sound card, and sometimes the CD drive, as well as the tools needed to access the higher memory blocks. Once I was done gaming, I'd reboot the system so that it could return to normal operations and access to things like Windows. These days, we don't need to fiddle around with such things, even as RAM requirements and availability have grown. And these days it would be something more like a boot image of some sort, a way of loading a specific environment and then booting directly into the game itself. I wonder what kind of game might take that on as their packaging method, trying not to allow installs, even if they might allow for the mounting and running of the image inside some form of container, but otherwise trying to keep the entire thing on the disc image created.

Boot disks were another way of helping me get comfortable with the command line, and with giving me an incomplete understanding of how a computer actually sets itself up to run and produces the environment that the user will be working in. That's all basically abstracted away, and we only see a little bit of it when watching the console output scroll by as my current machines load up. I'm glad of not having to make boot disks any more, and I'm glad that we have more sensible ways of managing memory and startup now, so that people don't have to do arcane things to set themselves up for playing games and running software. Terminal comfort can come from other sources than hacing to rearrange your entire environment just to play a game.

For some time after that, as Windows got better, and then became the way that most games were played, and DOS eventually found its way to emulation, rather than being a major part of everyone's lives, those command line skills didn't pick up a lot of use, although they also never really went away, because, as I was getting older, this somewhat new-fangled object called The World Wide Web had joined the scene (again, telling you more about how old I am than not) and the interconnectedness of computers was now not only possible, but achievable to people who weren't on defense or university networks. The early parts of this interconnectedness relied on a few different protocols to make it all work - HTTP for HTML document transfer, FTP for binary file transfer, there was Gopher around, and a few other protocols. (All of these protocols still exist, although not many people are maintaining FTP servers any more, I suspect, having found it easier, faster, and better on the bandwidth to seed large files through BitTorrent.) ECMAScript/Javascript/Typescript were promising new ways of doing things, and a lot of website addresses at the time had a /cgi-bin/ in their paths, so even at that time, there were attempts to bolt interactivity and responsiveness onto the more static HTTP protocol.

Since I missed the BBS scene entirely, and never had newsreader access, I don't have the experience of dialing in with a modem and using a program to peruse the bulletin boards and the newsgroups - that would come later, with things like phpBB and other implementations of forum software, before we all decamped for our individual blogs and tried to link them together through rings and RSS. What I do have, however, is that there was a…surge? resurgence? rediscovery? of the Multi-User Dungeon and the use of the telnet protocol to connect to such things and interact with them. I won't say I was any good at any of them at all, and a friend of mine wanted to have me build some things for their own MUD, but I didn't get very involved with that, and so I didn't contribute all that much to it, either. I could have possibly learned a few things about scripting and other such things if I had persisted with the building aspect of it, but I didn't have the time nor the always-available Internet connection, to do most of my building and scripting work with. A more involved me might have instead grabbed the ability to run a local server on a non-Internet-connected machine and put together all of the things that needed doing to make it work, before uploading all of that to the live instance when I had an Internet connection. Which very well may have required either exporting in some way or retyping everything that I did in the local copy onto the non-local copy.

As it is, I entered university days with some amount of telnet experience with the MUDs, and a little more from having used the earliest form of using computers to make requests from other locations in the library system. (With the added bonus of being able to use that same system to look up and make requests from home, instead of having to be at the library to do so.) This made me particularly well-suited to using whatever computers were handy to do things like work on assignments, check e-mail, and do the occasional bit of socializing or other such between classes. While the university provided us with a disc of useful programs to put on our personal computers in the dormitories, or off-campus, I don't remember how many, if any, of the machines that were in the shared computing labs had those same programs present. As a further not-really-complication, since most students were comfortable with Windows machines, that usually meant the available machines were on the Macintosh side of the lab. As someone who could get things done in both of those environments, it mostly meant that I was on the Mac side of the lab instead of the Windows side. (Even more so in graduate school, as the Macs had a good text editor with syntax highlighting that I could use when I was away from my own Linux machine and its syntax highlighting.) The University e-mail system had a command-line interface and interaction point, and I think that was accessed by telnet as well. (What I remember much more clearly about it was that all of the servers we could connect to were identified as being arcade games. While we used a single point of entry to connect, the server we were assigned at random always was a classic arcade game. Zaxxon, Xevious, Pac-man (and Ms. Pac-Man), Asteroids, Battlezone, etc. I liked being able to get the reference and wondered which game I would be working with every time I signed in.) Pine was the system, I remember that, and it was a perfectly serviceable TUI to check, manage, and respond quickly to various e-mails that had been sent out and I was looking at in the time between classes, or when I was in the lab. I felt smart and technologically awesome that I was able to use the terminal for this kind of purpose, and to do it well. And, yes, I did feel a little smug and superior that I could do this on whichever machine was available, instead of having to wait for a specific machine to come available or to trek to a specific laboratory where those machines were available. My university-aged self is still unlearning things as much as they are learning things, and so I have to treat them with patience and understanding.

So when it comes to the terminal and the command line, I have decades of experience in using it, in having things blow up in my face, in having to use it because various utilities, servers, and tools run best (or at all) from terminal, and in using it because I want to see what a piece of software does, and whether I can get things to go faster from there than from other methods. I'd say that comfort with the command line is a second-order comfort when it comes to computers, because you can't really get comfortable with a command line until you are properly comfortable with the machine itself, and feeling competent and curious enough to try things, have them explode, recover from them, and otherwise recognize that many things that wreck a computer can be recovered from, although what form the recovery takes is different depending on how big of an explosion happened, and that most systems with a GUI will ask if you're sure before they do something destructive. This is the kind of thing that a spare machine is perfect for, because spare machines are what you do things that are destructive or explosive on, and then when they do explode or do unwanted things, you have gained knowledge about what to do or what not to do, or that the thing you tried to do was not properly formed, even if it was accepted as valid. Sometimes you discover some really cool things you can do and then take that knowledge back to the main machine to make it run better and more according to your needs.

Once you have the willingness to experiment and see what happens, and the knowledge backstopping you that you can get out of most common bad situations, and perhaps even the knowledge of how to reconstruct a system from scratch and start again, then you can start getting more comfortable on the command line and using the terminal when it seems appropriate or useful to do so. Because, again, many terminal commands don't ask if you're sure, they just do what you told them to do. (More of them probably should ask, but most of the core utilities and commands on any operating system were developed and used by people who did know what they were doing, and they probably found it annoying to have to confirm it every time they wanted to do something. For Linux specifically, even though many distributions of Linux are better about not requiring the use of the terminal or the command line, there's still a certain assumption baked in that the terminal is the real heart of using Linux, and everything else is eye candy, abstraction, or concession made to those who don't want to do everything from the terminal. The terminal-centric focus of Linux makes it both very powerful and very portable, since the terminal itself, and the core utilities don't require a lot of fancy anything to work, and can be put in embedded or underpowered systems to provide functionality and flexibility to their operation. Terminal commands and abilities are also part of creating scripts and programs that will chain together commands to produce useful output, which is the part where the possibilities expand outward exponentially.

I'm trying not to make the terminal sound completely intimidating, and that you need all the time and experience that I have with it to produce useful things and be comfortable with it. But especially in Linux systems, grasping the terminal and what you can do with it is almost a prerequisite for unlocking the full potential of such a system. And I don't fully know everything that I can do with the terminal, because I haven't had to learn it yet, so you don't have to know everything and read all the man pages before you can start using and experimenting with it. I do think, though, that having grown up in an era where the command line was the primary method of accessing programs and using the computer has made it easier for me to re-adopt a terminal, now that I've chosen an operating system that relies on it. I'd still rather that people took the time to put in interfaces and help for people when they release programs to users, or that, if it makes sense, they build a GUI component for their program so that it's more widely accessible, but that is not always the case.

I guess the point is to say that computer touchery does not have to involve terminals and text editors, and that there are several fine programs that require neither to run admirably and well. And that for as much as I have experience with it, there's still plenty that I don't know and may never know. It's one of the places where I can have a growth mindset about myself, and I think it's one of the places where others can, as well, so I'd encourage you to dive in, in whatever way that you can. There will be gatekeeping jerks, there will be unhelpful StackOverflow answers, and sometimes the thing that's the best and most useful response for you will be a blog post from decades ago, but there is a certain satisfaction, at least for me, that comes from accomplishing a task through clever program use or even writing the script yourself and seeing the output that you wanted to have happen scroll by in the console. I am unlikely to claim that I'm good at any of this, but I could venture forth that I am at least semi-competent.