IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Nice resource

I'm not sure I'd leap directly to strace, though, myself.

I like to actually look at the error messages, observe the error behavior and milk the logs a bit.

There are some good tips there, however, for more in-depth trouble tracing.

Tom Sinclair

"This is a lovely party," said the Bursar to a chair, "I wish I was here."
-- The Bursar is a man under a *lot* of stress
(Terry Pratchett, Lords and Ladies)
New strace: I would
The problem is the logs depend on the programmer actually logging something.
Strace almost always shows you where the programmer tried to access a non-existant file and aborts badly. With a stupid error message, not telling you what file it could not access. I LOVE strace.
New I'm glad to say that I don't have that problem
I work with programmers who are smart enough to put filenames in error messages.

Cheers,
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
New Wouldn't it be nice...
If everyone included useful error statements?

Especially microsoft?
--
[link|mailto:greg@gregfolkert.net|greg],
[link|http://www.iwethey.org/ed_curry|REMEMBER ED CURRY!] @ iwethey
Freedom is not FREE.
Yeah, but 10s of Trillions of US Dollars?
SELECT * FROM scog WHERE ethics > 0;

0 rows returned.
New They don't have to
It's always the same solution anyway.
===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
New This typically occurs with commercial apps.
New Speaking of which
I've decided it was time for my PFY to branch
into utility coding. He's spent the last year
baby sitting my stuff, and reviewing my code,
occasionally commenting and offering some
suggestions.

He is an odd mix of lots of book learning, combined
with an incredible level of naivety.

While he's coded "professionally" in Perl for a
couple of years, and he got my sample interview program
without any problem, there was no way I would have
hired him into the group as a database programmer.

So I decided it was time to ratchet his skills up
a notch.

I got a spec for utility to implement some select /
bypass logic against a flat file. Extract out fields,
drop stuff that match any of the bypass rules, then
keep stuff that matched any of the select rules.

It had to be runnable by people in our production group.

Take command line arguments, create logs / reports,
sanity check the arguments and the data.

Pretty straight forward. I had it coded in about a
1/2 hour. I assigned it to him as well, not telling
him I already coded it.

After about 3 hours he had a "working" program. Anytime
it encounters a problem (bad argument, file open failure,
etc), it would spit out a message that said: "Error" and
then printing the generic help text.

I was VERY emphatic about creating very explicit error
messages at that point. I asked him if he wanted to take
midnight support calls from the production group as we
ground to a halt because they typoed a file name and he
didn't tell them which one.

He missed the logging / reporting piece of the spec, and the
fact he needed to handle multiple select and bypass statements.

I read the code, slowly, and pointed out a couple of possible
errors, clarified the spec for him, and told him to go code
some more.

He came back the next day and I saw that he had cut&pasted a
bit of my old code into his script, and he left a chunk of dead
code in it.


Me: Do you know what the goal is?

Him: Um - To have a working program as quickly as possible.

Me: Nope. The goal for you to write a program, me to
review it and guide you. To tune our communication, to make
sure we understand each other. To learn from each other.
After we consider it complete, then to review the one I already
wrote, and determine which one should go into production.

Him: Oh. You wrote it already? OK.

I then went over his code, found a couple of ideas to steal
for mine, and made sure he knew that I liked the ideas and
was going to implement them in my code.

We've done 3 back and forth passes so far. He's got some
loops within loops that annoy me (should be factored out),
and a lots of useless copying of variables around (pulls
hash entries into scalars), but it seems workable.
New Make him read the following
1. perldoc perlstyle - I don't follow all the advice, but it is good.

2. Perl Best Practices - It is a good coding set of standards. I don't agree with all of it, and you won't either, but it is good food for thought. (It is very hard to come up with coding standards that are decent for all situations. Damian has succeeded at that. But for specific situations, it is easy to improve on it. Unfortunately it is the nature of the beast that one chance undermines the next rule and you wind up needing to change more than you think. Read it, think about it, and you'll see what I mean.)

3. Code Complete - A classic. If I had my druthers, every programmer would be made to read it. And quizzed until they re-read it until they understood it.

Cheers,
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
     Guide to Troubleshooting Linux Problems - (drewk) - (8)
         Nice resource - (tjsinclair) - (7)
             strace: I would - (broomberg) - (6)
                 I'm glad to say that I don't have that problem - (ben_tilly) - (5)
                     Wouldn't it be nice... - (folkert) - (1)
                         They don't have to - (drewk)
                     This typically occurs with commercial apps. -NT - (broomberg)
                     Speaking of which - (broomberg) - (1)
                         Make him read the following - (ben_tilly)

Any more detail than what's there and you'd have to have the magic software they use in movies to pull a license plate out of five pixels.
91 ms