Sometimes I try to figure out what to do in a given week, and my first step is to think "what are my long term goals?". Then I realize I have no long-term goals. I sit down and think, "Hmm, what do I want to do with my life?" Eventually I give up, depressed, and go make breakfast or something.
Recently I tried going the other way, with much more success. I call this exercise telescoping. It takes 7 minutes, and is performed as follows:
Open a text document or grab a piece of paper. Grab a kitchen timer with an alarm, or your phone's alarm app.
For one minute, answer: What do I want to happen today?
For one minute, answer: What do I want to happen this week?
For one minute, answer: What do I want to happen this month?
For one minute, answer: What do I want to happen this year?
For one minute, answer: What do I want to happen this month?
For one minute, answer: What do I want to happen this week?
For one minute, answer: What do I want to happen today?
I found this a bit enlightening. Here's an early example (I type fast):
Today
Enjoy myself, do some intention journaling.
Make at least a little progress on the zorchpad
Socialize with someone enjoyably
Become a little more long-term coherent
This Week
Work on the puzzle contest with XXX
Hang out with YYY
Get enough sleep!
Maybe get exercise
This Month
Make a prototype zorchpad and start carrying it around
Release qr-backup with no scary warnings
Continue to learn about electronics a bit, possibly
Have some kind of new social thing in my life
This Year
Get an income source where I don't have to do anything, and relax
Have a satisfying version of zorchpad
Learn electronics
Continue to learn programming languages
Spend a bunch of time chilling with friends
Get a boyfriend
This Month
Make a prototype zorchpad and start carrying it around
Keep my focus on zorchpad and intention journalling through the puzzle contest
Make 1 new friend -- might be hard, so at least attend social events in a more friend-condusive way
This Week
Breadboard a zorchpad
Hang out with XXX
Work on the puzzle contest with YYY. Wait, would she actually enjoy it? A: Yes!
Help someone with their quest!
Today
Work on breadboarding a zorchpad
Order zorchpad parts -- at least buffers/shift registers!
Write up telescoping in a blog post
Possibly, think about long-term planning a little maybe perhaps
Think about how to get sleep consistently, maybe?
I realized went from "Make progress on the zorchpad" to having a specific list of parts to order, and noticing I needed sleep. It helped me prioritize what I wanted to do.
I think it's more helpful to think about outcomes (What do I want to happen) rather than tasks (What do I need to do?), although I usually try to do both.
I did this two or three times, and kept finding it helpful. I decided to find out what happened if I did it every day.
Two weeks of doing it daily, I will report: it was neither super helpful nor a waste of time?
Basically, it was pretty helpful to think through things I hadn't. The main benefit of doing this every day was keeping long-term goals in sight, but I was no longer thinking through new things much.
The most surprising thing for me was that one minute quickly became too long. I reduced it to 30 seconds per step.
On the one hand, it's not that helpful. On the other hand, it takes 3.5 minutes, and it's a nice way to orient to the day. So, might or might not keep doing it.
The most useful part is that I can see my long term goals. Each day, they can shift. Do I want to keep working toward this thing? Have I had a long term goal that I haven't been working toward? Writing it anew each day is a much different feeling than glancing at a to-do list and either crossing it out or ignoring it (and feels much healthier).
Overall I'd recommend trying it at least once. I don't think it's for everyone, but I suspect it will help people like me that don't have clear goals.
As previously mentioned, I have switched off wordpress. Hopefully, you can't tell. It's meant to be behind-the-scenes.
The only change should be the new comment system. Feel free to try it out by commenting below. You could be the very first commenter!
The rest of this post is for anyone curious why and how, which I skipped last time.
If all is well, my blog looks exactly the same. All links should continue to work. The RSS feed should keep working. Basically it should be a behind-the-scenes change.
I want to edit markdown locally, not use the Wordpress editor, which is getting increasingly bloated.
My server (a VPS) has previously been hacked due to an insecure wordpress installation. Hopefully it can't happen again due to some security changes I made, but that's always a danger. Static sites have almost no security problems.
Static site generators are just nice.
After some discussion with folks on IRC, I realized I could do the migration easier than I thought. (I didn't do it the easy way, but I could have.)
Why not make the change?
It's a lot of work. Not doing things is easier than doing them. Specifically, I have about 200 posts here, so migrating would be a lot of work. Starting a new blog is a valid avenue I didn't take either.
Really, seriously, it's a lot of work.
Comments are hard to deal with on a static site generator. You can not have them (but I like comments), you can have someone else like disqus host them (which is icky), or you can host them yourself (which leaves security problems). In addition, most static-site comment systems require javascript, which is sort of a shame.
It's pretty hard to check whether you've done it right. Reviewing 200 posts is no joke. If you want a computer to check, you'd need the before and after to match exactly, which may not be quite the right goal -- an exact match is only a reasonable goal is it was perfect before.
Nonetheless, I forged on and decided to change. It was probably not worth the work, but since I put in the work, I'll at least share what I did.
Let's talk about how, rather than why, for the rest of the post. This took the better part of a month.
I thought about what I wanted to use. There were a few good options -- Jekyll and Hugo both came recommended, and I've used Jekyll before. They both use a format called frontmatter. Below is an example of a frontmatter document. The top is YAML and the bottom is HTML.
---
type: blog post
title: The worst types of pizza
---
<ol>
<li> Ham and Pineapple
<li> Anchovy
<li> Reheated in the microwave
</ol>
Basically, frontmatter consists of a "front" metadata section, in YAML or TOML or JSON, all of which are different ways of representing metadata. Metadata for a blog post includes things like the title of the blog post, when it was published and updated, and the author. And then below that, is a main content section in HTML or markdown. For a blog post, the main section is the text of the blog post.
I wasn't sure what engine I wanted to use, but I decided to use frontmatter. The content would just be the HTML, verbatim and unchanged from my existing blog. That way, everything would display right. I could write new posts in a new format. Old posts would be ugly behind the scenes, but it work, and I wouldn't have to migrate 200 posts.
I also really, really, didn't want to break the blog. I hate people who break a website changing things halfway. My work would only see the light of day once it was ready to wholly replace my existing blog. All the old links would work perfectly, even if I had to hand-code 200 redirects.
First, I wanted to have my existing posts in some format. Wordpress stores everything in a database. There are a couple options to get them out:
- We could do a database dump. (This is very ugly. Don't do it.)
- You can export them as an XML file. This is probably the best option.
- You can download your website as HTML by crawling it. This is what I did, because I wanted to be sure I could have a blog that looked the same as my current one, and it seemed pretty foolproof.
So I had a big directory full of HTML blog posts, images, comments, etc. Next, I wrote an extractor. It looked at each file corresponding to a post, and grabbed the <article> element with the content of the post, together with any comments. It also extracted some relevant info like the author, publication date, title, and so on. It put them all together into a file. Now I had something that Jekyll and Hugo could use.
I took a look at Hugo. Wow, was it big. It supported YAML, TOML, JSON, HTML, Markdown. It had an asset pipeline. It had three different module systems to extend it. It did overlay filesystem mounts. Templating in Golang's templates. I slowly backed away.
I took a look at Jekyll--small, very opinioned. I generally like that in software. But, absolutely no customization. You had to put everything in a folder called _posts, and the publication date had to be the first part of the name. YAML only for the top. Etc. It seemd good, but I wasn't quite feeling it.
I decided I would roll my own. This was a small project. I only wanted a very limited set of functionality.
I wrote a template. It was an HTML page with a hole in it. You put the blog article HTML in the hole, and you got a finished HTML document. Looked fine. I used mustache from the templating, because I remembered liking it in the past. I got a blog showing. It looked great. It loaded lots of files (like icons images and styling) from the live site, rather than having a local copy. Most of the links went to the live site too.
I converted all the links. I wrote a checker to search for dead links. I decided to generate a page for each tag, since those would change over time. I noticed the tag pages and the post pages had most of the layout in common, so I factored that out. I discovered my python mustache library didn't do "factoring out", and only the javascript library did. I realized I had never liked mustache--I had been thinking of handlebars or spacebars. I decided to put it off--switching templating engines was easy, but it's better not to switch horses mid-stream. I factored out the tag cloud. I got the number of dead links down to just the page of links by one author and the RSS feed. I generated those too. I started generating more of the blog post--the title and author and comments section, too. The HTML shrunk. I had a working version.
I started feeling super disheartened. This was a giant mess. I just wasn't feeling motivated. I took a step back. Was it the work? No, I decided. It was that I didn't want to put in a ton of work, to get a system I wasn't all that happy with. Wordpress was already okay. It wasn't perfect, but it was alright. If I was going to put in work, I wanted the new system to be better. I wanted... I think I wanted to convert the old HTML posts to markdown?
Hoo boy. That was going to be a lot of work.
I took a look around. A year ago (the last time I saw a gorgeous Amal Murali blog post), I had tried a wordpress conversion. I had tried wordpress-export-to-markdown, but I had remembered not liking the output that much. Things had been missing. They hadn't looked right. But it done 80% of things correctly. I checked what it used. Hmm, turndown. A javascript tool to convert HTML to markdown. Sounded promising.
I converted everything to markdown. I took at look at the output. Seemed... reasonable. I'd have to take a look before I decided anything past that. So I needed a tool to convert markdown back to HTML. I was using Python, so I picked markdown2 -- the markdown (1?) page seemed pretty.. theoretical. User comfort seemed like maybe a fourth priority. It hadn't been updated in a few years. markdown2 seemed to care about speed and user comfort. It had lots of plugins. It had been updated last week, though it looked like they hadn't done anything major in a couple years. I gave it a try.
I took HTML, converted it to markdown, converted it back to HTML, and looked at the result. It was... eh. It had some of the same content, but it didn't look quite right. I looked at the HTML. Oh, I had forgotten to wrap it in an <article> tag with all those special wordpress classes. I gave it another try. WOW! That looked almost identical. I made a webpage to look at them side-by-side.
before and after view
Okay, I could do this. There was going to be a list of problems, but I could get through them one by one.
I started looking at articles. Okay, this was missing a class. Galleries were just a series of images now. iframes were being dropped. This was all stuff I could fix. Some of it would be problems converting HTML to markdown. Cases of stripping vital information was especially problematic, because I couldn't fix it later.
Some problems happened when converting markdown to HTML--code blocks inside lists disappeared and became regular text. I started looking into fixes. I was annoyed how hard it was to extend Turndown. I considered writing my own HTML to markdown converter. That was the easy direction--anyone can parse HTML, there are libraries for it. Outputting is easy in any language. Wait, I thought. Turndown would disappear in the final version. Once I had converted the old HTML, that was it. How many problems were there, really? If it was just a few articles, I should fix it by hand instead. That would be easier. I decided I'd wait until I had a better overview.
Other problems happened when converting markdown back to HTML. Parsing markdown would be a nightmare, so I crossed my fingers and prayed I wouldn't have to. I hoped markdown2 was easy to extend. I started thinking with distaste about if I would have to... rewrite the HTML output shudder. I put things off--disappearing information was more important.
I decided to take stock. How would I tell if I was making progress? What if fixing one thing broke another? I had some kind of visual diff tool in mind. If the HTML and markdown versions looked the same, that was good enough for me. But would they? I don't care about little changes. One font slightly different, a section a few pixels to the left. I was worried I would compare the before and after, and none of them would match. I don't know how to tell a computer to ignore that stuff. Oh well, I'd check. Maybe it would work.
I ran a first check using puppeteer to take Chrome screenshots. 24% of posts were identical, right out the gate. That was more than 0%. That meant that yes, this method would actually let me make a TODO list. 0% would have been bad. OK. I started opening up articles. Yes, they actually looked different. It wasn't a few pixels. Every page I opened, seemed to have genuine differences I wanted to fix.
I started fixing the problems. Some big problems got fixed. Smaller ones started cropping up. The first one I found was these. They were comparing different. Was that right?
see the difference? me neither
I stared. I saw nothing. I visually showed the difference. The fonts were highlighted in red. Was it a font issue? I looked at the HTML. Oh, one gray was 10% lighter. Should I fix it? No wait, I didn't want things to be pixel-perfect identical. That was just a tool to measure how close I was to done, let's not lose track of the actual goal. Hmm.
I was starting to feel burnt-out. I wasn't sure where to go next. I talked to friends. I ended up using a heuristic to rank the pages from most to least similar. I'd tackle the big problems. As it happened, some contractors were jackhammering my basement for a few hours, so I had time to kill where I couldn't focus anyway. I opened all ~100 blog posts in chromium, and make little notes about each problem before I closed the tab. If I would be fine not fixing a problem, I didn't write it down. If I saw the same problem twice, I'd add a little + mark next to it. At the end, I had some problems with a lot of + marks next to them. Those were the ones I'd tackle first. Maybe more importantly, I had a good idea of the total amount of work. It was maybe 10 or 20 things to fix, even if I was very fussy. I was okay with that. I could do it.
I went in and started fixing. I found out that Turndown was pretty unmaintained, just like I suspected. I made about 5 PRs--none had any response, so I used a local fork. pyhon-markdown2 usually worked. Every time I thought I found a bug, it was my fault--I hadn't understood something about the nuances of markdown. In one case a bug was real but already fixed in a newer version.
After fixing a dozen problems, I was done. I took a look through the articles again. Most of them looked fine now. I generated the markdown one more time, and then hand-fixed 5-10 articles with problems. I filed fixed articles into a "finished" folder, so they wouldn't be overwritten if I changed my mind and did an automated rebuild.
It was done. I looked, and looked again. Then I deleted all the HTML sources. The side-by-side view. The visual comparison tools. The side-by-side view. The dead link checker. The crawler that extracted the original HTML. I was left with a single tool--it took markdown, and generated a blog. It was tiny again. I rejoiced, and took a well-needed break.
At this point, I had a working blog. Posts were YAML frontmatter, and markdown content. I could write new posts easily in markdown, and all my old posts were in markdown too. I was pretty happy.
I had two more big tasks. One, which I'm punting indefinitely, is to re-style the blog. My current approach is to just have a copy of the old wordpress CSS in one file. It's 7,838 lines long, which is too long. I could reduce it, but it's probably equally reasonable to just make an entirely new stylesheet from scratch. I'm not sure whether old articles will keep the old stylesheet. Probably yes, just to avoid breaking anything. That is... not urgent. I'll do it sometime.
The other part, which I did care about, was to get comments working again. I looked around at a few static site commenting options, and settled on Isso. The user-friendly front page encouraged me. It didn't require registration, it had email moderation where you click a link to approve a comment, comments could use markdown, there was no database setup. And it supported wordpress comment import (although I didn't do this actually).
Great! Now how to install? Oh... the debian package is discontinued? Okay, it was actually a bit of work.
I didn't bother with RSS -- no one reads an RSS feed of comments, and they get included in the RSS feed of posts.
I ran isso by hand:
sudo -u isso /bin/isso &
tail -f /var/log/isso
Added an nginx frontend proxy:
# Run as isso.service
upstream isso {
server 127.0.0.1:9007;
}
server {
listen [::]:443 ssl;
server_name blog.za3k.com;
[... rest of blog.za3k.com ... ]
# comments
location = /comments {
return 302 /comments/;
}
location = /comments/ {
proxy_pass http://isso/;
}
location /comments/ {
proxy_pass http://isso/;
}
}
Added some code to the static generation:
<script src="https://blog.za3k.com/comments/js/embed.min.js"></script>
<section id="isso-thread">
<noscript>Javascript needs to be activated to view comments.</noscript>
</section>
And debugged a few errors here and there. Then I added a systemd unit, which I enabled and started:
I recently tried to buy a 3-ring binder, and I was annoyed didn't list spacings on paper OR binders. This is my attempt to write a reference for future searchers.
The spacing between rings seems to be standard. The ring size itself isn't standard. Holes vary from 6-8mm. I live in the United States -- different binders may be standard where you live.
Here are the spacings I found. If you encounter a 3-ring binder not listed, or pre-punched paper that doesn't match the below, please email me with the measurements and brand name.
Paper sizes:
US Letter: 215.9x279.4 mm / 8.5x11 inch
A4: 210 x 297 mm / 8-1/4 x 11-3/4 in
A5: 148 x 210 mm / 5-7/8 x 8-1/4 in
A6: 105 x 148 mm / 4-1/8 x 5-7/8 in
Filofax (brand name): 95x170 mm / 3.75x6.7 inch
SMD "sampler" parts sheets (unclear if standardized): 117x175 mm; A6 6-ring spacing
US Letter, 3-ring
These are the "standard" 3-ring binders in the USA.
Join me, and learn about how to debug cron jobs, as well as a little about env and strace.
I have a cronjob on my desktop which plays audible reminders for me of various events. For example, my wakeup alarm is:
#minute hour day of month month day of week user command
0 10 * * * zachary chronic notify --here "alarm time. wake up"
Every morning, notify speaks aloud "Alarm time. Wake up.". It speaks on my laptop... and then my laptop again... and finally my desktop. It's not supposed to do the laptop step twice. It should speak two times, not three. It's just one of those small things that niggle at you over time.
In fact, I run on my desktop manually:
chronic notify --here "Alarm time. Wake up"
And... it plays on my laptop... then my desktop. Two times. That's what it's supposed to do. Um, what gives?
I do my usual trick to re-create the (kind of weird) cron environment:
#minute hour day of month month day of week user command
* * * * * zachary env > /tmp/cronenv
0 10 * * * zachary chronic notify --here "alarm time. wake up"
I wait a minute, and read /tmp/cronenv. Yep, looks good.
I turn that back off, and run again, using the cron environment.
env -i $(cat /tmp/cronenv) chronic notify --here "Remember to do review" # 3 times
Okay, that speaks three times. Problem reproduced.
Incidentally, I found something interesting reading the man page to env. As you may or may not be aware, shebang lines at the top of a program execute the script listed there:
#!/bin/python
import os
...
when run as an executable, is the same as calling
/bin/python <path/to/script.py>
And
#!/bin/python -i
(which runs the script, then lets you interactively look at variables) is the same as
/bin/python -i <path/to/script.py>
Incidentally, the /bin/ is optional -- you can just use python. But it's better for security to use full paths.
So far, so good. But what about
#!/bin/python -i -q
Nope. It prints the confusing:
Unknown option: -
usage: python [option] ... [-c cmd | -m mod | file | -] [arg] ...
Try `python -h' for more information.
Why? That's actually the output of python "-i -q" <path/to/script.py>. Why does python print this message? It's trying to parse short-form options (-abcd as -a -b -c -d) and it sees the second short-form option is a space. It's... not the best error message, certainly (#132414).
Going back to our original digression, the point is that shebang lines can contain zero one or arguments to their command-line program, but not more.
env -S is a neat little option that fixes this:
#!/bin/env -S /bin/python -i -q
Huh, you learn something new every day. Anyway, back to that alarm clock. What's going on? Well, let's bisect.
env >normalenv
Give us a long, long list of environment variables. I delete two that I can't figure out how to get to work correctly because of spaces:
env -i $(cat normalenv) chronic notify --here "Remember to do review" # 2 times
env -i $(cat cronenv) chronic notify --here "Remember to do review" # 3 times
OK! That works. So I have a working case, and a non-working case, and the only different are the two env files. This should be straightforward, if tedious, from here on out.
I delete a few lines... still works. Those lines didn't matter. Delete a few more... works, those lines weren't important. Delete a few more... it breaks now. Guess one of those was important. I'll return to that section later, restore it for now. Delete a few more... those didn't matter.
At the end of the day, only one line mattered. I can reproduce with a one-line environment file.
Yeah, yeah. I have a gross PATH. There are bigger things in life.
OK, so... hmm. What's going on. Am I calling an external program inside of notify? Let's strace it.
strace is a tool which shows all system calls a program makes. I could read my code carefully... or I could just print what it does. I trust the latter more (and if you didn't write the program, it's handy).
juice:~ $ env -i $(cat normalenv) strace --silence=attach,exit -f -e trace=execve notify --here "Remember to do review" 2>&1 | grep -v SIGCHLD | tee correct.log
execve("/usr/bin/notify", ["notify", "--here", "Remember to do review"], 0x7fff82957da0 /* 1 var */) = 0
[pid 512920] execve("/usr/bin/which", ["which", "sendmail"], 0x616259d51d30 /* 4 vars */) = 0
[pid 512921] execve("/usr/bin/id", ["id", "-u"], 0x616259d53920 /* 4 vars */) = 0
[... many more lines ... ]
[pid 512949] execve("/home/zachary/.opam/default/bin/speak", ["speak", "Remember to do review"], 0x59833be8ac40 /* 6 vars */) = -1 ENOENT (No such file or directory)
[pid 512949] execve("/usr/local/sbin/speak", ["speak", "Remember to do review"], 0x59833be8ac40 /* 6 vars */) = -1 ENOENT (No such file or directory)
[pid 512949] execve("/usr/local/bin/speak", ["speak", "Remember to do review"], 0x59833be8ac40 /* 6 vars */) = -1 ENOENT (No such file or directory)
[pid 512949] execve("/usr/bin/speak", ["speak", "Remember to do review"], 0x59833be8ac40 /* 6 vars */) = 0
juice:~ $ env -i $(cat cronenv) strace --silence=attach,exit -f -e trace=execve notify --here "Remember to do review" 2>&1 | grep -v SIGCHLD >incorrect.log
OK, so we have the correct and incorrect calls. We diff them, and the difference is... everything. Whoops, because we have all kinds of raw pointers and process numbers. Hmm, how do other people do this?
Googling it... it's not a super solved problem. I'll just replace all the numbers by question marks.
for f in correct.log incorrect.log; do
sed -r -E 's/^(.+)pid [0-9]+(.+)$/\1pid-xxxx\2/;s/0x[0-9a-f]{12}/0x????????????/;s/[0-9]+ vars?/? vars/;' -i $f
done
diff correct.log incorrect.log
And we see something I should have already spotted:
> /usr/bin/notify: line 75: beepz: command not found
If I had just run the program outside of chronic, I would have seen this output already. Oops. Hindsight is 20-20.
Aha. So beepz is not in the cron path.
juice:~ $ env -i $(cat cronenv) beepz
env: ‘beepz’: No such file or directory
We'll add it to the path. Done. Uh oh, beepz still doesn't work. What else do we need? I pull the environment bisecting trick again, and add to cron:
And a quick test confirms I get one wakeup alarm per computer now, just as I like it.
As a last step, why did it break? Well, I know the answer to that one. I used to install all the programs from ~/.projects/short-programs to /bin. But when I was working on developing the programs, the two would get out of sync, so I deleted the system versions. Guess it broke something. Oops.
I am offering two bounties to improve qr-backup. I think both are worth doing regardless.
My rewards are time-in-trade. You can use 5 or 10 hours of my time however you like. I usually charge over $100/hr, so this is a good deal.
If the github bugs are open, the bounties are unclaimed. I will try to update this post when they are claimed, too.
Bounty 1: Improve QR code scanning on Linux
Chances are, there is exactly one command-line program your distro has available to scan QR codes: zbar
Even on digitally-generated images, which are perfectly correct, pixel-aligned, and generally perfect, it still fails to read the codes sometimes. At least one-third of the bugs in the issue tracker are about this problem.
The bounty is to fix this issue in zbar, getting it to read QR codes with a 0% failure rate. The current failure rate is at least 0.1%.
Bounty 2: Code a one-page short C program to restore qr-backup backups
qr-backup is designed to save to paper, and restore from the command-line.
but, it's possible that someday we might lose all the nice infrastructure we have today.
you want to restore your backup, but you're poor and don't have an internet connection
no one runs "unix" any more. we just have neural meshes
it's been 50 years and you can't figure out how to install all these programs no one has heard of like "zbar" and "qr-backup"
your country has become a totalitarian state, and you can't be seen downloading "archiving" programs.
you are a lizard-person who has recovered piles of paper from a previous civilization. what secrets could they hold?
who knows! wouldn't it be great if you could still restore?
this feature request is to add a printable, 1-page short C program which you can type in by hand, compile, and use to restore backups from an image.
This is a very difficult technical challenge in minimization. You should provide a 1-page (2KB) short version of qr-backup's restore process, written in C. Library use is not allowed. Arguments will be accepted for other short programs if 2KB is impossible.
qr-backup actually prints a bash one-liner to do the restore, if you prefer to reference that.
Each of the steps is done by qr-backup in the most standard way possible. Decompression calls zcat, for example. You should be able to re-use existing code easily, the challenge is just to shrink it.
The reward is 5 hours of my time and everlasting fame.
The Zorchpad is a low-power computer I'm working on. Standard keyboards unforunately need too much power, so I'm making my own.
The keyboard layout I'm using has ~60 keys in a 12x5 grid.
12x5 ortholinear layout
The standard way to wire a keyboard is to use a set of wires -- one for each row, one for each column. That's 12 + 5 wires = 17 wires. By driving one of 12 outputs low for a column, and checking each of 5 inputs, we can see which (if any) of the 5 keys in the column are being pressed. We then rapidly switch which of the 12 outputs is low, much faster than human speed, to see which of the 60 keys is pressed.
We'd like to support n-key-rollover, a term which means we can detect any number of keys being pressed at the same time. We don't really need lots of letter keys pressed at once, but this lets us not treat keys like Shift or Control specially. It doesn't cost much, and makes the hardware and software simpler.
Wiring things up the simplest way results in ghosting, a problem where if you press several keys at once, others can erroneously appear pressed as well. Installing a diode on each key solves the issue. Easy-peasy.
But we have a problem. My microcontroller doesn't have 17 free pins. So my plan is to instead use shift registers.
A serial-in, parallel-out shift register lets you send 8 bits, one at a time, and then a special pulse (the "latch"). This sets 8 different output channels.
A parallel-in, serial-out An input shift register lets you do the reverse--you set a "clock" pin to read from 8 input channels to an internal buffer, then read one of the stored bits at a time.
Using 1 SIPO and 1 PISO gives us 8 pins out and 8 pins in. It takes 3 pins per shift register. Some can be shared, so the total might be less than 6, but we have 6 free pins.
We need 12 outputs, not 8. How do we deal with that? One valid approach is to use 2 SIPO (or 2 PISO) shift registers. But I noticed that we only have 60 keys on the keyboard -- in theory 8 inputs x 8 outputs should be plenty. And in fact, we can rearrange things.
What if we take a 8x8 layout, which we know we can wire, and slice it up?
(Thanks for splud of #electronics for this specific arrangement.)
Looks great. All I need to do is hand-wire that layout onto a keyboard.
a keypad someone else hand-wired
Okay... that looks hard. I really don't want to do the whole thing and realize I wired it wrong. Let's actually write out an entire schematic to make sure I do the right thing. We have a lot of complicated wiring and diode directions and so on.
logical 8x8 layoutphysical 12x5 layout
All right, I'm ready to assemble and solder. Wish me luck!
I like to keep my home directory pretty small ideally. Just what I'm currently working on, plus maybe one or two permanent directories like docs or the like.
But, it accumulates! Just like a real desk, it gets covered in junk and needs cleaned off.
hitlist (source] is a small program I wrote today to make the process of cleaning it up more fun.
cleaning up my home directory
It functions similarly to the classic unix command watch. The idea is that you have a list of problems, and cross them off one by one.
Cleaning up your home directory by running hitlist -- ls ~
Complete your daily todo list with hitlist -- grep '[ ]' ~/documents/TODO.txt
Fix a list of compilation errors with... okay, I haven't figured this one out yet. But it seems doable!
Unlike a real list, it "crosses off" problems for you, once they disappear from the command output, and lists how long you took to solve each one.
You could use this as a race. Or you could do some analysis after one run, and decide "actually, this took too long to fix--next time I'll give up on a bug if it takes more than 5 minutes to solve."
On-screen output is optionally saved to a file on exit.
Every year, there is a puzzle contest on April 1. You can play over on IRC on #ircpuzzles. Instructions here. The contest is already well underway, sorry for the late notice!
