Re: [Anarchdb-devel] Re: database layout questions?

[Meshee]

2006/3/13, Karl George Schaefer <address@hidden>:
> Removed extraneous text for this reply (for clarity).  There is some good
> development talk in the previous messages, though.
same

> Well, no one's actually place a date on us.  But, we've all sort of nodded
> that we need to have the new version out quickly afterwards.  In the past,
> that was about a week after, so we should try to keep up the pace.

Good, having a goal will help involving everyone.
> I consider refactoring a great way for a developer to learn about his code
> base.  I would push it higher on the spectrum, simply because it gives the
> newer developers a greater sense of code ownership and a deeper
> understanding of how the code actually works.  We have very few known
> issues and it might be best to wrap them into refactoring.

a agree with you but i also use to call refactoring "rebugging" :) so
i would go smoothly with low level refactoring.

>  Also, as I've
> looked at all of the known issues, some will be difficult to reproduce.  We
> need to get a Mac developer to check out some of them.  If we can't
> replicate the problem, we'll need to wait until it's reported again in a
> better fashion.


> >
> > Agree, the app is deadly missing developpers docs. we should consider
> > including doxygen to our building env to generate doc.
> Never used it.  But, my chief language is Java, so sure whatever everyone's
> comfortable with.  Do you have a link to information about how to use
> Doxygen?
http://www.stack.nl/~dimitri/doxygen/

well i guess we were able to find that out :o)

I used it years ago for a c projet, basically it is a codebase parser
that works like javadoc (search metatages in comments) so we should be
at home

>
> >> 2.  A UI group focused on good UI design that encompasses a heuristic
> >> methodology about user interaction will give ARDB a higher level of
> >> polish.
> >
> > Agree. The best way should be to do it user-driven
> But, we should endeavor to give the users a good product to begin with.  I
> have a list of UI heuristics that I use when developing an application.
> I'll post them later.

We should setup a wiki where we could put our 'best-practices',
roadmap, tips and tricks etc...

> > agree, we should also take care of françois deck morphing issues.
> What's this?

xml decks that are not restored in the UI the wahy they were stored, i
guess it is related databases changes that cannot be pushed to xml
data (card id that change value between two updates for example)

> > Yes, i did notice that the codebase does not include any automatic
> > unit tests. That is something i'm willing to promote.
> Sure.  I used to do QA work and hated it.  So, if you're willing...

Well i won't sign for QA :o), but having some unit test to avoid
rebugging would be great, especially in the future if we split the app
in persistance/business/ui.

> > None the less i think we need to evaluate our task force to see what
> > is acheavable in short and long terms
> So, we have a lot of developers here.  Who can do what?  Who has time?

check my other post  (Who's who) and reply to it.
>
> Karl
Sylvain