Re: Fastest way to search text file for string
From: Julie (julie_at_nospam.com)
Date: 09/22/04
- Next message: James Curran: "Create an object from an object."
- Previous message: craig: "Re: quick question..."
- In reply to: Drebin: "Re: Fastest way to search text file for string"
- Next in thread: Julie: "Re: Fastest way to search text file for string"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 22 Sep 2004 12:40:48 -0700
Drebin wrote:
>
> Julie,
>
> Just one other random thought, if I may. I guess the reason why you are
> finding so much resistance is that pretty much everyone - except for you -
> finds "solutions" in their jobs and remains open-minded in their work. Very
> rarely are we asked to blindly "fill these requirements". Our industry is
> such that, most companies simply can't afford to work that inefficiently.
> Instead, most companies give a developer a "problem" and we are to use our
> expertise to find the most efficient solution. "Efficient" means not only
> the fastest to implement, but also the the most scalable and easiest to
> change.
Your points would be valid if: you were talking to someone that didn't know
what they were doing and/or asked for comments on process. Neither of those
apply to me.
I'm *very* open minded, I examine all of the potential solutions that I can,
and make informed decisions. I did that work before posing the original
question. I challenge you to be a little more open minded and realize that
simple-text searching can be (and IS! in this case) a valid solution to the
problem posed.
I work very closely w/ those that define the requirements, I know exactly what
they want, and they are informed as to the details, costs, issues, etc.
Honestly, I had gone your route and implemented this using a database, it would
have completely changed the disposition of the components that I'm working on,
the installation requirements, licensing requirements, base system
requirements, implementation time frame, complexity, maintainability, version
issues, etc., etc., etc. Absolutely none of that can be tolerated on the
project for a relatively simple part of the component that I'm working on.
> In other words, when we hear such unreasonable requirements as you've
> vaguely defined, everyone's first reaction is to get a handle on those,
> because they don't sound reasonable.
Answer me one question: how can you determine that those requirements are
unreasonable?
> When someone comes to me with with
> outrageous requirements, I don't even BOTHER trying to answer the original
> question, because 99% of the time, they don't have a handle on the problem.
> But I'm gathering from your reaction and style that you likely work in the
> gov't or aerospace - and I know that is a completely different mindset
> there.
Oh wise sage, I work in neither of those disciplines.
> Anyhow - for future reference, it would probably be a big time-saver if you
> were to actually share (in some level of detail) what your requirements are.
> What IS the format of this data? Because without that, you come off as an
> inexperienced and stubborn developer that is not pushing back on
> unreasonable requirements when you CLEARLY should be (in our minds). So, if
> you want people to stop reacting to your requirements, it might be best to
> actually go into some detail about why they are so immutable so people can
> get past it - and start helping with your actual problem.
How about this, for your future reference: try answering the question posed,
don't spend so much time trying to read more into it than exists. If you have
questions about the requirements, ask them _after_ you have answered the
original question. Otherwise, you come off as a know-it-all.
Finally, my requirements were well defined, you just don't happen to want to
believe them.
>
> For whatever it's worth..
>
> "Julie" <julie@nospam.com> wrote in message
> news:414FB738.C3C73C6E@nospam.com...
> > James Curran wrote:
> > >
> > > Daniel O'Connell [C# MVP] wrote:
> > >
> > > > For what its worth, this heavy push for a database is probably
> > > > foolish.
> > >
> > > But I'm not pushing heavily for a database. I'm pushing heavily in
> > > favor of looking beyond a very naive reading of the requirements, and
> > > putting some knowledge of the domain space behind the problem.
> >
> > Thanks for the insult of calling me naive.
> >
> > I really find it hard to believe that you think that I can't understand
> what my
> > requirements are.
> >
> > > For example, I have trouble believing that the input data here
> > > ("datafiles from external laboratory instruments") are completely
> free-form.
> > > There's probably recognizable rows & columns. Further, I don't believe
> > > searching would generally be limited to one search per file, so reading,
> > > indexing, do several indexed searches, and then expiring the indexing
> would
> > > probably be faster than doing several simple text searches.
> >
> > I still don't see where I'm asking for anything faster than 1 hit in a 100
> MB
> > file in 10 seconds or less. That is all that the performance requirement
> > dictates. Anything more is completely wasted effort.
> >
> > I appreciate your comments and suggestions, but please, don't become so
> focused
> > on what you think is necessary that you completely ignore what I know to
> be the
> > requirements.
> >
> > Thanks
- Next message: James Curran: "Create an object from an object."
- Previous message: craig: "Re: quick question..."
- In reply to: Drebin: "Re: Fastest way to search text file for string"
- Next in thread: Julie: "Re: Fastest way to search text file for string"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
