I am involved in the testing of a new SOTA related software, and the MT have suggested I ask for some Beta testers here on SOTAwatch.
The program is a “web application” ( Web application - Wikipedia ) that is expected to run correctly on any device equipped with a modern browser (PC’s, tablets, smartphones, …).
The application displays the recent SOTAwatch spots and
SOTAwatch filter needs to store your filter choices, and does it using “cookies”.
The message “LocalStorage is not working!” is its way to tell you that it cannot store “cookies” on your device, and therefore cannot remember what your choices are.
This can often be resolved by adjusting some settings: see the SOTAwatch filter Frequently Asked Questions on
If you use nice explanatory text error messages you only have to translate them into other languages. So the correct response is to either give an error number or crash. Or better still, an error and then crash when the user hits the OK or Continue button.
Back in the prehistory of personal computers, a small 2 or 3 digit number would be fine for errors. Now with the ever increasing expansion of software, or bloatware as we call it, error numbers should be 64bits long and in hexadecimal. Although for a laugh using octal keeps us old-timers amused and confuses the spotty youths.
These message were brought to you by the team that developed an operating system where the START MENU is the place to go when you want to finish working.
Now that we know the error message shown when the cookies are not enabled on the device is unclear (and will be changed soon), are there other comments, remarks or suggestions ?
Most of the items on the wish list for SOTAwatch filter are now implemented, including the filter on points and comments (like ‘test’, ‘ignore’, ‘RBNgate’).
The alerts could be filtered too, but this would require a separate development. I am not sure at this stage how many people would actually use a filter on the alerts, but here is a good place to request this feature
All feed-back about how the spots are displayed on various devices and screen sizes has been taken into account, and the manageable issues have been resolved.
I think Christophe is aware that are going to be changes to SOTAwatch but others may not yet be.
There is an RSS feed of spots from SOTAwatch so it’s quite trivial to be able to handle spots in your own software, grab the feed, see what’s changed, parse the XML and import the data you want into your own domain. Job done! There is no easy way of handling alerts, you need to scrape the screen. Everyone who has written a screen scraper knows how naff that is. With the changes to come it’s probably not worth the effort to write an alerts scraper when it will be changing soon. (Don’t ask when!)
The new SOTAwatch will have a proper API for applications to use to fetch information about what is happening and will be the correct way to get the info out of SOTAwatch.
Now maybe some people will still write an alert scraper, which is fine and dandy but at least they should now be aware that it may change and they will need to change their own software. Forwarned is forarmed, as they say.
There is, yes, but as far as I am aware it is undocumented and hence just as risky as screen scraping - possibly more so as even the URL is a hostage to fortune.
It’s actually not much better than screen scraping. The key data comes back as a single unstructured string which still needs reverse engineering and ad hoc parsing to extract the components. You get less information (e.g. activator name missing). It seems to be undefined which spots you will actually get back.
On the plus side there is at least a full timestamp rather than just the time, but it comes as text and would need parsing to convert it to a value that can be processed.
So for the Twitter feed I decided to cut out the middle man and scrape, ugly as that is.
The new SOTAwatch will have a proper API for applications to use to
fetch information about what is happening and will be the correct way
to get the info out of SOTAwatch.
I look forward to this. Will there be a preview or will we have to play catch-up?
The key data comes back as a single unstructured string which still needs
I pointed an Python RSS library at the RSS URL and get a nice structured dictionary of data in all the correct data types in the right places. Simply iterate over the dictionary and as they say “my name’s Robert, I’m your dad’s brother”. I gave up rolling my own solutions to standard problems a while back, life’s too short to keep reinventing the wheel. And anyway, I’d probably do a rubbish job and end up with a square wheel.
I’d certainly not like to handle the raw data but there again that’s the joy of these soft languages like Python (or Ruby or Lua or Groovy). They either have suitable methods and containers for the data in the standard library or there are 3rd party libraries where the hard work is already done. I know you happen to use Perl and I’m sure there’s something available. Personally, I never got on with Perl, to me it’s like Forth, unreadable. But that’s just me, the actual language used doesn’t matter, it’s whether it has the features needed to make the job painless. In the case of RSS feeds, the Python library is excellent.
As to a hostage to fortune. It doesn’t matter whether the API is documented or not, it can still change forcing everyone to adapt. Even if there’s a promise it wont change!
Will there be a preview
I don’t know as it’s not really much to do with me. I’d expect there to be an initial version to encompass what is available now so that people can move to that with evolutionary changes to come.
