Two years ago, every person of a working team were processing a bunch of txt files by hand, using excel, against the time (data that would be published at the website). As the deadline was really close, they asked for more monkeys from the rest of the people in the building.
Instead of doing that in excel, I wrote a small script with some flipflops and regexprs in some minutes and processed my assigned files. Then run over the rest of the files assigned to my team, and finally, run against the whole folder, just to check that the script was OK (and found some errors in files manually generated by others).
The same requirement would be processed again last year, so they asked for my script. Some days later, I was told that it run without problems, giving the results just in a pair of seconds!!!
Last week someone was struggling to merge a few hundred names and addresses into letters. His source was a Word doc containing a two column table. He fought Word but Word won. :-) I was able to knock it into a csv file and within half an hour he was merging with ease. Perl won!
It was satisfying that everyone told him, "Oh, give it to wfsp he'll sort that out." And he bought me a couple of pints. :-)
Now, as for the people who think a spreadsheet is squared paper...
Projects that other people can take over without getting a headache.
But also - admittedly sometimes at the other end of the
maintainability scale - snippets of code which are so compact that
people just have to sit back in awe at the magic that can
be done with a couple of lines of Perl :)
The nice thing is that Perl allows me to have both.
Sometime a few jobs ago (seems like a lifetime ago to me) I started a job with a smallish company with a not too sophisticated team of Unix System Administrators. On day #2 of my employment there I noticed one of the "senior guys" there reading an email and manually selecting information from it to create accounts on various systems. What I further noticed was the information he was reading was in a fixed format in fixed columns.
For the sake of this posting to protect the guilty I'll call this guy "Ben."
I asked Ben why he hadn't automated this process and his reaction was to stare blankly at me and ask "how can you do that?" I told him that I'd work on the problem and get back to him on that.
Ben then patiently explained to me that it couldn't be done because there were too many different types of systems involved and blah blah blah blah... He also told me that of a 40 hour work week he was spending 30 of those hours processing these account requests.
Off to my cubicle I went and opened up an Emacs session and typed the ubiquitous
that many a script of mine had started with. The result was actually four different scripts. One that processed the requests, and three others that acted as "agents" as I called them on the VMS, Solaris and Tru-64 systems that the accounts had to be created on. Each system requrired some customization of the agent scripts and the master script communicated with the agents over a TCP/IP socket and the data going to them was encrypted using GnuPG. The master script was invoked from the same alias that the system administrators (4 of them) go their requests through. (Yeah... I know.. there's a secruity hole there.. best I could do at the time. Later a web application replaced the master)
What made me proud of all this was the fact that I was saving 120 staff hours a week enabling the 4 SAs to do other things besides data entry. The other thing that I changed in the process was instead of setting default passwords for new accounts as was being done (which never got changed) I now gave the new users random passwords and the script emailed the login and password to the user's manager. On first login the users were required to change their password.
There were two other side effects to all this. The first of which was I damn near gave Ben a heart attack when he realized that he hadn't gotten a new account request all day the first day I installed the master script. (Oops.. forgot to tell him... there was no change control process in place either...) The other side effect was I was given a quality award (including a very spendable Amex gift card for $100) by my vice president, He was happy over the staff hour savings.
Peter L. Berghold -- Unix Professional
Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg
chexmix, as one who also isn't working in their major anymore (I was a chemist, now I'm an engineer), there are tons of things I use from school in my daily gig. I just don't ruin my clothes with acid anymore. :)
Yep, the general state of my wardrobe improved mightily after switching to computer science, and I never poisoned myself once after that. (Jenda: not yet, though there have been days where I was close...)
Gee, I don't feel quite so bad now - I actually got my BA in English and now I work with computers. There's not necessarily a huge difference really. Plus it gives me a good base for creative problem solving and "thinking outside the box" (although it's sometimes hard to think outside the box when you sit in a cube ;-)
It's something I wrote as a stopgap at a former job many many years ago. It's still in production because a) it works, b) the customers use it as well as the company, c) it's platform-independent, and d) it works way better on Windows than anything the VB folks did.
Plus, it's used in a software package that helps save people's lives, so that doesn't hurt.
tbone1, YAPS (Yet Another Perl Schlub) And remember, if he succeeds, so what.
- Chick McGee
Not long ago, I visited some folks with whom I had worked at a large Insurance company. My job there was to work as a deployment engineer in a large group of developers. It was good to sit and have a beer and visit with them, as it had been a couple of years. As the beers flowed and the hours dwindled toward bar time, we began to reminisce about tech issues, apps, code, politics...etc.. . I was astounded to hear that the Perl code I wrote to bridge between CVS and an expensive, complex proprietary SCM application was still being used, unchanged!
This was/is not pretty code! I have seen good code writing, and know very well that what I do would not be described as such. It was never intended to be much more that an interim tool that I and a couple of others could use while the "real" tool was being written in Java, incorporating all sorts of neat things from Maven to God only knows what else.
As I sat there, beer in hand, mouth hanging open in surprise, my former co-worker explained to me that the "real" tool never did come about, and the goofy ugly code I wrote was and is being used still, everywhere in that company!
Of that I am proud. It ain't pretty, but it works. And what I am most proud of is that it works for others as well as it did for me. Many who use it are far better programmers than I will ever be. But, By God!... they like it!
...the majority is always wrong, and always the last to know about it...
The Spice must flow...
..by my will, and by will alone.. I set my mind in motion
I'm most proud of the code I wrote in 1986 to monitor fish in real time, so they can be used to detect water quality changes. It's still in use.
My favorite perl code was a bit of munging I wrote for someone literally halfway around the world, to interpret GPS logs to prove illegal fishing took place.
I didn't realize that the GPS system could detect baited hooks in the water. Maybe this is an 'undocumented feature' that is only accessible via a CPAN module (in which case, I would be *really* proud of that code)? Oh, wait, you meant the 'Global Phishing System'?