Irreal

Russ Cox has an excellent post on managing software dependencies. He begins by describing the problem: we’ve gone from talking about but not implementing code reuse to the wholesale use of packages/libraries/modules that we often don’t know much about. Most often these dependencies are downloaded from the Internet. All too often, these dependencies are integrated into projects without any analysis or investigation. This is, Cox says, like hiring a programmer you’ve never heard of and about whom you know nothing. The results of this are well known within the programmer community and Cox mentions a few.

The rest of post concerns strategies for dealing with the problem. Sadly, the solutions are difficult to implement and require a large commitment of engineering time and resources. They involve things like:

• Investigating the history of the project that produced the package.
• Examining the code for obvious red flags and quality.
• Making sure the project uses regression tests and running them yourself.
• Identifying the package’s dependencies and iterating the process on them.
• Writing and running your own tests that focus on your use of the package.

and other strategies.

The problem is ongoing. Every time the package is upgraded you have to rerun the regression tests and look at the diffs to make sure it’s still doing what you need it to.

Finally, Cox considers technical solutions to the problem. By this he means things like enhancing package managers to track subdependencies and enhancing compilers to embed a manifest of dependencies and their version numbers in the binary.

As usual with Cox, the post is interesting and thought provoking. If you’re working on large projects that use external libraries you should definitely read it. Of course, implementing his recommendations is hard. Even Cox admits that they often don’t so at Google because it’s so much work and takes so long.

Mike Zamansky has a new video up but it’s not one in his Using Emacs Series. Zamansky is doing a miniseries (probably 2 or 3 videos) on GitHub Classroom and how he uses GitHub in his teaching. His first video is on Travis-CI and how it fits in with his overall teaching workflow.

If you’re in CS education, you will definitely want to follow this series but even if you’re not, there’s still something to learn from the videos. For example, although I was vaguely aware of Travis-CI, I didn’t know how it worked or all the things you could do with it. Zamansky’s current video fills in that gap nicely and even though it’s unlikely that I’ll need to set up a teaching environment, it’s entirely possible that I might find having a continuous integration environment of the sort that Travis offers useful. As usual with Zamansky’s videos, there’s always something to learn.

The video is 18 minutes, 45 seconds so plan accordingly. I’m looking forward to the rest of series not only out of curiosity but also to see what other useful things I can learn.

About a year and a half ago, I wrote, somewhat disparagingly, about the idea of using the ed editor for every day work. The problem is that ed is a line editor meant for use with teletype-like devices. Because it can’t use cursor addressing, editing happens on whole lines. Although a few intrepid souls claim to use it for day-to-day work, it really has only two uses today:

• Emergency fixes. Because ed is small and lives in /bin, it’s available even if Unix/Linux has problems coming up and wasn’t able to mount /usr/bin, the home of full screen editors such as Vi(m) and Emacs. Many developers and system administrators learn ed for just such occasions.
• Scripting. Most editors can do some sort of scripting but they aren’t really that good at it. Scripting has always been an important ed use case.

After writing the above post and another that looked at a scripting application of ed, I went back to not thinking about it. Then, I saw the coda to Brian Kernighan’s video about where the name “grep” came from. In it, Kernighan was asked what editor he uses today. He mostly uses either Vi or Sam but said that he occasionally fires up ed for a quick editing job or when he wants to script. For some reason that inspired me to take another look at ed.

I’d never bothered to actually learn ed but I knew enough about it from Vi—which is built on top of ed¹—that I could use it in an emergency. There are only a handful of commands to learn (remember there are no cursor movements) so it was pretty easy to get up to speed. Almost all the action is in the line addressing, which, again, is almost the same as that in the Vi(m) ex commands.

I have a log file that I edit everyday—mostly just deleting certain lines that match a regexp—so I’ve taken to doing that in ed. That helps me remember the ed commands and various line addressing functions. Occasionally, I’ll do some other (really unnecessary) edits just for practice. The next time I have a boot emergency, I’ll be ready. Of course, I haven’t had to worry about that in some years but if the day ever comes…

If you’d like to come up to speed with ed (it probably takes less than an hour), here are some resources:

1. The Gnu ed manual. It’s sort of like an extended man page and covers all the commands.
2. Kernighan’s ed tutorial which covers just about everything you need to know about ed.
3. Kernighan’s Advanced Editing on UNIX tutorial, which covers some of the more advanced ed features.

Realistically, you’ll probably never need to use it in anger but if you do learn it, you can tell everyone that you can use the standard Unix editor, and as Eric S Fraga says, familiarity with ed makes using sed scripts easy.

NOTE (Added after this was written but before it was published): Despite popular belief, ed is far from dead and is, in fact, still being actively maintained as a GNU project. Here’s the announcement of the release of GNU ed 1.15. It’s 2019 and the standard Unix editor just keeps on keeping on.

This post may seem Apple-centric but it’s not. Even though it’s Apple that is patenting this idea, it’s the technology itself that I find interesting and want to discuss.

According to AppleInsider, Apple has applied for a patent on replacing keyboards with a glass panel having raised key sections. Once can see why, after the keyboard disaster of the penultimate MacBook release, Apple would be interested in such an idea. It would certainly prevent crumbs and dust from jamming things up as well as making keyboard cleanup easier. It would, I suppose, even protect against the occasional coffee spill.

According to the article, the raised key sections and a small amount of give provide tactile feedback to the user, making it easier to touch type on the keyboard than it is with the virtual keyboards of the iPhone and iPad.

This seems attractive to me but I’m not convinced that it would provide a good “typing” experience. Of course, Apple patents all type of ideas but only actively develops a few of them so there’s no guarantee that such a keyboard will ever become a reality.

Many developers, myself included, prefer mechanical keys and a few us diehards still swear by the IBM Model M and its Unicomp progeny. It’s hard to imagine that cohort accepting a keyboard where the keys are not only not mechanical but don’t move at all. Still, I love a chance to tryout such a thing. What about you?

This post is nominally specific to Mac users but the same techniques, mutatis mutandis, could be used by developers on Linux and perhaps even Windows.

It’s a commonplace today that disk space is cheap and that we can operate—to a first approximation—as if we had infinite disk storage. The reality, of course, is a bit different. Our local disk space, while generous in comparison to just a few years ago, is anything but infinite and sooner or later we’re going to have to clean things up. That’s because crud—in the form of log files, old caches, and other such files—accumulate over time wasting space and making things slower.

There are, of course, programs to automate a lot of the cleansing but developers have special needs that most of those programs don’t know about. Gant Laborde has a nice post entitled How to free up space on your developer Mac that discusses some of the things developers can do to free up space on their Mac. As I said, most of his ideas translate to other Unix-like systems and perhaps—although I don’t know for sure—to Windows.

It’s surprising how many ways cruft can accumulate on your machine so it’s nice to see some techniques for getting rid of a bit of it. If you’re a developer, be sure to take a look at Laborde’s post even if you’re not a Mac user.