30 Sep 2020
tap, tap, tap Hello, is this thing on?
I started this blog way back in 2008 and was fairly active through to 2012. Unfortunately, apart from a period in 2017, it
has been dormant since then. Working for a hedge fund, who are notoriously secretive, and having children, who are
notoriously good at sucking up all your free time, meant that blogging really wasn’t an option. Now I work for a
more open company (Ocado Technology) and my kids are a little
older, so require a bit less time, I’m hoping to resurrect my blog.
Originally I created the blog on Wordpress.com, which worked great. It was free, reliable, and easy
to use. Unfortunately, when I started writing a new post the editor had become unusable for me. Perhaps I’m an old
fuddy-duddy, but I just want to be able to write my text, add some simple pictures, and have the editor get out of my way.
Sadly, it quickly became clear that WordPress was going to get in my way, so it was time to give the blog a new home and a
new lick of paint.
For many years I’ve had a Linode server, which I use
to host a few small websites. I’ve always been a fan of Markdown, so a static site generated by Jekyll seemed like the obvious choice.
Read More...
22 Nov 2017
Docker is a great tool for running your applications in a consistent and
repeatable environment. One issue that I’ve come across occasionally is getting data into and out of the
environment when it’s running.
In this post I want to talk about exposing ports that are published by applications running inside a
container. When you start up the container it’s pretty easy to configure the ports you want to expose using
the --publish or -p parameter. It’s followed by the internal port number, a colon, and the
external port number. For example:
docker run --publish 80:8080 myapp
This will publish port 80 from inside the container as port 8080 on the host.
This works great if you know want ports you want to expose before you run the container. Once it’s running,
if you decide you need access to a port, you can’t expose it. Unless that is, you cheat.
Read More...
15 Nov 2017
I’m currently working with some large Java monoliths which talk to each other over ActiveMQ. There are several
aspects of the architecture that I’d like to change. Certainly, new production environments (Kubernetes, etc)
mean that monoliths are not required because of the overhead of deployment, and the benefits of easier testing
and more modular architecture mean that I think the expense of migrating to smaller services will be well
worth it. With such an established code base though, the question I’m grappling with is how can we transition
to a better, more open technology stack without needing to rewrite from scratch and do a big bang deployment.
Currently I’m toying with the idea of writing an ActiveMQ to Web Sockets bridge. Web Sockets are a way of
emulating a direct TCP connection in a web browser, although a more normal use case is to send and receive a
stream of JSON encoded events. Although Web Sockets were created for use in browsers all languages have
libraries available which will allow you to connect to a server.
ActiveMQ natively supports connecting over Web Sockets, so why would I propose building a bridge application?
In our case the messages being exchanged are binary encoded, so you can’t decode them unless you’re running
Java and have the same library used to send the messages. By building an application to act as a bridge you
get much more control over the Web Socket API than if you use the native ActiveMQ implementation, so you can
tidy up the JSON representations you use and easily make any other improvements to the API that you want.
Read More...
08 Nov 2017
In a previous post
, I talked about network booting a Raspberry Pi MythTV frontend. One issue that I had to solve was how
to turn on my Onkyo surround sound speakers, but only if they are not
already turned on.
I already had an MCE remote and receiver which can both
transmit and receive, so it is perfect for controlling MythTV and switching the speakers on. There are plenty
of tutorials out there, but the basic principle is to use irrecord to record the signals from the
speaker’s remote control, so the Raspberry Pi can replay them to switch it on when the Pi starts up. In my
case, I needed two keys, the power button and VCR/DVR input button. Once you’ve recorded the right signals,
you can use irsend to repeat them.
Initially, I had it set up to always send the power button signal on boot. This had the unfortunate
side-effect of switching the speakers off if they were already on, for example, if I had been listening to
music through Sonos before deciding to watch TV.
Read More...
01 Nov 2017
At work, there is a discussion going on at the moment about
introducing Kotlin into our tech stack. We’re a JVM based team, with the
majority of our code written in Java and few apps in Scala. I don’t
intend to discuss the pros and cons of any particular language in this post, as I don’t have enough experience
of them to decide yet (more on that to come as the discussion evolves). Instead, I wanted to talk about
how you can decide when to introduce a new language.
Programmers, myself included, have a habit of being attracted to anything new and shiny. That might be a new
library, a new framework or a new language. Whatever it is, the hype will suggest that you can do more, with
less code and fewer bugs. The reality often turns out to be a little different, and by the time you have
implemented a substantial production system then you’ve probably pushed up against the limits, and found areas
where it’s hard to do what you want, or where there are bugs or reliability problems. It’s only natural to
look for better tools that can make your life easier.
If you maintain a large, long-lived code base then introducing anything new is something that has to be
considered carefully. This is particularly true of a new language. While a new library or framework can have
its own learning curve, a new language means the team has to relearn how to do the fundamentals from scratch.
A new language brings with it a new set of idioms, styles and best practices. That kind of knowledge is built
up by a team over many years, and is very expensive both in time and mistakes to relearn.n Clearly, if you
need to start writing code in a radically different environment then you’ll need to pick a new language. If
like us, you mostly write Java server applications and you want to start writing modern web-based frontends to
your applications then you need to choose to add Javascript, or one of the many Javascript based languages,
into your tech stack.
Read More...
