Setting up audio Bluetooth on the Roland TD-27 had been super easy, and I’ve been using it to play along to backing tracks or to use with Drumeo. I think my success there might have led me down a misleading path of thinking that Bluetooth would be the answer to all my problems. The trouble is that any audio latency shows up really quickly when you’re using Melodics and trying to trigger drums over MIDI at the same time as you’re hearing the backing track.

One approach is to connect using a cable between MIDI out on the TD-27 to a USB hub. This is actually documented on the Melodics site as their Method 1, although because of the enshittification of search on the internet, it took me far too long to find that page.

My MIDI cable has a USB-A plug that I’m connecting into an Anker USB-C hub that connects to my iPad. I’ve also got a USB to headphones adapter plugged into that hub so that I can hear the sound. To be honest the MIDI connection seems pretty unreliable, and unplugging and plugging things at random can seem to help.

Another option is to use MIDI over Bluetooth between the TD-27 and the iPad, following Melodics Method 2 for connection, but do make sure you’re not using the Bluetooth audio and trying to listen through headphones connected to the TD-27 because that’s WAY too laggy. I’ve ended up leaving both Bluetooth audio and MIDI turned on on the TD-27, because it’s easier to leave it that way for when I just want to play along to a backing track, but I just need to make sure the audio out from the iPad is not over Bluetooth when I’m using Melodics. With this set up, I don’t need the Anker hub, and I’m using my USB-C to headphones adapter plugged directly into the iPad.

On the TD-27 I was having further problems because the hi-hat always appeared to be triggering as open, even when it was closed. It turns out there’s a setting under MIDI -> Control called the Hi-hat Note Border which I ended up setting to 80 instead of its default setting of 127, thanks to this useful post on Reddit. This setting defines the border between open and closed. For what it’s worth I also changed the MIDI mapping to trigger the general midi closed hihat note 42 (F#2), whether I’m hitting the high hat on the bow or the edge – the settings for this are under Kit Edit -> Kit Midi.

I hope this helps someone else get set up more quickly than it took me!

Another episode in an occasional series of learnings about using containers, virtual machines, and Kubernetes.

If I’m doing a demo on stage, I prefer to avoid network dependencies, conference WiFi being what it usually is. So for years I ran container or Kubernetes-related demos in virtual machines running on my laptop, with no dependency on the outside world.

Virtual conferences changed all that —streaming from home, I figured that if my internet connection goes down, no-one would be able to see or hear the fact that my demo had broken since the stream would also be affected. Additionally, after switching to an M1 Mac it was a whole lot harder to run demos on that, since it seemed there was always something I wanted to lean on that didn’t run on ARM architecture yet.

But as we gear back up to IRL events, I’ve been exploring whether it’s realistic for me to get back to VM-based demos. And I believe it is, because:

• Lima-VM is awesome. It knocks the socks off Vagrant/VirtualBox or UTM, at least for my use-cases.
• Most things (but not everything) now seem to be built for ARM as well as Intel.

Lima config files

You define your VM config in a YAML file that can also run provisioning scripts. Here’s an example of a Lima config file that I’ve been using for eBPF coding, based on Ubuntu. I know it works on ARM, I would love to hear from you if you try it out on an Intel machine.

# This example requires Lima v0.8.0 or later
images:
- location: "https://cloud-images.ubuntu.com/releases/22.04/release/ubuntu-22.04-server-cloudimg-amd64.img"
  arch: "x86_64"
- location: "https://cloud-images.ubuntu.com/releases/22.04/release/ubuntu-22.04-server-cloudimg-arm64.img"
  arch: "aarch64"

cpus: 4
memory: "10GiB"

mounts:
- location: "~"
  writable: true
- location: "/tmp/lima"
  writable: true
provision:
- mode: system
  script: |
    apt-get update
    apt-get install -y apt-transport-https ca-certificates curl clang llvm jq
    apt-get install -y libelf-dev libpcap-dev libbfd-dev binutils-dev build-essential make 
    apt-get install -y linux-tools-common linux-tools-5.15.0-41-generic

Kind on Lima

To run a Kubernetes cluster, I’ve been running a multi-node Kind in the Lima machine, and this has been working flawlessly so far. Cilium works great too.

Lima port-forwarding to localhost

Lima comes with automatic port forwarding for localhost so that if you run a web server on the VM on, say, port 3000, you can use your browser to it from https://localhost:3000. That example is exactly what I do if I want to run the Prometheus & Grafana dashboard set-up described in the Cilium docs.

kubectl -n cilium-monitoring port-forward service/grafana --address 0.0.0.0 --address :: 3000:3000 

This works for localhost, but what if you want to access a different IP address within the virtual machine? For example, if I want to demo exposing a service using Cilium Ingress, using Kubernetes port-forwarding would simply bypass the Ingress — and that would be missing the point.

Lima port-forwarding to other IP addresses

In a real-world deployment, services are exposed to the world using a LoadBalancer service with an external IP address. If you’re running in a public cloud like AWS, GKE or Azure, the LoadBalancer service will automatically get assigned an external IP address that you can access from outside the Kubernetes cluster. You can recreate this on your own virtual machines using MetalLB.

In this example the LoadBalancer for my Ingress has been assigned the address 172.18.255.200 but this address is only meaningful within the VM. Your laptop can’t route to it automatically as it has no way of knowing anything about the IP addresses assigned inside the VM.

But we can get traffic there using ssh port forwarding from the Mac (shout-out to my colleague Marga Manterola for pointing me in this direction!) The pattern looks like this:

ssh -L <port on Mac>:<external IP address>:<port> -o Hostname=127.0.0.1 -o Port=<Lima VM's port> lima-<VM name> 

• <port on Mac>is whatever port you want to assign (you’ll be pointing your browser to localhost:<port on Mac> )
• <external IP address>is the assigned IP address for the LoadBalancer
• <port> is the port number for the service on the LoadBalancer’s IP address
• <VM name> is the name you gave to the VM when you created it with limactl
• <Lima VM's port> is the port on which the VM is accessible from your Mac. You can get this by running limactl list:

~ ❯ limactl list
NAME           STATUS     SSH                ARCH       CPUS    MEMORY    DISK      DIR
ubuntu-kind    Running    127.0.0.1:50156    aarch64    4       20GiB     100GiB    /Users/liz/.lima/ubuntu-kind

Here, my VM name is ubuntu-kind and it’s accessible through port 50156. I can arbitrarily pick port 9999 on my Mac, and use it to access the external IP address assigned to the LoadBalancer inside the cluster, with this command:

ssh -L 9999:172.18.255.200:80 -o Hostname=127.0.0.1 -o Port=50156 lima-ubuntu-kind 

So now I can access the bookinfo service that I exposed using the Cilium Ingress.

The bookinfo example from Istio is one thing that hasn’t been officially built with ARM support yet. I was able to built most of its services easily enough with docker build, though I ran into issues building the reviews component. The beauty of a microservices architecture is that I can just leave that component out for now!

Istio has recently got ARM support built in the master branch, with support coming in the upcoming 1.15 release. That should make it a lot easier to run Cilium Service Mesh and Istio demos side-by-side on ARM machines!

On my Intel-based Macs I have been using VirtualBox and Vagrant to run Linux virtual machines for years. Using VScode to SSH “remotely” into these VMs is a great set-up for development, for me.

I recently got a MacBookPro built on Apple’s M1 ARM CPU, and my usual set-up is impossible because VirtualBox doesn’t (yet) support ARM processors. For a couple of minutes I seriously entertained the idea of returning this machine and getting another Intel-based one. But a bit of searching led me to UTM as a MacOS hypervisor that would support the M1 processor.

Here’s what I did to get myself up-and-running with an Ubuntu virtual machine running on UTM, editing code with VScode’s Remote-SSH extension.

Downloads

• Download and install UTM — you can get a free version, or pay a small amount for it to get updates and to its support development
• Download the Ubuntu Server ISO image for the version you’re interested in (I used 20.10). The Ubuntu site tends to take you to the Intel version, so make sure you grab an ARM download.

Set up the VM

I essentially followed the UTM instructions to set up the virtual machine, with a few minor differences.

• I picked 8 GB memory as hinted at by the the illustration in step 6
• Under Display set console access only (I don’t need the GUI as I’ll be SSHing into the box)
• In the Network tab, configure port forwarding so that an arbitrary port on the host (I picked 2200) gets forwarded to port 22 on the guest virtual machine.

First boot

On the first boot I did get thrown into the UEFI shell as described in the UTM instructions Troubleshooting section. Running fso:\efi\boot\bootaa64.efi as described in the Troubleshooting section seemed to work.

You then get a series of prompts about the installation process. I accepted all the defaults including downloading a new installer, except for accepting to installing OpenSSH Server. You get to pick a username & password as part of this process.

At the end of the installer process you’re asked to reboot. For me, this first reboot didn’t look terribly promising, reporting a firmware error about a image base having a bogus value. But like all good engineers my first resort was to turn it off and on again — after another reboot all looked good and I was able to log in with the username & password previously selected.

At this point you might want to check that you can access the VM from a terminal on the Mac with ssh <username>@127.0.0.1 -p 2200

VScode remote SSH

VScode’s excellent remote-SSH extension lets you access a remote machine as if it were local — not only can you edit files on the remote machine through the VScode interface, but you can also access the built-in terminal in the normal way. VScode does this by accessing the remote machine over SSH and installing an agent on it.

Once you’ve added the extension to VScode, run Remote-SSH: Add New SSH Host… and you’ll be prompted to enter the SSH command. Use the same command as you tested earlier, using port 2200 so that the connection is forwarded to the VM.

For me this results in an SSH config like this:

Host 127.0.0.1
  HostName 127.0.0.1
  User liz
  Port 2200

You’ll be able to clone a Git repo directly onto the VM from within VScode, and then work away at it as if it were your local machine!

Should you buy an M1 Mac?

The price/performance ratio for ARM is very attractive, and I’m noticing the difference. My old machine would regularly sound like it was attempting lift-off but I’m honestly not even sure whether my new laptop has fans. And every Mac app I have tried to run on the laptop has worked perfectly. But does that mean that I wholeheartedly recommend switching to an M1 Mac?

I kept having to remind myself for what seemed an embarrassingly long time that this VM can still only run executables built for ARM. And not every container image has an ARM version included. You can’t necessarily just `docker pull` and expect that everything is going to work.

Not everything will build nicely either. Everything I’ve tried written in Golang has been seamless, but I found myself trying to build something written in Node (not an area of expertise for me) and ended up resorting to my old laptop. When I bought the new machine, I figured that if I ever found that I needed an Intel processor, I still had that old one to hand – or I could always just use a cloud provider. Those options might not be suitable for everyone, or might be inconvenient. If you’re a developer you might want to think carefully about your tools, your team’s workflow, and whether you need to be able to replicate builds that are currently only being performed for Intel, before jumping aboard the M1 train.

But with such attractive pricing, I see a lot of folks moving to ARM processors anyway. This is happening not just in personal, but also in the cloud, for example with AWS Graviton processors. With this momentum, I don’t think it will be long before it’s completely normal to expect builds for both Intel and ARM as a matter of course. And then there will be no good reason not to adopt the cheaper, higher-performance option.

As an AWS Container Hero I was lucky enough to get hold of one of the new DeepComposer keyboards at re:Invent a couple of months ago. The service preview has been rolling out slowly, and I’ve finally had a chance to get hands-on with it.

The idea with DeepComposer is that you input a melody, and artificial intelligence will generate accompanying tracks that harmonize and complement the melody.

At time of writing the Music Studio interface within DeepComposer is pretty basic. You input 8 bars using the physical keyboard (or the on-screen version) but there’s no editing just now. Having recorded the melody you can download it as a Midi file; hopefully that means you’ll soon be able to upload the melody file so that you can use something else, like Garageband, to correct any errors.

Thinking that it might be unfair to saddle the poor algorithm with a melody from my own brain, I thought I’d start with something that might already be familiar: the keyboard riff from Billie Eilish’s Bad Guy. It happens to be eight bars long, which is conveniently the length of melody that you can input into DeepComposer today.

I managed to pick it out on the keyboard. With the melody in place you get to choose one of five pre-trained AI models, and then hit “Generate Composition”.

The first model in the list is “Rock” so I thought I’d give that a whirl. It takes very little time to get the generated composition back, but I can’t say I loved the results. The first six bars sound like five musicians each battling to play a different song, and then finally coming to some kind of rough consensus for the last two bars.

The “Symphony” model was marginally more successful in that my artificial players seem to be more-or-less agreed on the rhythm of the piece, if not the key.

At this point I started to think that maybe the Bad Guy riff wasn’t such a good choice as a melody. DeepComposer comes with a few well-known pieces like Twinkle Twinkle or New World Symphony to get you started, and these all have slower-tempo, more easily hummable tunes. Maybe I needed something similar? I came up with something, but I’m not sure my AI musicians really grasped what I was aiming for with this piece.

In my first few attempts the input was monophonic, but the New World Symphony option inspired me to try something different. What would happen if I put in some harmonies of my own as part of the melody? I don’t know if you agree, but to me this seemed to steer the AI in a better direction.

Based on today’s experiments I don’t think I’m about to generate the next global hit through DeepComposer any time soon, but it’s pretty interesting to play with. I haven’t as yet done anything to understand what’s going on behind the scenes other than skim over the introductions to the AI models and the DeepComposer labs. But here are a few few observations based on my initial experiments with the basic models:

• The generated drum tracks seem super-simplistic: lots of hi-hat on 8th notes for a few beats, then 16th notes for a few beats, but bass drum and snare seem very sparse even on the Rock model. This made me wonder whether a successful music generation algorithm needs a different model (or sub-model?) for drum beats, to understand the general need for more consistent repetition.
• The most successful melodic tracks seem to echo the original melody pretty closely, which sounds OK but is not very creative. I wonder if this is because the loss function might tend to zero if the generated track closely copies the original?
• Giving polyphonic input for the melody gives the algorithm a lot more clues about chord progression, and it seems to be able to take advantage of that.
• I don’t know how much my timing on the input might affect the output. I’d like to be able to edit the Midi / piano roll to make sure the notes are happening at precisely the right time, and see whether that helps DeepComposer understand the structure of the piece better.

So far I’ve only used the provided models. You can also generate your own — I’ve got one spinning up now, but I’ll come back to that later, as it takes ~8 hours to create. (During DeepComposer preview, AWS aren’t charging for the compute time it takes to create a model, thankfully!)

It will be interesting to see whether my model generates significantly different results from the provided ones. I’ll have to get back to you on that once my model is generated. Meanwhile, go listen to some better music!

Go slices, maps, pitfalls — and generics

I don’t recall how, exactly — probably something in my Twitter feed or my overly cluttered Inbox — but I recently landed on this article by Paolo Gallina about using pointers to slices.

I like Go a lot, but it does have a few shortcoming where it sets traps for programmers, and this is a big and dangerous one. Take a look at Paolo’s article, and/or the following code on the Go playground, to see what I mean.

func main() {
    slice:= []string{"a","a"}
    func(slice []string){
        slice[0]="b";
        slice[1]="b";
    }(slice)
    fmt.Print(slice)

    slice = []string{"a","a"} 
    func(slice []string){
        slice = append(slice, "a")
        slice[0]="b";
        slice[1]="b"; 
    }(slice)
    fmt.Print(slice)
}

This code prints [b,b] after the first function call, as you would likely expect. If you know your slices, you won’t be so surprised that after the second function the output is [a, a]. Not very intuitive!

To use a slice effectively you have to know that:

• a slice is implemented as a structure containing a pointer
• the pointer value can change.

A better way? Return the slice

Paolo recommends using a pointer to the slice, which is perfectly acceptable solution to the problem, though I’d like to propose what I think is a slightly better approach: if you’re writing a function that takes a slice as a parameter, include the slice as a return value. You can take this as a general guideline, or only use it when the function might append to the slice, which is when the problem can occur.

I’ve adapted Paolo’s example (and you can find it on the Go Playground here).

func main() {
    slice:= []string{"a","a"}
 
    slice = func(slice []string) []string{
        slice= append(slice, "a")
        slice[0]="b";
        slice[1]="b"; 
        return slice
    }(slice)

    fmt.Print(slice) 
}

I like this better because it’s absolutely explicit that you’re getting back the updated version of slice. And it avoids the extra pointer — I am keen on avoiding unnecessary pointers in general because they add cognitive overhead, and involve additional allocations and subsequent garbage collection, which will impact performance.

What about maps?

In many respects maps and slices look (superficially) similar, what with the use of square braces [ and ], and the common use of make to allocate them in both cases. In practice the underlying implementation is really very different. For the purposes of this post, the difference I’m most interested in is that a map is implemented as a pointer.

From this thread Ian Lance Taylor wrote

In the very early days what we call maps now
were written as pointers, so you wrote *map[int]int. We moved away
from that when we realized that no one ever wrote `map` without
writing `*map`.

I would never have found this illuminating quote were it not for this post by Dave Cheney, which you should dive into for more on how maps are implemented.

Given that a map is already a pointer, there is no need to worry about using a pointer to a map in case it changes underneath your feet.

What have generics got to do with all this?

Imagine that slices weren’t a fundamental part of the Go language, but instead they were a regular struct with methods like append(). As a Go programmer you would see the struct, with its pointer, length and capacity field values, and you wouldn’t have to be terribly experienced to recognise that all these field values might conceivably change when you called a method. And therefore, you’d be less likely to fall into the trap.

You might be thinking at this point “maybe I should just use the slice header directly in my code for extra transparency”, but it’s really not worth it. One big reason you won’t want to do this is (the absence of) generics. The nice thing about slices — and maps for that matter — is that Golang allows you to use them to store data of any type, whereas your hand-generated, artisanal slice header struct would need to specify a type for that pointer. And then you’re going to need a different set of methods for every different type you want to store in a slice. That’s going to get very dull very fast.

(Re-)learning to love slices

I still wish that Go didn’t require folks to understand the underlying implementation of slices. Perhaps I would feel better about it if there were some subtle visual clue, like the use of a different brace type, to help us all distinguish when we’re talking about a slice, an array, or a map.

I may be coming around to the idea of generics :-)

If you like this article you might also like this one on variables and functions in Go.

Go slices, maps, pitfalls — and generics was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

I use Vagrant a lot for example, to run a VM with Kubernetes as installed by vanillakubeadm. By default Vagrant sets up some SSH config so that it’s super easy to get into the VMs you run with it — all you need to do iscd to the directory holding the Vagrantfile, and then simply run vagrant ssh.

This is great, but it obscures the parameters being used under the covers to open that SSH connection — and you’ll need that information in order to configure Remote-SSH. Turns out it’s really easy!

# Change to the directory containing the Vagrantfile
~$ cd vagrant/machine

# Get the SSH config that Vagrant uses
~/vagrant/machine$ vagrant ssh-config
Host default
  HostName 127.0.0.1
  User vagrant
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile /Users/liz/vagrant/machine/.vagrant/machines/default/virtualbox/private_key
  IdentitiesOnly yes
  LogLevel FATAL

Copy the output of this into an SSH config file — I added it to my default SSH config at ~/.ssh/config. In VScode you can easily open this file, or generate a custom config file for VSCode to use, by pressing ⌘⇧P and selecting Remote-SSH: Open Configuration File…

Connect VScode to the machine with ⌘⇧P Remote-SSH: Connect to Host… and select default (where “default” is the machine name that Vagrant assigned). The first time you connect it will take a little while to download the VScode server onto the VM. Voilà, your files on the host available to view and edit inside VScode.

Bonus: if you put the config in your default SSH config file, you can now also SSH into the box from your laptop terminal with ssh default, saving you the bother of moving into the Vagrant machine’s directory.

If you’re looking for an introduction to the mathematics that make cryptography work, perhaps this list might help.

Why I’m looking for cryptography maths resources

I’m currently writing a book about Container Security for O’Reilly Media, and one of my chapters will deal with how and why X.509 certificates are used to secure connections between containers (or other entities in a distributed system). X.509 certificates make use of public/private key pairs for both identity and encryption purposes.

Now, the maths (I’m British, so I put an ‘s’ on it) of how these key pairs work is beyond the scope of my book – not to mention that I’m far from an expert. But it seems like an interesting direction that some readers might like to take. So I put out a call on Twitter.

🇪🇺Liz Rice 🎄 on Twitter

If you were looking for an introduction to maths for cryptography, where would you go?

I got some great responses, including one from Yiorgos Adamopoulos suggesting I turn the results into a blog post. So here’s what I learned:

Some classics don’t age well

Quite a few folks told me that Applied Cryptography was on their reading list at university, but it’s now considered one to avoid as it’s outdated. (We actually have a copy of this at home, and I have a vague, and possibly incorrect, recollection that during the 1990’s US ban on the export of cryptography this book wasn’t supposed to leave the country, so it was something of a badge of honour to own this book.)

Recommended reads

Instead, consider one of the following options that were recommended in response to my tweet:

• An Introduction to Mathematical Cryptography by Hoffstein, Pipher & Silverman seems to be popular undergrad reading.
• Practical Cryptography by Schneier & Ferguson came up several times, but as per schneier.com this book is now superceded by Cryptography Engineering.
• Handbook of Applied Cryptography by Menezes, Oorshot & Vanstone (also available online)
• Stallings’ Cryptography & Network Security came up a few times, and is still on the reading list for some university courses
• Aumasson’s Serious Cryptography was recommended a few times, with the caveat that it’s less theoretical so has less maths in it.
• Holden’s Mathematics of Secrets was also mentioned.

Online resources

If you want something immediate and possibly interactive, here are some options that folks suggested.

• Crypto 101
• CryptoPals looks like fun!
• MIT OpenCourseWare
• Talks by Tanja Lange
• The mere mention of the word “bitcoin” usually sets off my scepticism alarm, but I’m told that the section on Cryptography in Mastering Bitcoin is really good.

If you try out any of these books and resources, let me know what you think of them – and tell me if something good is missing!

This is a copy of an article previously published on write.as. Putting it here on Medium, as an experiment in seeing which platform gets the best reach. Will update on that later!

Pop quiz! What do you expect this code to do?

func main() {
  x := 1
  f := func() {
    fmt.Printf("x is %d\n", x)
  }
  
  x = 2
  f()
}

Try it at the Go Playground

This is a super-simplified example of something that recently came up reviewing some code at Aqua. Some function and variable names have been changed to protect the innocent.

You can refer to x inside the function f()because it’s in scope. The value for x inside f() is whatever value it has at the point f() is invoked.

But you can’t do this:

func main() {
  f := func() {
    fmt.Printf("x is %d\n", x)
  }
  
  x := 2
  f()
}

You’re not allowed to use variables before they are declared, because the compiler needs to know what type of variables it’s dealing with. That code is not OK, in the same way that this isn’t OK:

func main() {
  fmt.Printf(“x is %d\n”, x)
  x := 2
}

The important point is that the compiler needs to know the type of the variable in advance of your function, but it doesn’t need the value in advance. You just need to declare it, you don’t need to define it. This is fine:

func main() {
  var x int

  f := func() {
    fmt.Printf("x is %d\n", x)
  }
  
  x = 2
  f()
}

We had a bug that was a much more complicated version of this:

func main() {

  y := 1
  x := y

  f := func() {
    fmt.Printf("x is %d\n", x)
  }

  // Getting the right value for y
  y = 2

  f()
}

We were setting the variable x too early, before we had the correct value (though in our real-world case the variables were nested structures, not just ints, so it was harder to see the problem).

The proposed fix looked more like this:

func main() {

  y := 1

  f := func() {
    x := y
    fmt.Printf("x is %d\n", x)
  }

  // Getting the right value for y
  y = 2

  f()
}

This works fine, but it made the definition of f()quite long (remember we are dealing with variables much more complex than ints). This made it harder to read — by the time you got to the end you had forgotten that it was a function definition being assigned to a variable, and not being executed until later.

Following the principle of left-aligning the happy path, I’m a fan of keeping inline definitions short for readability. So the final version looks more like this:

func main() {

  var x int

  f := func() {
    fmt.Printf("x is %d\n", x)
  }

  // Getting the right value for y
  y := 2
  x = y

  f()
}

Who’d have realised there are 180 IBMers working in an underground bunker at Wimbledon?

IBM’s very excellent Holly Cummins invited me to take a look around and see more about the technology behind the scenes. Given my interest in cloud native, my first question was “Are you using Kubernetes?” And the answer is “yes”.

Cloud native at Wimbledon

To be honest, it’s a pretty straightforward use of Kubernetes: the Wimbledon web site is Apache / Java, running in four small clusters in the IBM cloud. Around 98% of the content gets served from cache by the CDN, so the load on the clusters themselves is actually pretty small.

But it‘s reassuring to see a familiar-looking Grafana dashboard, fed by Prometheus metrics. Cloud native technology quietly doing its job.

Artificial intelligence applied to security

Another area I was keen to hear about is security. Logs are collected by QRadar, and IBM’s Watson for Cybersecurity looks at these logs to recognize interesting patterns and anomalies that might indicate an unusual attack. Human security experts take it from there.

This is essentially a perimeter defense — looking at the messages being sent from outside the system to detect potential attackers. Imagine the defence-in-depth you’d get by combining this alongside the sort of “shrink wrap” security we provide at Aqua, where we’re detecting and preventing anomalous behaviour within the containerized application. If an attacker somehow manages to get past the outer defences, they’d still struggle to run their malicious payload.

There are some nice SOC-style screens showing world heat maps indicating where attacks are coming from, and live animations of suspicious events, but quite reasonably I’ve was asked not to share any of that information while the tournament is ongoing.

Tennis statistics and video

A lot of the interesting technology revolves around the interesting things you can do with video footage combined with data. Unlike, say, rugby or football, tennis is by its nature broken up point-by-point, and each point generates concrete statistics. Not just who won each point, but things like how long is the rally, what’s the service speed, whether the point was lost through an unforced error on a backhand, and so on.

If you’re an ex-tennis player looking to make some coin after your playing years are over, one option is to be a professional tennis statistician. This means watching matches, and recording a lot of these data points. Distance covered by each player is automatically generated from the video feed, and serve speed comes from radar.

These stats combined with the video footage enable Wimbledon to offer useful video tools to players and coaches. For example, you could look back at the match you just played and easily pull out and view, say, all the points you lost through unforced errors.

Here’s another screen that not everyone gets to see, and that takes some of these statistics into account: automatically generated recommendations for the most exciting points of the day so far. The system considers factors like crowd noise, player gesticulations, and the stats about how each point is won.

Human editors use this to help them put together an hour of highlights from the day’s play. By my calculation that’s something like 1% of the total footage, so it’s making that editorial job considerably more manageable.

A special atmosphere

I was lucky enough to be in Centre Court watching Cori Gauff win her terrifically exciting match against Polona Hercog. (If you didn’t already hear about this game: she turned it around from being behind in the second set, having already lost the first 6–3. And she’s 15 years old.) The atmosphere was fantastic — and it makes total sense that the crowd noise would be a great indicator for how exciting a point can be.

The Tour de France starts today. Anyone know if they’re using Kubernetes?

A giant thank you to Holly K Cummins, Justina Gilbert and the IBM UK team for the opportunity to see behind the scenes — not to mention watching some fabulous tennis and witnessing the unique Wimbledon atmosphere!

Vagrant machine running Centos

Here’s my Vagrantfile:

Vagrant.configure("2") do |config|
  config.vm.provider "virtualbox" do |v|
    v.memory = 16384
    v.cpus = 2
  end

config.vm.box = "bento/centos-7.6"
  config.vm.network "private_network", type: "dhcp"
  config.vm.network "forwarded_port", guest: 8443, host: 8443
  config.vm.provision "docker"
end

Put this in an empty directory and run vagrant up

Once it’s up and running, get shell access to it with vagrant ssh

Add insecure registries settings

As per the instructions on this page you need to have Docker running with an insecure registry parameter. Create a file at /etc/docker/daemon.json (you’ll need to sudo) with the following contents:

{
   "insecure-registries": [
     "172.30.0.0/16"
   ]
}

Restart Docker:

$ sudo systemctl daemon-reload
$ sudo systemctl restart docker

Download Openshift binaries

Download the version you want (I’m going for 3.10.0) from the Openshift releases page on GitHub, and unpack it.

$ wget https://github.com/openshift/origin/releases/download/v3.10.0/openshift-origin-client-tools-v3.10.0-dd10d17-linux-64bit.tar.gz

$ tar xvf openshift-origin-client-tools-v3.10.0-dd10d17-linux-64bit.tar.gz

I like to tidy this up:

$ mv openshift-origin-client-tools-v3.10.0-dd10d17-linux-64bit openshift

$ rm openshift-origin-client-tools-v3.10.0-dd10d17-linux-64bit.tar.gz

Now I have a directory called openshift

$ ls openshift
LICENSE  oc  README.md

Add oc to your path

If you’re using Openshift you’ll be running oc all the time (it’s roughly the equivalent of kubectl in Openshift-land) so you’ll want it in your path.

$ export PATH=$PATH:~/openshift

Start the cluster

Red Hat made this super simple!

$ oc cluster up

Open the console

Because of the port forwarding line in the Vagrantfile, you’ll be able to view the console in your browser at https://localhost:8443 (once you have pushed your way through a number of browser certificate warnings). You can log in as “developer” with any password.

All-in-one Vagrantfile

To make this even easier, here’s a Vagrantfile with all the installation steps included. You’ll just need to vagrant up and then oc cluster start

If you’re using VS Code you might find it convenient to SSH into Vagrant machines directly from there.