Today marks the 179th anniversary of the opening of Tivoli Gardens, the oldest amusement park still standing.

Tivoli Gardens

In any case…code.

Iungimoji

GitHub - jcolag/iungimojiA generator for simple memory games. Contribute to jcolag/iungimoji development by creating an account on GitHub.

If you’d like to skip the discussion, you can play Iungimoji at its new home.

As discussed last week, emboldened by the success with G.L.O.B.E., I decided to start the same process for Iungimoji, making it “hostable” without any server-side processing. I won’t talk about that as much as I did the first attempt, because it’ll largely take the same work: Creating a shell, converting generation code to initialization code, reading an external data file, replacing and seeding the random number generator, and handling the URL’s query to choose dates and now sizes.

It requires slightly more than that, though, because this game involves more than one random choice. The biggest difference involves what to do with the doubled-and-shuffled emoji list. In the original version of the game, it iterates through the list to generate plain HTML. Here, though, I need to insert DOM elements into the existing page.

const card = document.createTextNode(all[i]);
const div = document.createElement('div');

div.classList.add('cell', 'hide');
div.addEventListener('click', () => clicked(div));
div.id = `id="c-${i}"`;
div.title = '0';
div.appendChild(card);
board.appendChild(div);
if (i % size === size - 1) {
  const br = document.createElement('div');
  br.classList.add('break');
  board.appendChild(br);
}

Rather than creating HTML code to represent those elements, this directly creates each “card,” sets the assorted attributes—text content, ID, tool tip, ID, and click-handler—and adds it or a “new line” to the game board.

For the most part, though, the work revolved around finding bits of information that I used to generate, and so need that information built in the new code.

However, I did make one enhancement that might interest people: In testing, while everything seemed mostly random, it felt unsatisfying to see the same emoji turn up in different-sized games for a given day. This happens because the code uses the random number generator to choose emoji as its first act. And while most players will never notice—does anybody really want to play multiple sizes of memory game every day?—it still seemed sloppy.

To solve this, I added the board size to the seed string, meaning that the default seed for today looks something like 2022-08-15 4, distinct from my game seeding with 2022-08-15 6.

Also, the game no longer allows players to peer into the future. Any date set in the future will use the current date as the seed. You do, however, have all of history to play with.

Finally, since the game publishes from the repository, I’ve changed the default styling to reflect what I use on my personal website.

G.L.O.B.E.

GitHub - jcolag/g-l-o-b-eA generator for daily scavenger hunt puzzles at. Contribute to jcolag/g-l-o-b-e development by creating an account on GitHub.

As you can guess, I took some lessons learned from Iungimoji back to G.L.O.B.E..

That includes preventing players from seeing future games, for example. This seems more useful here than it does on a memory game, since knowing a future answer in advance eliminates the challenge of the game.

More deliberately, though, I modified the page style to reflect my personal website, since GitHub Pages doesn’t distinguish between “default” and “published” stylesheets.

Entropy Arbitrage

GitHub - jcolag/entropy-arbitrage-codeThe Jekyll blog for https://john.colagioia.net/blog - GitHub - jcolag/entropy-arbitrage-code: The Jekyll blog for https://john.colagioia.net/blog

At some point in the undetermined future, I may change my mind on this, but I opted to direct Jekyll to ignore the folder that I use to store chart data.

I based the decision on the reasoning that I don’t think that anybody needs the blog to publish those data files. However, it occurs to me that Jekyll also doesn’t watch those folders, meaning that it won’t alter my local server when I update such data.

In addition, apologies for the brief outage if anybody stumbled across it, but something in Jekyll seems to have mildly broken. When publishing, I started getting the following error.

To use ES6 syntax, harmony mode must be enabled with Uglifier.new(:harmony => true). (Uglifier::Error)

Because I publish posts with a script, this sort of error derails the process and then proceeds to replace the existing blog with a mostly empty folder, hence the apology. When you get a permissions-related error, it probably relates to this. The ES6 appears to relate to the new line-chart plugin, probably the Chart.js code, itself, since my generated code has become fairly conservative.

The solution makes no sense to me. The correct solution should involve upgrading to something that doesn’t choke on modern JavaScript. Instead, the solution panics.

jekyll-minifier:
  compress_css: false
  compress_javascript: false
  compress_json: false

In other words, I tell the minifier (which uses the uglifier, and 🎶 I don’t know why she swallowed the fly…) to…not shrink things. Apparently, I need all three, despite the error seeming to narrow it down. This means that you’ll see some slower page loads, until Jekyll gets its act together.

Library Updates

I needed to bump library versions for ScanData.

Next

As mentioned last time, I’ll try to set my sights on CPREP, this week, making it hostable on GitHub Pages, since the server no longer routes to the demonstration version correctly.


Credits: The header image is Tivoli Gardens 4 by a European Commission photographer, released into the public domain by European Commission law.