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...
25 Oct 2017
When we moved house earlier in the year I wanted to simplify our home theatre setup. With my son starting to
grow up, in a normal house he’d be able to turn on the tv and watch his favourite shows without needing us to
do it for him, but with the overcomplicated setup that we had it would take him several years longer before he
could learn the right sequence of buttons.
I’ve been a MythTV user for well over ten years, and all our TV watching
is done through it. At this stage with our history of recorded shows and a carefully curated list of recording
rules switching would be a big pain, so I wanted to try and simplify the user experience, even if it means
complicating the setup somewhat.
I had previously tried to reduce the standby power consumption by using an
Eon Power Down Plug, which
monitors the master socket and switches off the slave sockets when the master enters standby mode. This works
great as when the TV was off my Xbox and surround speakers would be switched off automatically. The downside
is that if I want the use the speakers to listen to music (they are also connected to a
Sonos Connect) then either the TV needs to be on, or I need to change the
plug over. Lastly, because I was running a combined frontend and backend it wasn’t connected to the smart plug
(otherwise it wouldn’t be able to turn on to record.) If you turned the TV off the frontend would still be on,
preventing the backend from shutting down for several hours, until it went into idle mode.
Read More...
18 Oct 2017
Since I received my Pebble Steel back in 2014 I knew I never wanted to go back to using a normal watch.
Having notifications and apps on my wrist was just too useful to me. I skipped the Pebble Time, but when the
Time 2 was announced I happily put in a preorder. Unfortunately it was not to be, and Pebble folded and was
sold to FitBit. If Pebble
wasn’t able to survive then as an existing FitBit user having them as a buyer is probably the the best
option.
The idea of FitBit’s scale and expertise in building hardware, combined with Pebble’s excellent developer
platform was an enticing prospect. Rather than switch to an Apple Watch (or Android Wear, although that would
have required a new phone) I decide to wait for the fruits of the combined company’s labour to be released.
I was getting a bit itchy, and my trusty Pebble Steel was showing it’s age, but eventually the
FitBit Ionic was announced. A few days before the official release date my
preorder arrived. It’s now been two weeks of wearing it nearly 24/7, so it seems like a reasonable time to
post my thoughts.
Read More...
