Re: Input needed.

["Chris Travers" <..hidden..>]

On 10/22/07, Del Miller <..hidden..> wrote:
> Hi Chris,
>
> Thanks, as always, for the response.
>
> I took a look at the road map and the brief architecture outline -- is
> there a more in depth document?  I'm assuming there might be and I'm
> also assuming that I need to register with the site in order to get
> access.  To that end, I registered (about 3 hours ago) and have yet to
> receive the confirmation email.  Perhaps the following questions will be
> answered once I gain access as a registered user.

1.3 is nearing feature freeze.  Once the authentication system is a
little more stabilized, and the last call for patches is made, I
expect we will probably make that branch bugfix only and perhaps even
branch 1.3 off at that time so people can start working on 1.4.

>
> I've got bits of time here and there and an itch that desperately needs
> to be scratched.  LSMB is the closest thing I've seen to meeting my
> needs and it's close enough that I'd like to put in the effort to make
> it work.  In short, I'd like to help in any way I can.  Can you provide
> me with anything to get me up to speed on the old code, the current
> code, what needs done, what is done, how to work with things, etc.

Old code:
1)  Understand that you will be hard pressed to find more antipaterns
together in code anywhere.  He also breaks a number of Perl best
practices rules in gratuitous and unnecessary ways .

2)  Secret decoder ring-type stuff:
abbrev.   Meaning
CT          Contact
AA           AR/AP
CP          Cash Payment (and Check Printing too!)
OP          Overpayment
PE           Project Entry
JC          Job Costing
etc.  If you need to understand what something is, check the comment
header in the file.

3)  Beware of variable scopes.  More often than not, they have issues.

4)  Things may not be where they seem like they should.  If in doubt,
ask on this list.

5)  Try not to burn out and know when to take a break.

New Code:
The architecture document does a good job of explaining the general
outline of the code.

1)  LedgerSMB is the base class with many utility functions.
2)  LedgerSMB::DBObject does the basic mapping.
    a)  No, AUTOLOAD isn't a good practice.  I am thinking we should
build some sort of alternative interface.
   b)  exec_method is only for methods you want to map arguments to
the current object's properties.  If you dont what to do this, use
call_procedure instead (defined in LedgerSMB.pm)
3)  LedgerSMB::Template is the base view handler.

Good examples can be found in scripts/login.pl, scripts/menu.pl.,
LedgerSMB/DBObject/Menu.pm

What needs to be done:  Authentication stuff in 1.3 needs some
additional attention.  I wouldn't recomment trying to install it yet
unless you want some help.  Try again in another week.  If you do,
however, I can send you a dump of a db cluster I use to test with.

One more general hint:
We have an irc channel on Freenode (#ledgersmb).  Join there and ask
questions when you need immediate information.

Best Wishes,
Chris Travers


>
> You speak of 1.3 (1.4, 2.0)... is there a time frame for 1.3 (1.4,
> 2.0)?  Is there a working 'beta' of 1.3 (1.4, 2.0)?  How about
> engineering details?
>
> Are there coding standards to read?  If not, that's OK... could you
> point me a some well written LSMB code that I can look at to get a feel
> for style?
>
> Any sort of database diagram exist?
>
> BTW, thanks for pointing out the CT module as I had not run across that
> one yet.  After looking at it, it appears to do everything *but* what
> I'm after -- go figure.  I'll set about working on a quick fix for my
> immediate needs.
>
> Regards
> Del
>
> Chris Travers wrote:
> > Hi Del;
> >
> > The major reason for keeping the development discussion on this list
> > at the moment at least is to avoid overwhelming basic users with
> > technical details :-)  Hence I will provide a few quick pointers to
> > the code here, and we can further discuss the issues here.
> >
> > Before I begin, I will warn you about the quality of the source code
> > we have not replaced yet :-).  once you see it and start working with
> > it, you will see why we are looking at re-engineering the whole thing.
> > :-)
> >
> > First, you probably want to take a look at our roadmap and our new
> > architecture document.  If you can implement the database side in
> > stored procedures you will find that is helpful (warning:  db design
> > is to the same standards as the Perl programming).   In short, we are
> > redesigning the entire customer/vendor structure and interface in
> > 1.3,as well as the base framework.
> >
> > If you can wait for 1.3, my suggestion is to work with us on this area
> > for 1.4.  This basically means helping us fully redesign the
> > project/timecard/job costing system as it will probably be less work
> > than struggling with that codebase.
> >
> > On 10/22/07, Del Miller <..hidden..> wrote:
> >
> >> Hello All,
> >>
> >> After some discussions with Chris Travers over on the -users list, I
> >> have decided to attempt to make some changes to LSMB for my own personal
> >> usage but would gladly contribute back anything useful (or even
> >> marginal) that I can come up with.  To that end, I am writing to make
> >> sure that what I am about to attempt a) will fit with LSMB in the best
> >> way possible b) is not a duplicated effort c) doesn't step on anyones
> >> toes ;)
> >>
> >
> > See below.
> >
> >> Here's what I'm thinking and why...
> >>
> >> I am a small time consultant and bill on a monthly basis -- LSMB seems
> >> to have everything I need with one small exception -- I'd like to create
> >> a non-customer based project (no problem), enter a time card against
> >> that project and, *on the time card*, have a drop-down list of customers
> >> from which to select for billing.  I realize that I can enter the time
> >> cards, generate sales orders, and *then* select the customer at that
> >> time -- which, functionally, is what I'm after but is a bit less than
> >> convenient for how I work.
> >>
> >
> > You can also enter timecards, select the customer, and then generate
> > the sales orders, but that poses the same basic issue you are trying
> > to avoid.
> >
> > There are some other usability options also, which I will send on the
> > other thread.  In short, maybe set up different services, and then
> > treat projects as customer contracts.
> >
> >> So, being a bit of a Perl programmer (although a bit rusty), I began to
> >> look at the LSMB code to see how one would shoehorn in a customer
> >> selection function on the 'add timecard' page.  All I can say it, wow.
> >>
> >
> > Why we are replacing the old code :-)  All I can say is that we welcome help :-)
> >
> >> After a few hours I came to think that my life would be simpler if I
> >> created a new module, called something like VendorCustomer.pm, that
> >> would provide all the needed functions  to customer/vendor info...
> >>
> >
> > CT.pm does this.  BTW, CT.pm is going away in 1.3 to be the first
> > target of our refactoring/re-engineering efforts.
> >
> > The original author liked short names.   CT stands for Contact.  If
> > you take a look in svn /trunk, you will see we don't like short names
> > so much, and our code is remarkably... different... from Dieter's.
> >
> >
> >> most
> >> importantly, a 'get_customer' function that could return a drop-down
> >> selection list and provide a drop-in replacement for the current
> >> get_customer routine in the PE and RP modules.
> >>
> >
> > For now, my suggestion is that you put your function in a new module
> > like LedgerSMB::ContactWidgets.pm or the like.
> >
> > PE and RP are probably the worst of the messes.  If you can avoid it,
> > I would *hightly* avoid touching those modules any more than we have
> > to.
> >
> > RP.pm is going away in 1.4, PE.pm may go away in 1.4 if we get to it,
> > but is more likely to be between then and 2.0 unless someone wants to
> > help with it.
> >
> >
> >>  I would think that it
> >> could easily be expand it to include add, delete, update, etc. and start
> >> to be dropped in all around.
> >>
> >> Well, anyway, before I go chasing rabbits and put the time in to fix
> >> things the way *I* want them, I thought it only prudent to address you,
> >> the developers, so as to avoid any duplicated effort, get your input,
> >> and see if this would be a useful thing to do, etc.
> >>
> >
> > If this can wait for 1.3, my suggestion is that you work with us to
> > re-engineer the project/timecard/job costing system.  It need not be
> > done all at once, but will probably be *less* work than struggling
> > with the code we inherited.  Notice I said "help" as I would be happy
> > to provide some effort in this area as well.
> >
> >
> >> Any thoughts/suggestions here?
> >>
> >
> > My only concern is that the inherited codebase is brittle and we are
> > re-engineering portions of it that your work will depend on.  Since
> > you are looking at adding customer/vendor functions, I would suggest
> > looking at what we are doing for 1.3, ask lots of questions, and see
> > what you can hook into there.
> >
> >
> >> Apologies if I'm sticking my nose where
> >> it doesn't belong -- feel free to tell me to go away. :)
> >>
> >
> > Don't worry, we don't work that way,  The purpose for bringing it up
> > on this list is to ensure that everyone can coordinate what everyone
> > is doing.  We would also naturally review patches for quality before
> > applying them, but as 1.3 goes forward, some large areas of the
> > codebase are getting cleaned up.
> >
> > Best Wishes,
> > Chris Travers
> >
> >
> >> Regards
> >> Del
> >>
> >> -------------------------------------------------------------------------
> >> This SF.net email is sponsored by: Splunk Inc.
> >> Still grepping through log files to find problems?  Stop.
> >> Now Search log events and configuration files using AJAX and a browser.
> >> Download your FREE copy of Splunk now >> http://get.splunk.com/
> >> _______________________________________________
> >> Ledger-smb-devel mailing list
> >> ..hidden..
> >> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
> >>
> >>
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Ledger-smb-devel mailing list
> > ..hidden..
> > https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
> >
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Ledger-smb-devel mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>