I’m a senior software engineer. I’m full stack. Python, Perl, C#, SQL, ReactJS, Nextjs, JS, etc. I’d love to pitch in, if you need some lightening of your load.
Check out my profile on LinkedIn Tomas Hood - HFRadio.org | LinkedIn
I’m a senior software engineer. I’m full stack. Python, Perl, C#, SQL, ReactJS, Nextjs, JS, etc. I’d love to pitch in, if you need some lightening of your load.
Check out my profile on LinkedIn Tomas Hood - HFRadio.org | LinkedIn
Thanks for the offer, Tomas!
The HamAlert backend (spot acquisition, trigger matching, alerting) is based on Node.js with a MongoDB to store all the user/trigger info. The web frontend uses some PHP on the server side, and an ancient (by 2024 measures) client side JS templating engine called JsRender with some (equally old) Bootstrap version. The HamAlert iOS/Android app is built with Apache Cordova and Onsen UI.
My idea is to eventually rewrite the backend to make it scale better, splitting up the various tasks (gathering and preprocessing spots from various sources, matching against triggers, rate limiting, sending out alerts), which are currently done by a monolithic application. Perhaps the performance of the trigger matching (which already makes extensive use of hash tables and set intersection in native code for reasonable performance) could also be further improved, e.g. by rewriting it in Rust, or by further algorithmic optimization. A message queue like ZeroMQ could connect the components. Finally, the web interface could be rewritten with a more modern framework like Vue.js coupled with a suitable UI component library.
I’ve been thinking about making HamAlert a community/open-source project, to also reduce the “HB9DQM bus factor”. Perhaps it would be best to start a new project (HamAlert NG?), taking the time-proven parts from the existing code base and implementing the rest from scratch. Ideally there would be a team of 3-5 developers to work on it, to split the work and benefit from individual expertise.
What are your thoughts?
Wow! I would love to participate in such a project. I have many thoughts.
I am well-versed in React and NextJS. These could work quite well (React Native on devices, React/NextJS on website). I’m very well versed in traditional SQL and optimization of MSSQL. I’m good with PHP, Perl, Python, JS, etc.
I’m a paid users of GitHub, so if we have a repository (and project management) on there, that might facilitate great collaboration. Just ideas, of course.
Send me a direct email, and we can hash out protected details. This is exciting.
73
NW7US
Sounds great! Let me ponder this for a few days, and I’ll get back to you once I have a clear picture in my mind of how such a new project and collaboration could work ![]()
Has there been any progress on this front? I was recently pondering a feature that I’d love to contribute.
There hasn’t been any relevant progress on this front last year. The optimizations implemented in the backend in summer (FT8/FT4 spots & backend scalability) have completely obliterated the scalability issues for the foreseeable future, so the pressure to change something in the architecture has been greatly diminished ![]()
I’m still reluctant to work on larger new features, mostly because the UI is really outdated and clumsy to work on. I guess that would be the first thing that should get rewritten.
I am coming up for air, at work, so I hope to now have some time to dig in and get my bearings in the code. I noted that Github has detected security vulnerabilities in the code, so I want to look into that before much else. Maybe this weekend if all goes well.
Thanks!!
Hi, Billy.
A long shot, but if you have anything to contribute, it would be great have you on board. I’m just putting together a list of people that may be able to help. If you want to be added, could you email me at cjhandrew@ a popular search engine.
Thanks,
Chris.
Hi, I’m Bernard.
I might be able to help with the UI design/redesign/UI for larger features.
I’m a user centred design of of 15+ years (a.k.a UX designer) and licensed ham (ei8fdb / m5fdb) of 30 odd years. I’ve got good experience contributing and working in FOSS projects (if you decide to go that direction also).
My experience is in user research (talking to users to understand how they need something to work, and why), translating that into UIs (that doesn’t need to be explained too much), and then also usability testing (testing those, what we think are usable, UIs to make sure they actually are usable!).
I’ve recently started using Hamalert, I wish I found it earlier!
One thing I am not is a graphic designer, brand designer, logo designer. So I can’t help with that kinda thing! But I know people who are, if that’s needed.
One thing I could start with is some research with other hamalert users on the main problems, and could also do a usability review of hamalert (android app, website) to identify low hanging fruit/most serious issues?
Let me know what you think. And thanks a lot for Hamalert.
Hello Bernard,
Thanks for your message, and for considering to help with HamAlert development!
I think the most important issue currently holding back HamAlert development is the outdated UI code. It simply doesn’t make sense to implement larger new features if the UI part needs to be coded for the ancient JsRender framework, only to be reimplemented (hopefully) soon in a new technology.
My hope/expectation is that once things are implemented in a more modern way, the usability will also improve as a side effect. And in the course of reimplementing the UI, some paradigms could be rethought.
All the HamAlert source code is on GitHub (HamAlert · GitHub), and some issues have been created in the individual repositories to track progress.
Perhaps your talent could be put to use in determining whether the current trigger/conditions paradigm is still the best way for users to express what kind of spots they are interested in, or if there’s a better way? That way, any changes to this paradigm could be incorporated in the development of a new UI right from the start.
73,
Manuel HB9DQM