Printable View
One of my coworkers almost got 90 days in jail because he thought "tickets just expired if you didn't pay them" (uhh, that'd be a "no", dude.) and he got a second one after they suspended his license (I didn't know they could do that without notifying you in Minnesota!) and he had to go to court for that one.Quote:
Originally Posted by Melcar
REALLY smart guy but apparently entirely uneducated about some things.
Quote:
Originally Posted by Mitebe
Interesting. I was at one place that wouldn't work.Quote:
Originally Posted by Mitebe
I'm not sure how they did it because "Passwords must meet complexity requirements" in Group Policy doesn't cover that.
Could have been some kind of third party software, but that makes me cringe too because you're passing all password change requests through someone else's software.
At this place, if your password had the same string in it anywhere as any of your last 8 or 10 (I forget) it was not allowed.
I can imagine they had lots of written passwords in little black books in desk drawers.Quote:
Originally Posted by Merrick ap'Milandra
My office's password requirements aren't that strict - Alphanumeric with caps, change every 90 days, and I still see people with them written down on post-it notes on their monitors.Quote:
Originally Posted by FilanFyretracker
Ours aren't even that strict, no need for numeric or caps, just 8 character minimum, and STILL people write them down or forget them.Quote:
Originally Posted by Mileron
Customer: I have your program
Me: Okay
Customer: I have between 50 and 100 datasets in it
Me: Okay
Customer: I need to upgrade to the most recent version of your program
Me: Okay
Customer: The version of the program I am running is from 2002, will the update be seamless?
Me: Wait, what?
When I used to code, I would write the updates so that they automatically updated any datasets from the most recent revision to the new format, and then I would write a small standalone updater that did the same thing. Then I just included every standalone updater with each new upgrade disc. That way, a customer could upgrade from any prior version and keep their original datasets, though they would have to apply each standalone updater in sequence to bring older datasets into compliance with the latest version.
That way I didn't have to worry about adding new axes of data to the dataset format, which made accommodating requested features easier. Most of the coding I did was machine control software for various multi-axis automated devices, and some in-house manufacturing and inventory control systems. So we got a lot of requests for custom additions, with various one-off features conceived of by customers who had unique manufacturing needs. Stuff like "can you add a prox sensor at this point" kind of requests.
THANK YOU.Quote:
Originally Posted by Alikat Astrae
I've inherited software that didn't and taking time to hand-craft a thousand plus lines of SQL code just to update the schema from one major version to another just because the developer figured everyone should just stay on the version that was newest when they were originally installed was a real pain.
One of the worst pieces of software for that thankfully stored the sa password plaintext in the registry and the other even worse one just allowed windows login so as long as you were local admin on the machine...
Thankfully I only had to do that once before I discovered Redgate Software's SQL Compare program which, while not cheap is worth every penny.
You just point it at two databases and it'll write the SQL Code to change the schema FOR YOU. I used it on a several hundred million row db of about 100gb in size on a whitebox and it worked flawlessly, which shocked me.
Holy fucking shit. That is awesome.Quote:
Originally Posted by Merrick ap'Milandra
yes, RedGate software is awesome. the bastards still didn't give me the job they interviewed me 3 times for, though.
Wow. "Useful" doesn't even begin to describe that. Schema changes are pull-hair-out inducing operations...Quote:
Originally Posted by Merrick ap'Milandra
Yep!Quote:
Originally Posted by Dawlin
I still copied the code out, put the db and application on a virtualized whitebox, ran the schema-change code, and hand-tested it before giving it to QA and then to a test group of users long before it ever went live (every once in a while it'd find an issue with duplicate records that weren't flagging on the old schema yet did on the new one, but that was just finding them and hand-removing them.)
The only time I ever had a problem with it was when I tried to jump more than 4 major versions of the schema (2002 vb6 to a 2006 .NET 2.x version of the app) and even that was easily corrected by whiteboxing each major version and running the schema changes one version at a time and I blame it mostly on the original .net 1.0 version because .net 1.0 was FUGLY on the database backend due to an inexperienced set of developers spending more time on the app than they did on the db in this particular case.
Paraphrased from almost 35 minutes of calls:
Tech: I keep getting errors using your program on the network saying network communication dropped
Me: Did you reboot?
Tech: Why would I reboot when it's your program having problems?
Me: My program having problems communicating on YOUR network...
Tech: No, that's not it
Finally got him to reboot... guess what happened next?
Quote:
guess what happened next?
Armageddon?
Think I got ya beat though... my best for the day.
"Wireless mice use batteries?"
"But what about the part I have plugged into the USB port? Doesn't that charge it?"Quote:
Originally Posted by Melcar
This always irritated me in tech support, The outright allergy people have to rebooting. I could understand if it was a server but a home PC or cubical workstation can be rebooted without disrupting the operation.Quote:
Originally Posted by Mileron
That said when it comes to home PCs I once had someone's computer take ten minutes to fully restart...
Ugh, I have a couple of Vista64 machines, and they can take a long time to fully shut down and restart.
Rebooting is pretty much the first thing I ask people to do. Between the specialized callcenter/TCI software, CRM systems, accounting software and various browser-based tools that people use all the time - I have to know that it's not "just" that interaction that's messing things up.
And those are just the tools that the non-tech workers use...
I have successfully trained nearly every end user I still come into contact with that they should reboot BEFORE they try calling in. I wish the other techs would try doing that, but some of them are driven by getting "free" ticket closures more than they are by doing the best job possible for the customer.Quote:
Originally Posted by FilanFyretracker
Thankfully the few customers I still interact with don't even lie about having rebooted when they haven't anymore.
They got more irritated at the 2+ minute hold times waiting to get a tech (especially a senior systems administrator who only has to answer the phones when the calls are REALLY backing up) than they did at amount of time it took to perform the reboot most of the time.
That being said, most of our end users are productivity-driven business professionals who would rather be working, so they're more likely to try the things they can do for themselves before calling us.
I guess we're lucky that way.