|
Marc Clifton wrote: how destructive AWESOME! human beings are
Except that they're not 
But how is such a blast not awesome?
|
|
|
|
|
Michael Bay would be proud
What's the music though? Shazam doesn't recognize it 
|
|
|
|
|
Just awesome.[^]
Kudos to those construction workers!
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???
|
|
|
|
|
"Jason Haney ... built an 8-foot tall Waldo from the famous "Where's Waldo?" books"
Well, I'm sure the people who wrote the books are very happy that this philistine shreds them to make papier mâché figures.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I suspect that's "built an 8-foot tall (Waldo from the famous "Where's Waldo?" books)", not "built (an 8-foot tall Waldo) [out of] the famous "Where's Waldo?" books". 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
When your email service, that handles emailing you exceptions, itself throws an exception...
Which is then caught by the message processor, that then tries to email you a notification that your application threw an exception...
By queuing an exception message...
Which gets dequeued on a separate thread...
And the whole process repeats itself.
Marc
|
|
|
|
|
I ran into that myself about a year and a half ago. You find out the hard way that your email notification code better be rock-f***in'-solid before you launch the site.
|
|
|
|
|
I thought it was just me! 
I ended up putting the error log to a DB, with a delayed bulk email at intervals to prevent locking it all up with error reports... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
We ended up doing the same thing. We don't get email notifications for every brain fart the site runs into, just the most severe.
I really have to overhaul the email system anyway. There's a ton of notification subscriptions the system supports as well as site errors. In the overhaul I'm going to split out the site errors from everything else and handle it with a different, very simple, subsystem. The remaining subscription emails will be handled by message queuing and an email system running as its own process.
I wish I had the time to do it that way before launch but we had to launch the site 6 months earlier than planned.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
