|
Dave Kreskowiak wrote: You find out the hard way that your email notification code better be rock-f***in'-solid before you launch the site.
Yeah, and with the vagaries of the email server, the only way to really do that is wrap the whole thing in a try-catch that handles its own errors -- I have a UDP message to PaperTrailApp for those super critical help help help! problems. 
Marc
|
|
|
|
|
Marc Clifton wrote: PaperTrailApp
Huh? Wha'dat?
|
|
|
|
|
|
It looks cool, though it appears to be cloud-based logging and aggregation?
Damn it!  I can't use it. Security would throw an epic temper tantrum.
It took SIX MONTHS of thrashing those guys to get authorization to have a 3rd-party stand up TWO SERVERS in Azure to be managed by that company and we would install a client app on a dozen machines that connects to them and feeds them data all day for analysis. And that wasn't even HIPPA regulated nor business critical stuff either!
They're heads would explode if I showed them this thing.
|
|
|
|
|
Exceptionception!
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
I was hoping (and still am) that this was going to be a 'well, ironically, having made an attempt at writing a HAL in Python, the kiddies have discovered that they can't do it, and have come to me cap in hand to help them'
I LIVE for that post, Marc
|
|
|
|
|
Garth J Lancaster wrote: having made an attempt at writing a HAL in Python, the kiddies have discovered that they can't do it, and have come to me cap in hand to help them'
First part happened, second part has not.
Now they're writing it in F#, because one of the kiddies as a Haskell background. 
The irony here is:
1) very few people actually know F#, so the code will undoubtedly be thrown away by the next iteration of kiddies, if not sooner.
2) it's like reading imperative code with match statements instead of switch and type instead of enum, and everything is mutable.
3) FP is just the wrong approach for this kind of work because you're dealing with a lot of struct stuff for the hardware, a lot of mutable data from the I/O, and possibly the need to maintain some sort of state information, like is the hardware up or down since the last time we checked.
4) from what I've seen so far, no logging, no exception handling, no modularity, and a lot of hard coded constants and strings, but hey, "we're ahead of schedule!" is pronounced loudly and proudly at every stand up.
I write better prototype code.
Marc
|
|
|
|
|
Garth J Lancaster wrote: I LIVE for that post, Marc
Actually, what's worse is that one of them said the UI (Javascript/HTML hosted in a CefSharp browser client) was ready for QA, so I volunteered to pre-QA the UI before we sent it over the fence to the "real" cough cough QA people.
An hour later, I had 8 pages of bugs.
Marc
|
|
|
|
|
Oh nice, give the old bastard who has spent years being nitpicked by QA a shot at your first UI
Don't get me wrong I think QA people are essential but what a bunch of pedantic, anally retentive, irritating, annoying and bloody persistent sods they are.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: Oh nice, give the old bastard who has spent years being nitpicked by QA a shot at your first UI
I must admit, I took great sadistic pleasure in the process.
Mycroft Holmes wrote: but what a bunch of pedantic, anally retentive, irritating, annoying and bloody persistent sods they are.
Yeah, aren't they wonderful? Honestly, once I started to learn how to work with QA (part of which was, don't rely on them accurately telling you what they did to break your software), I started enjoying the process, because it did improve the quality of the product, as well as my code and I learned better architecture (ok, fancy word for automatic logging) as well as a result of my QA experiences. The best thing though was when we got to a point of working together, and I could ask them "I found this weird bug in my code and I can't figure out how to reproduce it, could you try?" That was great.
Marc
|
|
|
|
|
The only good case I found for empty try-catch blocks, when your error handling (logging, emailing, whatever it is you do) goes awry 
|
|
|
|
|
Old story, even the Unix haters' handbook has it.
|
|
|
|
|
One petard wedgie, coming up.
Welcome to humanity, Marc  .
Software Zen: delete this;
|
|
|
|
|
Install a mail agent on each server, send all emails to the local agent, and let the local agent send it upstream to the actual relays.
Your emails will arrive eventually, even if the whole network is down!
You can tune the retry parameters on the local agents to be pretty aggressive on retries.
|
|
|
|
|
Marc,
In our little system we have email sending configured as a Boolean. Down when we're instantiating the class that sends the email, we look at that. If false, we instantiate an implementation of the class which writes to a local file instead of sending the email.
So, we can check content etc in development without the risk of "oops that was a real email address."
I wonder if something similar could be wired up for your error condition. Once you're in the catch block, fire off the email send, but pass the magic param which says "write to log/file/send up a flare/whatever."
|
|
|
|
|
At least someone is *trying* to handle/report errors. Better than ignoring them.
|
|
|
|
|
I did something similar. My program connects to a SQL database and when that database connection is broken an exception is thrown and logged to a message processor which also tries to log it to the, wait for it, SQL database. Which then throws the exception again.....
|
|
|
|
|
Alcohol is a direct cause of seven forms of cancer, finds study[^]
 Science: ruining fun for everyone.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
"Everything causes cancer" -- Joe Jackson
|
|
|
|
|
Not exactly his area of expertise, but he's right. You could see a living cell as a very complicated biochemical machine. Everything that can directly modify the DNA or interfere with its replication can eventually cause cancer.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Birth, the leading cause of death! 
|
|
|
|
|
Exactly.
However, moderation is the key here, that no one is talking about. A few drinks a month versus a few drinks a day...moderation - same goes for most things/vices. BIG DUH! 
|
|
|
|
|
Always reminds of the quote generally misattributed to Einstein "Insanity is repeating the same actions and expecting different results".
Wrong on two counts (at least):
1. Einstein never said it.
2. Even if he did, I don't think being a genius in physics necessarily qualified him to make statements on diagnosis of mental illness.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
He never used a computer; certainly not a web browser.
|
|
|
|
|
you have to die from something - shortness of breath, whatever - you can be the healthiest person in the world and get hit crossing the street (or these days, get an lead injection from some maniac with a gun) ... so you may as well do everything in moderation, enjoy, be a nice person, and not beat yourself up
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
