boffbowsh's comments

Swiping makes this much easier to use and even more addictive. Nice work!

I was late to sleep because of this, thanks! One suggestion, allowing swipe on touch devices would feel a lot more natural than tapping each square, which was a bit error prone. Either that or make the hitboxes a bit bigger.

This does deserve more recognition but unfortunately we don’t talk about Bruno

This is like the Rosetta Stone between zoomers and us millennials

Ah yes I’m sure those scientists in Denmark and the UK will try to maximise coverage of this due to an election in some other country. Grow up.

Those were originally part of the GaaP (Government as a Platform) programme. The PaaS is explicitly just the Cloud Foundry-based deployment platform.

Monzo engineer here. 99.99% of changes don't require key ceremonies. When they do, we can usually book them with a few days notice. It's normally for things like onboarding big new systems and gets planned into a project from the beginning.

The people who implemented this process are the same type of "IT/devs" or "Devops" you mention. There isn't a whole lot of throwing things over the wall to Ops, or for that matter putting up arduous processes against "normal" engineers.

I'd love for it to work over NFS. It should be easily doable, but I guess it means adding another dependency to the boot2docker ISO.

We haven't yet had the pleasure.

No, 99% of our devs run Macbooks

waves. We don't change anything in the Dockerfiles, it's more that we use the dependency logic in Make to ensure that x is done before y and before z. We also use it to actually run a lot of our containers with the ability to switch in configs for production-like databases if the developer needs it.

Make was the perfect tool for the task at the beginning, but it's getting a little unwieldy and will probably need rewriting in something else soon, probably Python.

We (hi, I work at Lyst too!) see Docker images as fairly similar to pre-built AMIs conceptually, just a lot more lightweight. We bake our Docker host AMIs relatively regularly and use them in the ASG that runs the Dockerized website. Building AMIs (and booting new instances from them on each deploy) takes a lot longer than building a new Docker image and launching containers from it.

I'm not entirely sure I understand what you're asking though. We've so far only Dockerized the main Python application, and not many of the supporting applications. We don't think we'd go down the route of running Postgres, ElasticSearch, Redis etc under Docker.

To give you an example of times taken, Pull Requests take about 10 minutes to test, a full master build (including uploading build artifacts) takes around 15 minutes, and a deployment to 8 Dockerized web hosts is about 5 minutes, including a smoke test on each host.

EDIT: Just realised what you're asking. If you're running many processes on each host then yes it can take a while to deploy. We deploy our Celery workers under separate Docker containers and this can take a while to stop and start. For the website though we run uWSGIs in forked mode, so it's only one container per host. This will probably change in the future, we're evaluating Mesos + Marathon for a more PaaS-like deployment where we can say "14 web processes please!"

Hope that answers your question.

Finally scratching an itch from 3 years ago, and I think it's still relevant. It's for freelance designers and small agencies so they don't have to do CMSes themselves, and can get a bit of recurring revenue from their clients.

We had some serious proactiveness from antirez there :)

Interesting article. I've been part of a Rails Rumble before and attempted to get a hack day sorted at my previous job. The selling part is what we missed out :(