If posting has been light, one reason is I’m spending nearly all my non-working hours trying to sort out a new membership management system for my club. I consider this part of the “local engagement” I was speaking about earlier.
We largely decided not to go with a cloud-based solution, which is fine with me. Maybe this will be my curmudgeon technology issue, because the young folks seem to love the cloud, and even I have to admit, having worked with Amazon Web Services professionally, and helped a few clients through migrations, Bezos has built one hell of a nice ecosystem. But I like the saying, “There is no cloud. There’s just someone else’s computer.” I don’t like the idea of trusting personal data to an entity I don’t really know or trust, and who only sees me as one of many income sources. Also, AWS is damned expensive. So are most other Cloud solutions.
We have an existing card access system for the gate and for the various doors around the property. The old system worked off an Access database. Recently we upgraded that software, and the new version is backed by SQL Server. The old card access system was a mess. There were people in the system who had been dead for some time and still had active cards. People were missing from the system who were members. I think some of them may be grandfathered lifers who just never bothered picking up an access card. It took another trustee helping me sort that out, and I’m still not sure all the cards are assigned correctly.
Originally I had chosen to put the member database in MySQL. Since I already have SQL Server running, why not just use that? Saves having to run a Linux machine and cuts down on the number of skill sets needed to maintain the system. As long as I’m cutting MySQL out of the picture, I might as well also cut OpenLDAP and set up Active Directory to use with Google Cloud Directory Sync (GCDS). I’m teaching myself a bit of PowerShell to make a script that will push out changes in the member database to the card access system, to QuickBooks (via qODBC), and to Active Directory.
After working with PowerShell scripting a bit, I’ve decided I hate it with a burning white hot passion. At this point I’ll probably stick to it because I’ve already invested the time, but the future of that function will probably be with Python if serious changes are ever required in the future. So in the end the system has ended up being far more Microsoft than I expected going in, because I had no idea what the new card system would look like. Our new card system will even work with an ID card printer to manage and print member badges, so we got one of those too.
I think what I’m coming up with will be a decent platform for the next decade or so. It will certainly make managing dues processing for our 1300 members easier than the old paper process.
Our club was founded in the early 1960’s and is now at around 800+ members. It still operates pretty much flintstones. It’s run mostly by an elected founder’s generation who are great guys (club founders, not Jefferson/Washington and the ilk). Fortran cards would be an improvement. The club secretary seems overwhelmed.
On the other hand, 3Gun, IDPA, Cowboy and other sub contingencies use practiscore and tablets to run matches efficiently.
Please advise on what you find.
Our founders generation is getting old and dying off. We’ve been around since 1958.
“Fortran cards would be an improvement.”
Hey, watchit. Fortran put men on the moon and flew reentry vehicles that when launched from Vandenburg AFB on a Minuteman would land within a few feet of a target on Kwajalein Atoll; putting the “assured” in “mutually assured destruction.” And we didn’t need no stinkin’ cloud to do it. ;-)
My favorite comment about Fortran, though, is “We don’t know what kind of language scientists and engineers will be using in the future. But we *do* know that it will be called ‘Fortran'”.
I’ve been doing small stuff like this using Java and Apache Derby. Derby is fast, simple and able to handle a lot of data. It’s SQL is compliant so it’s east to port to/from. I’ve used Derby in my commercial offerings for over ten years (before it was even an Apache project) and when deployed it just works.
I have a customer that in over 9 years had had zero issues and has never had to do any maintenance on an application I wrote that uses Derby quite heavily. Not even an upgrade or a patch. Try that with anything from Redmond. That application is critical to many things, so they won’t even take a patch unless they really need it. They have been very happy with our code, and don’t even know that Derby is under the covers. That’s my definition of good tech – nobody has to care about it.
The best thing is it’s pure Java, so I can dump the end result into pretty near any OS I want and not worry too much. PHP, Python, Java, C, C++ will all connect to it just fine.
I gave up on Windows years ago and generally won’t go back. I have a Windows VM I fire up only when some idiot does something that requires it – these days the biggest idiots are the government.
Also, for hosting you might want to look at Rackspace. Small servers are pretty cheap, but local means an internet outage won’t shut you out of your member DB.
Good luck.