The Mandelbear's Musings

Rant: Patient Portal as a (dis)Service

Thu, 01 Feb 2024 05:42:11 GMT

\begin{rant}

If you look at Done Since 2024-01-21 and scroll down to Friday (or search for "0126Fr"), you'll find an uncharacteristically-long log item that starts out "contact liberatormedical.com Customer Service"... followed by a series of '->' items. When you see this sort of thing, it's often a sign that Someone (or more likely some company) is WRONG on the Internet.

This has gotten long, so I'm putting it under a ( cut tag. )

\end{rant}

comments

Happy Birthday to Git, and a signal boost

Fri, 07 Apr 2023 16:54:08 GMT

The Git version-control system was released 18 years ago today, so it's old enough to vote in the US. (The most recent version, 2.40.0, was released this year on my birthday. But I digress.)

In related news, I'd like to join elf and ysabetwordsmith in boosting the signal for The Fujoshi Guide to Web Development by Essential Randomness, on Kickstarter.

The Fujoshi Guide to Web Development is a series of zines/books featuring anthropomorphized versions of programming languages and concepts (aka gijinka), each one engineered from the ground up to cater to transformational fandom's sensibilities and interests.

elf summarizes it as:

Problem: The corporate webosphere is all based on public feeds of identical-looking scrolling content. Fandom has mostly lost the habit of creating their own webspaces for purposes other than constant interaction. But most of the tutorials are horribly hostile to beginners, or to fandom purposes, or both.
Solution: Learn web development from hot anime guys in a dating sim. Well, not actually a dating sim. But it looks like a dating sim.

... and appropriately enough the first demo is about Git (personified as a hawt catboy). (My guess is that Git's persona was chosen so that they could personify GitHub as an octocat-boy.) I'm not in the target demographic, obviously, but I'm all for anything that promises to get fans and other outsiders hooked on web development and version control.

comments

Public Service Announcement: Things to watch out for

Wed, 29 Sep 2021 23:34:59 GMT

A rather mixed bag of things that, arguably, I should have written about a week ago.

1: the Let's Encrypt root certificate.

Hopefully this won't affect you, but if your browser starts complaining about websites suddenly being untrusted, you need to upgrade. The problem is that Let's Encrypt's root certificate is expiring, and will be replaced by a new one (see the link above for details). Starting October 1^st, browsers and other programs that rely on the old cert will have problems if they haven't been upgraded in the last year.

You keep your OS and your browser up to date, right? There are some old apps and operating systems that are no longer receiving upgrades, and so won't know about the new root cert. Specifically, if you're using one of these products:

OpenSSL <= 1.0.2, Windows < XP SP3, macOS < 10.12.1, iOS < 10 (iPhone 5 is the lowest model that can get to iOS 10), Android < 7.1.1 (but >= 2.3.6 will still mostly work), Mozilla Firefox < 50, Ubuntu < 16.04, Debian < 8, Java 8 < 8u141, Java 7 < 7u151, NSS < 3.26, Amazon FireOS (Silk Browser).
Possibly, Cyanogen > v10, Jolla Sailfish OS > v1.1.2.16, Kindle > v3.4.1, Blackberry >= 10.3.3, PS4 game console with firmware >= 5.00, IIS

(You can probably uptrade to the newest Firefox or switch to a recent version of Chrome, which will restore your ability to browse the web, but a few other things might still fail. (For example, Firefox will keep working on my ancient Mac Mini, but Safari probably won't.)

The following articles go into a lot more detail; you can get a good overview from the first two:

Smart TVs, fridges and light bulbs may stop working next year: Here's why An Internet of Trouble lies ahead as root certificates begin to expire en masse, warns security researcher • The Register The Impending Doom of Expiring Root CAs and Legacy Clients Let's Encrypt's Root Certificate is expiring! Certificate Compatibility - Let's Encrypt

2. Phillips Respironics CPAP recall:

If you're using a CPAP made by Phillips Respironics, hopefully you've already seen the Recall Notification [PDF]. I missed it, through my habit of ignoring notifications in the Dreamstation app and website. The email I got from Medicare says:

If you own or rent one of the Philips products that was recalled, talk to your doctor as soon as possible about whether to continue using your recalled equipment. If you would like to replace or repair your equipment, the supplier you bought the equipment from is responsible for replacing or repairing rental equipment at no cost to you when the equipment is less than 5 years old.

If, like me, you insist on continuing to use your facehugger, install an antibacterial filter, which will keep little bits of soundproofing foam out of your lungs. This is probably only necessary if you've been using ozone to clean your device, but I decided not to take chances.

3. Chevrolet Bolt EV recall:

If you own a Bolt, you should have received several letters about this recall. Hopefully you haven't been throwing them away unread, but if you have, you'll want to enable "hilltop reserve" to limit your charging to 90%, don't run your battery down below about 70 miles, park outside immediately after charging, and don't leave your Bolt charging indoors overnight. "Experts from GM and LG have identified the simultaneous presence of two rare manufacturing defects in the same battery cell as the root cause of battery fires in certain Chevrolet Bolt EVs." You don't want to take chances with battery fires. They're nasty; lithium is perfectly capable of burning under water.

Be safe out there.

On a more hopeful(? helpful, at least) note, dialecticdreamer has posted Demifiction: Breaking Omaha!, which despite being set in a fictional universe contains a lot of practical advice for disaster preparedness.

comments

Songs for Saturday: Singing in the time of COVID19

Sat, 09 May 2020 20:14:00 GMT

You may remember that, somewhat over a month ago, I asked whether there were any tools for voice teaching online. I didn't get any useful suggestions. (Discord was suggested, but with an inherent 200ms delay it would be pretty useless for teaching or band practice.)

Since then, a couple of things -- not necessarily answers -- have turned up. From the National Association of Teachers of Singing, we have a COVID Resources Page and two video panel discussions: Emergency NATS Chat Calming the Coronavirus Crisis and Taking Your Teaching Online #natschats, and A Conversation: What Do Science and Data Say About the Near Term Future of Singing. The description of the latter is:

The National Association of Teachers of Singing, the American Choral Directors Association (ACDA), Chorus America, Barbershop Harmony Society, and Performing Arts Medical Association (PAMA) present an important webinar about the near term future of singing as we seek fact based solutions in protecting our singers, teachers, and conductors during this time.

There are more specialized services specifically for jamming that were mentioned in some of the related discussions -- JamKazam, Jamulus, and NINJAM, and a couple of others. With the possible exception of JamKazam they all work by delaying sound by an integral number of beats or bars, which may work for improvisation but probably not for teaching. It's difficult to find good comparisons. There's a conversation going on in this forum; the 2020 part starts on Page 3. Jitsi might work, too, perhaps with a lightly-loaded private server.

(added 5/12) VoiceLessons.com was recommended in one of the NATS videos; didn't make it onto the list in the previous paragraph because it wouldn't be useful to most of my readership, but definitely worth a look if you're teaching.

Disclaimer: I have not (yet) worked through all -- or even most -- of the stuff linked from NATS, and I have not tried any of the remote jam software.

For performers who want to stream concerts, there are lots more options. Here is a blog post on the Pros and Cons of 6 live streaming sites for musicians (from 2016, so a bit dated), and Lynn Noel's Crosscurrents Blog. Lynn has been hosting virtual "house concerts" recently, and has written a great blog series about how to do it.

I'll close with a quote from the last section, titled "Crisis and Transformation" of Reflections on Our First Six Weeks. (I'd link to it directly, but the sections don't have IDs.) Then double back and read the rest. (taken out of sequence because it makes a good closer)

Crisis builds community from within. Six weeks ago, my mom had just died, I was laid off, my knee replacement had just been postponed as an elective surgery, and the Mermaid's Tavern was a pile of old Macs and cables in my basement. I needed motivation to face a pandemic day to day. I found it in a community that urgently needed to sing together. Thank you all for making me believe I too could be essential.
We WILL make harmony again in real time. Harmony is like bread: staple soul food, powered by a living community organism. There's nothing like it hot and fresh. Still, once you've sung with dear friends across five time zones, there's no going back. Online community is here to stay. Come on down to the Mermaid's Tavern.

Feel free to point me at other resources in the comments.

comments

Query: Tools for voice teaching online?

Tue, 24 Mar 2020 04:35:55 GMT

If you've been reading this journal for a while, you probably know that I've been taking singing lessons. (Comparatively few of you have heard me sing recently; those who have say that the improvement has been noticable.)

And even if you've only been reading for the last week, you'll know that I've been "socially distancing" myself -- I'm in a high-risk category due to my age, and not going out of the house for anything but medical appointments and food. Singing lessons aren't "essential", so I've stopped going -- and Nancy, my singing teacher, has a huge problem.

So I'm asking the lazy web for help finding a videoconferencing system that can be used for singing lessons. I want Nancy to be able to play something on a MIDI keyboard and hear me singing along with it. That would require suppressing the normal simultaneous monitoring on the teacher's end -- the MIDI should play only on my end, and get mixed with my voice at that point. But when Nancy is using her microphone, the return channel has to be muted. And if she wants to sing along with something she's playing, she needs to hear the keyboard at her end, without the round-trip delay.

I'm beginning to suspect that the only way to get all of this is to write it myself, but I'd love to be proved wrong. Meanwhile, I'd settle for something with extremely low transmission delay; that would mean point-to-point rather than going through a server.

And if any of you are giving lessons remotely, I'd love to hear what works for you.

comments

test4

Sun, 29 Dec 2019 03:18:20 GMT

test headers (crossposted from $BLOGIN)

comments

How to MakeStuff (blogging)

Wed, 06 Nov 2019 06:05:00 GMT

Today the computer curmudgeon talks about how he blogs.

I think it's widely known that I update this journal (and by that I mean both my Dreamwidth journal, which you are probably reading now, and my Computer Curmudgeon website), using a rickety combination of shell scripts and makefiles called MakeStuff. There are several good reasons for that. (Whether "because I can" is a good reason or not is debatable. There are others.)

A little over a year ago I made a planning post, and the "Where I am now" section remains a pretty good, albeit sketchy, description of the process. There's also an even sketchier one in the README file for MakeStuff/blogging. It had a list of what I wanted to do next, but essentially the only thing I've actually done is posting in either HTML or Markdown.

I have, however, reorganized things a bit, so that all of the relevant scripts are in MakeStuff/blogging -- the last part was moving in the script, now called charm-wrapper, that takes the post's metadata out of its email-like header and turns it into a command line for charm, a livejournal/dreamwidth posting client written in Python. It isn't a very good solution, but it works.

And since I'm running out of time to make a post today, I'm going to start this series with the other utilities in MakeStuff/blogging. And then go add this list to the README.

check-html is a simple wrapper for html-tidy, a popular HTML syntax checker. Since it's not actually being used to fix syntax, it can play fast-and-loose with things like the header (it's just text) and blog-specific tags like <cut> and <user>. It handles those by putting a space after the "<" character. It would be trivial to add this to the make recipe for post.
last-post is a site-scraper that returns the URL of your most recent post. It's useful, because charm doesn't return it. (I eventually put that functionality into charm-wrapper, but it's still useful. Eventually it wants to take a date on the command line.
word-count is what I use to generate the NaBloPoMo statistics at the bottom of posts in November. (In other months, you just get a straight list; you can also get a listing for a whole year.)

NaBloPoMo stats:
     43 2019/11/01--rabbit-rabbit-rabbit.html
   1731 2019/11/02--s4s-memorials.html
   1465 2019/11/03--done-since-1027.html
    145 2019/11/04--i-ought-to-post-something.html
    430 2019/11/05--how-to-makestuff.html
-------
   3814 words in 5 posts this month (average 762/post)
    430 words in 1 post today

Another fine post from The Computer Curmudgeon (also at computer-curmudgeon.com).
Donation buttons in profile.

comments

Armagadd-on 2.0

Sat, 04 May 2019 15:34:35 GMT

If you were using Firefox any time after midnight UTC on Star Wars Day (May the 4th), you probably noticed that all your add-ons were disabled, with the unhelpful message: "... could not be verified for use in Firefox and has been disabled". If you're reading this before 9am or so Pacific time on the 4th they may still be.

This happened because a certificate in the code-signing certificate chain expired at midnight UTC. The same thing happened three years ago, causing today's version to be dubbed "Armagadd-On-2.0".

wait for the fix to roll onto your browser (you can look for it by browsing to about:studies and looking for hotfix-update-xpi-signing-intermediate-bug-1548973) (make sure that "Firefox Options/Preferences -> Privacy & Security -> Allow Firefox to install and run studies" is checked) (it landed in my browser at 8:18 or so Pacific time)
download and run either the Firefox nightly build, LTS, or developer edition and set xpinstall.signatures.required to false in about:config
temporarily switch to Chrome.

This outage highlights a weakness in any security technique that involves code-signing, or indeed anything else that involves the Public Key Infrastructure and X.509 certificates (which is just about everything except SSH and PGP/GnuPG): an expired or revoked certificate can wreak wide-spread havoc. X-509 certs are used not only for code signing but for TLS/SSL (the protocol behind HTTPS). At this point there doesn't seem to be much that can be done about it in the near term.

Resources

Another fine post from The Computer Curmudgeon (also at computer-curmudgeon.com).
Donation buttons in profile.

comments

Git: The other blockchain

Fri, 22 Feb 2019 06:25:57 GMT

Part 1: Blockchain

Blockchain is the technology behind Bitcoin and other cybercurrencies. That's about all anyone outside the software industry knows about it; that and the fact that lots of people are claiming that it's going to transform everything. (The financial industry, the Web, manufacturing supply chains, identity, the music industry, ... the list goes on.) If you happen to be in the software industry and have a moderately good idea of what blockchain is, how it works, and what it can and can't do, you may want to skip to Part 2.

Still with me? Here's the fifty-cent summary of blockchain. Blockchain is a distributed, immutable ledger. Buzzword is a buzzword buzzword buzzword? Blockchain is a chain of blocks? That's closer.

The purpose of a blockchain is to keep track of financial transactions (that's the "ledger" part) and other data by making them public (that's half of the "distributed" part), keeping them in blocks of data (that's the "block" part) that can't be changed (that's the "immutable" part, and it's a really good property for a ledger to have), are linked together by hashes (that's the "chain" part, and we'll get to what hashes are in a moment), with the integrity of that chain guaranteed by a large group of people (that's the other half of the "distributed" part) called "miners" (WTF?).

Let's start in the middle: how can we link blocks of data together so that they can't be changed? Let's start by making it so that any change to a block, or to the order of those blocks, can be detected. Then, the fact that everything is public makes the data impossible to change without that change being glaringly obvious. We do that with hashes.

A hash function is something that takes a large block of data and turns it into a very long sequence of bits (which we will sometimes refer to as a "number", because any whole number can be represented by a sequence of binary digits, and sometimes as a "hash", because the data has been chopped up and mashed together like the corned beef hash you had for breakfast). A good hash function has two important properties:

It's irreversible. Starting with a hash, it is effectively impossible to construct a block of data that will produce that hash. (It is significantly easier to construct two blocks with the same hash, which is why the security-conscious world moves to larger hashes from time to time.)
It's unpredictable. If two blocks of data differ anywhere, even by a single bit, their hashes will be completely different.

Those two together mean that if two blocks have the same hash, they contain the same data. If somebody sends you a block and a hash, you can compare the hash of the block and if it matches, you can be certain that the block hasn't been damaged or tampered with before it got to you. And if they also cryptographically sign that hash, you can be certain that they used the key that created that signature.

Now let's guarantee the integrity of the sequence of blocks by chaining them together. Every block in the chain contains the hash of the previous block. If block B follows block A in the chain, B's hash depends in part on the hash of block A. If a villain tries to insert a forged transaction into block A, its hash won't match the one in block B.

Now we get to the part that makes blockchain interesting: getting everyone to agree on which transactions go into the next block. This is done by publishing transactions where all of the miners can see them. The miners then get to work with ~~shovels and pickaxes~~ big fast computers, validating the transaction, putting it into a block, and then running a contest to see which of them gets to add their block to the chain and collect the associated reward. Winning the contest requires doing a lot of computation. It's been estimated that miners' computers collectively consume roughly the same amount of electricity as Ireland.

There's more to it, but that's blockchain in a nutshell. I am not going to say anything about what blockchain might be good for besides keeping track of virtual money -- that's a whole other rabbit hole that I'll save for another time. For now, the important thing is that blockchain is a system for keeping track of financial transactions by using a chain of blocks connected by hashes.

The need for miners to do work is what makes the virtual money they're mining valuable, and makes it possible for everyone to agree on who owns how much of it without anyone having to trust anyone else. It's all that work that makes it possible to detect cheating. It also makes it expensive and slow. The Ethereum blockchain can handle about ten transactions per second. Visa handles about 10,000.

Part 2: The other blockchain

Meanwhile, in another part of cyberspace, software developers are using another system based on hash chains to keep track of their software -- a distributed version control system called git. It's almost completely different, except for the way it uses hashes. How different? Well, for starters it's both free and fast, and you can use it at home. And it has nothing to do with money -- it's a version control system.

If you've been with me for a while, you've probably figured out that I'm extremely fond of git. This post is not an introduction to git for non-programmers -- I'm working on that. However, if you managed to get this far it does contain enough information to stand on its own,

Git doesn't use transactions and blocks; instead it uses "objects", but just like blocks each object is identified by its hash. Instead of keeping track of virtual money, it keeps track of files and their histories. And just as blockchain keeps a complete history of everyone's coins, git records the complete history of everyone's data.

Git uses several types of object, but the most fundamental one is called a "blob", and consists of a file, its size, and the word "blob". For example, here's how git idenifies one of my Songs for Saturday posts:

git hash-object 2019/01/05--s4s-welcome-to-acousticville.html
957259dd1e41936104f72f9a8c451df50b045c57

Everything you do with git starts with the git command. In this case we're using git hash-object and giving it the pathname of the file we want to hash. Hardly anyone needs to use the hash-object subcommand; it's used mainly for testing and the occasional demonstration.

Git handles a directory (you may know directories as "folders" if you aren't a programmer) by combining the names, metadata, and hashes of all of its contents into a type of object called a "tree", and taking the hash of the whole thing.

Here, by the way, is another place where git really differs from blockchain. In a blockchain, all the effort of mining goes into making sure that every block points to its one guaranteed-unique correct predecessor. In other words, the blocks form a chain. Files and directories form a tree, with the ordinary files as the leaves, and directories as branches. The directory at the top is called the root. Top? Top. For some reason software trees grow from the root down. After a while you get used to it.

Actually, that's not quite accurate, because git stores each object in exactly one place, and it's perfectly possible for the same file to be in two different directories. This can be very useful -- if you make a hundred copies of a file, git only has to store one of them. It's also inaccurate because trees, called Merkle Trees are used inside of blocks in a blockchain. But I digress.

Technically the hash links in both blockchains and git form a directed acyclic graph -- that means that the links all point in one direction, and there aren't any loops. In order to make a loop you'd have to predict the hash of some later block, and you just can't do that. I have another post about why this is a good thing.

And that brings us to the things that make git, git: commits. ("Commit" is used in the same sense, more or less, as it is in the phrase "commit something to memory", or "commit to a plan of action". It has very little to do with crime. Hashes are even more unique than fingerprints, and we all know what criminals think about fingerprints. In cryptography, the hash of a key is called its fingerprint.)

Anyway, when you're done making changes in a project, you type the command

git commit

... and git will make a new commit object which contains, among other things, the time and date, your name and email address, maybe your cryptographic signature, a brief description of what you did (git puts you into your favorite text editor so you can enter this if you didn't put it on the command line), the hash of the current root, and the hash of the previous commit. Just like a blockchain.

Unlike earlier version control systems, git never has to compare files; all it has to do is compare their hashes. This is fast -- git's hashes are only 20 bytes long, no matter how big the files are or how many are in a directory tree. And if the hashes of two trees are the same, git doesn't have to look at any of the blobs in those trees to know that they are all the same.

@ Blockchain 101 — only if you ‘know nothing’! – Hacker Noon @ When do you need blockchain? Decision models. – Sebastien Meunier @ Git - Git Objects @ git ready » how git stores your data @ Git/Internal structure - Wikibooks, open books for an open world @ Why Singly-Linked Lists Win* | Stephen Savitzky

Another fine post from The Computer Curmudgeon (also at computer-curmudgeon.com).

comments

Privacy Tips

Tue, 08 Jan 2019 04:20:05 GMT

Some day I ought to put together a comprehensive list of privacy-related links. This is not that list; it's just a few of the links that came my way recently, in no particular order.

I'd suggest starting with the ACLU's What Individuals Should Do Now That Congress Has Obliterated the FCC’s Privacy Protections. It's a good overview.

DuckDuckGo is my current privacy-preserving search engine of choice. The DuckDuckGo Blog has been a good source of additional information. I especially recommend this article on How to Set Up Your Devices for Privacy Protection -- it has advice for iOS, Android, Mac, Windows 10 and 7, and Linux. Also check out a broader range of tips here.

The Electronic Frontier Foundation, as you might expect, is another great source of information. I suggest starting with Tools from EFF's Tech Team. While you're there, install Privacy Badger. It's not exactly an ad blocker; what it does is block trackers.

Here's an article on Which Browser Is Better for Privacy? (Spoiler: it's Firefox.) Then go to Firefox Privacy - The Complete How-To Guide.

For the paranoid among us, there are few things better than Tor Browser. If you use it, you'll probably want to turn off Javascript as well.

The Linux Journal's article on Data Privacy: Why It Matters and How to Protect Yourself has a lot of good advice, most of which isn't Linux-specific at all.

However, if you are running Linux, you'll want to look at How To Encrypt Your Home Folder After Ubuntu Installation, Locking down and securing SSH access to your server, and Own Your DNS Data.

Another fine post from The Computer Curmudgeon (also at computer-curmudgeon.com).

comments

Done Since 2018-07-29

Mon, 06 Aug 2018 00:59:06 GMT

It's been a week. There were some good parts. Music Under the Trees, yesterday at Betsy Tinney's, was one of them, even if we did have to leave early because Colleen was flagging. (I didn't object, because to be honest I'd been dreading driving home in the dark after three nights of not enough sleep. But still.)

Another was getting the rest of the bed box installation done, which happened last Sunday. It's awesome. N got to try it out Saturday night; it was complete enough for sleeping in at that point.

A third good thing wa a very nice visit to the southern end of the Rainbow Caravan, to spend a day with N and the kids. We will get our household back together. It may take a while.

And I got a very preliminary version of my "Consulting business" website done, as a GitHub Pages site. Last week N and I had picked a theme: Read Only, by HTML5 Up. It's cool - big banner across the top of the text, and a neat circular image (which it turned out was masked out by setting the enclosing box's boundary radius to 100%). Only one problem.

GitHub Pages are a snap to set up; you can do it in five minutes if you accept all the defaults. And it uses a nice static site builder called Jekyll which has themes that are pretty easy to set up. The devil's in the details, as usual. Because although we found "Read Only" through a gallery of Jekyll themes, it turned out that it wasn't a theme at all, just a mock-up. And although I eventually found a Jekyll version, it wasn't particularly usable.

I now know how to roll my own Jekyll theme, and I can consider myself an advanced beginner at the – Liquid template language and CSS stylesheets. By the way, the MDN Web Docs (MDN stands for Mozilla Developer Network, BTW) are awesome. They have tutorials on all the important web technologies: HTML, Javascript, and CSS, plus some more obscure ones. And when you get to the edge cases, they have reference docs.

It took me, basically, all week, with a huge amount of frustration along the way.

We appear to be getting into the bad parts of the week, don't we? Right.

I believe I mentioned that I'd been dreading going home from Betsy's late at night (I'm nowhere near as good a driver as I was at 50, and I know it). My guess is that that was at the root of the anxiety attacks I had Saturday and Sunday. (Panic attacks are intense, and supposedly last for only a few minutes to an hour or so. Anxiety attacks can -- and in my case, do -- last all day.

And I have "Trigger finger" in my left thumb. It's been getting worse, not better, in spite of the brace I'm wearing, which incidentally makes it almost impossible to type because my thumb keeps hitting my laptop's trackpad and left button. Anyway.

Aaaaaaand, I've been spending almost all my time grappling with Jekyll and CSS, and not getting any job applications done. Bletch.

( Notes & links, as usual )

comments

Blog posting software planning

Mon, 23 Jul 2018 04:25:15 GMT

In comments on "Done Since 2018-07-15" we started having a discussion of mirroring and cross-posting DW blog entries, and in particular what my plans are for implementing personal blog sites that mirror all or some of a -- this -- Dreamwidth journal.

Non-techie readers might conceivably want to skip this post.

Where I am now:

Right now, my blog posting process is, well, let's just say idiosyncratic. Up until sometime late last year, I was posting using an Emacs major mode called lj-update-mode; it was pretty good. It had only two significant problems:

It could only create one post at a time, and there was no good way to save a draft and come back to it later. I could live with that.
It stopped working when DW switched to all HTTPS. It was using an obsolete http library, and noone was maintaining either of them.

My current system is much better.

I run a command, either make draft or, if I'm pretty sure I'm going to post immediately, make entry. I pass the filename, without the yyyy/mm/dd prefix, along with an optional title. If I don't pass the title I can add it later. The draft gets checked in with git; I can find out when I started by using git log.
I edit the draft. It can sit around for days or months; doesn't matter. It' an ordinary html file except that it has an email-like header with the metadata in it.
When I'm done, I make post. Done. If I'm posting a draft I have to pass the filename again to tell it which draft; make entry makes a symlink to the entry, which is already in a file called yyyy/mm/dd-filename.html. It gets posted, and committed in git with a suitable commit message.

You can see the code in MakeStuff/blogging on GitHub. It depends on a Python client called charm, which I forked to add the Location: header and some sane defaults like not auto-formatting. Charm is mostly useless -- it does almost everything using a terminal-based text editor. Really? But it does have a "quick-post" mode that takes metadata on the command line, and a "sync" mode that you can use to sync your journal with an archive. Posts in the archive are almost, but not quite, in the same format as the MakeStuff archive; the main difference is that the filenames look like yyyy/mm/dd_HHMM. Close, but not quite there.

There's another advantage that isn't apparent in the code: you can add custom make targets that set up your draft using a template. For example, my "Done since ..." posts are started with make done, and my "Computer Curmudgeon" posts are started with make curmudgeon. There are other shortcuts for River and S4S posts. I also have multiple directories for drafts, separated roughly by subject, but all posting into the same archive.

Where I want to go:

Here's what I want next:

The ability to post in either HTML or markdown -- markdown has a great toolchain, including the ability to syntax-color your code blocks.
The ability to edit posts by editing the archived post and uploading it. Right now it's a real pain to keep them in sync.
A unified archive, with actual URLs in the metadata rather than just the date and time in the filename.
The ability to put all or part of my blog on different sites. I really want the computer-related posts to go on Stephen.Savitzky.net (usually shortened to S.S.net in my notes), and a complete mirror on steve.savitzky.net (s.s.net).
Cross-links in both directions between my sites and DW.

How to get there:

Here's a very brief sketch of what needs to be done. It's only vaguely in sequence, and I've undoubtedly left parts out. But it's a start.

Posting, editing, and archiving

Posting in HTML or markdown is a pretty easy one; I can do that just by modifying the makefiles and (probably) changing the final extension from .html to .posted so that make can apply its usual dependency-inference magic.
Editing and a unified archive will both require a new command-line client. There aren't any. There are libraries, in Ruby, Haskell, and Javascript, that I can wrap a program around. (The Python code in charm doesn't look worth saving.) I wanted to learn Ruby anyway.
The unified archive will also require a program that can go back in time and match up archived posts with the right URLs, reconcile the two file naming conventions, and remove the duplicates that are due to archiving posts both in charm and MakeStuff. Not too hard, and it only has to be done once.
It would be nice to be able to archive comments, too. The old ljbackup program can do it, so it's feasible. It's in Perl, so it might be a good place to start.

Mirror, mirror, on the server...

This is a separate section because it's mostly orthogonal to the posting, archiving, etc.

The only part of the posting section that really needs to be done first is the first one, changing the extension of archived posts to .posted. (That's because make uses extensions to figure out what rules to apply to get from one to another. Remind me to post about make some time.)
The post archive may want to have its own git repository.
Templating and styling. My websites are starting to show their age; there's nothing really wrong with a retro look, but they also aren't responsive (to different screen sizes -- that's important when most people are reading websites on their phones), or accessible (screen-reader friendly and navigable by keyboard; having different font sizes helps here, too). Any respectable static site generator can do it -- you may remember this post on The Joy of Static Sites -- but the way I'm formatting my metadata will require some custom work. Blosxom and nanoblogger are probably the closest, but they're ancient. I probably ought to resist the temptation to roll my own.

Yeah. Right.

Another fine post from The Computer Curmudgeon.

comments

Languages: Imperative, Object-Oriented, and Functional

Fri, 06 Jul 2018 05:36:51 GMT

Back when smalltalk was sports and the weather, And an object was what you could see, And we watched "Captain Video" in black-and-white, Before there was color TV. -- "When I Was a Lad"

Even if you're not a programmer (and most of the people I expect to be reading this aren't) you've probably heard one of your geek friends mentioning "object-oriented" programming. You might even have heard them mention "functional" programming, and wondered how it differs from non-functional programming. The computer curmudgeon can help you.

If you are a programmer, you probably know a lot of this. You may find a few items of historical interest, and it might be useful explaining things to the non-programmers in your life.

Imperative languages

As you may recall from last month's post on computer languages, the first programming languages were assembly languages -- just sequences of things for the computer to do, one after another (with a few side-trips). This kind of language is called "imperative", because each statement is a command telling the computer what to do next: "load a into register 2!" "add register 2 to register 3!" "roll over!" "sit!" You get the idea.

Most programmers use "statement" instead of "command" for these things even though the latter might be more correct from a grammatical point of view; a "command" is something one types at a terminal in order to run a program (which is also called a "command").

Most of the earlier programming languages (with one notable exception that we'll get to later) were also imperative. Fortran, Cobol, and Algol were the most prominent of these; most of today's languages descend more-or-less from Algol. (By the way, the Report on the Algorithmic Language Algol 60 is something I always point to as an example of excellent technical writing.)

Imperative languages make a distinction between statements, which do things (like "a := 2", which puts the number 2 into a variable called "a"), and "expressions", which compute results. Another way of saying that is that an expression has a value (like 2+2, which has a value of 4), and a statement doesn't. In earlier languages that value was always a number; later languages add things like lists of symbols and strings of characters enclosed in quotes.

Algol and its descendents lend themselves to what's called "Structured Programming" -- control structures like conditionals ("if this then {that} else {something-else}") and loops (for x in some-collection do {something}) let you build your program out of simple sections that nest together but always have a single entrance and exit. Notice the braces around those sections. Programming languages have different ways of grouping statements; braces and indentation are probably the most common, but some languages use "if ... fi" and "do ... done".

Languages also have ways of packaging up groups of statements so that they can be used in different places in the program. These are called either "subroutines" or "functions"; if a language has both it means that a function returns a value (like "sqrt(2)", which returns the square root of 2) and a subroutine doesn't (like "print('Hello world!')", which prints a familiar greeting.) Subroutines are statements, and functions are expressions. The expressions in parentheses are called either "arguments" or "parameters" -- I was bemused to find out recently that verbs have arguments, too. (A verb's arguments are the subject, and the direct and indirect objects.)

Object-oriented languages

As long as we're on the subject of objects, ...

In the mid 1960s Ole-Johan Dahl and Kristen Nygaard, working at the University of Oslo, developed a language called Simula, designed for simulating objects and events in the real world. Objects are things like cars, houses, people, and cats, and Simula introduced software objects to represent them. Objects have "attributes": my car is blue, my cats are both female, my wife has purple hair. Some of these attributes are objects in their own right: a car has wheels, a cat has four legs and a person has two legs and two arms. Some of these are variables: sometimes my driveway has a car in it, sometimes it doesn't, and sometimes it has two or three.

What this means is that objects have state. A car's speed and direction vary all the time, as does the position of a cat's tail. An object is a natural way to bundle up a collection of state variables.

An object also can do things. In a program, objects rarely do things on their own, some other object tells them what to do. This is a lot like sending the object a message. "Hey, car -- turn left!" "Hey, cat! What color are your eyes?" Software objects don't usually have any of their state on the outside where other parts of the program can see it; they have to be asked politely. That means that the object might be computing something that looks to the outside like a simple state variable -- a car computes its speed from the diameter of its tires and how fast its wheels are turning. All these things are hidden from the rest of the program.

An object has to have a method for handling any message thrown at it, so the documentation of most languages refers to "calling a method" rather than "sending a message". It's the same thing in most cases. As seen from the outside, calling a method is just like calling a function or subroutine, except that there's an extra argument that represents the object. If you think of the message as a command -- an imperative sentence -- it has an implied subject, which is the object you're talking to. Inside the little program that handles the method, the object is represented by a name that is usually either "self" or "this", depending on the language.

One natural thing to do with objects is to classify them, so objects have "classes", and classes tend to be arranged in hierarchies. My cats are cats -- we say that Ticia and Desti are instances of the class "Cat". All cats are animals, so Cat is a subclass of Animal, as are Dog and Person. (In programming languages, classes tend to have their names capitalized. Variables (like "x" or "cat") almost always start with a lowercase letter. Constants (like "Pi", "True", and "Ticia") can go either way.)

An object's class contains everything the computer needs to determine the behavior of its instances: a list of the state variables, a list of the methods it can handle, and so on. Now we get to the fun part.

Simula was just objects and methods tacked on to a "traditional" imperative language -- Algol in that case. Most other "object-oriented" languages work the same way -- C++ is just objects tacked on to C; Python and Perl had objects from the beginning or close to it, but they still include a lot of things -- numbers, strings, arrays, and so on, that aren't objects or (like strings in Java) are pretending to be objects. It doesn't have to be that complicated.

Shortly after Simula was released, Alan Kay at Xerox PARC realized that you could design a programming language where everything was an object. The result was Smalltalk, and it's still the best example of a pure object-oriented language. (It inspired C++ and Java, and indeed almost all existing OO languages, but very few of them went all the way. Ruby comes closest of the languages I'm familiar with.) Smalltalk is ~~turtles~~ objects all the way down.

In Smalltalk numbers are objects -- you can add new methods to them, or redefine existing methods. (Your program will eventually stop working if you redefine addition so that 2+2 is 5, but it will keep going for a surprisingly long time.) So are booleans. True and False are instances of different subclasses of Boolean, and they behave differently when given messages like ifTrue: or ifFalse:. (I'm not going to go into the details here; Smalltalk warrants an article all by itself). Loops are methods, too. The trickiest bit, though, is that classes are objects. A class is just an instance of Metaclass, and Metaclass is an instance of itself.

Someone trying to implement Smalltalk has to cheat in a couple of places -- the Metaclass weirdness is one of them -- but they have to hide their tracks and not get caught.

Functional languages

Smalltalk, for all its object orientation, is still an imperative language underneath. A program is still a sequence of statements, even if they're all wrapped up in methods. Objects have state -- lots of it; they're just a good way of organizing it. Alan Kay once remarked that programming in Smalltalk was a lot like training a collection of animals to perform tricks together. Sometimes it's more like herding cats.

But it turns out that you don't need statements -- or even state -- at all! All you need is functions.

About the same time Alan Turing was inventing the Turing Machine, which is basically a computer stripped-down and simplified to something that will just barely work, Alonzo Church was developing something he called the Lambda Calculus, which did something similar to the mathematical concept of functions.

A mathematical function takes a set of inputs, and produces an output. The key thing about it is that a given set of inputs will always produce exactly the same output. It's like a meat grinder -- put in beef, and you get ground beef. Put in pork, and you get ground pork. A function has no state, and no side-effects. State would be like a secret compartment in the meat grinder, so that you get a little chicken mixed in with your ground beef, and beef in your ground pork. Ugh. A side effect would be like a hole in the side that lets a little of the ground meat escape.

Objects are all about state and side effects. You can call a method like "turn left" on a car (in most languages that would look like car.turn(left)) and as a side effect it will change the car's direction state to something 90 degrees counterclockwise from where it was. That makes it hard to reason about what's going to happen when you call a particular method. It's even harder with cats.

Anyway, in lambda calculus, functions are things that you can pass around, pass to other functions, and return from functions. They're first class values, just like numbers, strings, and lists. It turns out that you can use functions to compute anything that you can compute with a Turing machine.

Lambda calculus gets its name from the way you represent functions: To define a function that squares a number, for example, we say something like:

square = λ x: x*x

Now, this looks suspiciously like assigning a value to a variable, and that's exactly what it's doing. If you like, you can even think of λ as a funny kind of function that takes a list of symbols and turns it into a function. You find the value of an expression like square(3) by plugging the value 3 into the function's definition in place of x. So,

square(3)
  → (λ x: x*x)(3)
  → 3*3
  → 9

Most functional languages don't allow you to redefine a name once you've bound it to a value; if you have a function like square it wouldn't make much sense to redefine it in another part of the program as x*x*x. This is vary different from imperative languages, where variables represent state and vary all over the place. (Names that represent the arguments of functions are only defined inside any one call to the function, so x can have different values in square(2) and square(3) and nobody gets confused.)

Lambda calculus lends itself to recursive functions -- functions that call themselves -- and recursion is particularly useful when you're dealing with lists. You do something to the first thing on the list, and then combine that with the result of doing the same thing to the rest of the list.Suppose you have a list of numbers, like (6 2 8 3). If you want another list that contains the squares of those numbers, you can use a function called map that takes two arguments: a function and a list. It returns the result of applying the function to each element of the list. So

map(square, (6, 2, 8, 3))
 → (36, 4, 64, 9)

It's pretty easy to define map, too. It's just

map = λ (f, l):
	if isEmpty(l)
           then l
	   else cons(f(first(l)), map(f, rest(l)))

The cons function constructs a new list that consists of its first argument, which can be anything, tacked onto the front of its second argument, which is a list. Using first and rest as the names of the functions that get the first item in a list, and the remainder of the list after the first item, is pretty common tese days. Historically, the function that returns the first item in a list is called car, and the function that returns the rest of the list is called cdr (pronounced sort of like "could'r").
I know, the classic introduction to recursive functions is factorial. Lists are more interesting. Besides, I couldn't resist an excuse for mentioning "car". We'll see "cat" in a future post when I discuss scripting languages.

We call map a "higher-level" function because it takes a function as one of its arguments. Other useful higher-level functions include filter, which takes a boolean function (one that returns true or false) and flatmap, which takes a function that returns lists and flattens them out into into a single list. (Some languages call that concatmap.) Higher-level functions are what make functional languages powerful, beautiful, and easy to program in.

Now, Church's lambda calculus was purely mathematical -- Church used it to prove things about what kinds of functions were computable, and which weren't, which is exactly what Alan Turing did with the Turing Machine. We'll save that for another post, except to point out that Church's lambda calculus can compute anything that a Turing machine can compute, and vice versa.

But in 1958 John McCarthy at MIT invented a simple way of representing lambda expressions as lists, so that they could be processed by a computer: just represent a function and its arguments as a list with the function first, followed by its arguments. Trivial? Yes. But brilliant. His paper included a simple function called eval that takes a list representing a function and its arguments, and returns the result. Steve Russell realized that it wouldn't be hard to implement eval in machine language (on an IBM 704).

I'll save the details for another post, but the result was a language called Lisp. It's the second oldest programming language still in use. The post about LISP will explain how it works (elsewhere I've described eval as The most amazing piece of software in the world), and hopefully show you why Kanef's song The Eternal Flame says that God wrote the universe in LISP. Programmers may want to take a look at "Sex and the Single Link".

And finally,

I'd be particularly interested in seeing comments from the non-programmers among my readers, if I haven't lost you all by now. Was this post interesting? Was it understandable? Was it too long? Were my examples sufficiently silly? Inquiring minds...

Another fine post from The Computer Curmudgeon.

comments

Git and GitHub, with a side of Microsoft

Tue, 05 Jun 2018 17:44:16 GMT

If you develop software and haven't just returned from the moon, you've undoubtedly heard that GitHub is being acquired by Microsoft. Depending on your affiliations you might be spelling "being acquired by" as "selling out to". The rest of you are probably wondering what on Earth a GitHub is, and why Microsoft would want one. Let me explain.

Please note: this post isn't about my opinion of today's news. It's really too early to tell, though I may get into that a little toward the end. Instead, I'm going to explain what GitHub is, and why it matters. But first I have to explain Git.

Git is a version-control system. (Version-control systems are sometimes called "source code management" (SCM) systems. If you look closely you might even have spotted "scm" in git's URL up there at the end of the last paragraph.) Basically, a version-control system lets you record the complete history of a project, with what changes were made, who made the each change, when they changed it, and their notes about what they did and why. It doesn't have to be a software project, either. It can be recipes, photographs, books, the papers you're writing for school, or even blog entries. (Yes, I do.)

Before git, most version-control systems kept track of changes in text files (which of course is what all source code is) by recording which lines are different from the previous version. (It's usually done by a program called diff.) This was very compact, but it could also be very slow if you had to undo all the changes between two versions in order to see what the older one looked like.

Git, on the other hand, is blindingly fast in part because it works in the stupidest way possible (which is why it's called "git"). It simply takes the new version of each file that changed since the last version, zips it up, and stuffs it whole into its repository. So it takes git about the same amount of time to roll a file back two versions or two hundred.

The other thing that makes git fast is where it keeps all of its version information. Before git, most version-control systems used a centralized repository on a server somewhere. (Subversion, one of the best of these, even lets you browse the repository with a web browser.) That means that all the change information is going over a network. Git keeps its repository (these days everyone shortens that to "repo") on your local disk, right next to your working copy, in a hidden subdirectory called ".git".

Because its repo is local, and contains the entire history of your project, you don't need a network connection to use git. On the beach, in an airplane, on a boat, ~~with a goat~~, it doesn't matter to git. It's de-centralized. It gets a little more complicated when more than one developer is working on a project.

Bob's been in the office all week working on a project. When his boss, Alice, comes back from the open source conference she's been at all week, all she has to do is tell git to fetch all the changes that Bob made while she was away. Git gets them directly from Bob's repo. If Alice didn't make any changes, that's called a "fast-forward" merge -- git just takes the changes that Bob made, copies those files into Alice's repo, updates her working tree, and it's done.

It's a little trickier if Alice had time to make some changes, too. Now Alice has to merge the two sets of changes, and then let Bob pull the merged files onto his computer. By the way, a "pull" is just a fetch followed by a merge, but it's so common that git has a shorthand way of doing it. (I'm oversimplifying here, but this isn't the time to go into the difference between merge and rebase. It's also not a good time to talk about branches -- maybe some other week.) As you can imagine, this gets out of hand pretty quickly, and it's even worse if there's a whole team working on the project.

The obvious thing to do is for the group to have one repo on a server somewhere that has what everyone agrees is the definitive set of files on it. Bob pushes his changes to the server, and when Alice tries to push her changes, git balks and gives her an error message. Now it's Alice's responsibility to make any necessary fixes and push them to the server. Actually, in a real team, Alice would send her proposed changes around by making a diff and sending email to the other team members to review, and not actually push her changes until someone approves them.

In a large team, this is kind of a hub-and-spokes arrangement. You can see where this is going, right?

GitHub is a company that provides a place for people and projects to put shared git repositories where other people can see them, clone them, and contribute to them. GitHub has become wildly popular, because it's a great place to share software. If you have an open-source software project, putting a public repo on GitHub is the most effective way to reach developers. It's so popular that Google and Microsoft shut down their own code-hosting sites (Google Code and CodePlex respectively) and moved to GitHub. Microsoft, it turns out, is GitHub's biggest contributor.

Putting a public repository on GitHub is free. If you want to set up private repositories, GitHub will charge you for it, and if your company wants to put a clone of GitHub on its own private servers they can buy GitHub Enterprise, but if your software is free, so's your space on GitHub.

That's a bit of a problem, because the software that runs GitHub is not free. That means that they need a steady stream of income to pay their in-house developers, because they're not going to get any help from the open-source developer community. GitHub lost $66 million in 2016, and doesn't really have a sustainable business model that would make them attractive to investors. They needed to get acquired, or they had a real risk of going under. And when a service based on proprietary software goes under, all of their customers have a big problem. But their users? Heh.

Everybody knows the old adage, "if you're getting a service for free you're not the customer, you're the product." That's especially true for companies like Google and Facebook, which sell their users' eyeballs to advertisers. It's a lot less true for a company whose users can leave any time they want, painlessly, taking all their data and their readers with them. I'm sure most of my readers here on Dreamwidth remember what happened to Livejournal when they got bought by the Russians. Well, GitHub is being bought by Microsoft. It's not entirely clear which is worse.

GitHub has an even worse problem than Livejournal did, because "cross-posting" is basically the way git works. There's a company called GitLab that looks a lot like GitHub, except that their core software -- the stuff that wraps a slick web interface around a git repository -- is open source. (They do sell extensions, but most projects aren't going to need them.) If you want to set up your own private GitLab site, it's free, and you can do it in ten minutes with a one-line command. If you find bugs, you can fix them yourself. You'll find a couple of great quotes from their blog at the end of the notes, but the bottom line is that 100,000 repositories have moved from GitHub to GitLab in the last 24 hours.

And once you've moved a project to GitLab, you don't have to worry about what happens to it, because the open-source core of it will continue to be maintained by its community. That's what happened when a company called Netscape went belly-up: Mozilla Firefox is still around and doing fine. And if the fact that GitLab is for profit is a problem for you, there's Apache Allura, gitolite3, gitbucket, and gitweb (to name a few). Go for it!

This so wasn't what I was planning to write today.

Notes:
@ Microsoft Reportedly Acquires GitHub | Linux Journal
The article ends with a list of alternatives:
Gitea
Apache Allura
GitBucket: A Git platform
GitLab
@ Microsoft acquires GitHub for $7.5 billion - TFiR
" According to reports, GitHub lost over $66 millions in 2016. At the same time
GitLab, a fully open source and decentralized service is gaining momentum, giving
users a fully open source alternative. "
@ Microsoft to acquire GitHub for $7.5 billion | Stories official press release
@ Microsoft + GitHub = Empowering Developers - The Official Microsoft Blog
@ A bright future for GitHub | The GitHub Blog
@ Congratulations GitHub on the acquisition by Microsoft | GitLab
" While we admire what's been done, our strategy differs in two key areas. First,
instead of integrating multiple tools together, we believe a single application,
built from the ground up to support the entire DevOps lifecycle is a better
experience leading to a faster cycle time. Second, it’s important to us that the
core of our product always remain open source itself as well. "
@ GitLab Ultimate and Gold now free for education and open source | GitLab
" It has been a crazy 24 hours for GitLab. More than 2,000 people tweeted about
#movingtogitlab. We imported over 100,000 repositories, and we've seen a 7x increase
in orders. We went live on Bloomberg TV. And on top of that, Apple announced an
Xcode integration with GitLab. "

Another fine post from The Computer Curmudgeon.

comments

Computer Languages: compiled, interpreted, and assembled.

Sat, 26 May 2018 04:52:53 GMT

A few months ago while waiting for a ferry with my sister I mentioned a programming language called Elm, which I've been particularly interested in because it's a functional language that compiles into Javascript. Her response, predictably, was something like "I have no idea what you just said. What does 'compiles' mean?" So I explained the difference between compilers and interpreters, and a few other things about programming languages, and she said that it was the first time anyone had explained how programming languages work in a way that made sense to her. In the back of my mind, I thought it might someday make an interesting blog post. So here it is.

Inside of a computer, everything is a number. These days, these numbers are all represented in binary (base two -- just ones and zeroes), stored in a couple of billion numbered locations each of which holds eight binary digits. (A binary digit is called a "bit", and eight of them together make a "byte", which is the amount of data needed to represent a number between 0 and 255, or a single character in a block of text. Apart from the numerical coincidence, computer bits have nothing to do with the bits that were made by breaking apart "pieces of eight".)

The numbers in the computer's memory are used for three different things. First, some of them are used to represent the data that the computer is going to be working on. Second, some of them represent the location of those data. And finally, some of them are instructions that tell the computer what to do with the data. Those instructions are called "machine language" because they're the only thing the machine actually understands. Nobody writes programs in machine language if they can possibly avoid it.

( the details )

TL;DR: an assembler turns each line in a program directly into a machine-language instruction. A compiler takes a program written in a more complicated (for the computer) but easier to write in (for people) and turns it into a sequence of machine-language instructions, that can then be read back in and run. An interpreter skips that last step -- instead of writing out the machine language instructions, it just does them on the spot.

Teaser: Next time I'll talk about different kinds of programming languages: functional, imperative, object-oriented, and scripting. I'm also open to suggestions -- what would you like me to write about?

comments

Project Planning

Sat, 21 Apr 2018 20:32:24 GMT

It's time to do a little planning. As you may remember from the previous post in this series, there are some projects I want to work on. (I also need to find a job, but that's a not completely separate issue. If anyone needs an expert Java programmer or a git expert, let me know.) The ones I want to concentrate on today are the apps, specifically the checklist app and the setlist app. The first major decision about each of them is which framework to base them on.

I really want to learn both React (with React Native on the back end), and Elm (with Electron on the back end), and I think it makes the most sense to write -- or at least start -- the checklist app first, and use React for it.

Here's my reasoning:

React: React is by far the more popular of the two frameworks, so a lot of jobs ask for React experience. One reason it's more popular is that it's basically just a Javascript library -- programs look like Javascript with a little bit of HTML and HTML-like tags embedded in it. It's easy to learn (not that that's really a problem for me -- see below), and there are a lot of starter kits and tutorials around.
Checklist app: It's pretty clear that the Checklist app will have a much wider audience, so it makes sense to do that first. It will also be easier to monetize (possibly as a freemium app, with the free version stand-alone and the premium version tied to a back-end service).
The Setlist app, which includes a lyrics viewer and playlist generator as well, is likely to start out using my rather unusual music toolchain, and would actually be more useful (and get a lot more traffic) as a front end to the lookingglassfolk.com and steve.savitzky.net Song pages. It makes sense for it to start out as part of a website rather than as a stand-alone app.
Elm is a pure functional language (I love functional languages, which is why it would be easy for me) that is closer to Haskell than to Javascript.

Next steps:

Make a place in my working tree for projects. Try not to give in to the temptation to completely refactor the whole hierarchy.
Pull down and install a React starter kit and some kind of Elm starter kit.
Set up the projects' git repos and working trees.

comments

Projects!

Fri, 13 Apr 2018 13:26:02 GMT

It's been just short of a year since I retired, and I don't have a whole lot to show for it in the way of programming, apart from a little work on MakeStuff. OK, a fair amount. And it has an actual user now. But still.

Somewhere around the New Year I started making a(nother) list of potential projects that I wanted to work on in my retirement. As these things do, it got out of hand -- at last count there were 86 unfinished items in it. Time to start something.

There are a few constraints. I can't start any of the woodworking projects yet, because the contents of the garage are in storage waiting for the remodeling to get finished; that includes all of the woodworking tools. So there's that. Same for the recording projects -- my good microphones have either been boxed, or vanished altogether in the last move.

More than half the "projects" on the list are ideas for articles or blog posts -- there are forty or so of those. I should start picking them off, one or two every week, but they're not really projects.

What remains is mostly software: programs (the young people call them "apps" these days) and work on my websites. These are also areas where I have a lot to learn, and where I can develop skills that will be useful if I want -- or need -- to do some consulting. And there's another factor: there's really no difference between a web app and a mobile app! Not any more: with React Native and Electron, one can now build stand-alone cross-platform applications using web front-end frameworks -- they basically bundle a stripped-down browser and a trivial server with your web"site", which is often just a Single-Page Application (SPA). And with languages like Elm that compile into Javascript,...

I can haz apps

One app I want to write will be for managing checklists. (There's an existing app called Checkmate -- my first choice for a name; grumble -- that looks worth mining for ideas.) Beyond being able to have multiple, named lists, I want timing information so that one can ask questions like "how long ago did I last take my pain medication, and is it safe to take another dose?" That needs to work for both scheduled items, and "as-needed", floating items that can start their timer going at any time. More like a combination checklist and reminder system. I'd also like to be able to track the time it takes to go through a checklist, both so that I know when to start if I'm getting ready for something, and so that I know how much I'm improving with practice. Eventually it would be nice to link this to both a website and an Alexa skill -- the website will be easy, since almost the entire app will be usable as the front end.

It would be nice to have a combined lyrics viewer and a setlist planner. (I used to have a setlist planner, but it was in Perl and kept its state in the HTTP query string - bad news for caching and sort of search-engine pessimization.) There would be some overlap with the checklist app, since they both involve going through a list of things in sequence, with associated times. It would be especially useful on a tablet for performances, but it would be most effective combined with a website that hosts lyrics and music, which brings us to...

What a mangled web

Another thing I've been looking at is "Responsive Web Design" -- making websites that adjust smoothly between tiny mobile devices and large-screen desktops. This has long been a design requirement of mine anyway -- almost all my sites do this, but they do it by simply not having much of a layout, and they look bad both on very large screens and very small ones. It's time to take this to the next level by adding responsive CSS and mobile.

There are several websites that need work: lookingglassfolk.com, steve.savitzky.net, Stephen.Savitzky.net, and hyperspace-express.com at least. The first one is by far the simplest; just songs, concerts, (proposed) albums, and a gig schedule. steve.savitzky.net adds writing and software projects, but there's still a lot of overlap.

It would make sense to do the others using different responsive design frameworks, just to get experience with a few of the options. Stephen.Savitzky.net, in particular, is my "portfolio" site; it's also the only one that has a sidebar at the moment. It might be a good idea to turn into a GitHub Pages site. hyperspace-express.com is my "commercial" site, and it would make sense to use a CMS like Joomla or Drupal for it.

(I have some other sites, e.g. rainbows-end.net and thestarport.org, but they're simple enough to simply copy the CSS from one of the others. The Interesting.Places sub-site would be worth some attention.)

Now, here's my plan...

The underlying reason for picking this particular set of projects is to market myself as a blogger, consultant, and developer, in hopes of making a little money on the side. That suggests that I should start with the checklist app, and probably start the site makeovers by moving Stephen.Savitzky.net to a GitHub site (which would give me an obvious home for projects like MakeStuff and my development-focussed blogging). On the other hand, making over steve.savitzky.net would probably teach me more about responsive design, especially if I make S.S.net into a GitHub site. It might make more sense to keep S.S.net as a separate site, and build the GitHub site from scratch.

In any case, my main blogging site will remain here on Dreamwidth; most likely I'll just cross-post development-related blog entries to S.S.net (and GitHub, if it's separate). Or would it make more sense to keep all of the blogging concentrated here?

Comments? Ideas? Suggestions? Over to you folks.

comments

Done last month (20171126Su - 1202Sa)

Mon, 04 Dec 2017 01:00:23 GMT

Got a few things done; a little guitar (in 5-minute noodles, but still -- I need to get my fingers back in shape) and a little hacking (kludged together a script for posting to DW from Emacs, using a bash front end to charm, which seems to be the only available command-line client. I can do better, but this was good enough for last week's post, and this week's). I also figured out why ljupdate.el is still broken: it's using an HTTP GET macro that doesn't handle https. :P

I've brought up over half of our CDs, and gotten most of them onto shelves. The new organzation, subject to minor revisions, is:

Filk/folk/rock/pop/etc. alphabetical by performer. Last name for people.
Filk/folk/rock/pop/etc. collections, alphabetical by title.
Classical alphabetical by composer. Special exception for Gilbert & Sullivan, filed under G.
Classical collections, alphabetical by performer or title, whichever makes more sense.
Jazz, alphabetical by performer.
Show tunes and operas, alphabetical by title.
Natural sounds, relaxation, ambient, etc. alphabetical by title.
Christmas music, alphabetical by performer.

The household coined two new words: "rambronxious" (portmanteau, me) and "rambrooxious" (portmanteau, N). These join "rambunct" (back-formation) as a verb. We (finally) have our fridge's icemaker working. The thing was apparently wrecked by having been left to freeze, sometime before 2015 when the house was installed. (What's the right verb for a manufactured home? Not "built", certainly. "Manufactured", maybe.)

Not nearly as productive on the psych front -- the LCSW I contacted last week isn't taking new clients. And there are only a handful of therapists on the island who take Medicare. (No surprise, especially to those following siderea.) So I got stuck, as I usually do.

I did, however have an Insight(TM), which is that I'm still nowhere near recovered from two years of burnout at Amazon. (Below you will find a few links for burnout recovery. Helpful, but not excessively so.) I also started using my happy light. (Yeah; it's a SAD light -- "happy light" is the brand.) And Ticia has been exceptionally cuddly, which is nice.

And one more insight: I figured out why I don't like writing in Markdown or other text formats, and prefer LaTeX or HTML: they're basically physical markup, not semantic markup. In HTML I can, for example, distinguish between a citation and emphasis, even though they both get shown as italics. Given my current set of emacs bindings, HTML is easier for most things; songs and poems are easier in LaTeX with my FlkTeX macros.

( Notes & links, as usual )

comments

third time's the charm

Sun, 26 Nov 2017 20:07:36 GMT

test headers

comments

Done last week (20170618Su - 24Sa)

Mon, 26 Jun 2017 01:46:17 GMT

I spent pretty much the whole week, during "working hours" anyway, working on a project that's been on my queue for years: getting my lyrics to print two-sided and ensuring that if songs occupy two pages that they span an even-odd two page spread. It's working, as of this afternoon.

There are a couple of subtleties. Notably, if you're just printing a whole bound songbook, you don't care which side of the page a one-page song goes on. If you're printing individual songs to go into a looseleaf binder, on the other hand, you need a cover sheet on the first (right-hand) page to force both pages of a two-page song onto the correct page. And of course if you're printing lyrics to go on a song's web page, you don't want the cover page. But I have it working.

I also got Father's Day calls from both of my kids, got the keys to the new house (in a little party Monday afternoon), scheduled our move out of the apartment (for Wednesday July 12th, which will give us a little time to pack), got in contact with the various utility companies, and, ... I'm not sure there was much else. That's probably enough.

I still have the persistent feeling of not getting much done, and I'm constantly appalled at how much has to be done before we can move into the new place, and how little time we have. I'm still scared about how little money we have, and worried about the amount of stuff we still have to do to the new house to make it work for our family.

Not to mention whether we'll have anything at all left after Trump and his goons get through destroying our social safety net, not to mention the planet.

And speaking of global warming, it's in the 90s this week. For Seattle, that's scorching.

( Notes & links, as usual )

comments

Done last week (20170507Su - 13Sa)

Sun, 14 May 2017 21:35:19 GMT

It's been another rough week. This week it's been mostly health care -- I found out Tuesday that Amazon hadn't continued my health care as they said they were going to, so I was unable to order Colleen's humira. (Which, at $1800 for two doses, isn't something one wants to pay for out of pocket.) My HR contact is looking into it, but it took several days to get through; meanwhile I went online and signed up for Medicare Part D and identified a Medigap provider (ExpressScripts and Premera Blue Cross; both for continuity and because they seem to get top reviews. Who knows how long that will last under Trump(Doesn't)Care.)

I know there's something called compassion fatigue. Is despair fatigue a thing? Or is that just another phase of despair? I find myself incapable of being surprised at whatever outrageous thing Trump and the "Republicans" have done each day. (I put "Republicans" in quotes because they are rapidly turning this country into a right-wing dictatorship. I feel powerless to stop them.)

Onward. Had a really good trip with Colleen up to Whidbey Island; we went up the whole length of it and came back by way of Deception Pass. It's been a very long time since Colleen and I went out for a drive that long that was just a drive -- our occasional loop drives along the California coast were probably the last ones. It was a little too long, but it went ok.

I've been spending much of my spare time catching up on my reading. For some reason I'd stopped reading LWN (Linux Weekly News) sometime around the first of the year; in the last two weeks I've completely caught up. You can see the results in the links, most of which came from LWN, or indirectly by way of Sacha Chua's awesome Emacs News. I've also been finding Whidbey-related links. At some point I need to go back through my to.do archives, extract all the links, and aggregate them. They're kind of useless scattered across blog entries the way they are.

I've even done a little walking (not quite every day, and not much because I seem to be walking at about half my old 3mph pace), a little music, and a little hacking (almost entirely cleanup tasks). On the whole, I appear to have been keeping myself busy in a relaxed kind of way, though I haven't yet fallen into any kind of routine. Later, hopefully.

But.

My last few trips down to the house we used to call Rainbow's End (should we call it "Rainbow's Ended" now?) have been increasingly sad and discouraging. We put a lot of ourselves into that house; it was a large part of what we were as a family. Now we're scattered. We'll come back together, mostly, on Whidbey Island in a little over two months; it may very well be wonderful -- I hope it will -- but it won't be the same. I can't keep from thinking of what I might have done differently, over the last few decades(!), that might have made it possible to stay there. Hell, we all made decisions that seemed like the right thing at the time. Can't be fixed.

"I can't fix it!" is probably what I say most often when things are going badly. It always feels like my fault. I don't think I can fix that, either. I should shut up and go for a walk with Colleen.

( Notes & links, as usual )

comments

Done this week (20161121Mo - 26Sa)

Sun, 27 Nov 2016 17:57:17 GMT

So I took the week off from work. I'd originally planned to return from Orycon Sunday afternoon, and go in to work Monday and possibly Wednesday. The best-laid plans... Monday was occupied by the drive back from Portland, Tuesday by medical stuff (including a urology appointment on short notice for Colleen), and Wednesday by waiting for the tech from Acorn to show up and do the proper inspection that the tech who had arrived early on Monday had failed to do. So.

Spent much of the week on personal software projects. Wednesday and Thursday I was mostly hacking in my .emacs file, fixing some long-standing annoyances with html-helper-mode (and incidentally lj-update-mode, which is partially derived from it). Friday and Saturday I worked on the build software for my website Songs pages -- you can see the results (so far -- there's still quite a bit of prettying-up to do) on LookingGlass Folk's Songs. The LgF page was the main motivation -- it's been a broken link on the site for years. The secondary motivation was putting my songbook on GitHub.

In the course of doing this, I finally got around to writing tests for the makefiles -- predictably, they turned up lots of bugs. By no means complete, but I now also have an easily-extensible test framework that I can use for the rest of MakeStuff and my other make-based projects like Honu.

Thursday we had a Thanksgiving dinner that couldn't be beat. Glenn spatchcocked the bird -- this was my introduction to the technique, which lets a 16-pound turkey cook in two hours with a beautifully crisp skin. Recommended. There were just Colleen and I, Glenn and Naomi, and N's kids. The YD had dinner with her boyfriend's family, and Chaos spent the day working on term papers. The tenants ate at C"'s parents'. (I may have to go to subscripts.)

Fair amount of political stuff in the links; not going to re-hash most of it because apparently Post-Trump Stress Disorder is a thing, and I haz it. I can, however, recommend moem's Cybersecurity for the Trumped series, and Tor Browser.

( Notes & links, as usual )

comments

Done last week (20160904Su - 10Sa)

Sun, 11 Sep 2016 18:24:19 GMT

This post covers most of my week-long vacation, so while it's not quite time for a wrap-up of my goals, I can say that I met about half of them. Which was about what I expected.

The big accomplishment for the week, without a doubt, was posting my one-line Linux setup/configuration package up on GitHub. (I then spent much of the rest of the week debugging and tweaking, but that's also to be expected.) It's called Honu, after the Hawaiian name for the green sea turtle, because a turtle carries its home around with it. The README starts off with this quote from my song, Windward, because I just couldn't resist:

Where the wind takes us next year no turtle can tell
But we'll still be at home, come high water or hell,
Because home is wherever you carry your shell.

The implied puns on $HOME and sh(1) are, of course, entirely intentional.

Honu is meant to be fairly general; it's expected that any user -- including me! -- is going to want to customize the heck out of it. To that end, there's a sample customization package, also on GitHub, called Myrtle. Of course. (My own customization package, which you will not find on GitHub, is called Mathilda, after LookingGlass Folk's name for the narrator of "Windward".)

It hasn't been all roses and rainbows, however. I've spent an inordinate amount of time coping with the bindweed (morning glory's evil twin) that has overgrown the walkway along the south side of the house, sorting a year or two's worth of mail, and recovering from last week's disk crash on the server. I've been doing quite a lot of writing, though a lot of that has been on Quora, so I'm not sure whether that counts toward my daily writing goal, or away from it.

I'll say one thing for Quora, though -- it makes me appreciate my own knowledge and social skills. Being able to answer questions is a real boost to my self-confidence in both those areas. Who knew?

Psychologically, well, ... mixed. I've definitely been less stressed out the last two days of the week than the first two -- I was able to handle a trip downtown that turned out to be a total write-off, due to things being closed/not where I expected, quite calmly and even with a little wry humor. The check from last week's stock sale arrived on Tuesday, which helped. On the other hand, it still apparently doesn't take much frustration to put me back over the edge.

I was a total wreck on Sunday. I seem to handle stress a lot better when I'm by myself. With Colleen around, especially, I get into a horrible feedback loop. By the time I got home I could probably have used an Ativan, but my prescription on those has long since expired. I settled for reading and gin. Low blood sugar may have contributed; I'm not sure I can tell the difference between anxiety and hunger. Alexithymia in action.

I am not ready to go back to work tomorrow. I may never be ready. I'll do it, but it won't be pretty. ( Notes & links, as usual )

comments

Done last week/month (20160828Su - 0903Sa)

Sun, 04 Sep 2016 15:47:21 GMT

If yesterday is going to be typical of this vacation (I'm taking all of the coming week off), I'm going to need a month or two of work to recover from it. Not fun.

Friday Nova, my main server, developed a corrupted root partition. I've been keeping an eye on that drive for a while, and had a replacement on hand, so I set up a transfer of the home and data partitions and went to bed. So far, so good.

Yesterday was another matter entirely. Installing a new copy of Debian should only have taken an hour or so. Hah! Instead, I was plagued by a long series of problems, which took me pretty much the entire day to finally analyze. These included:

A corrupted download of the Debian installer. It appeared to work ok, but the keys on the right-hand side of the keyboard kept generating the wrong characters! WTF?
Apparently the idiot Intel motherboard I used for my server won't let you change the boot order of your hard disks (despite having a BIOS option that claims to do exactly that), and it considers a USB key to be a hard disk. So if you have a hard drive that doesn't already have a bootable OS on it, it will keep the damned thing from booting.
Snowflake, the box I've been using for a desktop apparently has a similar problem.

I eventually ended up using the only other working spare system, Trantor, to install Ubuntu. I then swapped the disk into the former Snowflake, which is significantly faster and quieter than either Trantor or the Atom board I'd been using for Nova, so that's a win. I also decided, since I now had Ubuntu on Nova, and it was the fastest machine I had, that I would use it as my desktop as well as my fileserver. There are some potential problems with that, but I have to admit that it's convenient.

It will probably take me a while to get everything on (Novo) Nova configured -- I still need to start doing backups, for example, and don't have a web server up yet -- but at least I have DNS and my main file store up and running. But there was a lot of frustration involved.

The frustration made me more susceptible to other sources of stress, so sure enough, that happened too. Kat and Rabbit are in the process of moving out into their own apartment (finally!), so they brought movers in to handle the bed, the futon, and some other large furniture. Which meant taking the seats off the stairlifts.

And, of course, Colleen woke up and walked down the first flight of stairs before calling for help. I hastily put the seat back on the lower lift, and told Colleen (not exactly calmly -- I was pretty stressed at that point) that she should have gone back to the room, sat down, and called for help.

Then the lower lift wouldn't go back up to its charging position. It was already pretty badly damaged from previous moving attempts; it turned out that the limit switch that detects whether the seat is turned properly had finally broken to the point of unusability. Its little cam follower had been crumpled up from previous clumsy seat replacements. There ensued a frantic search for my multimeter (and a hasty battery replacement) so that I could identify the normally-closed contacts on the switch and move the connectors to them.

At that point I went back to my struggles with the computers. Just as I was getting things pretty stable there, Colleen went up to bed. Or tried to: the bottom lift didn't want to go up. Again. More swearing. More switches to reconnect. A quick trip to Google to look up error code E6, which turned out to be the bottom limit switch. Which hadn't given us any trouble up to that point.

... by that time I was a complete wreck. My stress level was not helped by being worried sick -- literally, by that point -- about the fact that the check from my stock sale still hasn't showed up. And berating myself about not being persistent enough to figure out from Morgan Stanley's miserable website how to do a direct transfer.

The one good thing about all this is that I tend to wake up around 4:30 when I'm stressed. When I feel as though I don't have enough time to get everything done, it helps.

It's been a long month. September is fired. ( Notes & links, as usual )

comments

Done last week (20160821Su - 27Sa)

Sun, 28 Aug 2016 17:30:56 GMT

Moderately productive. Two "publishing events".

Sex and the Single Link is up on my "formal" website, Stephen.Savitzky.net. This is, despite the clickbait title, an article about the joy of singly-linked lists.
MakeStuff is up on GitHub. This the first of several projects I intend to put up there; it's the collection of makefiles and scripts that powers all my websites. You can see it in action here.

Apart from that, and a bunch of Quora answers, not a whole lot going on. One my Quora answers led to a good discussion on the comment thread. Fairly prodctive at work, though as usual not quite as much as I wanted to be.

One particularly interesting article for the programmers in the audience, Developer Differences: Makers vs Menders, which seems to describe me fairly well.

Also of note, the first episode of the Lesbian Historic Motif Project Podcast: Ordinary Women by Heather Rose Jones (hrj on LJ) is up.

( Notes & links, as usual )

comments