Want to play? Get a MFi controller for Christmas

It would probably be an understatement to say I'm not a gamer. Last console I got was a Game Boy, 22 years ago (IIRC). Never got a gaming PC. I have 4 games on my Mac, and one is ASCII based. But my main source of mindless leisure for the past 7 years, aside from reading, has been playing with some iDevice. From an iPod Touch back then to my current iPhone and iPad Pro, playing, for me, has been Apple. Mostly strategy games, occasionally getting some simulator or arcade depending on how good it looked and how well designed for touch it seemed.

Recently, though, I got a MFI (Made for iDevices, I guess) Bluetooth controller (affiliate link to Amazon: SteelSeries Nimbus). It has made playing the games it is compatible with impressive. Case in point, yesterday I finished playing the outstanding Forma.8 Go an open world exploration-driven platformer. I had started playing it several months ago, and stopped by the frustration at my inability with touch controls. Mind you, they are very well designed, it's just that I could not adjust to them. Playing with a controller was a totally different experience, much more enjoyable (looking at you, Downwell).

It is rechargeable (have been using it for a couple of weeks and so far the battery has not depleted... as I said, I'm not a huge gamer) and works with iPhones, iPads, Apple TVs and even with Mac's, although for older games you will need several tricks (first, a converter from MFi to HID you can compile from this github repository, and depending on the game a HID remapper tool like Enjoyable, with these two I could almost play Reassembly... I will try to play following another path, but with this I could play old DOS based games instead).

Nimbus SteelSeries MFi Controller
The SteelSeries Nimbus

Sadly, not all games support controllers, they have to be specially programmed for it. For the ones that support it though, playing with a controller is way more fun, which has made the purchase totally worth it, even if I play less than 2h/week on average. Be sure to check which games are available (and which you already own and like!) before getting it to avoid a letdown. Oh, and in case you are wondering... neither PES 2018 nor FIFA 18 support it, sadly. NBA 2K18 seems to do, but I have not purchased it yet to try. Some of the GTA titles do, as well as the iOS classics Thomas was Alone and Galaxy on Fire 2.

Oh, and in case you prefer different kinds of controllers, there are plenty to choose from. Some convert your iPhone in what looks like a weird PSP, or have a clip to hang your phone. Can't vouch for them: the Nimbus feels high quality.
Written by Ruben Berenguel


Change the parameters of a docker container without knowing the docker run command used

I'm not sure how useful this Docker "trick" is, since it happens in a very niche situation.

At work, we have several instances running a suite of Docker containers, with some non-trivial amount of environment variables, port configurations, volumes and links among them. This is set up really easily using ansible: writing link/port/volume mappings in ansible (using the docker, container or docker-container modules, depending how long ago we set it up). The syntax is similar to docker-compose, but scripted for ansible.

The problem arises when you are logged in on one of the machines and you want to change (or add) one parameter to one of the currently running containers. Re-running the ansible script in full is not always an option (for reasons I don't want to get into), so up until now we had to painfully rewrite the docker run command from the ansible set up, by hand. Which is terribly error prone. And a pain. And in general very much a process you don't want to follow, ever. We were very close to writing a short python script to convert the yaml specifications from python into docker run commands when we found out a relatively less painful way of doing it.

We jokingly call it the Indy swap

It's quite easy, and is best described using a checklist to avoid messing up.
  1. First, you figure out what you want to do. For instance, map a port
  2. Change to super-user
  3. Get the container id from docker ps
  4. Use your favourite remote editor to inspect the file /var/lib/docker/containers/{container_id}/config.json to figure out what you need to add
  5. service docker stop
  6. Edit the file in step 4 to add/remove any extra setting
  7. service docker start
  8. VoilĂ 

Steps 5-7 are the actual Indy swap, if we are not fast enough the healthcheks in our elastic load balancers will mark the instance as failing and stop it. Yes, we could disable the check while we do this, but where's the thrill, then?

By the way, the file in 4 will be a JSON file with the settings of the container. Any saved edit needs to be done with the docker service closed (since the file is in use otherwise). The format of adding ports, volumes or links is pretty self-explanatory as long as you have already a port, link or volume set up in the instance. Otherwise, check the configuration of any other running container having that. I suggest opening it in 4 with the editor already so you can up-arrow just after stopping the service without needing to find it, and also having planned the changes beforehand (or having done them in a config.json1 you then swap)

Oh, and don't do this in production. Oh, of course you won't because you are not using Docker in production, are you?
Written by Ruben Berenguel


Shading dependencies with sbt-assembly (in particular, shapeless in Spark 2.1.0)

A few weeks ago I needed to parse configuration files in Scala for a Spark project and decided to use PureConfig. It is incredibly lean to use, needing minimal boilerplate. I recommend you check it out (give also a look at CaseClassy, which I haven't had time to test yet).
Everything seemed straightforward enough, and I got it working pretty quickly (as in, it compiled properly). The surprise? spark-submit failed with a conflict with Shapeless (lacking a witness). This is due to Spark 2.1.0 needing Breeze, which in turn needs Shapeless 2.0.0 (which is pretty old). Problem is, Spark's required library prevented PureConfig from pulling the correct version. D'oh!
There is an easy fix, though, if you are using sbt-assembly you can shade dependencies, by adding something like the following to your assembly.sbt file:
assemblyShadeRules in assembly := Seq(ShadeRule.rename("shapeless.**" -> "new_shapeless.@1").inAll)
Written by Ruben Berenguel