I’ve successfully deployed my SpotViz app on WildFly running locally and tested running a visualization playback of FT8 signals received during a whole day, from 9am to 10pm. It’s interesting to see the propagation move from my location on the US West coast out to the East coast, and then gradually move West during the day, following the sun, until the propagation dies out on 20m completely around 10pm.
Here’s a screen capture of the playback:
Next up, I’ll be setting this up hosted on a VPS somewhere, and start working on some of the bugs in the UI.
A few years back I built an AngularJS webapp for visualizing JT65/JT9 spots over a period of time, logged as you run the WSJT-X app to decode FT8 signals you receive at your station. At the time I had it deployed on RedHat’s OpenShift, running in a couple of ‘gears’: one for JBoss hosting a REST API backend, a queue and MDB for processing uploaded spots, and one for a MongoDB database to store the collected spot info. Unfortunately the ‘bronze’ basic plan which was an incredible good deal for hosting apps at the time (at around $1 a month if I remember right) was discontinued, and the replacement plans were multiple times the cost, so I discontinued the app and didn’t redeploy it again after that.
At some point thought I was planning on taking another look at deploying it elsewhere, and if I’m going to pick it up again, I might as well take a look at refreshing the architecture. Here’s what the original v1 deployment looked like:
For personal projects I typically build them using some api or technology I want to get more familiar with. I remember at the time I had a need to refresh myself on JAX-WS SOAP based webservices, so the client that is monitoring the WSJT-X log file and uploading to the serverside for processing is a generated JAX-WS client to a webservice deployed in front of a queue; it receives the messages sent from the client and adds them to the queue for processing. If I had to refresh this part there’s no real need for this to be as heavy as JAX-WS and could be simpler with a simple REST api, so that’s probably how I’ll update that part.
I’m interested in something like Apache Kafka can be used to process high volumes of incoming data, so this might be a good refresh for the serverside queue and MDB.
I remember putting a lot of time into building my animated map display of received spots in the AngularJS app. This was back in 2015 I think, so this could probably do with a refresh to at least the latest/current Angular version, which would be a considerable rewrite I think. I’ll take a look.
Anyway, I haven’t run any part of this even locally in development for years, so that will be my first steps, get it up and running, and then start incrementally updating some of the parts.
This project is related to my recent experiments with getting WSJT-X and a SDRPlay RSP2 running on a Raspberry Pi, as a low cost FT8 monitoring station, so now that part is up and running, time to work on the software side again.
I’ve been learning some React and Flux. You don’t have to develop React apps with ES6, you can still use ES5, but I think having a library that can be used (or has been over the past couple of years) with two different languages with differing syntax and quirks, and is supported via bewildering layers of complexity like transpilers and webpackers and the like, it does nothing to help developers who are just getting started.
The problem is, you start reading articles and tutorials and initially you’ve no idea that ES5 syntax is not the same as ES6, so you start inter-twining concepts from both and finding out that even copying snippets of using React apis using ES5 into ES6 classes does not work (for example). At least in the Angular world they made a clean break when introducing Angular 2 which can be developed using TypeScript and other languages. The two frameworks are obviously and deliberately different.
I don’t think this is entirely React’s fault. It’s more to do with browsers not natively supporting ES6 (yet), and hence the need for transpilation from ES6 source to ES5 for runtime. Just to get Babel and Webpack setup and configured is a significant task. True, you can use a starter project template that’s preconfigured and ready to go, but I like to know how to do things myself so I have the understanding of what I’ve got, rather than working with a black box of magic that I have no idea how to fix if it goes wrong.
There is no denying that the JavaScript world right now is complex and diverse. It’s very complex. It’s also growing and changing quick (just look at the new module trends for JavaScript modules shared via the npm repository – it’s outgrowing every other language by far, in rate of growth and sheer numbers of modules – e.g. take a look at ModuleCounts). There’s so much going on and changing that the phrase ‘JavaScript Fatigue‘ has been coined to describe what it’s like to try and keep up (click that link or Google that for yourself – there’s over 1,000,000 hits right now, which tells you this is not an isolated feeling among just a few developers). The article ‘How it feels to learn JavaScript in 2016‘ attracted a huge amount of attention this year, and many followon discussions, but there’s no smoke without fire.
Which brings me to my question. Ten years from now will we look back and say:
‘Wow, Facebook React and Flux was so ahead of it’s time. It was a remarkable approach to web development’
or will it be more like:
‘Wow. Facebook React and Flux. Why on earth did we think that was a good idea?’
