Developer Diary, Nabka Day

If you thought that last week’s days of remembrance didn’t have enough grimness to them, today the Palestinian diaspora acknowledges Nabka Day, commemorating their 1948 displacement from their homes in 1948, the day after Israel’s Day of Independence, though the latter keeps to the Jewish, rather than the Gregorian, calendar.

Once again, I apologize for the downer holiday, but May doesn’t give me much to work with. On to the software, then…

Entropy Arbitrage

GitHub - jcolag/entropy-arbitrage-code

I wrote myself a new plugin for the blog, this one to insert emoji into a post. Yes, I could already do that by pasting the emoji in, but that process always felt like it had a handful of problems.

First, getting the emoji to copy and paste required changing contexts, while I open an application that lets me find an emoji. Unless that application looks like a web browser with a decent search—which takes time and can’t work if the Internet goes out—I also need to know the official name of the emoji, and hope that somebody maintains the application at least as quickly as I update the emoji font on the blog. I suspect that it impacts the blog’s searchability, since you need to have the emoji to find the emoji. I don’t see pasting as a portable solution; if someone, someday, wants to read my blog on a device that doesn’t support Unicode, or if emoji fall out of favor, then they have no reasonable way of figuring out what I meant. And maybe most importantly, the tiny emoji don’t always display well, against a given background.

I started with the main file—dist/emoji-en-US.json—of the MIT-licensed emojilib. Loading it into the plugin, I can search for an emoji whose name(s) include a match for an arbitrary string, and insert it into the text. But it can actually do more than that, so it probably should. Rather than only print the emoji, I wrap it in a span element with title-text as what I called the emoji, and class="emoji" set. The title-text should help people decipher what I meant, and the CSS class lets me style them, specifically enlarging them when you hover over one for better visibility, like this 👾 Space Invaders-looking thing. It took some doing to get right, so I’ll explain what I ended up with.

.emoji {
  display: inline-block;
}
.emoji:hover {
  background-color: $background-color;
  border-radius: 0.5em;
  padding-left: 0.25em;
  padding-right: 0.25em;
  transform: scale(3);
}

My first attempt ended with changing the font-size. I abandoned that, because it changes the layout of the entire page.

Turning the span element into an inline-block, though, allows the enlargement to happen reasonably, with the transform style. I magnify the emoji by a factor of three, in this case, and it does so “on top of” the surrounding text. I then gave it a background without a texture for better visibility, and some minor padding and a rounded border to better match the rest of the blog’s styles. You’ll notice that the left- and right-padding does alter the layout slightly—much to my chagrin—but not enough that it’ll cause as many problems as changing the font size did.

Future Issues

While this does work, though, it still has its flaws. For example, I still need to paste emoji into titles, both because Jekyll processes them differently and because I use those titles across many platforms. The scale() function also magnifies the already-rendered image, rather than re-rendering it at a larger size, as messing with the font size would do, leading to some unpleasant artifacts.

Oh, and I still need to know emoji names, for the most part, to get what I want. However, as I use the plugin more, I can edit the JSON file to add my own names for the emoji that I find myself using regularly.

Since it looked like the post with the heaviest emoji, last week’s developer diary—where I mentioned upgrading the font and got me thinking about presentation—served as my test case, replacing the thirteen emoji with the plugin referencing them. You can see that zooming (and adding a solid background) improves the readability of the emoji on the rendered page, and the plugin makes the intent clearer in that post’s source file.

Non-Emoji Unicode

That raises a related question that I often grapple with and probably answer inconsistently, by the way: Emoji seem especially controversial and unstable today, in terms of whether you should assume support and acceptance. Until recently, though, the same often seemed true about Unicode in general. Most modern software deals with most of Unicode, but enough older and fussier software still exists, out there, that I often wonder whether I should include non-English text or text with diacritical marks as the appropriate Unicode text, or using HTML coding. At this point, I type with HTML encoding, since typing non-Latin characters becomes non-trivial quickly, but paste non-Latin text in, when I need to include someone else’s work. But a plugin—something that I have considered—would make the source file unreadable.

Morning Dashboard

GitHub - jcolag/dash

You might remember that, in last week’s developer diary post, I talked about how I generate daily diary—or “journal,” if the feminized word terrifies you, or something…—entries, focusing in particular on the format of logging media. I went to that trouble, primarily because I wanted to start displaying that information in my Morning Dashboard.

Using Chart.js, I now display three overviews of my viewing habits: The number of shows watched per platform, the average sentiment of emoji used per platform, and the average sentiment of text written per platform.

While there, I also finally decided to make use of my weird pedometer backup files, giving me charts of the changes in steps per day over the last bunch of days and the average steps per hour over the same number of days. The latter gives me a stronger sense of when I “naturally” walk more, in case I want to start setting aside time specifically to walk. It probably wouldn’t surprise anybody to learn that I walk significantly less during when I generally eat and go through social media, since neither of those allow for much meandering or require pacing to clear my head.

Why Chart.js, rather than hacking together my own graphs, like I’ve done for weather, sleep, and journal sentiment? Partly, I got tired of hacking together my own graphs. However, Chart.js creates dynamic graphs. I can hover over the data points to get their meaning—without writing any extra code, like I have for the other charts—and I can click on the legend to turn specific data lines (streaming services) on and off. If I only want to focus on the paid services, then I can toggle off the freebies.

If you would like more detail on making this work, I published a blog post about working with Chart.js on Wednesday, including some examples.

Will I overhaul the existing graphs to make use of the new library, as long as I already have it in use? Maybe, but I don’t think so, unless the library can do more sophisticated work than I expect. In the case of the sleep and sentiment charts, I need them to respond together, highlighting days between graphs. And in the case of the weather chart, I want the emoji representing the day’s weather to sit in each hour’s bar, as well as colors representing the time of day. If Chart.js can do those things, then I’ll look deeper into replacing my code. But it seems like too much of an edge case for a general purpose library.

Mastodon Tool Trunk

GitHub - jcolag/tool-trunk

The overall project now has an ESLint configuration, so that nobody needs to redo it to check the code. Interestingly, it took creating a Node.js project, so that I could install ESLint, so that I could configure it, which hits a level of abstraction that I didn’t entirely expect.

The Morning Dashboard mostly took over the week, though, so I didn’t get as much done as I would have preferred.

Next

Given that I mostly ignored it, this past week, I should get back to the Rummager, once I finish committing the changes to the Morning Dashboard today.

---

Credits: The header image is 42nd St Bway 7th Av td (2018-05-18) 06 - Nakba Day Protest (advertising blurred by me) by Tdorante10, made available under the terms of the Creative Commons Attribution Share-Alike 4.0 International license.