I don’t post on here any more, so I’m converting the existing wordpress to a static site.

The whole site will probably disappear or be replaced in the future.

If you use Slack in a Browser, change the user agent to a Mac OS X one, for example:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3188.0 Safari/537.36

You can use the User-Agent Switcher plugin for chrome. (Their default OS X Chrome is a too old version, so slack won’t load).

If you use the Desktop App it’s a bit more complicated:
Quit slack.

npm install -g asar

Open a console in C:\Users\{your user}\AppData\Local\slack\app-3.0.5\resources
(version number may change in the future)

asar e app.asar app-extract

open app-extract/package.json
Add the whole user agent from above in to the the version field (Keeping the version at the start)
example: “3.0.5 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3188.0 Safari/537.36”.

move app.asar app-original.asar
asar p app-extract app.asar

And restart slack! You’ll have to re-do this every time slack updates.

Download OBS Studio https://obsproject.com/download
Install it
Run OBS

File, Settings

Tab: Video
Change Base and Output to be the same resolution (1920×1080 probably)

Tab: Output
Encoder: Hardware (Anything)
Recording Format: mp4

ok, close out of settings

Sources [+] (at the bottom)
Display Capture
[ok] [ok]

Check your video looks right in the video area (Should be showing your desktop)
You can click in there and resize, but if you need to do that you probably didn’t get the video resolution correct before.

Ready!

Hit [Start Recording] to record.

In the future you should just be able to start OBS, the display should already be in the video pane, hit [Start Recording]

Last week I released a game called “Massive Match“. It is the first ever Massively Multiplayer Match 3.

You can go play it right now, just click: Here!

Massive Match Gameplay

I built this game using TypeScript and Phaser. There is a little write up on the stack over at Gamasutra and I talked a bit of the tech details on HTML 5 Game Devs.

Enjoy!

I was lucky enough to attend YOW! in Melbourne last week, here is a braindump of what I went to.

Day 1

It’s Complicated…

Virtual Teams: Making Them Work

Interesting talk on Virtual Teams (Not remote teams). A Virtual Team is where (ideally) everyone is remote. Some takeaways:
Almost everyone in the room used Slack.
When there is an office and some people remote, if the people in the office all go in to a room to have a call with remote people, this will make the remote people feel even more remote as the people together will have a conversation between themselves that they can’t really be a part of.

Rethinking MVC with React Native & ReactiveCocoa

React Native is a React Framework for doing native looking mobile apps using javascript and React.  It looks pretty awesome.

ReactiveCocoa is a React style framework for Cocoa UI, also looks pretty awesome.

Pragmatic Microservices: Whether, When and How to Migrate

This was an excellent talk. Randy went through lots of things around moving towards a microservice architecture, recommend watching this one back when the vids arrive.

Production Haskell

Sustainability Supporting Data Variability: Keeping Core Components Clean while Dealing with Data Variability

Another really good talk, talked about how they added lots of custom logic and processing to their app without making it a mess.
Spoilers: Preprocessing data, hook points to allow specific extensions and validation.

Frugal Innovation and Scaffolding software

Really good feel good talk on innovation in Africa, when the video comes up make sure you watch it!

Thriving in a Stochastic World

Good talk for teams that try optimise for reliability in their process.

Day 2

Using Formal Methods to Eliminate Exploitable Bugs

Delivery Mapping: Turning the Lights On

Really Really good talk for anyone doing scrum, Slides are online but don’t make sense by themselves, watch out for the video.

Talks about the human-improvement side of this process, writing down what skills people think they have and what they’d like to improve on. Forming scrum teams based on the work that needs doing rather than trying to fit the work to the team.

Facebook’s Product Infrastructure

Talked about how facebook is just a giant hack and they like it that way.

Making Hacking Child’s Play

Really entertaining talk on how easy it is to hack poorly made sites.

Deploying and Scaling Microservices

The Future of Software Engineering

Good talk about the practice of Software Engineering. Everyone talks about how Software engineering isn’t real engineering, but when you delve in to it it turns out it is.

Designing for Failure: Scaling Uber’s Backend by Breaking Everything

Interesting talk about failures that Uber has had and how their architecture ended up like it is.

Following up last month where I released Simpulls on iOS, Simpulls is now available on the other big platform, Google Play!

https://play.google.com/store/apps/details?id=ironshod.simpulls

Download it free and enjoy 🙂

Download ffmpeg

ffmpeg -i clip.mp4 -vf palettegen palette.png
ffmpeg -y -i clip.mp4 -i palette.png -lavfi paletteuse output.gif

DONE!

ref http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html

You can also use giflossy to reduce the size https://github.com/pornel/giflossy

What is a microservice

First, you need to learn about the go language. Do these pages in order to learn the bare basics:
https://tour.golang.org/
https://golang.org/doc/install
https://golang.org/doc/code.html

Then you’ll need to learn what docker is, read the understanding docker page:
https://docs.docker.com/introduction/understanding-docker/

And then go install docker and run their hello-world example:
https://docs.docker.com/installation/

Now hopefully you have the basics of go and docker down, so let’s grab an existing microservice and set it up.

On your docker host run:

wget https://github.com/danzel/go-docker-playground/archive/master.tar.gz
tar -zxf master.tar.gz
cd go-docker-playground-master
docker build --tag=danzel/go-docker-playground:1.0 .

This will fetch and then build this docker image which contains a simple web server. Now we can start it up with:

docker create --name=test -P danzel/go-docker-playground:1.0
docker start test

Docker will automatically expose the server on a free port (Thanks to EXPOSE in the Dockerfile and -P in the docker create command line).
To see the port it has chosen:

docker ps

Then you should be able to open it by browsing to http://dockerhostip:port

When you have a popular repository on github, you can get a lot of Pull Requests.

Some of these are good, some need work and some should never be merged. As the maintainer it is your job to figure out what category each PR fits in to, work with the original author to fix any issues and finally do the merge.

But how do you decide what PRs should actually end up in the project?

The naive view would be to merge every feature. But what if that feature is only useful to one person? Is the person submitting that PR going to stick around to maintain their code in the future or (more likely) is maintaining that code going to fall to you? Is the feature even something that other users want?

Every change adds extra weight to the project that must be carried and updated when any refactoring is done. These features also add complication to the project that can hinder further changes. Sometimes the best change is one that makes the project more extensible without adding any features itself.

The way I deal with PRs that I’m not certain about is to let them sit. If someone else wants them they’ll hopefully come along and comment on them. Usually this works well, PRs that add or fix urgently needed things tend to have people on there asking for them to be merged.

Sometimes your PR won’t get merged or looked at because the maintainer has other things to do. The people who maintain projects on Github are people, they only have a limited amount of time in their day and they probably have a job they should be doing.

And finally sometimes the maintainer will miss the notifications so your PR never gets looked at. So don’t get too upset when things don’t get merged, wait a while

TLDR

Ways to help your PR be merged

• Explain why your change exists
• Add tests
• Fix build errors
• Change anything that is requested
• Bump it after a weeks in case the maintainer has missed it

Ways to help your PR not be merged

• Break the build
• Do a large amount of changes
• Include automatically generated files

Grab the .deb file from their cydia repo http://www.libretro.com/index.php/downloads/

Extract it with “ar xv something.deb” (I had to use a linux machine for this)

Create an Entitlements.plist like on here:
http://stackoverflow.com/questions/15634188/resigning-an-ios-provisioning-profile
(The example is missing )
Replacing the application-identifier with one compatible with your signing cert.

Save the following as r.b64 (This file gets created automatically if you build the project)

nBsaXN0MDDRAQJVcnVsZXPTAwQFBgcMUi4qXxATUmVzb3VyY2VSdWxlcy5wbGlz
dFpJbmZvLnBsaXN0CdIICQoGVndlaWdodFRvbWl0I0BZAAAAAAAACdIICQ0GI0Ak
AAAAAAAACQgLERgbMTw9QklOV1hdZgAAAAAAAAEBAAAAAAAAAA8AAAAAAAAAAAAA
AAAAAABn

Convert it into ResourceRules.plist with:

cat r.b64 | openssl base64 -d > RetroArch.app/ResourceRules.plist

Run roughly these commands:

$CODE_SIGN_IDENTITY – Your signing name, check “Keychain Access”

$PROVISION – a copy of your provisioning profile file

 codesign -fs "$CODE_SIGN_IDENTITY" RetroArch.app/modules/*.dylib
 cp "$PROVISION" RetroArch.app/embedded.mobileprovision
 cp ResourceRules.plist RetroArch.app/
 codesign -f -s "$CODE_SIGN_IDENTITY" --resource-rules RetroArch.app/ResourceRules.plist --entitlements Entitlements.plist RetroArch.app
 xcrun -sdk iphoneos PackageApplication "RetroArch.app" -o "RetroArch.ipa" --sign '$CODE_SIGN_IDENTITY' --embed "RetroArch.app/embedded.mobileprovision"

Install the IPA 😀