Other SOTA sites: SOTAwatch | SOTA Home | Database | Video | Photos | Shop | Mapping | FAQs | Facebook | Contact SOTA



Here follows a summary of what has kept me entertained for years and years now:

A: I love SOTA.

B: Good, we are pleased you love SOTA.

A: I love it, but I want you to make a major change to it.

B: We will bear that in mind.

A: Amateur radio awards scheme XYZ already has this feature.

B: May we suggest you participate in amateur radio awards scheme XYZ as well then.

A: No, I don’t want to. I just want to do SOTA, but change it to be more like XYZ.


Its important to remember here that your ideas are not being rejected, but rather stalled for the priority of bringing associations online.

Comparatively, I would rather have more choice ( and more activation’s in other regions around the world) then have a few extra nerdy features built into a website. The DB works for now, yes ADIF and other features would be brilliant.

I like Gerald’s point in a previous unrelated topic about instant gratification, sometimes its good to wait for these things…

That’s a part of life.

If I am being ultra nerdy Rob, I could complain the the SMP doesn’t work very well on my Andriod smart phone, sure I know if I wasted several hours of my time messing around I’d get something to work. I choose to prioritize on more important matters.


:+1: I go with that Tom. GMA gives me an alternative view on what I have achieved by combining SOTA with the HuMPs that I have activated and chased… and I can include the GMA summits that I have chased as well. I use it as an all-round summing up of my activities.

I don’t get this “us and them” attitude. Surely at the end of the day we are all people that love amateur radio from the hills and mountains.


That’s a fair comment, but: the SMP was never designed to do that, and I have no plans to implement a version optimized for a tiny screen, although I have played with some ideas in that direction. The SMP does what it was designed to do, in what I hope is a user-friendly way.

It’s not the ADIF entry I’m talking about, that’s just a distant nice-to-have. It’s actually about designing a user-friendly interface, rather than a programmer-friendly one. It’s about things like, for instance, the situation where the user has to upload a CSV file TWICE to the database if that file contains S2S contacts. That’s crazy! - it wouldn’t be at all difficult to write a piece of code to check, on a single upload, if any particular line in the CSV file contains S2S details, and write out to the S2S data tables at the same time as writing to the ordinary activations tables - one upload, job done.

To do it the way it is at present is an imposition on the user and - if I may be so frank - a sure sign that the programmer cares little whether the user is inconvenienced by having to upload the file twice - those pesky users can wait a few years until the new, updated version of the database is rolled out. Ditto with the user having no means of editing QSO details in the database, except by editing a CSV file with the details, and uploading it again, possibly even twice! It’s a situation not so far removed from having to create punched cards with the data on them, and post them to some PO box in the far north of Scotland, and wait for somebody to feed them into an old IBM punched-card reader.

YMMV as always…


Very much so Rob.
I like to see where I am going and the SMP is great.
Night night and thank you.


Reading that arrogant diatribe makes it easy for me to understand why Andy gets a bit fractious from time to time. I wonder what you think you were trying to accomplish? Now can we keep the discussion a bit more friendly or do I as moderator have to pull the plug on it?


And … we can do no wrong folks! It’s all down to those arrogant SOB’s out there. Good luck with that attitude.


You really like to push your luck, Rob. The database is not my responsibility, but the reflector most certainly is. Have you ever read the Acceptable Use Policy? Just to remind you, here it is as given on the website:

"In order to maintain the facility for the above stated purpose and to prevent it being degraded for the vast majority of users, some moderation of posts is occasionally necessary. A post is likely to be removed if it is:

Over argumentative
Inappropriate to the purpose of SOTAwatch
Infringing copyright

Would you deny that your post and your rejoiner above were both discourteous and offensive? well, whatever your opinion, I’m the Moderator and mine is the one that counts. They were. Now you will keep your posts courteous or you will suddenly find yourself unable to post on the reflector. Don’t think that I won’t do it, there are several people who thought that they could post whatever they liked and to Hell with the Moderator. They aren’t about any more.


I mean, you DO realise that the “arrogant SOB’s” is me (us out here)?? - right? Not YOU and the MT?? RIGHT???


I most assuredly would deny that, Brian. Twenty-five years of programming and creating graphical user interfaces for a multitude of users on PCs and for the web has taught me a thing or two about such matters; heck, I was producing database-driven PC applications back in 1992, and dynamic user-friendly and user-interactive database-driven web applications as early as 1994. I know what I’m talking about when it comes to such matters, and if I see a web application that plainly has little regard for the user, then it HURTS me to see it, and I call it for what it is.

If you want to describe a wake-up call to get things right as being discourteous - go ahead, be my guest. If such remarks cause offense, then, well, it takes two to tango.


That will not do, Rob. I know little about the areas of your expertise, nor do I need to know anything about them. I am tasked with keeping the reflector a friendly place for the SOTA community, with keeping a lid on tantrums, diatribes, rudeness and the sort of general nastiness that abounds on eHam or the Zed. When wearing my moderator hat I do not care what you or others think about the database, I am here to prevent the discussion taking place in immoderate terms - hence “moderator”.

A “wake-up call to get things right” need not be discourteous or offensive, but this one most assuredly was. Its time to stop digging.


Frankly, Brian, I couldn’t care less any more what happens from here on in.


Sleep on it, Rob. Perhaps tomorrow you will see that I am only doing what I am supposed to be doing.


This comment is not worthy of an experienced programmer. Very few data systems and no commercial ones that I came across while working in IT allow users to directly modify data. Such access provides opportunity for fraud and misrepresentation.
This also fails to allow for the fact that the people involved actually have jobs to do and SOTA is fortunate to have their expertise.



Rob, part of the problem is the underlying assumption that we in the MT don’t care about user experience. As someone who has spent 11 of the past 12 years working in a series of roles where my primary responsibility is to deliver awesome customer experiences, I find that particularly galling.

Unfortunately, the world is not split into the white of customer experience and the black of people who don’t care, neither in the real world, nor in the SOTA MT. The main challenge for us in this case is a function of time versus functionality. Do we spend time improving the entire IT infrastructure for the better of SOTA, or fixing a function that the folks now running IT inherited from the folks no longer running IT, that hasn’t really received a bunch of complaints until now?

As I’ve just posted, there’s a metric scadload (0.454 imperial scadloads) of work for the IT team for the next year, and to assume we’re not customer focused is both wrong and a little hurtful.

In short, for everyone out there, we will take feedback and feature requests, and action them as we can.

Now this is not aimed at you, Rob, but is a general statement. What we get upset about is the way that feedback is often given. Assumptions are made about our intents, motives, or our technical capabilities. Often, we wear the blame for inherited problems, or there’s a very good reason why something has been done that way, or it was done that way because it made perfect sense to do it that way in 2002, but it’s now 2017 and SOTA is 100+ associations and worldwide, but it takes time to remedy the situation.

I was accused of tolerating regression on RBNHole when in fact I was at that very point spending vacation time writing a newer, more stable version, running on servers that I, not SOTA, pay for. I didn’t feel sorry about snapping back at that. Thankfully, the vast majority of feedback we receive is positive, constructive and used to improve SOTA.

Are we blameless? Of course not. From the MT side, we’ve not been open enough about what our workload is like and what we’re working on, and that, as you’ve probably already seen in the other thread, stops today. I will commit to providing at least yearly updates on what the IT group will be focusing on in the following year. I will endeavour (although not commit) to providing further updates throughout the year. Progress should be self-evident, in any case.

But, please, do not assume that we are either incapable of solving the problems or maliciously hiding under the bridge delighting in the perceived mediocrity of our systems, ignoring any and all feedback with a delighted cackle as the email burns its way out of our inbox and into the bin. There is good technical skill in the IT group, and there is a furious desire for improvement.


How can I help the site accept ADIF logs? I put together the first search engine support for XML and I worked on an XML database (MarkLogic). I can also spell SGML, which is the pre-3.0 ADIF format.

I presume we want to take an ADIF file, strip out the SOTA-relevant fields and make two CSV files, one based on the SOTA_REF field and one based on the MY_SOTA_REF field.

I prefer Python but I’ve written production code in Concurrent Euclid, so I’m pretty flexible. PHP is vile, but I’ve written prod code in that, too. I’m learning Go, so that’s good, too.



We’re not really set up at this point to accept code or pull requests, although we intend to change that. The code is ASP.NET. I think the logical path at this point is to take ADIF2SOTA and merge it in from there, but to be honest, I haven’t thought much about it.