Re: Future of LedgerSMB: Ideas and RFC

[Chris Bennett <..hidden..>]

On Fri, May 20, 2011 at 08:51:18AM -0700, Chris Travers wrote:
> 
> In cases where there is a change to desired behavior I would agree
> with you.  In cases where the change is still in line with
> documentation, I am not sure that's necessary.
> 
> Also I don't think it's practical to fully document the functions in
> the files in bin/ (that we inherited from SL) because quite frankly
> the code is such a mess that troubleshooting usually has to begin with
> a new review of the code.  For the files in scripts, I am also not
> sure that documenting every function as a function call is helpful
> simply because 90% of every piece there is going to be boilerplate.
> Maybe it would be better to put in Perl comments (rather than POD)
> identifying which screens are rendered by which functions, and have
> the flow documented in the technical documentation of the manual.
> 

Yes, that  makes sense.

> >
> > Yes, I see that there is some code documention inline, but there is really no detailed man page
> > describing "the big picture". It would make getting started on coding much easier to see the
> > overall workflow for a variety of common tasks (from a coding point of view, not a users point of
> > view).
> > That's a writen document, a nice review.
>
> There's a code overview in the manual but it's a little out of date
> and needs to be revisited and expanded.

Yes, that too, but I meant something more like a flowchart, but a written guide.
Some people see "pictures" better others see "words"  better.
Its a fair task  to  do,  but bit by bit. Should be easy to update, later, much later :).


> 
> >
> > A tougher project would be a nice sort of visual flow chart like this but graphic:
> > sub A($this, $that) -> sub B(etc) -> module whatever sub C
> >
> > Chris, you would know this overflow best, but only giving a very rough start and handing off all
> > of the details to others would let this get done fast.
> 
> What would folks need from me?

Well, for me, I want enough to get a good feel overall. Its boring to dig and dig to just get that first clue. After  that, I  think its fun to work on making crappy or badly done code good.

In my opinion, something fairly rough is enough. Outline a few workflows, in  loose detail.
Digging  into  details requires opening an editor, at this end
If its not enough, we can ask more questions.

> 
> > You have been doing almost too much of the work. It is very difficult to try and not do the detail
> > work but pass it on to others to struggle through. I learned this lesson the hard way with ?my
> > business. Get some people started and let them fly or fail. But don't handhold. Very hard to do :)
> >
> > I can code, but I would prefer to concentrate on the small picture, this "thing" needs to be
> > changed
> > I will give it ?go.
> >
> > I agree with the comments on SQL COMMENTS on the other thread.
> > Get all those in place, require them for any new functions (like I said above).
> > Then make an overall man page for interflow.
> > A flowchart could also be helpful.
> 
> What do you think a flow chart should cover?  Are we talking about an
> architecture diagram?

Basically. But come up with it in digestable pieces.
Others can make "zoom" details later.

> 
> >
> > It is pretty easy to get basics out of database. Just need to see general overflow and all will
> > be "clearish"
> >
> Thanks for the thoughts :-)
> 
> Best Wishes,
> Chris Travers
> 
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its 
> next-generation tools to help Windows* and Linux* C/C++ and Fortran 
> developers boost performance applications - including clusters. 
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Ledger-smb-users mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-users