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