From: Rob Sacks (editor_at_realization.org)
Date: 2001-07-31 03:43:36
Hi Ken,
> I just found out that I was selected as the project
> lead for a big project at my "real" job so I
> won't have nearly the time I thought I would have
> when I volunteered here in the first place.
Could you clarify what role you're willing to
take now? Maybe you've already talked about
this privately with Waldemar and others but if
there's any public mention of it, I can't find it.
Maybe I've overlooked some messages.
> For collaborative open source to work there needs to a clear
> deliniation of the interface standards in force with the hardware
> portion but beyond that it is pretty much open to each individual
> sofware developer/programmer how they choose to support development
> of display and interaction with the information presented by the
> hardware.
I'm a little puzzled by this because I don't understand
how this applies to our situation. In our case, the hardware
exists and the hw/sw interface is already defined by the
format that Joerg chose for the machine's serial output.
You say, "Beyond that it is pretty much open to each
individual software developer/programmer how they
choose to support...." This would be true if we wanted
each programmer here to write a separate program whose
input comes directly from Joerg's machine, but -- unless
I'm very confused -- this isn't the idea at all. I thought
we wanted all the programmers here to collaborate on
a single program. Am I mistaken about this?
Also, I suspect that when we do get to the stage of
multiple programs on the PC side, the relevant interface
will not be between the hardware and software, but
rather, between a sort of PC engine and PC clients.
This is how the Brainmaster software works. There
is a DLL (call it the engine) that reads the serial port
and converts the voltage time series from the EEG
machine into frequency-domain information. Various
programmers have written applications that take their
input from this DLL instead of the EEG machine.
Regards,
Rob
----- Original Message -----
From: "Ken Michel" <michelangelo46_at_h...>
To: <buildcheapeeg_at_yahoogroups.com>
Sent: Monday, July 30, 2001 10:28 AM
Subject: [buildcheapeeg] Re: Software development outline
> Hi Rob, Yaniv and all,
>
> I am sorry I have been absent for awhile. I just found out that I was
> selected as the project lead for a big project at my "real" job so I
> won't have nearly the time I thought I would have when I volunteered
> here in the first place.
>
> A couple of quick comments:
>
> I closed the polls even though the total number of responses was far
> less than the number of members in the group. I did not intend for
> the polls to become a source of controversy. I was merely trying to
> get a feel as to the variety of current members preferences. It was
> an initial step that apparently had already been decided. If part of
> the idea is to make this information available in kit form or just as
> plans for an enterprizing person to build, there is nothing to
> preclude making a variety of drawings or plans available.
>
> As a software developer, I agree that a needs analysis is the first
> thing that must be done. Since I came in here in the middle of the
> project I was unfamiliar with what had and hadn't been done already.
> I am also not that familiar with professional EEG or Neurofeedback
> protocols. This can often be an advantage I've found.
>
> For collaborative open source to work there needs to a clear
> deliniation of the interface standards in force with the hardware
> portion but beyond that it is pretty much open to each individual
> sofware developer/programmer how they choose to support development
> of display and interaction with the information presented by the
> hardware.
>
> My experience with using "portable code" libraries leaves a lot to be
> desired. I think that we will end up writing code for specific
> platforms at least initially.
>
> From the description of the "needs" identified so far they sound
> suspiciously like desires to me and everything but the
> proverbial "kitchen sink" has been requested by the potential users.
> This is good initially. It can help define a more flexible
> architecture and modularized approach so that new features can be
> plugged in as they are developed.
>
> Sorry but I have to go.
>
> Ken Michel
>
> --- In buildcheapeeg_at_yahoogroups.com, "Rob Sacks" <editor_at_realization.org> wrote:
> > Hi Yaniv,
> >
> > > isn't there anyway to divide this work , for example - one
> architect ,
> > > to write the document ,but then he explains to the experienced
> > > people , and they pass it on ?
> >
> > I think that could happen if we have a few programmers
> > with that kind of experience.
> >
> > If the programmers have less experience, then it's
> > easier if somebody writes the core part of the
> > source code. Then the other programmers have
> > something concrete to work with. They can examine
> > it and add to it and modify it.
> >
> > This is assuming that the other programmers like this
> > idea of writing an application in C++ from scratch.
> > I don't know if that's the case.
> >
> > > rob , do you think help from linux ppl should be need
> > > on managing this ?
> >
> > The Linux project is so big, it's probably a bureaucracy,
> > and I wonder if the experience would be relevant.
> > But I bet we could learn a lot from somebody
> > who had worked on a small open-source project
> > like ours.
> >
> > Rob
> >
> >
> > ----- Original Message -----
> > From: <yaniv_vi_at_yahoo.com>
> > To: <buildcheapeeg_at_yahoogroups.com>
> > Sent: Monday, July 30, 2001 7:05 AM
> > Subject: [buildcheapeeg] Re: Software development outline
> >
> >
> > > hi rob
> > > i read your mail , it's very enlightening on how to develop this
> > > habve some remarks on the message body
> > >
> > > thanks , yaniv
> > > --- In buildcheapeeg_at_yahoogroups.com, "Rob Sacks" <editor_at_realization.org> wrote:
> > > > Hi Waldemar,
> > > >
> > > > > Maybe if you explain in details your swplan for
> > > > > the members, it will make the results of poll
> > > > > more efficient. And I wonder you could help a lot
> > > > > too in practical programming.
> > > >
> > > > Okay. Here's a proposal for how to write the software.
> > > >
> > > > My understanding is that the group wants to produce a
> > > > fullblown neurofeedback program (something in the same
> > > > category as Waveware, BioLex, etc.) that can be extended
> > > > in the future to other forms of biofeedback such as skin
> > > > temperature, skin resistance, and so forth. It will be free
> > > > software under the General Public License.
> > > >
> > > > The program will work with the RS232EEG. (But with
> > > > almost no additional effort on our part, it will also work
> > > > with other EEG machines, so of course we should
> > > > make it work with other machines too.)
> > > >
> > > > If this is correct, then here's what I think the group needs
> > > > to do.
> > > >
> > > > The first step is to complete the needs analysis. I know
> > > > you've worked on this but I'd like to suggest an entirely
> > > > different method based on interface design. (The easiest
> > > > way for users to contribute their ideas is by playing
> > > > with drawings of the proposed interface.) We need
> > > > two volunteers for this aspect of the work, one programmer
> > > > and one user (I bet Jim Peterson would be great at
> > > > this). Let's call these two guys "The Interface Honchos."
> > > > Their job is to put drawings of the proposed screens for
> > > > the new program on the Web and collect suggestions
> > > > from everybody else. They can also publish screen shots
> > > > of existing programs like Waveware and BioLex for
> > > > people to react to. (One of the easiest ways to write
> > > > a functional spec is by letting users criticize existing
> > > > programs.)
> > > >
> > > > The Interface Honchos' job will be complete when they
> > > > have drawings or screen shots of what the actual
> > > > program will look like. All the menus and all the
> > > > menu options will be shown in their drawings. In fact,
> > > > this will be a functional spec in visual form. (If the
> > > > programmer on the Interface Team is ambitious, he
> > > > can implement the interface as a prototype in actual
> > > > code.)
> > > >
> > > > Step two -- and here is what has been holding up
> > > > the project -- is an architecture document. This
> > > > is the blueprint that outlines the basic structure
> > > > of the source code from the programmers' point of
> > > > view.
> > > >
> > > > The architecture document describes the individual
> > > > pieces of the program and (more important) how they
> > > > fit together. Until that happens, nobody can write any
> > > > of the pieces, because nobody knows how his
> > > > individual piece will get invoked by the rest of the
> > > > program, and nobody knows which resources in the
> > > > rest of the program will be available to be invoked by
> > > > his individual piece.
> > > >
> > > > For example, once the architecture is known, we can
> > > > tell each programmer: "Eighteen times a second, the
> > > > program will call a member function in your component
> > > > called OnTick(). That will be the entry point for your
> > > > component. If you need to find out the current FFT
> > > > data for that eighteenth of a second, you can call
> > > > a function in the cFFT module called CurrentData()."
> > > > (I'm making up these details to suggest the kind of
> > > > information that we can specify after we have a
> > > > blueprint.)
> > > >
> > > > It seems to me that the most important thing about the
> > > > architecture of this program is to guarantee that the
> > > > source code can be easily modified in the future. The
> > > > program almost has to be like an engine for future
> > > > plug-ins. Ideally, if we do this right, then after the
> > > > program is complete, a new programmer should be able to
> > > > add a new piece to the program without changing any
> > > > existing code. Sound impossible? It's possible, but it will
> > > > require some clever planning at the beginning.
> > >
> > > if we could have this -GREAT!
> > >
> > > >
> > > > After we agree on the architecture, we'll make a list
> > > > of the individual pieces -- the components, which
> > > > presumably will be implemented as C++ classes --
> > > > and devise a schedule for writing them. The goal
> > > > with the schedule is to be able to build a version of
> > > > the program that runs almost from the first day. It will
> > > > have very limited functionality, but it will run. This makes
> > > > development much easier. (I think we should use daily
> > > > builds, incremental development, and zero bug counts.
> > > > That kind of stuff is a big help, and we need all the help
> > > > we can give ourselves.)
> > > >
> > > > (Incidently, if anybody wants to read good books
> > > > about the sorts of development strategies I'm outlining
> > > > here, I recommend two books by Steve McConnell, both
> > > > published by Microsoft Press: "Rapid Development" and
> > > > "Software Project Survival Guide." The second book
> > > > is intended for managers and customers, not just
> > > > programmers, and everybody here might want to consider
> > > > looking at it.)
> > > >
> > > > The next step is for each programmer to volunteer to
> > > > write a chunk of the program. Actually, it would be great
> > > > if each programmer plays two roles. Role number one,
> > > > write a chunk. Role number two, review somebody else's
> > > > chunk. That way we can do real live code reviews just
> > > > like the big boys at Microsoft.
> > > >
> > > > The next step... well, that's enough for now. You'll notice
> > > > that I didn't talk at all about ports or operating systems.
> > > > To me, there really isn't any choice. If the group wants
> > > > a really good-looking program, one with outstanding
> > > > graphics and sound, it will have to be a native program
> > > > (i.e., written directly for the OS in question), and obviously
> > > > if we're writing for just one OS, it's going to be Windows.
> > > > Windows implies DirectX and Microsoft Visual C++.
> > > >
> > > > Alternatively, we could go with the strategy suggested
> > > > by Moritz and Joel -- portable code, multiple operating
> > > > systems, GUI library -- but I am skeptical that we can
> > > > achieve the same quality of graphics and sound, and the
> > > > maintenance will be greatly complicated by the fact that
> > > > the program will become dependent on maintenance of
> > > > the GUI library. In general, any time you use a third-party
> > > > library, you add a risk factor to your program, because
> > > > new versions of the operating systems will probably break
> > > > the library, and we'll be dependent on the library publisher
> > > > to publish new versions quickly. If whoever wrote the
> > > > library stops supporting it... not good.
> > >
> > > one question how much percent is interface and how much percent
> is
> > > code ?
> > > because win98 is great but also another goal - maybe not for now ,
> > > is portable device using palm pilot . so how hard you think it
> would
> > > be to "transport" the win98 version to palm ?
> > > also this may require palm interface design in later stage .
> > > also maybe the s.w. should be build in a certain way for this or
> > > there should be no problems (maybe cheking memory and speed ?)
> > >
> > > >
> > > > I didn't mention the port question because it's trivial
> > > > from the software point of view. It's a hardware issue,
> > > > not a software issue. We can add support for new
> > > > types of ports to the program almost instantly at any
> > > > time. At the moment, our hardware has a serial port,
> > > > so obviously we need to write the program that way.
> > > >
> > > > Of the issues I raised, I think the hardest one is
> > > > the architecture. In order to create a good architecture,
> > > > a person usually needs to have a few years' experience
> > > > writing whole applications. We don't seem to have a lot
> > > > of folks here like that. Also, it's hard to do that by
> > > > committee. In fact, I can't imagine it happening here by
> > > > committee.
> > > >
> > > > The way I can imagine it happening is, somebody (let's
> > > > call him the architect) writes a proposed design. He posts
> > > > it. Everybody else reads it. They give criticisms, suggestions
> > > > for changes, etc. The architect makes changes until
> > > > everybody is happy (or too exhausted from arguing to
> > > > argue anymore.)
> > > >
> > > > The biggest problem I see is that the architect is going to
> > > > end up as the lead programmer, and not only that, he
> > > > may end up spending a lot of time teaching other
> > > > people about various aspects of writing software. So he
> > > > had better have a LOT of time on his hands!
> > >
> > > isn't there anyway to divide this work , for example - one
> architect ,
> > > to write the document ,but then he explains to the experienced
> > > people , and they pass it on ?
> > > rob , do you think help from linux ppl should be need on managing
> > > this ?
> > > does anybody kno wnay linux guy ?
> > >
> > > >
> > > > By the way, when is Kenneth coming back? :)
> > > >
> > > > Regards,
> > > >
> > > > Rob
> > >
> > >
> > >
> > > To unsubscribe from this group, send an email to:
> > > buildcheapeeg-unsubscribe_at_egroups.com
> > >
> > >
> > >
> > > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
> > >
> > >
>
>
>
> To unsubscribe from this group, send an email to:
> buildcheapeeg-unsubscribe_at_egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:31 BST