From: Peter Olcott on

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
message news:mtk6r5hecbpgf40ess1dfla1p4dmg4b50b(a)4ax.com...
> See below...
> On Tue, 30 Mar 2010 13:39:29 -0500, "Peter Olcott"
> <NoSpam(a)OCR4Screen.com> wrote:
>
>>
>
>>
>>
>>Remember how we met? (In a 2005 email, about this article
>>of yours)
>>
>> http://groups.google.com:80/group/microsoft.public.vc.mfc/msg/74db496855f60a0f
>>
>>That said, there is almost no reliable way to send mouse
>>clicks to an application; lots of
>>people have tried this and failed. You are in the model of
>>"I want to write a Windows
>>scripting language", and it is nearly impossible to get
>>right. I've been involved with at
>>least two projects that failed miserably
> ****
> Hmm. I just re-read that article, and I think it is all
> still true today. And both those
> projects DID fail, so that is completely true. And there
> is still no really reliable way
> to simulate mouse clicks in an application. So what is
> the point you are trying to make
> here?
> joe

This was cut from an August 7, 2006 email to me from you
regarding the above link:
Interesting. This does sound like the first viable approach
I've heard in a
long time.
joe

> ***
>>
>>
>>>
>>> ****
>>>>
>>>
>>> Joseph M. Newcomer [MVP]
>>> email: newcomer(a)flounder.com
>>> Web: http://www.flounder.com
>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>
> Joseph M. Newcomer [MVP]
> email: newcomer(a)flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm


From: Peter Olcott on

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in
message news:04l6r5pbufl74s28tl65irc89upid2al4g(a)4ax.com...
> See below...
> On Tue, 30 Mar 2010 17:42:28 -0400, Hector Santos
> <sant9442(a)nospam.gmail.com> wrote:
>
>>Joseph M. Newcomer wrote:
>>
>>>> Sure I have you just haven't gotten to it yet, email. I
>>>> haven't got any more time for this discussion. I am
>>>> convinced that I will get it right. I will get back to
>>>> you
>>>> on this when I am pretty sure that I have it right and
>>>> you
>>>> can double check my final design.
>>> ****
>>> Oh, in your fantasy world, email is a reliable delivery
>>> mechanism? It isn't out here in
>>> the real world. And did you read Hector's comments on
>>> email acknowledgement (and he's far
>>> more an expert on email than I am; all I know is that
>>> there are serious reliability issues
>>> with email; the evidence is that people send me email
>>> which I never receive, and which
>>> never even arrive at my ISP, although there is a record
>>> that they were sent).
>>
>>
>>I am an active member and contributor of the SMTP working
>>group/mailing list. I'm acknowledged in the RFC 5321 SMTP
>>specification.
>>
>> http://tools.ietf.org/rfc/rfc5321.txt
>>
>>including acknowledged in the recently RFC 5598 endorsed
>>creation of
>>the "Internet Mail Architecture," document by one of the
>>fathers of
>>electronic mail, David Crocker:
>>
>> http://tools.ietf.org/rfc/rfc5598.txt
>>
>>I write and market a very highly integrated modern mail
>>system and
>>been doing mail systems since the 80s. I think I know
>>maybe *a
>>little* about this. :)
> ****
> Which is why I said your credentials were better than mine
> in this area!
> ****
>>
>>> Apparently, you once read an article on email, and now
>>> believe you understand it
>>> completely. Even your concept of a "veriiable email
>>> address" shows a degree of
>>> cluenessness that is, alas, unsurprising.
>>
>>
>>Abstract level thinking :) which is ok, if he had the
>>integration right.
>>
>>For example, for all this fault tolerant talk, if the
>>machine dies ,
>>how can it even send email? That means he needs an
>>integrated
>>redundancy that deals email. His database has to be on a
>>remote
>>server as well which I'm sure he didn't take into account
> ***
> If he uses a transacted database, upon recovery, there can
> be a process that scans the
> database and detects a transaction that was "in flight"
> but "uncompleted" and send the
> email then. Of course, this can take the 500ms limit to
> hours or days, but what's a
> little flexibility with the realtime window, given the
> mooshiness of the rigid and
> non-negotiable requirements.
>
> Of course, this DOES presume that "recovery" is a
> possibility; if the hard drive fried,
> there IS no "recovery"
>
> Oh, wait a moment: he's using RAID 1. And we know that it
> has ZERO performance cost over
> a regular hard drive, because he wouldn't choose to use it
> had any performance penalty.
> Unless throwing buzzwords around has zero cost. And this
> presumes that someone decides
> that it not simply easier to replace the failed computer
> without trying to do any
> recovery. Of course, this would be part of his contract
> with the ISP, to guarantee that
> no matter how cost-ineffective it is for the ISP, the ISP
> will have to try to do recovery.
> And the commodity ISP will agree to this without charging
> extra. And all the little pink
> puppies will live happily ever after, the evil sorceror
> will be conquered, and the Ring
> will be returned to the volcanoes of Mordor. Sorry, I get
> carried away. I sometimes lose
> my grasp of what is fantasy and what is reality.
>
> (And in December, a component failure in the SCSI
> backplane of my server corrupted two of
> my three RAID-5 drives. So much for redundancy.
> Fortunately, my Business Continuity
> clause in my insurance policy meant that my business
> insurance covered the US$6,000
> recovery cost).
> joe
> ****

If the only thing that I must insure does not occur is that
the customer is not charged for a transaction that did not
complete, this simplifies the design. For every complex set
of issues there is always a way to minimize the effective
complexity.

One thing that I need to know hopefully without the need to
read a 1,000 page book first, Is there any way that the
sender of an email message can automatically confirm that an
email was received. This is one of the questions that I know
needs to be answered and if no one else is helpful on this I
will eventually find it elsewhere.

If email has precisely measurable reliability, then on the
fly backups of transaction details can be made.

>>
>>He hasn't come close to realizing what are all the
>>integration and
>>communications issues are. He discovers another piece on a
>>daily basis
>>but just fails to see how things fit - which is OK, not
>>everyone can
>>be a good integrator, but Joesph, Mary, Charlie, Peter,
>>John, Sally
>>and David - this guy really wants to act like a maroon and
>>as Delgado
>>said, he really thinks he is serious!
> ****
> Real systems are astoundingly complex. Which is why, when
> I had to do massive complex
> integration, I got experts to help me. Key to this is
> that I LISTENED CAREFULLY to what
> they were telling me. I outsource my site maintenance,
> because I don't want to be
> bothered with concepts such as "roaming profiles". I now
> know what they are, but I still
> don't want to know the details. And this costs me real
> dollars to get this support.
> Several hundred a month.
>
> I had to build a computer room in 1981 (for computer
> delivery in March, 1982, of a huge
> mainframe computer). I had to learn HVAC, humidity
> control, fire systems, power
> distribution (did you know that most industrial buildings
> have 240-volt delta 3-phase
> systems, and mainframes of that era required 208-volt Y
> 3-phase power? I didn't when I
> started, but a $20,000 delta-to-Y converter with power
> conditioning and regulation solved
> the problem...) I spent close to $100,000 building that
> room, and there was no room for
> error. It had to be perfect. You better believe I got
> REAL experts involved early! HUGE
> sets of interacting systems (how does the HVAC system shut
> down the computer when it
> fails? I BUILT the relay box that activated the shutdown!
> I had to, because the signals
> produced by the HVAC system were incompatible with the
> inputs required by the power
> system, so I had to DESIGN it as well. And another to
> handle the signals from the fire
> supression system (Halon), because its signals were
> incompatible with the power
> conditioning system) Later people dealt with interfacing
> the Internet to our machine, a
> nontrivial action in those days (1982), that involved
> boxes that cost $70,000 each (we
> needed two), expensive and special lines from the
> predecessor of Verizon (Bell of PA), and
> integrating problematic software into the operating
> system. By that time, I'd hired
> experts to do this for me. And I listened to them, and
> they had to convince me that they
> were about to do the right thing, and that all
> alternatives had been explored, and we had
> real budget numbers and schedules with milestones. I
> could do this because for nearly a
> year I had been the person having to do that. (Operating
> systems in those days did NOT
> come with TCP/IP built-in! In fact, TCP/IP was the New
> Kid On The Block, just having been
> released, so even FINDING the appropriate software was a
> challenge)
>
> I see none of this "due diligence" being manifested in
> these conversations. Not that we
> aren't trying to tell him.
>
> The almost-daily morphing of the requirements is seriously
> scary. The fact that new
> requirements keep getting added that are incompatible with
> previous requirements is not a
> good indicator. The fact that every problem is solvable
> with an apparently zero-cost
> buzzword (which is usually used incorrectly) is not a good
> indication.
>
> But boiled down to its essence, it is simple: this system
> shall be perfect in all ways.
> And this perfection will require zero effort, and incur
> zero performance cost, and zero
> dollar cost. And zero support cost.
>
> Corollary: this system will be such a finacial success (at
> $0.10/transaction) that he will
> soon have unlimited funds to hire people to solve all the
> very real problems he has been
> ignoring. [He even said so!]

It is not a matter of counting my chickens before they
hatch, it is a matter of simple arithmetic. The minimal
system will be able to handle at least 10 transactions per
second. (With the redesign it is looking more like 100 per
second now). I will have to have sufficient load on my
system before upgrading it is justified. There is no sense
upgrading a system for much better performance if peak load
it is only at 1% of capacity. This 1% of capacity produces a
dime a second. Even an huge degree of difference between
peak load and average load should not change this overall
evaluation much. Whenever I do need to upgrade beyond a
single core processor, I will be able to afford it, and it
looks like a long time before I will need to upgrade.

>
> One thing I learned being self-employed: every expense
> turns out to be expressible
> precisely in hours of my time. So to hire me for 1 hour
> will require 1,000 transactions.
> And I'm cheap (I've been told I consistently underprice
> myself). A full-time person
> requires about 2,500 transactions for every hour they
> work, so to support a full-time
> person requires 1370 transactions every day, 57
> transactions/hour EVERY HOUR OF EVERY DAY
> just to break even. That's a little under 1/minute

Right and the cheap single core processor can do 100 per
second, so there is a much greater chance that I would hire
you or someone else than there is that I would need to
upgrade beyond a single core, thus all this talk about
multiple threads or multiple processes is not really
cost-effective for me right now.

>
> Oh, I forgot. I've also had to develop business plans,
> work with people developing
> marketing plans, and so on. I guess this has given me
> unfortunate biases about how to
> deal with costs. It must be wonderful to go through life
> free of all biases. Then
> ANYTHING is possible!
>
> Note that by handling an average of 1/minute 24/7, this
> produces zero profit, does not
> cover the cost of the server, just enough to cover the
> base salary ($50,000) of one
> full-time person. I have not taken into account other
> costs, such as payroll taxes,
> health insurance, and other overheads. Half a million
> transactions per year, just to
> cover salary. One ring to rule them all...and the Three
> Little Kittens found their
> mittens, and everyone lived Happily Ever After. Whoops,
> there I go, losing my grip on
> reality again...
> joe
>
> Joseph M. Newcomer [MVP]
> email: newcomer(a)flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm


From: Hector Santos on
Peter Olcott wrote to Joe

>>>

>>> The official C++ standard defines a std::vector as
>>> contiguous memory are they wrong too?
>> ****


>> They require contiguous VIRTUAL memory. Essentially, they
>> require contiguous memory in the environment in which
>> the code is operating, and in the case of a virtual memory
>> system, that means contiguous VIRTUAL memory, which
>> probably is NOT contiguous physical memory!

> OK. I also read the Wikipedia article that says a lot of
> what you said. I never realized before that Virtual Memory
> also handles memory fragmentation.

Oh brother!

You might go down in history has the first virtual fragmented product
purely designed around virtual fragmented world of WikiPedia
information. I'm going to coin a new term - Virtual WikiFragments!
you heard it here!

--
HLS
From: Pete Delgado on

"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message
news:bsGdnZJPcN687C7WnZ2dnUVZ_vednZ2d(a)giganews.com...
> If the only thing that I must insure does not occur is that the customer
> is not charged for a transaction that did not complete, this simplifies
> the design. For every complex set of issues there is always a way to
> minimize the effective complexity.
>
> One thing that I need to know hopefully without the need to read a 1,000
> page book

Had you taken the time to read portions of the 1,000 page books and various
articles that were suggested much earlier in this thread, you might have
saved yourself a lot of requirements thrashing and the embarassment of
looking ignorant when people suggested various solutions to you.

I realize that not everyone can read hefty technical tomes and come away
with an understanding of the topic, but in many cases sitting down with a
good book on software development can pay dividends in years to come. Thus
far I haven't seen anything suggested to you that isn't well written,
interesting and full of good information. Why not give it a try???

-Pete



From: Peter Olcott on

"Pete Delgado" <Peter.Delgado(a)NoSpam.com> wrote in message
news:uPWXKvP0KHA.3624(a)TK2MSFTNGP05.phx.gbl...
>
> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message
> news:bsGdnZJPcN687C7WnZ2dnUVZ_vednZ2d(a)giganews.com...
>> If the only thing that I must insure does not occur is
>> that the customer is not charged for a transaction that
>> did not complete, this simplifies the design. For every
>> complex set of issues there is always a way to minimize
>> the effective complexity.
>>
>> One thing that I need to know hopefully without the need
>> to read a 1,000 page book
>
> Had you taken the time to read portions of the 1,000 page
> books and various articles that were suggested much
> earlier in this thread, you might have saved yourself a
> lot of requirements thrashing and the embarassment of
> looking ignorant when people suggested various solutions
> to you.
>
> I realize that not everyone can read hefty technical tomes
> and come away with an understanding of the topic, but in
> many cases sitting down with a good book on software
> development can pay dividends in years to come. Thus far I
> haven't seen anything suggested to you that isn't well
> written, interesting and full of good information. Why not
> give it a try???
>
> -Pete
>
>
>

I can only do that to the extent that it is cost-effective.
I am doing that now on those things that I must know in
depth, so far that is three books totaling 2500 pages. The
reason that I come to the various newsgroups is to reduce
the search time. I could simply read a couple dozen 1000
pages books and skip this newsgroup step.

When I ask whether or not there is a way to verify with
certainly that an email message has been received, providing
a yes or a no does not take that much effort. referring me
to the current working set of email specifications is not
very helpful.