I bought my first RTL-SDR receiver a little over a year ago and was
soon up and running with FlightAware's dump1090. Shortly after that I
signed up with Flightradar24, downloaded and installed the x86_64
package and started contributing. ADS-B Exchange has a script to
bootstrap Linux installation and that too made it easy to get up and
running. It was only when I created a second ADS-B feeder site at a
new location that I appreciated how onerous maintaining all the
installs and configuration could become.
Somewhat ironically I could not contribute to FlightAware either since
PiAware, as the name implies, only supports the Raspberry Pi and not
x86_64 Linux. I was similarly disappointed to find out that RadarBox
only has Pi and Windows feeders.
While investigating various solutions I stumbled across the work of
Mike and his fellow SDR Enthusiasts. They have done the hard yards and
bundled the RadarBox rbfeeder and other clients into docker images
supporting x86_64, arm32 and arm64 architectures - either by compiling
native binaries or emulation through qemu. The docker-compose examples
made it all too easy replace to my manual installs with
docker-flightradar24 and docker-adsbexchange then ditch dump1090 for
docker-readsb.
This was swiftly followed by the addition of docker-radarbox,
docker-piaware and docker-planefinder feeders. Maintaining just a
single docker-compose.yaml in each location couldn't be more simple.
Deployments have been quite robust with very little intervention
required. The PiAware client occasionally loses connectivity to
FlightAware and requires a restart. The connection failure is picked
up by the healthcheck.sh script so I've added
Will Farrell's docker-autoheal into the mix to automate the restarts.
posted by James Gemmell on Sat, 06 May 2023 at 20:47
| permalink
| tags: adsb, docker, rtlsdr
Loggers are not constants, they are mutable objects.
I am currently working on a legacy Java/Spring codebase littered with
calls to LOG and LOGGER, proudly declared as static final. There
appear to be sound justifications for adopting this convention
(besides avoiding Checkstyle complaints) but sometimes it is useful to
reflect on how we ended up here.
Loggers have traditionally been declared static as their construction
was considered expensive and therefore justified a singleton
status. Times have changed along with coding conventions.
Most of the applications in this particular codebase are of the
vanilla Spring application variety, namely singleton services
processing value objects on multiple threads.
Loggers used by service singletons are obviously singletons themselves
and clearly don't warrant this premature optimization. Loggers in
value objects shouldn't be there.
A grey area exists for short lived domain objects, say some business
logic encapsulated in a function that would log input arguments and
the result. The solution is to have the object factory inject the
logger at object construction time. Dependency injection ensures that
logging is just another service, singleton or not.
A further argument against using static final loggers is the increased
use of semantic logging. The implications are that if, in order to
unit test the logging feature, the object under test requires the
static mocking capabilities of PowerMock then you're doing dependency
injection incorrectly or not at all.
In another example, this practice was followed to the absurd extreme
with SimpleDateFormat. Not only is this not a constant but the methods
are not thread-safe. Declaring it as such merely increases the
likelihood of multiple threads executing the unsafe methods
concurrently, even more so when running in a multi-application
container.
The Google Java Style guide suggests some reasonable conventions for
constant names.
Forgetting why we started doing it in the first place and blindly
following the static final Logger convention is, at best, premature
optimization and, at worst, a shining example of donning the
coconut headphones.
posted by James Gemmell on Tue, 24 Nov 2015 at 22:37
| permalink
| tags: java, spring
Packt Publishing's Spring Data is their latest offering in the now
familiar cookbook format covering the Spring Data support for JPA and
Redis. The Kindle version was well laid out, which can be difficult
for technical texts.
The cookbook uses a simple domain model for contact data to
demonstrate the creation of a CRUD database and then steps the reader
through creating operations using Native SQL, Java Persistence Query
Language (JPQL) and the Criteria API. What I found most useful was
being able to compare and contrast the pros and cons of each approach.
This section may be less suited to the novice it assumes a working
knowledge of JPA. The cookbook could not be treated as a JPA tutorial
or reference as other texts have greater coverage using more complex
data models.
The chapters on Redis start with step-by-step instructions on
configuring the connection to a Redis service using the Jedis, JRedis,
RJC and SRP connectors. It then proceeds through to the implementing a
CRUD application for the contact data and adding publish/subscribe
notifications for updates.
By far the most beneficial thing I found in these chapters was how to
use Spring Data Redis to add transparent caching support to a JPA
repository.
Spring Data can be bought from Packt Publishing and Amazon.com.
posted by James Gemmell on Sat, 19 Jan 2013 at 13:46
| permalink
| tags: java, jpa, redis, spring
The Cookbook fills a long-standing vacancy on the Spring bookshelf and
plays a useful complementary role to the online
Spring Web Services reference documentation. Considering the volume
of publications, Spring WS is by far the poorer cousin of the Spring
core, persistence, MVC, batch and integration lineup.
Over the last two years I've used Spring Web Services extensively in
the implementation of a multi-operation web service facade to a
foreign exchange dealing system in a large Australian bank.
I wish I'd had this book when I started the project. The WS examples
from SpringSource are great, but they don't come close to
demonstrating the richness of the platform's capabilities. The
Cookbook's recipes and the accompanying sample projects cover just
about every combination of transport and object-XML mapping that
you're likely to use (SOAP over HTTP and JMS with JAXB2 and XMLBeans)
and some of the more esoteric (SOAP over e-mail and XMPP with JiBX and
MooseXML.)
Both XWSS and WSS4J for security are dealt with comprehensively. I was
pleasantly surprised to find a chapter dealing with JAX-WS and Apache
CXF as well as creating RESTful services, using Spring MVC. Testing
using Spring's MockWebService as well as TCPMon and soapUI also get
their own much needed chapter.
As you would expect of any cookbook, this one doesn't read easily
cover to cover, and the recipes can appear repetitive at
times. In-depth coverage has been sacrificed in favour of
breadth. However, in my opinion, this is the Cookbook's strongest
selling point. The wide range of subject matter allows the reader to
easily explore the featured technologies and make educated evaluations
and comparisons.
I find the Spring Web Services 2 Cookbook a worthwhile addition to my
bookshelf. The book can bought from Packt Publishing and Amazon.com.
posted by James Gemmell on Tue, 15 May 2012 at 21:00
| permalink
| tags: java, soap, spring
During peer code reviews I have sometimes observed that there is a
preference for programmers to interpret errors or exceptions as part
of the error handling process. Instead of reporting what caused the
error, an interpretation is applied and why the error occurred is
reported instead.
As an example, an exception such as "connection failed" is reported
as "the server is down". This is, quite clearly, a naive
interpretation. There may be many other reasons as to why the
"connection failed"; the connection credentials may be incorrect,
there may be a network fault, the service application may not be
running or a solar flare may be affecting your Wifi. Under these
circumstances, all you can safely assume about the situation is that,
well, the "connection failed".
The example above seem obvious but it becomes even easier to make the
mistake when reporting business exceptions from a web service. When
required to handle a particular error, the programmer often has to
rummage through a toolbox of available business exception codes and
apply the one that fits best. More often than not it doesn't.
The importance of getting this right may only become apparent after
that prolonged phone call with the irate user who insists that your
"server is down" when you know perfectly well that it isn't.
posted by James Gemmell on Wed, 01 Jun 2011 at 21:14
| permalink
| tags: java, soap, spring
RSS 2.0
