Earlier this year, one of my cousins reminded me about a game that we used to play on my old Amiga 500. The name of this game was “Atoms”, and it was a simple but somewhat addictive game created by Tom Kuhn that was given away on the coverdisk of an issue of the Amiga Format magazine back in 1993 (and based on an old 1989 Atari game of the same name).
Having been reminded of this game, I boldly claimed that I could probably write a clone of that game myself. Ideas were already forming in my head as to exactly how I was going to do this. The main thought that I had was that I wanted to do it purely using web technologies.
Initially the project sat on the metaphorical back burner, but having been inspired by looking at some of the games that my niece had created in Scratch, I decided I had to get started. Progress was slow, but I had set myself a deadline that I should have this game in an at-least-playable state by the next time I saw my nieces in England.
Naturally I had to first research how exactly the original game played since I hadn't played it myself in over 20 years. Unfortunately not having an Amiga to play it on I had to resort to internet research. With some searching online I did find that someone had already implemented a version of this game for Android phones which was pretty good (and even had the original music), but it didn't quite have the feel of the original, and I did still want to do my own version of it for the web. Another useful source I found was a (poor quality) YouTube video of the original game. Armed with this information I set out to create the atoms-www project.
In creating the game I got the chance to play with some web technologies that I hadn't had much experience with yet. Scripting CSS Transitions was fun, if a little challenging - at least until a friend explained the weirdness of double rAF (requestAnimationFrame). Combining the transitions with the transform property allowed for some nice animations mimicking the original game. CSS Grid Layout was very pleasant to work with, avoiding the need to use a <table> element for the game board, or another similarly evil hack. The atom visuals themselves were simple CSS border-radius and CSS radial gradients with the aforementioned scripted CSS transitions to move them into the right places each time an atom is added to a cell. The only places SVG was used was for the logo and the coloured mouse pointer images. No bitmap images were used at all, aside from the favicon / shortcut image.
The game was in a just-about playable state by the time my self-imposed deadline arrived, and I uploaded the work so far to a GitHub project.
Since then I've worked on polishing the game experience, adding the ability to play against computer players (or even just set 4 computer players fighting each other). I added a debug mode to allow me to compare my implementation with the video of the original (for which Vivaldi's tiled tabs feature was incredibly useful) which led me to fix a bug related to conservation of mass (and rediscover a bug in the original game in the process).
Although it's still missing one feature that I want to include (the music!), I think it's now just about ready to share with the rest of the world properly. So here it is:
Posted: 2018-08-05 10:14:49 UTC by Xiven | Cross-references (1) | Comments (1)
After more than 11 years working at Opera Software I have decided to move on. A difficult decision to make to be sure, but I'm really looking forward to my new job.
As of June 2018 I start work as a Backend Developer at Vivaldi Technologies AS.
Posted: 2018-05-17 12:51:54 UTC by Xiven | Cross-references (0) | Comments (0)
As well as working at Opera Software, I also sing in an amateur choir that performs opera music (these two things are only loosely related).
Here are some recent recordings of our choir in action:
Posted: 2018-02-28 21:12:19 UTC by Xiven | Cross-references (0) | Comments (0)
SSH Key Authority demo server
Following up on the recent open source release of our SSH Key Authority tool, there is now a demonstration server available. You can find it here:
SSH Key Authority demonstration server
Use one of the following sets of username / password credentials to log in:
- testuser / testuser - normal user with admin access granted to a few servers
- testadmin / testadmin - admin user
Posted: 2017-08-31 22:05:17 UTC by Xiven | Cross-references (0) | Comments (0)
Restoring a deleted custom field in JIRA from backups
Imagine if you will, the hypothetical scenario where your newest JIRA admin has just managed to delete a custom field from your JIRA instance. This of course means that all data stored in that field has been deleted across all issues in all of your projects, and all the schemes and configurations it was referenced by will no longer reference it.
So, after revoking this hypothetical admin's administration privileges, what is your next step?
Like any good system administrator, you obviously have full database backups running on at least a nightly basis, so almost all of the data is there and can (at least theoretically) be recovered. But you don't want to restore the entire database, otherwise you would lose all data for today, which would be very bad.
You could re-create the field through the JIRA UI and then restore the data into this new field, but that has a couple of caveats:
- You have to manually re-integrate the field into all the field configurations and screens that it used to be in.
- The ID of the field will have changed, so if the field is referenced by any workflows, scripts or filters by ID then all of these things will need to be fixed manually.
It would be much better if you could restore the field and all of the configuration surrounding it directly as it was before. But how will you know which data to restore, and how will you actually perform this restoration? Allow me to be your guide...
This guide is written for JIRA admins who are using a PostgreSQL database as the backend of their JIRA instance. If you're using a different database engine you will need to make various adjustments.
- First things first, get that database backup file and copy it to some server or workstation where you can safely mess around with a database without consequence.
On this safe place, import the file into your database:
psql jira < 2017-08-31.sql
Connect to postgres:
Find the ID of your now-deleted field:
select id from customfield where cfname = 'My custom field';(for this hypothetical scenario, let's assume the ID was 10141).
You'll also need to find the ID of any entries in the
fieldconfigurationtable that reference your field:
select * from fieldconfiguration where fieldid = 'customfield_10141';(we'll assume we got an ID from this query of 10131)
Copy out the data from the relevant tables, filtered specifically to your custom field:
create table cf_temp as select * from customfield where id = 10141; create table cfo_temp as select * from customfieldoption where customfield = 10141; create table cfv_temp as select * from customfieldvalue where customfield = 10141; create table fsli_temp as select * from fieldscreenlayoutitem where fieldidentifier = 'customfield_10141'; create table cli_temp as select * from columnlayoutitem where fieldidentifier = 'customfield_10141'; create table fli_temp as select * from fieldlayoutitem where fieldidentifier = 'customfield_10141'; create table cc_temp as select * from configurationcontext where customfield = 'customfield_10141'; create table fc_temp as select * from fieldconfiguration where fieldid = 'customfield_10141'; create table gc_temp as select * from genericconfiguration where datatype = 'DefaultValue' and datakey = '10131'; create table fcsit as select * from fieldconfigschemeissuetype where fieldconfigscheme = 10131; create table fcsit_temp as select * from fieldconfigschemeissuetype where fieldconfigscheme = 10131;
Now you'll want to extract this data from postgres in the form of SQL
INSERTstatements. From your shell command-line:
pg_dump --data-only --inserts -t cf_temp jira > cf.sql pg_dump --data-only --inserts -t cfo_temp jira > cfo.sql pg_dump --data-only --inserts -t cfv_temp jira > cfv.sql pg_dump --data-only --inserts -t fsli_temp jira > fsli.sql pg_dump --data-only --inserts -t cli_temp jira > cli.sql pg_dump --data-only --inserts -t fli_temp jira > fli.sql pg_dump --data-only --inserts -t cc_temp jira > cc.sql pg_dump --data-only --inserts -t gc_temp jira > gc.sql pg_dump --data-only --inserts -t fc_temp jira > fc.sql pg_dump --data-only --inserts -t fcs_temp jira > fcs.sql pg_dump --data-only --inserts -t fcsit_temp jira > fcsit.sql
These SQL files are almost what you need, but they'll be using the wrong table names. Use some simple
sedmagic to clear those right up:
sed s/cf_temp/customfield/ < cf.sql > cf-out.sql sed s/cfo_temp/customfieldoption/ < cfo.sql > cfo-out.sql sed s/cfv_temp/customfieldvalue/ < cfv.sql > cfv-out.sql sed s/fsli_temp/fieldscreenlayoutitem/ < fsli.sql > fsli-out.sql sed s/cli_temp/columnlayoutitem/ < cli.sql > cli-out.sql sed s/fli_temp/fieldlayoutitem/ < fli.sql > fli-out.sql sed s/cc_temp/configurationcontext/ < cc.sql > cc-out.sql sed s/gc_temp/genericconfiguration/ < gc.sql > gc-out.sql sed s/fc_temp/fieldconfiguration/ < fc.sql > fc-out.sql sed s/fcs_temp/fieldconfigscheme/ < fcs.sql > fcs-out.sql sed s/fcsit_temp/fieldconfigschemeissuetype/ < fcsit.sql > fcsit-out.sql
- Copy these SQL files over to your JIRA server.
- Back up your JIRA database! Trigger an extra special run of your trusty database backup script.
- Stop your JIRA instance.
Run all of these shiny SQL files:
psql jira < cf-out.sql psql jira < cfo-out.sql psql jira < cfv-out.sql psql jira < fsli-out.sql psql jira < cli-out.sql psql jira < fli-out.sql psql jira < cc-out.sql psql jira < gc-out.sql psql jira < fc-out.sql psql jira < fcs-out.sql psql jira < fcsit-out.sql
- Start your JIRA instance up again.
- Check to see if everything looks okay.
- Hopefully breathe a huge sigh of relief.
- Set a re-index going, just for good measure. This is JIRA we're talking about after all.
Posted: 2017-08-31 17:15:36 UTC by Xiven | Cross-references (0) | Comments (0)