Update coming
The release I’ve spoken about on this thread, and on others is just about ready to go. It has undergone substantial testing, including via the toughest test suite there is, Andrew @VK1AD who has this uncanny knack of finding code paths as yet unexplored and providing extraordinarily good bug reports. Many thanks to Andrew.
Over the coming days, we will gradually shift people across to the new site (our hosting allows us to scale which traffic goes to old and new sites). This is to allow us to observe how the new systems hold up under increased load (something that’s not as easy to test in a realistic manner) and back things out easily if the brown stuff makes contact with the air conditioning.
So, what is the big noise about?
New backend API
The major driver for this is to bring a new backend into play to eliminate some of the stability issues we’ve been having on the older API. The older API will hang around for a bit, but for those who are using api-db (and long accepted that I can change stuff at will and a moment’s notice), you may need to change hosts and endpoints in the coming weeks and months.
The new API provides for better scalability too, as we can easily add more compute in the event the load is higher than anticipated. We have additional compute as a result of this, which should help with speed under load.
We’ve also implemented a couple of performance approaches that should also speed up uploading and verifying of QSOs into the database. I can’t quantify exactly what percentage improvement we’re getting, but comments from our testers include “Hmm, much snappier than I was expecting”, which from Andy is high praise.
The number of bugs and cosmetic changes identified and fixed is too many to list here - but some of these have been around for a long time, such as the Completes page not working with filters, and the fixes are across both the front end display and the backend API. Some of the backend queries have been optimised and made more performant. I’m reasonably sure I’ve eliminated the horrible [Object object] display bugs (famous last words…). So progress forward, anyway.
FLE import support
We now have the ability to directly import FLE text files into SOTAData3, so you no longer need to convert to ADIF or CSV via FLE or FLEcli. The normal FLE syntax should be fine, with an additional benefit that you can add in more of the header commands (like mysota, date, etc) to enter multiple activations in a single file.
There are also options to copy WWFF/POTA references into the comments field for SOTA, and also any grid references.
To try it out, click on the Import FLE button when uploading:
Needless to say, I expect there to be bugs from this, but it’s been tested by Josh @WU7H and he’s ecstatic about it. If you use features outside of Josh’ normal workflow, we may exercise code paths hitherto unexplored.
New Badges
We’ve added the following badges:
- Additional Star Wars themed badges for activations on the 4th of May. We now have the Padawan, Jedi, Jedi Master and Obi-Wan badges for 2, 3, 4 and 5 years of activations and chases on the 4th of May.
- Height based badges, for chasing and activating summits with heights of 1km, 2km, 3km, 4km, 5km, 6km, 7km and 8km (the latter two not yet having summits in the database to claim), and a Low Rider badge for activating or chasing a summit below 200m in height.
- DXCC badges for chasing. This is based on the DXCC entity of the association, and is awarded for chasing 10, 25, 50, 100 (Century Club) and 150 DXCC entities. If you activate a border summit in another DXCC - say a DL summit from the OE side, you’ll give chasers credit for the summit DXCC (DL), not your actual location. I make no bones about this because it’s much easier to calculate than trying to work out actual DXCC across an entire log, so if anyone has a problem with it, tough - I write the code, I choose the rules :D. There’s also no activator equivalent yet, as that requires me to post-process every QSO in an activator log, and I don’t think that’s a good use of compute at this point, but I’ll probably get there eventually.
These badges will become available to you when you submit your next log via SOTAData3, and only for those using the new version.
Next steps
I’ll make the first adjustment to our traffic on or around 0000 UTC on 31 August. At this point, approximately 20% of people will start using the new system. If everything goes smoothly, no one should notice any difference, other than a new upload option, some new badges and hopefully some more stability. Once you are allocated to the new system, it should be persistent and you get the same branch each time.
If I notice anything off with the rollout, I’ll remove the traffic split and point back at the main system, but if it’s all going smoothly, I’ll increase the ratio of people using the system over the coming days, with the aim that everyone is on the new system around later Saturday.