5 Dec 2019

Today I found the solution to an incredibly first-world problem that’s been plaguing me for the majority of the months I’ve been using Arch (I use Arch, btw) full-time: Logging into a session when my laptop is connected to an external display and in *gasp!* clamshell mode. Signal boosting a post that solved this problem that I’ve been procrastinating on lo these many weeks for me probably shouldn’t warrant a whole blog post but I wanted to praise the author for walking the reader through a step that we all probably do, or at least probably should be doing more deliberately: pseudocoding.

Much like in the process of writing my first paper in college where I started drafting an outline without even thinking about it, a credit to the years of English teachers in high school who made me do it even though the topics of many of the papers I wrote in those classes weren’t so complex that I felt I could adequately hold it all in memory, there are times when we find ourselves with a problem sufficiently complex that we need to utilize swap-I mean scratch paper, and we start making (quite literally if you’re me) back-of-the-napkin diagrams and rough pseudocode with horrendously-named functions that we swear we’ll fix when it comes time to implement. If the code you ultimately write never leaves the confines of your hard drive, it’s fine if the chicken scratch you’ve scribbled to yourself never makes it off the page, but if you share that solution with anyone, and especially if you share it in the form of a blog post, it’s really to everyone’s benefit (including your own), that you share the pseudocode as well.

For those consuming your code, it greatly improves the likelihood that they can conceptually understand and appreciate what you’ve made even if they can’t understand the implementation very well (For example, if it’s in an unfamiliar or obtuse language, like bash). It benefits the author as well, as it gives them an opportunity to think though the problem more generally and perhaps even explore multiple solutions without wasting keystrokes implementing each one. I particularly like this problem of telling LightDM which display to use as an example of the merits of explaining through pseudocode as the problem itself can be presented rather trivially; maybe so much so that one would just start hacking away at it inside of a text editor without giving it much thought. Upon closer inspection though, the problem is revealed to be a little more complex, with multiple sub-problems branching out like the length of a coastline, growing with each step in magnification.

24 Nov 2019

I’ve made some much-needed updates to the site over the last couple of weeks, and I’d like to summarize some of the changes and things I learned along the way.

Design

Unfortunately, I don’t have much formal training in design beyond art classes in middle school, but I like to think I at least have a sense of what looks good and what does not (though I probably couldn’t formulate a cogent explanation as to why something looks good). One facet I’ve been working to develop in is color theory. Ironically, I think the RGB color system may have deterred me from doing so for quite some time. As an implementation detail, RGB is great, and as a lifestlye, it can’t be beat! However, it is a terrible way to think about color. Need to find a tint or shade of grey? No problem! Just make sure all of the component values are equal? Need a tint or shade of a color? Good luck unless that color happens to be red, green, or blue. Enter: Hue, saturation, and lightness, or HSL. You know that weird circumscribed triangle you sometimes find in photo editors? Yeah, that’s HSL. It’s an incredibly powerful tool for describing color, as it expresses it in terms more analogous to how humans process color. Hue refers to the point around the color wheel where its pure color resides. Lightness is a spectrum from black to white and indicates how bright the color is. Saturation is a spectrum between the hue and lightness, and is orthogonal to it, defining how prevalent the pure color is. The pure color component is the key to HSL’s power, in my opinion. Want a tint or shade of purp—I mean violet? Dial in the hue and saturation you want and then slide along the lightness spectrum to your heart’s content. Try doing that in RGB!

HTML5 Semantic Elements

For the uninitiated, HTML is an initialism that stands for the Hypertext Markup Language. I’d like to direct your attention to the word “markup,” as it’s doing the real heavy lifting in describing what it does. HTML syntactically structures and encodes the semantics of the content of the document within the document itself. Generally, this additional information is used to determine how the document should be laid out visually, but that information can be expressed in different ways for different people. For example, italic tags exist because a visually-impaired individual might not be able to see the subtle change in font depending upon how the page is rendered, but a text-to-speech program would also be able to convey that emphasis audibly. With this in mind, I’ve been incorporating more HTML5 semantic elements where applicable, such as wrapping paginated entries in section tags to better delineate them, and adding the button tag to my theme toggle switch. They’re particularly great because there’s no need for to worry about graceful degradation, as even browsers as old as IE6 can be taught how to handle them (more on that later) with as little as a single CSS rule. The internet was invented as a means of sharing information, but that information is only useful to those who can access it. Increasing accessibility (and awareness of accessibility as a ideal) is only to the benefit of everyone.

Disregarding Deprecated Browsers

Time stops for no one, especially anything related to the web. Before I began this overhaul, I knew I wanted to fully-embrace technologies such as Flexbox, but I also wanted to make sure this site is accessible to as many people as possible. In order to maintain my sanity and minimize hacks, I drew a line in the sand; I won’t be supporting any browser that isn’t supported by their developer, which I believe to be a reasonable compromise. I was astounded to discover that meant I only had to support as far back as IE11. I should clarify that when I say support, I mean in terms of visual appearance and functionality. I’ll still worry about graceful degradation when appropriate, but nothing more. After all, I’m one guy, and this is a personal website. No one’s life depends on my site’s footer displaying correctly.

“Hello darkness, my old friend”

I meant to write a post about my dark theme implementation when I made it way back when, but I forgot to do so. C’est la vie. Let’s talk about JavaScript instead! Some people love it; some people hate it; I love to hate writing it. Personally, my take on it is it’s all good in moderation as long as it isn’t doing anything creepy. With that in mind, I principally use JavaScript to enhance the readability and aesthetics of the site. For example, JavaScript powers the collapsible header that you may or may not be able to see depending on your scroll state (Go ahead! Scroll around a bit if you’ve never noticed it before). Why bother with such a thing? Well, most laptop and desktop displays are wider than they are tall, just like human vision, so to afford as much vertical screen-real-estate as possible, the header collapses out of sight as you scroll down the page, and returns at the flick of a scroll control. This design lends itself to progressive disclosure, while being forgiving to users who may not understand why the header disappeared originally. Likewise, it also degrades gracefully, as the header’s initial state is open, and won’t collapse without JavaScript available. Another example on the aesthetic side of things is lazily-loading images (this is still a work in progress as of time of posting). Let’s be honest, we don’t all always have a 100 Gbps down connection available to use at all times. Images are some of the largest assets a page has to load, and god dammit it will do so when it gets around to them! This leads to an unfortunate state of those images materializing in a slow-motion vertical wipe long after the rest of the page has been rendered. Aesthetics aside, this can also needlessly burn CPU cycles if the page layout is altered by the absence of these assets. Both of these issues can be solved very elegantly by lazily-loading images. A lightweight placeholder (even an inline SVG, perhaps?) is displayed while the actual image is loaded; upon completion of which, a handler is called that swaps out the placeholder for the actual image in the img tag’s src attribute. For those of you who don’t believe in JavaScript, have no some fear, for the noscript tag is here! Unfortunately, there’s nothing I can do to prevent the slow-mo wipe effect of potential doom or possible page re-rendering as the layout updates, but I can make sure that the correct image is displayed without being downloaded twice by wrapping a fallback img in noscript tags. If JavaScript is enabled, the fallback image isn’t even loaded!

RSS, Weblinks, and You

I’m kicking myself for not taking note of where I first saw a weblinks page (although the idea is probably as old as the internet, because everything is a remix), but I love the idea! It’s basically your bookmarks bar (or at least the interesting links) publicly available for others to peruse. I’ve made my own (find it in your local browser window!), and hope that I can use it as an opportunity to not only share things that are new and interesting to me, but things that I’ve known about for awhile and still find interesting or noteworthy, because "every day somebody’s born who’s never seen The Flintstones"_{Copyright 2000-something Merlin MannCopyright 2011 John Siracusa} (relavent xkcd). In a similar vein, I’ve also gotten into RSS like it’s 2009. My primary motivation was to limit my consumption of algorithmic content from platforms whose desires with respect to how I use the platform may not be (Read: aren’t) congruent with mine, which is totally fine, but recognizing that reality necessitates diversifying the channels through which I consume information. In the same spirit (and because it took basically no work on my part), I’ve also set up an RSS feed for this blog, so others can take a listen to what I have to say if they so desire, rather than if an algorithm is confident enough that they will. Oh, and I use and highly recommend FeedReader, as it’s built with Gtk, looks great, works great, and respects my window control preferences (@GNOME Feeds)!

Conclusion

I’m very satisfied with the updates I’ve made over the past couple of weeks, and there’s certainly still more to be done (apparently there’s some design paradigm known as “mobile first,” and I guess I’ll have to see what that’s about), and I’ll probably write some more about those in the future. I hope that others can take these ideas and lessons and apply them in their own endeavors of building a home for themselves on the web. As a wise man didn’t once say, “Be the change you want to see in the world.”

17 Oct 2019

Emoji 🚀 are ✨ great! ❤️ In a 🏠, with a 🐭, in a 📦, with a 🦊! The only places they really don’t belong are in the premise’s of movies, and CLIs (I’m looking at you, Kubernetes). One place I was sorely missing them though was on my Arch installation, until today that is.

For the uninitiated, under the hood, emoji are simply characters that were long-ago relegated to an unused corner of the Unicode table. As a result, this means two things for us; first, we’ll need to find a font that includes them, and that also means confronting… fontconfig *cue: wilhelm scream*. Second, we’ll need a way of typing them. In hindsight, that’s more like two and a half to three things, but I digress.

Finding the perfect font

Fonts are like opinions in that opinions are like assholes; everybody has one. The only things that everyone can agree on are that Arial is just a cheap knockoff of Helvetica and that Comic Sans isn’t the problem, people who use Comic Sans in inappropriate contexts are, but all of that goes without saying. There a quite a few emoji fonts out there, actually. As an iOS user, I should naturally believe that Apple’s emoji are hands-down the best (And I do, they’re absolutely gorgeous!) but sadly, due to licensing I couldn’t possibly install them (And no, I’m not using San Francisco Mono as my system monospace font! What could possibly lead you to ask such a ridiculous yet poignant question?). The few fonts that I did actually try include noto-fonts-emoji and twemoji-color-font. Had I thought about it for half of a second and realized that Noto emoji is used by Android, I would’ve stopped myself right there. No offense, but it looks like the typographer drew them grasping their pen in a fist like a cartoon character.

"This is fine."

Next stop, Twitter Color Emoji, Twitter’s open-source emoji font. I’ll admit it, I think it looks pretty good. Having been burned once not five minutes ago, I decided to give the README a thorough go. Not even one quarter of a way into the document, I stumbled across this little gem:

Note: This requires Bitstream Vera is installed and will change your systems default serif, sans-serif and monospace fonts.… DejaVu includes a wide range of symbols which override the Twitter Color Emoji characters… Bitstream Vera is the source of the glyphs used in DejaVu, 99%+ of people will not notice the difference.

You’d never guess, but I use DejaVu, and I quite like it, and I am one of the less-than-one percent who will notice the difference. So like any rational human being, I fire up yay and installed it anyway, foolishly confident in my skills and ready to pit them against fontconfig in glorious battle. After way more time than I should care to admit, I mostly had it worked out. Take that, RTFM! Happy as a clam, I carried on to the next step on my endeavour.

Selecting a Selector

As mentioned earlier, emoji are just characters, and so unless you’re Tom Scott, or don’t mind memorizing keycodes (I can’t find the forum post but yes, someone suggested that. I hope it was in jest 😰️), you’re going to want a way to select them graphically, preferably with some sort of search functionality included as well. Luckily for me, I use GNOME, which has an emoji picker built in that I knew nothing about and is apparently only documented in this Gitlab issue. Great! …except for the part where it only works, understandably, in Gtk applications. No worries, next stop, GNOME Shell Extensions! Everything useful in GNOME is à la carte these days it seems, and a system-wide emoji selector is no exception. Thankfully, there’s Emoji Selector, which includes a search feature! Hooray! Two clicks and we’re off to the races—oh no. Remember that quote from a paragraph ago that mentioned that DejaVu overrides Twitter Color Emoji but I thought I had fixed it? Turns out I hadn’t in this particular circumstance. And remember a paragraph ago where I had mentioned that I love Apple’s emoji but would NEVER violate their licensing? (If there any lawyers for Apple in the room, uh, you’re needed somewhere else) Ok, now that that’s taken care of, turns out that there’s an AUR package. I’m sure you’d never guess, again, dear reader, that in this twisting and turning tail there would be another turn, however this one is pretty minor. The conflicts list in the PKGBUILD is actually ridiculous. A quick 4dd and a few more incantations (sans any StackOverflow searches, thank you very much), my eyes were met with the prettiest emoji my system ever did see! Sadly, they were too beautiful for GNOME Shell it would seem, as in Emoji Selector they were rendered as silhouettes. UPDATE: Turns out I just needed to restart GNOME Shell. 🤷🏼‍♀️

Again, "This is fine."

All was not forgiven, though. I still had a couple of qualms about using a shell extension as an emoji selector: First, it couldn’t actually insert the emoji; it only copied them to the clipboard. You still had to manually paste them into whatever text buffer you were editing in. Second, the selector itself is just a popup menu item; it will always appear in the upper right corner of the screen, regardless of where the cursor is. This is admittedly a very minor quibble on the surface but for crying out loud this is a post about me wanting to be able to effortlessly spam my writing with modern-day hieroglyphs! Anyway, the fixed position of the selector almost never anywhere near where I’m typing really interrupts the flow of whatever context I might be in. It’d be much more preferable if the selector were able to be implemented as a drop-down list like other tools, such as autocomplete, do. After (I’ll admit it) some StackOverflowing, I stumbled across ibus-typing-booster. I had some vague recollection of IBus complaining about things way back when I used Ubuntu, but I never really knew what it did. I wish I had bothered to learn earlier because “Wow!” is it powerful! IBus, or Intelligent Input Bus is a multi-lingual input-method framework. Basically, it allows a user to easily input characters regardless of their keyboard’s physical layout. As we know, emoji are characters (I’m sorry I keep hammering that, but I’m always really excited by realizations that beneath the many layers of abstraction that modern computing sits upon, almost everything is incredibly mundane in implementation), meaning that it’s perfect for the job and, as icing on top, IBus operates via a panel that’s rendered at the text cursor!

This is actually great!

Installation (at least on Arch) proved to be a little obtuse, as it requires executing a program called ibus-setup. *sigh* Maybe I’m just becoming curmudgeonly in my old age, but separate setup applications have always felt like an antipattern to me. Perhaps I’m naïve, but why not do whatever initial configuration is required during installation, or perform a check on every run? For a daemon especially, even having the user manually perform it would be preferable. Perhaps I’m only saying this because of what happened next, though. At the end of executing, a preference window opened with some configuration options and no obvious “save” or “cancel” buttons to be found. Upon closing the window and trying to setup ibus-typing-booster, I was greeted with an error dialog stating that the Ibus daemon wasn’t running. There wasn’t any mention of any DBus service or systemd unit to start. Did I miss something? Do I have to restart my session? I was consulting the Holy ArchWiki and the only nugget it offered was the suggestion that some environmental variables may need to be set, so I tried that, and restarted my session as part of it and sure enough, IBus was up and running, but not knowing what action specifically solved the problem is frustrating, and may even cause trouble in the future if I need to fix anything. To be fair, I wasn’t being very scientific about it. I could have tried restarting my session first, but to be honest, I was getting a little tired. Having accomplished the necessary prerequisites, I turned to the matter of configuring ibus-typing-booster. This may be another reason why, in retrospect, I may be unnecessarily critical of IBus's documentation because I tip my hat to the creator of ibus-typing-booster, Mike Fabian. His README and documentation are my new gold standard to strive for in terms of communicating how to use the tools I make to others. The instructions are detailed but not incomprehensibly dense, and include screenshots! Even though the version of GNOME I use had buttons in slightly different places, seeing that the windows presented matched what was shown content-wise is a welcome relief when you’re deep in a sequence of steps.

Conclusion

I hope you enjoyed this tale of trials and tribulations. I think it highlights nicely that, as often is the case in Linux and in life, the first solution is rarely the best, and that experimentation can lead us to discovering solutions to problems we didn’t even knew we had. In the example of IBus, I’ve been learning French and now will be exploring if it can help me with typing all of the accented vowels, c-cedillas, and guillemets more easily.

Post-scriptum

One side-effect of my desire to share what I learn with others is that it also really encourages me to go the extra mile to make sure what I come up with is well-polished. One such example is the instance of this mildly-irritating error initially given by ibus-typing booster:

☹ en_US dictionary not found. Please install hunspell dictionary!

This would appear as the top suggestion (sometimes multiple times) no matter what I typed, and if I’m being perfectly honest, had I not written this article, I probably would’ve suffered for a quite a while until repeated incidents of accidentally selecting it for insertion would drive me to find a solution. But knowing that there was a chance I wouldn’t be the only person benefiting from the extra effort (and honestly taking solace in the fact that the solution to this problem probably already exists on the internet), I fired up my search engine of choice and got to researching. Here’s what I found.

Hunspell is a spell checker based on MySpell that’s used in a surprising amount of software, according to their homepage. ibus-typing booster uses it for completion prediction, thus requires dictionaries for any languages it’s used with. Installing a dictionary requires jumping through a few more hoops than usual if it isn’t in your distro’s package repos (Luckily everything is in Arch’s repos). The process is detailed in this StackOverflow post but the tl;dr of it is to download the desired dictionary from Apache OpenOffice Extensions, extract the .otf file (It’s basically a .zip file. You can actualyl just change the extension and use something like unzip), and move the .aff and .dic files to a directory on the PATH given by hunspell -D.

Honestly it might be more convenient to just install Arch.