Transitioning To A More Open Technology Stack

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.


Using A Raspberry Pi To Switch On Surround Sound Speakers

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.


Introducing A New Language

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.


Network Booting A Raspberry Pi MythTV Frontend

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.


FitBit Ionic Review

FitBit Ionic

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.