 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I remember reading about a memory of library stuff who saw somebody
>> using Telnet. She screamed "OH MY GOD, YOU'RE HACKING OUR COMPUTERS!!!"
>> and turned the computer off at the wall. The guy tried to explain what
>> he was actually doing, but she wouldn't have it.
>>
>> Apparently there are a lot of stupid people...
>
> Look at
> http://www.rinkworks.com/stupid/
> for many samples.
http://www.rinkworks.com/stupid/cs_paranoia.shtml
My story is about half way down. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19/04/2011 16:46, Darren New wrote:
> On 4/19/2011 2:45, Invisible wrote:
>> I don't personally know of anybody who actually sent a cheque
>
> AFAIK, I'm the only person in the entire world that ever paid for WinZip.
That's not even shareware any more. You get a free 30-day trail, and
after that you're legally required to pay for it. It's just that nobody
does. (I have no idea if PKZIP was shareware...)
Personally, I just use 7zip.
>> without the net it would have been infeasible.
>
> Yep. And without Windows it would have been infeasible too, because
> there wouldn't be enough people with compatible hardware to have a hope
> in hell of getting it working on enough varieties of machines to make it
> worthwhile.
How did all the other Unicies work?
>> of a lot of money for a program that doesn't even *do* very much and
>> isn't especially complicated.
>
> This coming from the guy who can't find the documentation on how to make
> it do stuff? :-) Granted, most people don't use most of its
> sophisticated features, but saying Word doesn't do much is like saying
> LaTeX just translates one text file into another format, no biggie.
LaTeX *does* just translate a text file into another format. ;-) About
the only special thing about it is that it has a Turing-complete textual
substitution engine and a sophisticated layout constraint solver. It
surprises me that nobody has yet taken the sophisticated layout engine
and put it into a modern piece of software...
>> Silly me, I'm thinking that prices have something to do with what it
>> costs
>> to produce something. This is the 21st century. Prices are driven by how
>> much you can rip people off and get away with it...
>
> They always have been.
Apparently I'm getting old. It used to be that people expected to *get*
something for their money - and if they didn't, they took it elsewhere.
Or at least, I'm now old enough to delude myself that this is how it
used to work.
> Next time you have a problem, I'll show you how to find the answer. It's
> generally not difficult, altho sometimes it can be ugly.
Any idea why printing through Terminal Services keeps breaking for no
apparent reason?
[You used to have to install an identical print driver on the TS server
or it wouldn't work. Apparently they fixed that now, so that's not it.]
I can understand it never working in the first place. What I can't
understand is why it works perfectly, and then one day one particular
user can't print anymore.
> Especially if
> they've rearranged their site and you start getting 404's. Really,
> Microsoft? You run Bing but you haven't figured out how to not have
> internal links to broken pages?
How or to clearly document when a hotfix is included in some later
hotfix or service pack. Or clearly state what product version(s) the
information in a document applies to. Or...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/20/2011 1:25, Invisible wrote:
> That's not even shareware any more. You get a free 30-day trail, and after
> that you're legally required to pay for it.
I think that's how it has always been.
> How did all the other Unicies work?
They were all processor-specific. You bought it from the hardware vendor,
just like you bought Apple DOS from Apple, TRS-DOS from Tandy, etc.
>> Next time you have a problem, I'll show you how to find the answer. It's
>> generally not difficult, altho sometimes it can be ugly.
>
> Any idea why printing through Terminal Services keeps breaking for no
> apparent reason?
Wow. OK, step one, learn to file a bug report.
When you go to the mechanic, do you say "my car's wrong, fix it"? Or do you
actually describe the symptoms, what you tried to do to fix it, what search
terms you used, etc?
> How or to clearly document when a hotfix is included in some later hotfix or
> service pack.
I've seen few rollups that didn't list the hotfixes included, or how to tell
whether you need a hotfix or how to tell whether you already have it, if you
actually read the KB article about it.
> Or clearly state what product version(s) the information in a
> document applies to. Or...
Oh come on.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/19/2011 23:02, Jim Henderson wrote:
> It's far easier if, for instance, you're using a tool like Source
> Navigator (which I really like for this type of thing) you are looking to
> analyze a bug. Having an error code and a call stack makes it far easier
> to use a tool like that than to say "I wonder how it does 'x'" and then
> work through the logic. It's possible, but it can take quite a while.
Here's the thing about that...
There are three steps to debugging a piece of code:
1) Find the symptoms of an error and confirm it's erroneous.
2) Find the program state (i.e., variable values) that isn't as expected at
that point.
3) Trace back the infected state to the defect in the code that caused the
original infected state.
4) Determine how to modify the code to no longer have that defect, hopefully
without introducing infected state that triggers an error from a defect
existent elsewhere.
An error code and a call stack gives you #1. But if you don't know what the
program state is supposed to look like, all you have to go on is the actual
variables that show the error message. I.e., if you don't know even the
slightest amount of what the data in a structure is supposed to be, then
having an error message tell you that a particular pointer is null when it
shouldn't be doesn't help nearly as much as looking at the values and
determining every value in the entire structure is zero when it should all
be filled out with good data.
What's the good data? *That* is what needs to be documented. Otherwise,
you're reading the code, trying to figure out what the code *does*, and once
you do, you *still* haven't even *started* to find the bug. Then you have to
guess what the author *intended* to have happening there, and then guess
from that what the state should have been. *Now* you've finished step #1.
With documentation, all that is tremendously simplified or eliminated,
depending on how detailed the documentation is.
Saying "the code is the documentation" is like saying "the commercial
airliner doesn't need maintenance documentation. You can just look at it and
see what's wrong."
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2011/04/20 10:52, Darren New a écrit :
> On 4/20/2011 1:25, Invisible wrote:
>> That's not even shareware any more. You get a free 30-day trail, and
>> after
>> that you're legally required to pay for it.
>
> I think that's how it has always been.
30 days, 60 days, 5 uses, 10 uses, 30 uses, 45 uses, 60 uses and 90 uses
are at least somewhat common.
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2011/04/19 20:10, Darren New a écrit :
> On 4/19/2011 17:06, Jim Henderson wrote:
>> On Tue, 19 Apr 2011 16:48:35 -0700, Darren New wrote:
>>
>>>> Most OSS projects rely on code as the internal documentation.
>>>
>>> Code is not documentation. Anyone who thinks that code *is*
>>> documentation on any project you feel the need to split into multiple
>>> files is fooling themselves.
>>
>> Of course, that was pretty much what I said in the next sentence after
>> what you quoted.
>
> Even if everyone uses the same style, code isn't documentation. Even if
> only one person works on the code ever, code isn't documentation. Code
> is no more documentation than the steering wheel is your turn signals.
>
Comments, comments, comments and more comments.
That's the only way that code can be used as documentation. That's when
the documentation is actualy writen in human readable form alongside of
the code itself.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/20/2011 10:37, Alain wrote:
> Comments, comments, comments and more comments.
> That's the only way that code can be used as documentation.
Yep. And that assumes you know the right place to look in the code to find
the documentation. Without an overview, you wind up guessing which source
files of which subdirectories you need to read for comments.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2011/04/20 14:23, Darren New a écrit :
> On 4/20/2011 10:37, Alain wrote:
>> Comments, comments, comments and more comments.
>> That's the only way that code can be used as documentation.
>
> Yep. And that assumes you know the right place to look in the code to
> find the documentation. Without an overview, you wind up guessing which
> source files of which subdirectories you need to read for comments.
>
You start the main with a big comment block that contains an exaustive
overview of the project. It's then followed by a table of content and an
index...
Then, each individual source files also contains a specific overview of
the function(s) of the following code, what kind of data it expect and
what kind of data it's expected to return. Don't forget the local table
of content and index.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 20 Apr 2011 07:58:46 -0700, Darren New wrote:
> On 4/19/2011 23:02, Jim Henderson wrote:
>> It's far easier if, for instance, you're using a tool like Source
>> Navigator (which I really like for this type of thing) you are looking
>> to analyze a bug. Having an error code and a call stack makes it far
>> easier to use a tool like that than to say "I wonder how it does 'x'"
>> and then work through the logic. It's possible, but it can take quite
>> a while.
>
>
> Here's the thing about that...
>
> There are three steps to debugging a piece of code:
>
> 1) Find the symptoms of an error and confirm it's erroneous.
>
> 2) Find the program state (i.e., variable values) that isn't as expected
> at that point.
>
> 3) Trace back the infected state to the defect in the code that caused
> the original infected state.
>
> 4) Determine how to modify the code to no longer have that defect,
> hopefully without introducing infected state that triggers an error from
> a defect existent elsewhere.
My experience (recently, anyways) is somewhat limited, but I have done
diagnosis with code+change documentation+snavigator+error code+call
stack. Fairly complex software, too.
But the code in question is pretty clean and even though there's millions
of lines of code, tracing the problem back to the root cause was pretty
simple given the proper tools.
> An error code and a call stack gives you #1. But if you don't know what
> the program state is supposed to look like, all you have to go on is the
> actual variables that show the error message. I.e., if you don't know
> even the slightest amount of what the data in a structure is supposed to
> be, then having an error message tell you that a particular pointer is
> null when it shouldn't be doesn't help nearly as much as looking at the
> values and determining every value in the entire structure is zero when
> it should all be filled out with good data.
>
> What's the good data? *That* is what needs to be documented.
> Otherwise, you're reading the code, trying to figure out what the code
> *does*, and once you do, you *still* haven't even *started* to find the
> bug. Then you have to guess what the author *intended* to have happening
> there, and then guess from that what the state should have been. *Now*
> you've finished step #1. With documentation, all that is tremendously
> simplified or eliminated, depending on how detailed the documentation
> is.
>
> Saying "the code is the documentation" is like saying "the commercial
> airliner doesn't need maintenance documentation. You can just look at it
> and see what's wrong."
I have to admit I like that way of looking at it. :)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/20/2011 13:01, Jim Henderson wrote:
> I have to admit I like that way of looking at it. :)
Elegantly described in detail here, along with what to do about it:
http://www.whyprogramsfail.com/
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
