The Blog of Tom Webster

Chronic Ranter, Reviewer, and Developer. I speak only for myself, opinions are my own.

PSA: Time Variables

  2015-11-25 16:19:00 PST

This is a public service announcement about naming variables dealing with amounts of time. I've had the misfortune of dealing with some code recently that didn't have properly named variables for different time-sensitive functions. What resulted is some confusion about why certain functions would never fire, even after the elapsed time.

The majority of the time variables in this application were in miliseconds, as is common in most of the code I work with. Unfortunately, miliseconds were not the only measure of time used in variables. There were integer variables that used seconds and even one that used hours. With no call out, comments, or specific names to differentiate them. What was set to 3600000 miliseconds was actually a variable for number of hours. Instead of firing every hour, as planned, because of the inspecific variable name and mixing of time units without comments, that event would fire once every ~411 days.

If you're going to use variables for time, keep these things in mind:

  1. Only use one unit of time across your project, stick to seconds or miliseconds for everything. Call this out in the comments or readme. If you want to be really nice, you can use #2 as well.

  2. Call out the unit in all variable names. Yes, this can get tedious, but it really helps people looking at your code figure out your intent for the variable. Maybe making everything use seconds as the unit is too big, maybe you need something smaller, but settling for miliseconds across every value is kinda crazy, seeing as you want to use hours in a couple places. Why not socket_timeout_in_miliseconds or auto_backup_time_in_hours?

The only wrong answer is mixing units and leaving them a mystery to the next developer to pick up your code.

The Most Evil Thing Imaginable: Mimic

  2015-10-30 03:50:03 PDT

This is just truly evil, and amazing to witness. Greg Toombs' (reinderien) new project Mimic. It randomly replaces characters in someone's source code with unicode-lookalikes. Just the other day I had to deal with a dataset that had some unicode spaces in it and I thought I might pull my hair out.

Anyway, awesome project and it does include a "Reverse Mimic" function, so you can fix your files if you suspect someone has mimicked them. Go check it out.

Writing about Jekyll Tags in Jekyll

  2015-10-28 03:08:45 PDT

Just ran into an annoying situation. How do you write about Jekyll tags inside of Jekyll? How do you get it to avoid parsing?

The best answer I've found is this Stack Overflow answer.

Updated 2019-01-29: This post keeps causing errors in recent versions of Jekyll. Just check the Stack Overflow link.

New Theme: Amber

  2015-10-28 02:30:00 PDT

Thanks to Stuart Webster for the awesome background! - CC-BY-2.0

As you may have noticed (unless you're reading this through the RSS feed or a screen reader), this site has undergone a major theme update. I'm calling it "Amber", because of the color choice. I took inspiration from various places on the web to come up with this design. This still uses the awesome Twitter Bootstrap under the hood. It just makes things too easy to build to get rid of.

My favorite feature, aside from the cleaned up navigation and better-looking site, is the per-post-backgrounds. This is accomplished with the code below. Pretty simple, if a bg element isn't present (or set to false), the default background is shown, otherwise show the image specified in the bg YAML Front Matter item.

{% if page.bg %}
  <header style="background-image: url(/images/{{page.bg}});">
{% else %}
 <header style="background-image: url(/images/bg.jpg);">
{% endif %}

I've gotten rid of glyphicons in favor of FontAwesome. It's way better to have just one icon-font library instead of two, faster page loads.

One of my favorite features (that was made before this theme was launched) is the compressed cache-busting asset-cruncher. The plugin is stupid, it takes all of your CSS, JS, and fonts from _assets, compresses what it can, then copies the compressed assets into assets that Jekyll uses to build the site. The result is a single CSS and a single JS file are used, brining the number of total requests down and site speed up. This is hugely helpful until HTTP/2 takes over everywhere. The plugin isn't perfect by any stretch of the imagination, it really needs to be tuned up to run only when it's supposed to. Right now, it doesn't re-fire when Jekyll runs in --watch mode, meaning you have to CTRL+C and re-launch jekyll serve for CSS/JS updates to take effect on your local system. Merge requests are appreciated if you have the time.

As always, you can get the code to my site on GitLab and if you'd like to base your Jekyll site off of mine, you can do so easily with the deployable version.

Gamestation

  2015-10-04 20:02:32 PDT

Thanks for the awesome background libretro!

About

Project Gamestation took a major backseat when I discovered RetroPie. petRockBlog did a fantastic job putting everything together and making it "Just Work". I seriously recommend checking it out. When it comes to gaming on the Raspberry Pi, RetroPie did everything I could have wanted and more, but it's really designed for the Pi, not for x86/x64 systems.

That's where Gamestation comes in. The project is really nothing special. It's a couple shell scripts that automate fetching the repos, building other people's projects, creating a Debian package, and installing it. It's not a major piece of work, but it makes my life easier and has resulted in a great double-click-easy system that I can hook to my TV that has a bit more power than a Pi 2.

The best part of this is combining it with Syncthing. I always hated how my roms and saves would differ between machines, requiring a central folder somewhere on ownCloud or manually syncing. Syncthing is like Bittorrent Sync, but open source and well respected. By using this and a centralized folder structure, you can keep all roms/saves/themes/metadata syncronized between Gamestation machines. It works really well and is useful for bootstrapping new machines.

Installation

Right now Gamestation is only supported by Debian and Debian-family Linux distributions. I'm 98% sure you can get it running on just about any *nix OS out there, but I can't claim to have tested it. If you'd like to add other OS support, check out the GitLab Repo.

Grab the .deb here and install with sudo dpkg -i. If your system complains about dependencies, try sudo apt-get -f install to find and install the missing libraries.

Gamestation expects the following folders to be in ~/roms/:

amiga
amstradcpc
apple2
atari2600
atari5200
atari7800
atari800
atarilynx
atarist
c64
coco
dragon32
fba
fds
gamegear
gb
gba
gbc
intellivision
macintosh
mame-advmame
mame-mame4all
mastersystem
megadrive
msx
n64
nds
neogeo
nes
ngp
pc
pcengine
ports
psx
quake3
scummvm
sega32x
segacd
sg-1000
snes
vectrex
videopac
wonderswan
zmachine
zxspectrum

And a symlink from ~/roms/megadrive to ~/roms/genesis: ln -s ~/roms/megadrive ~/roms/genesis

To actually run the system, use the command emulationstation.

Meta

As usual, the project is open source, grab the code here.

This project is licensed under the GNU GPL v3.

If you're building a nightly-release, check out the source code's README.md. It'll walk you through how to build one from source and end up with a Debian package of your own.

TODO

There's still a lot of work to be done. If you'd like to make this project better, send me a merge request.

  1. Windows support - This will make it easy for non-techies to get their emulators up and running easily.
  2. RetroPie currently makes controller bindings between EmulationStation and Retroarch seamless (for the most part). I'd love to port that over.
  3. Create a build-bot system that puts out weekly beta builds of GameStation. Ideally, this would be an ansible playbook or something equally as automated.
  4. Automated Syncthing setup. Currently, Syncthing is pretty geared towards techies. If mass adoption is going to be possible, this part will need to be easier to set up. Maybe a web service that links IDs together through the Syncthing API? Lots to consider.
  5. PIPE DREAM - I'd LOVE to get this working on a PiGRRL with wifi. Take your roms and saves ANYWHERE! Sync when you hit wifi.

Syncthing Setup

  1. Follow the instructions on Syncthing's Debian page.
  2. Create a service file for syncthing:
    • sudo cp /usr/lib/systemd/system/syncthing@.service /etc/systemd/system/syncthing@`whoami`.service
    • If you aren't on a system with systemd yet, use this init file.
  3. Go to your local syncthing management page at http://localhost:8384/.
  4. Click Add Folder and add ~/roms/, feel free to set up file versioning if you'd like.
  5. Click Add Folder and add ~/.emulationstation, feel free to set up file versioning if you'd like.
  6. Use Actions -> Show ID to show your device's code.
  7. On a new device, install Syncthing and click Add Device, paste in your first device's code and give it a name.
    • Adding your first device as an "Introducer" is pretty helpful, it can act like a central point for all things Syncthing in your setup.
  8. On the original device, Syncthing will eventually ask you if you'd like to trust the new device you've added. Go ahead and trust it, then share the .emulationstation and ~/roms/ folders with it.
  9. Synchronization should happen automatically.
  10. Install Gamestation on the new system, your saves, roms, and themes should all be synced between all Gamestation devices.

Credits

This project wouldn't be possible without the amazing work by the following projects:

For full details and credits, check out the README.md file.

Page: 6 of 32