Adam Moskowitz <ad...@menlo.com> wrote: [snip]
> Would you please take a few moments to send me a description of the > programs you've written in the last 3 or 6 or 12 months? Specifically, > would you please send me the following: > > * language used > * number of lines > * very brief description (< 140 chars? :-) of what > the program does > * who runs the program: > 1) you, from the command line > 2) people in your group, from the command line > 3) people outside your group, from the command line > 4) "the system" via anything from cron to whatever > config management system you use > 5) it's a web app > 6) other [snip] I know this thread is ancient now, nevertheless, here are two examples - one outside your time frame, but I still think you will enjoy it: A. Mid 1990s on an Air Traffic Control (ATC) program. Installation program for the ATC system in Bourne Shell. Several hundred lines and related text instructions in documentation. Run by: in country military personnel to install the ATC on several systems via the CLI, and crank up the ATC. I made sure to do a lot of input validation, and to adhere to the rule of pattern matching: whatever is seen on screen is referred to *exactly* as it is seen on the screen - never paraphrase. Along comes a PHB and declares that the instructions are "too complicated" for the what he declared to be an unsophisticated end user and that I really needed to produce "a one page installation document". Let me repeat: this PHB wants "a one page installation document" for a freakin' mission/safety critical ATC. So I scrapped what I had, and spent the next two weeks creating and testing (including user testing) "a one page installation document" - essentially a very specific cloning system, i.e., tell it what specific ATC site you want installed and it handles the rest under the hood. B. Weather Satellite sensor data transfer system (2013-2014) bash, approximately 500 lines runs via periodic cron but may be run interactively as well The sensor data is captured at our facility, the program is two step: 1. transfer new sensor data to a gateway system 2. transfer from gateway to customer facility Constraints were: System needs to transfer most new data in close to real time (within 24 hours, ideally within 8 hours or less) We were given - and had to defend against - a crappy, noisy VPN pipe Some data had a higher priority than other data, so non critical data could be delayed up to two weeks, and some data should not be transferred at all. Because this created a nominal QoS and they changed it on me more than once, the system had to be very flexible to allow for new data at different priorities. The system ran pretty well unattended until we had the 2013 US Government shutdown. That was definitely not anything the requirements prepared us for. When the customer's systems came back up weeks later, I had to tweak the data flow by hand, modifying the data's time window gradually, to get a graceful, smooth data flow restored. Like giving a gradual series of ntpdate commands to a system. _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
