Programmers: What Are Your Proudest Projects?

Post Reply New Topic

I've only been programming for a couple months now so I can't really say.

It is a tossup between two projects that involved three-dimensional trigonometry:

1) GCircle.exe: An MS DOS utility that derives the Great Circle route between any two points on the Earth's surface, given the Elevation, Latitude, and Longitude of both points.  This is useful for plotting courses and aiming antennas.

2) SatAnt.exe: An MS DOS utility that derives the Azimuth and Elevation needed to aim a communications antenna at a satellite in geosynchronous orbit around the Earth, given the antenna's current Elevation, Latitude, and Longitude, and also the satellite's longitude.

I wrote both of these while in the Navy, and used them while on watch -- the first to verify the QMC's own calculations and the second to facilitate satellite communications.  Together, they earned me commendations from both the Captain and the Admiralty.

Nothing off the shelf yet unfortunately, so far just business to business and one storefront system.

The skillsets I've been building:

- Full-stack programming between SQL, .Net Core (Entity Framework and MVC patterns), over to an Angular client.
- Different ways to build technical quoting applications and even now finance apps and including integration with services such as Stripe, Plaid, Transunion, etc.. In one last project I was researching connections from Angular to Azure AD and Microsoft Graph but turned out not to need it.
- Refresh and access JWT token patterns including integration with .Net Core Identity.
- Different ways to use third party grids and reporting tools in Angular.
- Building rather complex and HTML-laden reports for customers (technical reviews, quotes, etc.).
- Automated emails and charges.
- Overnight Cron jobs.
- Running on-push change detection strategy in as much of my Angular code as possible.
- Being able to use Angular's component-driven changes to affect CSS, I even used this for one company to 2D render parts from images.
- SQLDependency and SignalR for, respectively, setting up server-side code to listen to SQL changes through broker and for client-side information to refresh based on server-side changes.
- Integrating signature tablets with a .Net WPF app I made.
- Beating the heck out of SQL With statements and running as many raw SQL queries from .Net as I can because we're learning just how bad/slow EF has gotten.


Things I want to learn and that I think may be important sooner if not later:

- Webhooks (a bit like SQLDependency and SignalR pattern but between websites).
- Electron - in case I have clients that want something that feels more 'substantial' and gratifying in the old-fashion way.
- Rust - looks really powerful if I want to get into building libraries for my own use.
- Expanding my error trapping patterns and reporting which prevent SQL from saving bad data. I want to expand my theory on that from unit-sized to integration-sized stops as the place I work for doesn't have the time or $$ for testing.
- CORS - I just want to learn more about what kinds of things I can do with it that haven't been battened down over hacking concerns. Headers are one of those few categories, along with black-boxed components, that can still be a stumbling block.

I wrote a system for writing and tracking speeding tickets that was used in a number of states. It was just me by myself.

It was a year and a half into the project before I missed a deadline and that was by one day. There were also no major bugs ever found in the software. About the closest thing to a bug we found turned out to be so useful that we kept it as a feature.

There was one thing that some saw as a bug, but acted as intended. Twelve noon was displayed as "12:00:00 M". One second earlier was "11:59:59 AM" and one second later was "12:00:01 PM", but strictly speaking, noon is meridien, not ante-meridien and not post-meridien.

By the way, I set one record (kind of) with the shortest program ever written. It was 0 bytes long.

There is a trick to it, though.

It was on a PDP-11 with the RSTS/E operating system. Under RSTS/E, we had run time systems that would load and execute the program. Each file had a run time system associated with it so when you ran the program it would use the run time system from the file entry which would then load the program into memory and then execute the program.

I had a need for a terminal emulator to use to connect to other systems from the PDP-11 and so I wrote one as a run time system and called it TRM. Naturally, run time systems had to be coded in assembly language, but I considered that a plus, not a minus.

The run time system itself didn't actually need to load the file that invoked the run time system. The only purpose for the file was to switch to the TRM runtime system. So I could have used any file to invoke it, but I liked the idea of a zero length program so I just created a file with nothing in it.

I later thought of modifying TRM to read the file for the first commands to use such as the text needed to dial a number from the modem, but then the "program" file wouldn't have been 0 bytes any more.

So I used TRM for business use in the daytime and also to connect to the various BBS's in the evenings.

My next project CramCard. It will allow you to mix and match articles, books, and other writings into one cheat sheet or "CramCrad". This came from the issues I had with many books that had one good section on one thing but another book had a better section on another thing.

I wrote my first programs in 1971 so there have been a few along the way that I liked--most recently in VBA. But the "programming" I did that shines the most in my eyes was in SQL.

Back when dinosaur mainframes roamed the Earth I was a DBA for some mainframe DBMSs. We used the product on three mainframes at our location but also supported it on a small number of Customer locations.

We received some DBMS product upgrade scripts (pre-Internet!) and ran them first on the SysAdmins' test mainframe. The upgrade script ran THREE DAYS! These mainframes were used for Program Management functions so I could've lived with two days--just upgrade the product on a weekend--but three days was a problem!

I dug into the upgrade script and finally figured out that one specific step was the problem, and it was insane. First, that step didn't change anything--it just scoured the database for anything that would cause the upgrade to fail as it installed a new feature. If it found anything you had to abort the upgrade and adjust your data. Second, the guilty step appeared to have been written by someone completely unfamiliar with the product. I contacted the vendor and pointed out the problem.

When a revised upgrade script arrived we ran it. And it still took three days! I scrutinized the guilty step again and found there was something else in there that was not too bright--it wasn't as stupid as the previous error but it had not been thought through completely. I contacted the vendor and pointed out what they should correct.

When we got the next upgrade script we ran that. And it still took three days!

I could not see anything else obviously wrong with the guilty step. I was getting rather worried. And I hated to complain to the DBMS product vendor again because maybe it really had to take three days to do that bit. I didn't want to ask them to make it faster unless I knew it really could be faster. So, I decided to see if I could do that step faster.

I developed, from scratch, my own version of that step. Instead of stringing together a bunch of little assembly jobs that sloshed data around, I wrote one gosh-awful SQL query that looked for places where problem data might be hiding. My one single SQL query was two pages long, accessed system data tables, and used bit manipulation operations on data it got out of them--but that one query did the same job as the vendor's code.

And, instead of three days, my version of the step took about five minutes.

My version of that step was three orders of magnitude faster than the one provided by the vendor!

This site has the worst captcha's ever.

At one company, people kept asking me for new reports. I'd get new report requests two or three times a week sometimes. I would have to drop whatever I was doing and spend about 4 to 8 hours writing the software for the report and testing it.

I got tired of this and so I called a moratorium on new reports and refused to do them. I used the next two weeks to write a report system that would take any standard VAX/VMS file with data of fixed widths and let the user create and save a definition of what they needed in the report. They could then run the report by just entering the name they saved it under.

The users grumbled about how bad they need the new report but I just told them to wait. But once I finished it and taught them to use it, they loved it. I never had to write another report again at that company.

A wireframe 3d graphics thing I wrote in Basic on an Apple IIe computer when I was in HS/College.
I sometimes think of rewriting it in a newer language on a newer computer.
SDL might be a tech to use or WxWindows.

Wow, to say I'm out of my league would go beyond an understatement.

On the old Apple IIe 2d graphics was easy:

http://www.hoist-point.com/applesoft_basic_tutorial.htm

"To plot a pixel, use PLOT X,Y in lo-res mode and HPLOT X,Y in hi-res mode. Here X and Y are coordinates of the pixel you want to plot. Valid coordinates (X,Y) in low-res mode are X=0..39 and Y=0..39 (0..47 in full-screen sub-mode); in hi-res: X=0..279 and Y=0..179 (Y=0..159 in mixed HGR mode).

In low-res graphics you can plot horizontal or vertical lines using HLIN and VLIN commands.

In hi-res graphics you can plot a line between 2 points with HPLOT X,Y to X2,Y2 command. You can also plot a line from the last point you plotted (which is remembered) to a new location with HPLOT TO X,Y. "

The trick was going from 2d to 3d - and this was pre-internet so to research ideas I had to comb through books on art and lenses and math in the library. The part I liked about it was that I never did find anything that told me the answer - I had to make a mental leap from a diagram of "how the eye worked kind of like a lens" to get the idea: "if I could just plot a 3d line from my eye to the (data for the) cube and figure out where that crossed the plane of the video screen - then I would be able to calculate where the corners of the cube SHOULD appear to be - kind of like painting on glass." Then I had another ah-ha moment when I realized I could do this by using the Pythagorean theorem and the built-in Applesoft Basic trigonometry functions. Really I was just recreating the wheel. An it was VERY slow. But I liked the fact that I "figured it out all by my self". Computer graphics was JUST starting to be used in films then and it was "cool" and I was really happy to make something like that work on my little home computer.

On a modern browser you could do something similar using SVG.