[DUG] Validating CDS files

Tue Jan 18 15:28:52 NZDT 2011

Jaffas certainly were not in the original specification that I extrapolated
from your statements as an end user. My company will outsource to a committe
in india. I'm guessing they will come back with Maltezers as a more soothing
and relaxing option thats easier on the teeth.. But to be sure.. We will get
at least 5 independant opinions. Rest assured that the 5 opinions will only
be the cost of 1/4 of my own opinon on an hourly rate, and that my opinion
will only serve as an overview to make sure their opinions on the matter
serve you appropriately.

And if you change yourmind again, we have a persuasive sales team skilled in
the Salt and Vinegar industry.

LOL

On Tue, Jan 18, 2011 at 2:13 PM, David Brennan
<dugdavid at dbsolutions.co.nz>wrote:

> ROFL.
>
>
>
> Feels like a Friday afternoon... ;-)
>
>
>
> I can see both sides. I think there is a difference between dealing with a
> user/customer who generally speaking should be assumed not to be an expert
> on IT matters and therefore integrated deeply on exactly what it is they *
> REALLY* want/need, and dealing with another IT professional where a much
> more superficial checking that you both have the same understanding of the
> problem usually suffices.
>
>
>
> OTOH it is a balancing act and Paul’s suggestion of zipping XML CDS files
> which sounds like it might help might not have come about without more
> indepth discussion of the real problem.
>
>
>
> Oh, and I think you’re right, popcorn probably wasn’t the right thing but
> I’m not sure chips suit either, maybe Jaffa’s would be the ticket, great for
> watching movies anyway. No doubt given the chance to do a full analysis you
> would have got there ;-)
>
>
>
> Cheers,
>
> David.
>
>
>
>
>
>
>
> *From:* delphi-bounces at delphi.org.nz [mailto:delphi-bounces at delphi.org.nz]
> *On Behalf Of *Kyley Harris
> *Sent:* Tuesday, 18 January 2011 1:40 p.m.
>
> *To:* NZ Borland Developers Group - Delphi List
> *Subject:* Re: [DUG] Validating CDS files
>
>
>
> I'm wondering if you analyzed your need for popcorn carefullly. You asked
> for popcorn.. you got your popcorn. but perhaps you've been taken for a
> ride. If we analyze your need carefully for an hour, what we could have
> determined is that you truley wanted a 30 minute comedy show, and some salt
> - and -vinegar chips to go with it. Not popcorn at all. Perhaps the desire
> for popcorn stemmed from your not correctly seeing your needs in the first
> place. I feel its my duty to help you access the situtation so that you get
> what you need and not what you want.
>
> We could discuss this further privately, and I'm sure with all my
> experience in these situations that a 3 hour lunch break daily, with said
> included comedies and chips will satisfy your needs more appropriately.. The
> Popcorn is just a bandaid.
>
> On Tue, Jan 18, 2011 at 12:44 PM, David Brennan <
> dugdavid at dbsolutions.co.nz> wrote:
>
> Mmmm, I'm enjoying my popcorn as I watch...
>
>
> -----Original Message-----
> From: delphi-bounces at delphi.org.nz [mailto:delphi-bounces at delphi.org.nz]
> On
> Behalf Of Matthew Comb
>
> Sent: Tuesday, 18 January 2011 11:12 a.m.
> To: NZ Borland Developers Group - Delphi List
> Subject: Re: [DUG] Validating CDS files
>
> > Those developers that came back with "TO DO" lists were perhaps
> themselves
> > not taking the time to understand the customers problems.  The customer
> > told
> > them "those 10,000 features are great, but we'd really like X, Y and Z",
> > so
> > the developers simply came back to you with that list of "X, Y and Z".
> >
> > Far from analysing too much, they were most likely not analysing
> *enough*.
>
> What your argument does not take into account yet again (which was my
> point that was missed), is the time and money factor. If you have a 1 day
> or 2 day install, you do not have time to spend all 2 days taking on
> customer requests when the customer is not yet up to speed with the
> capabilities of the system. A customer often doesn't know what they need
> until they get to use the system, then their requirements frequently
> change. If you have unlimited time and money then by all means, spend
> every waking moment analysing each and every item raised, Cameron would
> probably tear his hair out.
>
> >
> >
> > That specialist you hired is most likely looking at the X, Y and Z and
> > then
> > asking the customer... "But what do you need X, Y and Z for?" then
> showing
> > them that they already HAVE X, Y and Z among the 10,000 other features.
> >
> >
> > That quite neatly demonstrates my point I think.  Understand the
> > problem...
> > not only might the solution you are asking for not be ideal, but you
> might
> > already be in possession of the solution !!!
> >
>
> I don't think it does at all.
>
> >
> >
> >   "I have a legacy piece of software which very very rarely corrupts a
> >    local data file - fact"
> >
> > The real problem to be solved is how/why the corruption occurs...
> > everything
> > else is just sticking plaster, not a solution, and even the sticking
> > plaster
> > can only help if you apply the right sort of dressing correctly.
>
> Thats right, that is the root problem, but as this piece of software has
> been in the field for 8 years, and is being decommissioned, there isn't a
> lot of point in that is there. So a bandaid is more than adequate.
>
> >
> >
> >   "Regardless of the better long term solutions, we will take
> >    a defensive programming measure to protect against the loading
> >    of corrupt files."
> >
> > And my point in this area was that unless you understand how/where the
> > corruption is occurring, the defensive measures you might take may very
> > well
> > end up not being defensive at all.
>
> If you validate a CDS file, and don't load it if it is corrupt. That is a
> defensive measure.
>
> >
> > e.g. the idea of checksuming the output from the server...  if the data
> > coming from the server is corrupt from the get-go, then check-summing
> > helps
> > you not one little bit.
> >
>
> Agreed which is why I didn't ask about it.
>
> >
> >
> > You initially blamed the corruption on a flaky wifi connection - highly
> > unlikely for the reasons that I and others have explained.  You then
> > explained that you were streaming the data, so the corruption might occur
> > in
> > sporadic bytes in the stream.
>
> I do not believe I did suggest the contents of the stream would be
> changed. What I said was that a TCP steam can be disconnected.  this was
> yet another wild assumption on your part. If you send a 1GB file through a
> stream, it is NOT as Kyley suggested an All or Nothing approach. You are
> taking bytes into a stream. It is up to you whether or not you discard the
> stream based on a disconnection or not. That decision point is out of my
> control as it is Midas + DBX4MySQL which manages this.
>
> >
> > But then you seemed attracted to the idea of using XML as a potential way
> > forward, which would seem to contradict the streaming nature of the data
> > transmission.
>
> The incorrect assumption you made at the beginnning was that the CDS file
> was coming from the server as a file payload. Its not. The client is
> connecting to MySQL DB server directly. All suggestions and
> misunderstandings about hashing, file downloads, etc were based on that
> incorrect assumption.
>
> >
> > And now you admit:
> >
> >    "I do not know yet where this corruption occurs. DB Server, Drivers,
> >     In Memory, Saving of the file, Server DB."
>
> I don't, and it doesn't matter. Why ? Because at a rate of 1/10000 it is a
> manageable issue, and with the software being decommissioned it is good
> business sense to investigate the server mechanics. its better to bandaid
> and move on.
>
> >
> >
> >
> >
> >
> >   "Its not true to take the standpoint that if someone asks for the
> > solution
> >    then they should be able to provide it e.g  If I ask for Word 2010
> > should
> >    I be capable of sitting down and writing the application suite?"
> >
> > I didn't say that they *should* be able to provide it in the sense that
> > you
> > took it to mean - I said as to draw attention to the inherent
> > contradiction.
> > The only way you can confidently ask for a solution in the form of a
> > solution specification, without explaining the problem, is if you fully
> > understand the problem and *could* provide the solution yourself.  In
> > which
> > case, you would never have needed to ask someone else to provide the
> > solution for you.
>
> Thats just rubbish.
>
> >
> > In other words, when someone asks for a solution, rather than stating a
> > problem, the likelihood is that they are asking for the wrong solution
> > from
> > the very start!
>
> Statistically probably correct more often than not, but still an arrogant
> assumption that the person is clueless / uninformed of possible solutions.
>
> Its also arrogant to assume you know everything abou the motivation and
> drivers as to why the person asked the question in the first place.
>
> For example in this case, the fact that the software is being
> decommissioned and the fact that its rarity does not make a server
> solution fiscally viable.
>
> >
> >
> > Your "Word 2010" example this is a quite different sort of request from
> > what
> > we are actually discussing (it's not a "technical solution" just a
> > shopping
> > list), never-the-less even this inappropriate parallel can be used to
> > illustrate the same point:
> >
> >
> > If you ask for Word 2010, should I just sell it to you simply because you
> > can't write it yourself ?
>
> That logic much like the rest of your logic is flawed. I did not say that
> you should sell it to me because I could not program it. You should sell
> it to me because I asked to buy it.
>
> I am asking to buy it, because I don't want to program it.
>
> >
> > Or should I first ask what you need it for.... ?
> >
> > If you tell me you want it for doing bulk emails, and you heard that Word
> > 2010 has some neat mail-merging capabilities, then I am pretty confident
> > that I can sell you a better solution for your needs than just handing
> > over
> > a copy of Word 2010.
>
> Again you are incorrectly assuming that the person asking the question is
> a retard.
>
> >
> > I could just give you what you want, but that may not be what you need.
> >
>
> Its not your decision to make.
>
> >
> > Incidentally, nobody "gave me" a blog.  I created my blog in order to
> > share
> > my skills and experience and - if my stats are to be believed - many,
> many
> > people appreciate it.
>
> Actually I've found your blog to be very good and useful. I feel that if
> you reigned in the arrogance a tad, you might get places faster.
>
> > I gain some sense of satisfaction from the fact that people (well, *some*
> > people at least) seem to appreciate my effort, but it certainly doesn't
> > "go
> > to my head".
> >
> > _______________________________________________
> > NZ Borland Developers Group - Delphi mailing list
> > Post: delphi at delphi.org.nz
> > Admin: http://delphi.org.nz/mailman/listinfo/delphi
> > Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
> > unsubscribe
> >
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at delphi.org.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
> unsubscribe
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at delphi.org.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
> unsubscribe
>
>
>
>
> --
> Kyley Harris
> Harris Software
> +64-21-671-821
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at delphi.org.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
> unsubscribe
>

-- 
Kyley Harris
Harris Software
+64-21-671-821
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20110118/fcccc046/attachment-0001.html 