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
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
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.
By commenting, you agree to follow the blog's Code of Conduct and that your comment is released under the same license as the rest of the blog. Or do you not like comments sections? Continue the conversation in the #entropy-arbitrage chatroom on Matrix…
Tags: programming project devjournal