An Impassioned Plea from an VTiger Integrator

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

An Impassioned Plea from an VTiger Integrator

Dennis Grant
Ladies and Gentlemen,

I am currently employed as the lead integrator/programmer for VTigerCRM
at a medium-sized manufacturing company. My job is to maintain the
VTigerCRM server, and to customize our installation of VTiger to match
our business needs.

Sometimes this involves getting other systems (like Microsoft Great
Plains) to play nicely with the CRM; sometimes it means changing VTiger
code to better adopt the CRM to our particular business needs.

Our current installation is a heavily-modified (and I do mean HEAVILY)
modified 4.3.2 installation. To be honest, I painted myself into a bit
of a corner with the way I implemented our code changes, such that
upgrading to newer versions is a formidable challenge. My intent is to,
soon, bring up a 5.0 installation and start backporting our changes into
it, but this time with patch management tools to better manage upgrading
in the future.

In a way, it's a bit like maintaining my own private fork of something
like the Linux kernel, and so I intend on adopting the best practices of
those who have gone before me.

Anyway, I have occasion to spend a LOT of time in VTiger code, and while
I have not yet seen the V5.0 code in any great detail, I have a pair of
impassioned pleas for all current VTiger developers (in any version)

1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! Those of
us who have to pop into a module to make a few tweaks to how it
looks/operates are hamstrung by the lack of comments in VTiger code. We
wind up having to work everything out from scratch, and that makes a
difficult job even more difficult. The fact that VTIger code, in
general, uses good descriptive variable names helps out a lot, but
comments would go even further.

Please please PLEASE get into the habit of commenting your code, even if
you think the functionality is obvious - you'll REALLY help guys like me
out.

2) I see a lot of code that looks like this:

if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] ==
'module_name2') {

   if ($some_parameter !='') {

       Do some stuff;
   }
}

What is missing here is any sort of exception handling. Not only does
this code fail silently if the tested assumptions aren't true (which has
caused some unusual bugs) it also fails to communicate to integrators
what the allowed/expected parameters of this code block are.

EVERY SINGLE IF OR IF/THEN NEEDS AN ELSE TO CATCH EXCEPTIONS, without
exception (heh) Failing to do this opens the door to bizarre bugs and
much wasted time trying to track them down. It also makes an
integrator's job that much more difficult.

Compare to this example:

// Prepare the foo object for writing to the database

// We are only supposed to be called from the module_name1 or
module_name2 modules
if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] ==
'module_name2') {

   // We need this to be set
   if ($some_parameter !='') {

       Do some stuff;
   }
   else {
      print_warning("Expected some_parameter to be set in
do_stuff.php");
   }
}
else {
   print_warning("Called with unexpected value of REQUEST[module] :
".$REQUEST['module']." from do_stuff.php.");
}

I don't want to get all programmer grammer nazi here, but I've been
ripping my hair out by the roots for the last few hours, and it's all
totally unnecessary.  

DG

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt 
Reply | Threaded
Open this post in threaded view
|

Re: An Impassioned Plea from an VTiger Integrator

Jeff Kowalczyk
Dennis Grant wrote:
> I don't want to get all programmer grammer nazi here

Programmer grammar Nazi.   ;)

I think many of us who are working on the periphery with vtigercrm have
pet peeves about the formatted representation of the source code. Those
pet peeves confer a certain squeal point for making a comment about it
(no pun) and another, higher, one for doing something about it on our own.

The interval between squeal points is where we've been circling for
months. No few persons (rightly) want to clean up a fraction of the code
when new checkins aren't guaranteed follow the same standards.

And so, the technical debt incurred by the fixable problem of poor source
formatting (including commentless code) continues to impose costs on
vtigercrm development.

Further, if we fix this before major vtigercrm-5.x branching, we reap
major merging benefits. If only after, we get zero backporting crosstalk
between branches, like we have with vtigercrm/branches/4.2 and
vtigercrm/trunk.


Fundable Fixes
--------------

What about setting up a fundable.org project for sponsoring source
cleanup? We who are interested in seeing the code beautified could assign
a monetary value to that interest.

Enough support would collectively make it worth the core team's while to
stop coding for a few days, and clean up the broken windows of the source
formatting.

Volunteers would of course augment their efforts at the same time, and
going forward, friendly admonishment could be leveled upon lazy checkins
with poorly formatted source.

http://fundable.org/
(example)
http://www.fundable.org/groupactions/ploneboard-phase-one/view?searchterm=plone

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt 
Reply | Threaded
Open this post in threaded view
|

Re: An Impassioned Plea from an VTiger Integrator

Sergio A. Kessler-2
In reply to this post by Dennis Grant
dennis,

On 7/11/06, Dennis Grant <[hidden email]> wrote:
> Ladies and Gentlemen,
>
[snip]
>
> Our current installation is a heavily-modified (and I do mean HEAVILY)
> modified 4.3.2 installation. To be honest, I painted myself into a bit
> of a corner with the way I implemented our code changes, such that
> upgrading to newer versions is a formidable challenge.

this is a mistake many people do.
you have choosed to fork the project instead of trying to work with
the community.

and all this people end up in the same corner as you...  :-)

> 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE!

I'm pretty sure that the vtiger developers will accept you code
comment patches...

your duty if that is what you really want...

> I don't want to get all programmer grammer nazi here, but I've been
> ripping my hair out by the roots for the last few hours, and it's all
> totally unnecessary.

keep posting patches to the trac please...
the people managing the 4.x branch have been very responsive and are
doing a good job...

cheers,
/sak
_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt 
Reply | Threaded
Open this post in threaded view
|

Re: An Impassioned Plea from an VTiger Integrator

Matthew Brichacek
> [snip]
> >
> > Our current installation is a heavily-modified (and I do mean HEAVILY)
> > modified 4.3.2 installation. To be honest, I painted myself into a bit
> > of a corner with the way I implemented our code changes, such that
> > upgrading to newer versions is a formidable challenge.
>
> this is a mistake many people do.
> you have choosed to fork the project instead of trying to work with
> the community.
>
> and all this people end up in the same corner as you...  :-)
>
While I would normally agree 100% with Sergio on this point, I think we
need to take the history of this project into consideration and maybe
look at the bigger picture.

There was a point in this project where you could come along, see a
project with a fairly vibrant community forming, an interesting product
being developed and a complete lack of direction and management.  This
type of environment is ripe for internal forks and the fact that the
project didn't fork into a new OSS project is nothing short of a miracle
(seriously!).

I think Dennis is just the first one to cry out for help publicly, there
are probably many more out there like him (I know of 6).  The system
integrators had a choice to make...  Stand behind the OSS project in all
it's glory and be at the mercy of a project with no direction or
leadership, or fork and be in charge of their own destiny.  While in
most cases I would say you're loony for privately forking a strong OSS
project, in those cases I would say it was a justifiable move (i'm
biased of course).

Ok, so there have to be a _ton_ of cool features and ideas floating
around in all these private forks and I think the project managers
should make a full effort to get these integrators back into the
community and help them get their features in 5.x.  Why not put them in
4.x?  Here are the options as far as I see them for people who have
forked from 4.x:

1) Keep running with your own 4.x fork even after the community drops
4.x in favor of 5.x.  Good luck, have fun, and let us know how that
works out :).

2) Submit patches for all your features into 4.x, get them integrated,
then submit them for 5.x (or hope some wonderful soul did it for you).
If you have to submit them yourself after you've done 4.x, chances are
you will miss the final release of 5.x and will be in a stable period
that may be harder to get your features into.

3) If not already done, stabilize your 4.x fork and get busy forward
porting everything to 5.x.  You'll need to create your own upgrade path
for your company/customers but IMHO you're chances of success are better
in this case.  Some of your features may not be accepted, but maybe the
underlying framework that you need to enable those features can be, or
if you're lucky, the API will do what you need (don't hold your breath).

It really comes down to options 2 and 3, and who wants to double all
their work when you know damn well that 4.x is going to be abandoned now
that 5.x shows the promise it does.  And I mean that with absolutely no
disrespect for the people working hard on maintaining 4.x for the
community.  Will 4.x be maintained forever?  I highly doubt it, once 5.x
stabilizes and upgrade paths are figured out we'll certainly want those
developer resources moved to 5.x right?

About code comments:
I'm in no position to preach about code comments, but I am getting
better at it (code comments that is :).  What I think we could use _way_
more than code comments is a sane API with at least _some_
standardization and logic to it. But I don't have the time to do it or
fix the millions of things that will break, so I'll just shut up now.

Matt



_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt 
Reply | Threaded
Open this post in threaded view
|

Re: An Impassioned Plea from an VTiger Integrator

Dennis Grant
In reply to this post by Dennis Grant


> I think many of us who are working on the periphery with vtigercrm
have
> pet peeves about the formatted representation of the source code.

I am actually fairly agnostic when it comes to code FORMAT. I think it's
possible to waste a great deal of heat & light arguing over things like:

if ($foo) {

        bar;
}

vice

if ($foo)
{
        bar;
}

vice

if ($foo) { bar; }

I really don't care one way or another, and attempting to force people
into an alien code format just for the sake of uniformity is really not
worth the effort. It's a freakin' if statement testing if $foo is set
and if it is, it executes bar - that's what matters.

I don't even care if the database access API (for example) is the same
everywhere - as long as I can figure out what is going on, I don't
particularly care about HOW you do it.

I'm a big boy, and I've written and maintained a ton of code. I can
adopt.

What I DO care about is that code is commented AS IT IS WRITTEN - not
after the fact, but as it goes into the code. I, as an integrator, need
to know how the code functions so I can quickly track down bugs, find
where features reside so I can modify them, and identify places to hook
into for integration.

I need to know WHY something is the way it is, and the only way to do
that is through comments.

> No few persons (rightly) want to clean up a fraction of the code
> when new checkins aren't guaranteed follow the same standards.

I (mostly) disagree - every comment is worth its weight (figuratively
speaking) in gold. I'd love it if somebody went through and commented
the entire codebase, but I understand that's a lot of work - and while I
think the dividends that pays are big enough to make the pain
worthwhile, I also understand that it's not very sexy and so not likely
to happen without somebody explicitly funding it.

(Hell, fund ME, and I'LL do it)

But I **DO** think that we can at least stop the bleeding by requiring
that all NEW code be properly commented. It takes a miniscule amount of
effort on the part of the coder and the check-in authority, and it pays
such enormous dividends for later maintenance that we really cannot
afford NOT to do it.

> keep posting patches to the trac please...
> the people managing the 4.x branch have been very responsive and are
> doing a good job...

I have submitted a variety of patches to a variety of places, including
this list, and to the best of my knowledge, not a single patch has made
it into the core.

Some of this may be my fault, and as I mentioned in my first message, I
intend to revamp my own code maintenance process to operate more like a
private fork of the Linux kernel, such that I can generate actual diff
patches, with the intent of making the incorporation of my changes into
the core (when it applies - it doesn't always have universal utility)
easier.

> There was a point in this project where you could come along, see a
> project with a fairly vibrant community forming, an interesting
product
> being developed and a complete lack of direction and management.  This
> type of environment is ripe for internal forks and the fact that the
> project didn't fork into a new OSS project is nothing short of a
miracle
> (seriously!).

Actually, I think with VTiger you are going to see a lot of private
forks, because individual businesses have their own needs and wants that
are supersets of core VTiger functionality that simply don't apply to
other businesses.

My life is easier the smaller the delta is between the vanilla VTiger
core and my own fork, so I intend to try and get as many of my changes
put into the V5x core as possible - but the bottom line is that there
will be things that my management want in our CRM that nobody else in
the world will want, and that's fine.

> Stand behind the OSS project in all
> it's glory and be at the mercy of a project with no direction or
leadership, or fork and be in charge of their own destiny.

I literally had no choice. I was directed to make the CRM do certain
things (after all, I have the source code) and "it doesn't do that out
of the box" was NOT an acceptable answer. Even "that's coming in the
next version of the CRM" is increasingly hard to justify, given how long
it has taken for 5.0 to solidify.

Some of the things I have done are really very pretty. Others are
horrible, horrible hacks (my version supports localized currencies, with
exchange rates, but you don't want to know how....)

Other changes are less obvious. For example, I was required to modify
the Quote engine so that it preserved the order that products were added
to a quote and printed them out accordingly - totally cosmetic, but our
sales guys had a valid need for that to happen, so I did it.

 
> It really comes down to options 2 and 3, and who wants to double all
> their work when you know damn well that 4.x is going to be abandoned
now
> that 5.x shows the promise it does.  And I mean that with absolutely
no
> disrespect for the people working hard on maintaining 4.x for the
> community.

Bingo. As far as I am concerned, 4.x is a dead tree being maintained
only as long as necessary to get 5.x established, after which it will be
dropped.

But the habits that NEED to be carried into 5.x MUST be established NOW.

Comment your code.

Every IF has an ELSE - even if that ELSE should never ever execute.

Simple simple simple; but yet they pay enormous dividends later on.

DG

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt 
Reply | Threaded
Open this post in threaded view
|

Re: An Impassioned Plea from an VTiger Integrator

Sergio A. Kessler-2
In reply to this post by Matthew Brichacek
Mat,

v4.x would not be abandoned while there is people interested in
maintaining it, that's all needed in open source, interested and
executive people...
it can be mantained forever while this condition is met...

and I agree with you that there was (is ?) an utterly lack of
receptive response to community developers from the core team, and the
project was crying for a fork, but all those people creating private
forks also lacked the balls to create a serious *public* fork...

I mean, if you are going to fork, then fork in all it's glory...

those people that never submitted a patch, never figthed for more open
development, created their own private branch, and then came up here
whining, are ... well, whiners IMO

those who want to mantain v4.x just need to step up and do something about it...

cheers,
/sergio

On 7/11/06, Matthew Brichacek <[hidden email]> wrote:

> > [snip]
> > >
> > > Our current installation is a heavily-modified (and I do mean HEAVILY)
> > > modified 4.3.2 installation. To be honest, I painted myself into a bit
> > > of a corner with the way I implemented our code changes, such that
> > > upgrading to newer versions is a formidable challenge.
> >
> > this is a mistake many people do.
> > you have choosed to fork the project instead of trying to work with
> > the community.
> >
> > and all this people end up in the same corner as you...  :-)
> >
> While I would normally agree 100% with Sergio on this point, I think we
> need to take the history of this project into consideration and maybe
> look at the bigger picture.
>
> There was a point in this project where you could come along, see a
> project with a fairly vibrant community forming, an interesting product
> being developed and a complete lack of direction and management.  This
> type of environment is ripe for internal forks and the fact that the
> project didn't fork into a new OSS project is nothing short of a miracle
> (seriously!).
>
> I think Dennis is just the first one to cry out for help publicly, there
> are probably many more out there like him (I know of 6).  The system
> integrators had a choice to make...  Stand behind the OSS project in all
> it's glory and be at the mercy of a project with no direction or
> leadership, or fork and be in charge of their own destiny.  While in
> most cases I would say you're loony for privately forking a strong OSS
> project, in those cases I would say it was a justifiable move (i'm
> biased of course).
>
> Ok, so there have to be a _ton_ of cool features and ideas floating
> around in all these private forks and I think the project managers
> should make a full effort to get these integrators back into the
> community and help them get their features in 5.x.  Why not put them in
> 4.x?  Here are the options as far as I see them for people who have
> forked from 4.x:
>
> 1) Keep running with your own 4.x fork even after the community drops
> 4.x in favor of 5.x.  Good luck, have fun, and let us know how that
> works out :).
>
> 2) Submit patches for all your features into 4.x, get them integrated,
> then submit them for 5.x (or hope some wonderful soul did it for you).
> If you have to submit them yourself after you've done 4.x, chances are
> you will miss the final release of 5.x and will be in a stable period
> that may be harder to get your features into.
>
> 3) If not already done, stabilize your 4.x fork and get busy forward
> porting everything to 5.x.  You'll need to create your own upgrade path
> for your company/customers but IMHO you're chances of success are better
> in this case.  Some of your features may not be accepted, but maybe the
> underlying framework that you need to enable those features can be, or
> if you're lucky, the API will do what you need (don't hold your breath).
>
> It really comes down to options 2 and 3, and who wants to double all
> their work when you know damn well that 4.x is going to be abandoned now
> that 5.x shows the promise it does.  And I mean that with absolutely no
> disrespect for the people working hard on maintaining 4.x for the
> community.  Will 4.x be maintained forever?  I highly doubt it, once 5.x
> stabilizes and upgrade paths are figured out we'll certainly want those
> developer resources moved to 5.x right?
>
> About code comments:
> I'm in no position to preach about code comments, but I am getting
> better at it (code comments that is :).  What I think we could use _way_
> more than code comments is a sane API with at least _some_
> standardization and logic to it. But I don't have the time to do it or
> fix the millions of things that will break, so I'll just shut up now.
>
> Matt
>
>
>
> _______________________________________________
> Get started with creating presentations online - http://zohoshow.com?vt
>
_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt 
Reply | Threaded
Open this post in threaded view
|

Re: An Impassioned Plea from an VTiger Integrator

Jeff Kowalczyk
In reply to this post by Dennis Grant
Dennis Grant wrote:
> Actually, I think with VTiger you are going to see a lot of private
> forks, because individual businesses have their own needs and wants that
> are supersets of core VTiger functionality that simply don't apply to
> other businesses.

This is one of the reasons why I care about making the source more
merge-friendly (particularly short, vertically formatted SQL statement
string lines).

If we can get the codebase to the point where branching and merging is a
manageable burden, customization branches have a fighting chance to be
maintained in the repository. Or use a distributed repository such as
bazaar-ng can be used (bzr has a trac backend now).


_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt 
Reply | Threaded
Open this post in threaded view
|

Re: An Impassioned Plea from an VTiger Integrator

Matthew Brichacek
In reply to this post by Sergio A. Kessler-2
On Wed, 2006-07-12 at 10:48 -0300, Sergio A. Kessler wrote:
> Mat,
>
> v4.x would not be abandoned while there is people interested in
> maintaining it, that's all needed in open source, interested and
> executive people...
> it can be mantained forever while this condition is met...
It could, but I just don't see it happening after 5.x is stable and
usable.  This is just my opinion based on past experience.

>
> and I agree with you that there was (is ?) an utterly lack of
> receptive response to community developers from the core team, and the
> project was crying for a fork, but all those people creating private
> forks also lacked the balls to create a serious *public* fork...
>
> I mean, if you are going to fork, then fork in all it's glory...
Because maintaining a proper OSS project with little to no support from
the community (and abandoning the core team) is no small task, esp. when
the boss is breathing down your neck to get X,Y,Z features enabled ASAP.
Other things.. the community was building quickly, features were
storming into the forums (even though they didn't get used) and the code
was a complete cluster fuck.  The pros of a fork barely outweighed the
benefits and for mere mortal to come along and try to tackle it would
have been near suicidal.
Also, in some cases the choice to fork may have been the career saving
moment after the boss found out you decided to deploy the company on
project that was abandoned over night with no warning or word of upgrade
paths, bug fixes, etc.

>
> those people that never submitted a patch, never figthed for more open
> development, created their own private branch, and then came up here
> whining, are ... well, whiners IMO
Most of them did submit patches and fought for more open development and
when they were ignored simply took their patches and went home.  Some of
us were a little more vocal about it but the only reason that worked is
because the critical mass needed to make a real change had already built
up from the people who came before us.
This really was my point in the last thread.  I would normally agree
with you 100% on this issue but I think this project had a period where
there was a sign on the front door saying "Open for business..
Developers Welcome.. and Trespassers will be ignored (or shot)" all in
the same breath.

>
> those who want to mantain v4.x just need to step up and do something about it...
My argument wasn't really for 4.x maint.  I think the current
maintainers are doing a fine job of keeping the release afloat for the
community (no thanks to me mind you).  My point was that we should find
a way to welcome these wayward forks back to the fold.  How?  I dunno..
but I think it's worth investigating as I am pretty sure that many many
private vtiger4.x forks are floating about.  Personally I am going
gangbusters to try and get all of our 4.x features into 5.x since I
despise being forked from a project but asking all of these integrators
to do that is not nice, nor is it standard operating procedure for an
OSS project.. I firmly believe that much less of this would have
happened if this project was following a true OSS format during the 4.x
devel and hadn't gone off half-cocked to start 5.x.  Do I think 5.x was
worth the wait and headache of what happened to 4.x?  Not even remotely
close, we could have added smarty, campaigns and all the AJAX fluff to
4.x in less time IMO.

So after the wind clears.. my point really comes down to getting all
these folks who are working on private forks to come back to the
community project, regardless of their justification (or lack of) for
the fork. In an OSS project your most valuable resource is your
developers and if we can find a way to get them back it will be well
worth it IMHO.


Matt

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt 
Reply | Threaded
Open this post in threaded view
|

Re: An Impassioned Plea from an VTiger Integrator

Matthew Brichacek
In reply to this post by Jeff Kowalczyk
I have started doing the query part as I run into them in my branch.
I'm also moving the query strings out of functions like get_leads() and
putting it in get_related_leads_query() instead.  This way the query can
be used for other things.. like for example if you want mostly the same
output of get_leads() but without the HTML that manged to find its way
out of the presentation layer and into the data layer... don't get me
started on that.
Anyways, with the HUGE db query strings that are used in the system,
breaking them into separate short lines is a great suggestion for
manageability and if it makes merges easier it's like getting your cake
and eating it too :).

Matt

On Wed, 2006-07-12 at 10:06 -0400, Jeff Kowalczyk wrote:

> Dennis Grant wrote:
> > Actually, I think with VTiger you are going to see a lot of private
> > forks, because individual businesses have their own needs and wants that
> > are supersets of core VTiger functionality that simply don't apply to
> > other businesses.
>
> This is one of the reasons why I care about making the source more
> merge-friendly (particularly short, vertically formatted SQL statement
> string lines).
>
> If we can get the codebase to the point where branching and merging is a
> manageable burden, customization branches have a fighting chance to be
> maintained in the repository. Or use a distributed repository such as
> bazaar-ng can be used (bzr has a trac backend now).
>
>
> _______________________________________________
> Get started with creating presentations online - http://zohoshow.com?vt 

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt 
Reply | Threaded
Open this post in threaded view
|

Re: An Impassioned Plea from an VTiger Integrator

Richie-4
In reply to this post by Dennis Grant
Hi DG!

Your comments are well taken. These will be in place at the earliest.
I know that this will be a quick fix but instructions have been sent across to have the code properly commented from now on for any future development/bug fixes.

Richie




---- Dennis Grant<[hidden email]> wrote ----

Ladies and Gentlemen,

I am currently employed as the lead integrator/programmer for VTigerCRM
at a medium-sized manufacturing company. My job is to maintain the
VTigerCRM server, and to customize our installation of VTiger to match
our business needs.

Sometimes this involves getting other systems (like Microsoft Great
Plains) to play nicely with the CRM; sometimes it means changing VTiger
code to better adopt the CRM to our particular business needs.

Our current installation is a heavily-modified (and I do mean HEAVILY)
modified 4.3.2 installation. To be honest, I painted myself into a bit
of a corner with the way I implemented our code changes, such that
upgrading to newer versions is a formidable challenge. My intent is to,
soon, bring up a 5.0 installation and start backporting our changes into
it, but this time with patch management tools to better manage upgrading
in the future.

In a way, it's a bit like maintaining my own private fork of something
like the Linux kernel, and so I intend on adopting the best practices of
those who have gone before me.

Anyway, I have occasion to spend a LOT of time in VTiger code, and while
I have not yet seen the V5.0 code in any great detail, I have a pair of
impassioned pleas for all current VTiger developers (in any version)

1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! Those of
us who have to pop into a module to make a few tweaks to how it
looks/operates are hamstrung by the lack of comments in VTiger code. We
wind up having to work everything out from scratch, and that makes a
difficult job even more difficult. The fact that VTIger code, in
general, uses good descriptive variable names helps out a lot, but
comments would go even further.

Please please PLEASE get into the habit of commenting your code, even if
you think the functionality is obvious - you'll REALLY help guys like me
out.

2) I see a lot of code that looks like this:

if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] ==
'module_name2') {

if ($some_parameter !='') {

Do some stuff;
}
}

What is missing here is any sort of exception handling. Not only does
this code fail silently if the tested assumptions aren't true (which has
caused some unusual bugs) it also fails to communicate to integrators
what the allowed/expected parameters of this code block are.

EVERY SINGLE IF OR IF/THEN NEEDS AN ELSE TO CATCH EXCEPTIONS, without
exception (heh) Failing to do this opens the door to bizarre bugs and
much wasted time trying to track them down. It also makes an
integrator's job that much more difficult.

Compare to this example:

// Prepare the foo object for writing to the database

// We are only supposed to be called from the module_name1 or
module_name2 modules
if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] ==
'module_name2') {

// We need this to be set
if ($some_parameter !='') {

Do some stuff;
}
else {
print_warning("Expected some_parameter to be set in
do_stuff.php");
}
}
else {
print_warning("Called with unexpected value of REQUEST[module] :
".$REQUEST['module']." from do_stuff.php.");
}

I don't want to get all programmer grammer nazi here, but I've been
ripping my hair out by the roots for the last few hours, and it's all
totally unnecessary.

DG

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt 
Reply | Threaded
Open this post in threaded view
|

Re: An Impassioned Plea from an VTiger Integrator

Richie-4
In reply to this post by Jeff Kowalczyk
I am game for it . Any takers?
What is the procedure and how do we guarantee that there are no breakages?

Richie




---- Jeff Kowalczyk<[hidden email]> wrote ----

Dennis Grant wrote:
> I don't want to get all programmer grammer nazi here

Programmer grammar Nazi. ;)

I think many of us who are working on the periphery with vtigercrm have
pet peeves about the formatted representation of the source code. Those
pet peeves confer a certain squeal point for making a comment about it
(no pun) and another, higher, one for doing something about it on our own.

The interval between squeal points is where we've been circling for
months. No few persons (rightly) want to clean up a fraction of the code
when new checkins aren't guaranteed follow the same standards.

And so, the technical debt incurred by the fixable problem of poor source
formatting (including commentless code) continues to impose costs on
vtigercrm development.

Further, if we fix this before major vtigercrm-5.x branching, we reap
major merging benefits. If only after, we get zero backporting crosstalk
between branches, like we have with vtigercrm/branches/4.2 and
vtigercrm/trunk.


Fundable Fixes
--------------

What about setting up a fundable.org project for sponsoring source
cleanup? We who are interested in seeing the code beautified could assign
a monetary value to that interest.

Enough support would collectively make it worth the core team's while to
stop coding for a few days, and clean up the broken windows of the source
formatting.

Volunteers would of course augment their efforts at the same time, and
going forward, friendly admonishment could be leveled upon lazy checkins
with poorly formatted source.

http://fundable.org/
(example)
http://www.fundable.org/groupactions/ploneboard-phase-one/view?searchterm=plone

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt 
Reply | Threaded
Open this post in threaded view
|

Re: An Impassioned Plea from an VTiger Integrator

Richie-4
In reply to this post by Sergio A. Kessler-2
I second /sak.
Contribute your code and we will have it in the 4.2.x branch and then have it subsequently ported to the 5.x too.
We could have done it much earlier but it is far too late to get any contributions into 5.x at this stage.

As far as possible, keep your changes in separate files so that they can be function invoked from the core code.

Richie




---- Sergio A. Kessler<[hidden email]> wrote ----

dennis,

On 7/11/06, Dennis Grant <[hidden email]> wrote:
> Ladies and Gentlemen,
>
[snip]
>
> Our current installation is a heavily-modified (and I do mean HEAVILY)
> modified 4.3.2 installation. To be honest, I painted myself into a bit
> of a corner with the way I implemented our code changes, such that
> upgrading to newer versions is a formidable challenge.

this is a mistake many people do.
you have choosed to fork the project instead of trying to work with
the community.

and all this people end up in the same corner as you... :-)

> 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE!

I'm pretty sure that the vtiger developers will accept you code
comment patches...

your duty if that is what you really want...

> I don't want to get all programmer grammer nazi here, but I've been
> ripping my hair out by the roots for the last few hours, and it's all
> totally unnecessary.

keep posting patches to the trac please...
the people managing the 4.x branch have been very responsive and are
doing a good job...

cheers,
/sak
_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt 
Reply | Threaded
Open this post in threaded view
|

Re: An Impassioned Plea from an VTiger Integrator

Richie-4
In reply to this post by Matthew Brichacek
I agree with Matt.
We have just started to work on a API-basis. The APIs will be
difficult to use initially no doubt. I expect the APIs to be APIs like by 5.2 only as it is a huge change in mindset.
Moreover, whatever APIs we have now, have to be properly documented and made much more usable.
Matt has pointed out quite a few lacunaes and I do assure you that we do intend to fix them.
Guidance and direction on the implementation toward achieving the same are welcome.

To all System Integrators, yes, I do understand your pain. But, please understand getting rid of legacy code is much easier said than done.
As of now, we will have to live with what we have.
Post 5.0, we will make appropriate changes.

Richie




---- Matthew Brichacek<[hidden email]> wrote ----

> [snip]

> >
> > Our current installation is a heavily-modified (and I do mean HEAVILY)
> > modified 4.3.2 installation. To be honest, I painted myself into a bit
> > of a corner with the way I implemented our code changes, such that
> > upgrading to newer versions is a formidable challenge.
>
> this is a mistake many people do.
> you have choosed to fork the project instead of trying to work with
> the community.
>
> and all this people end up in the same corner as you... :-)
>
While I would normally agree 100% with Sergio on this point, I think we
need to take the history of this project into consideration and maybe
look at the bigger picture.

There was a point in this project where you could come along, see a
project with a fairly vibrant community forming, an interesting product
being developed and a complete lack of direction and management. This
type of environment is ripe for internal forks and the fact that the
project didn't fork into a new OSS project is nothing short of a miracle
(seriously!).

I think Dennis is just the first one to cry out for help publicly, there
are probably many more out there like him (I know of 6). The system
integrators had a choice to make... Stand behind the OSS project in all
it's glory and be at the mercy of a project with no direction or
leadership, or fork and be in charge of their own destiny. While in
most cases I would say you're loony for privately forking a strong OSS
project, in those cases I would say it was a justifiable move (i'm
biased of course).

Ok, so there have to be a _ton_ of cool features and ideas floating
around in all these private forks and I think the project managers
should make a full effort to get these integrators back into the
community and help them get their features in 5.x. Why not put them in
4.x? Here are the options as far as I see them for people who have
forked from 4.x:

1) Keep running with your own 4.x fork even after the community drops
4.x in favor of 5.x. Good luck, have fun, and let us know how that
works out :).

2) Submit patches for all your features into 4.x, get them integrated,
then submit them for 5.x (or hope some wonderful soul did it for you).
If you have to submit them yourself after you've done 4.x, chances are
you will miss the final release of 5.x and will be in a stable period
that may be harder to get your features into.

3) If not already done, stabilize your 4.x fork and get busy forward
porting everything to 5.x. You'll need to create your own upgrade path
for your company/customers but IMHO you're chances of success are better
in this case. Some of your features may not be accepted, but maybe the
underlying framework that you need to enable those features can be, or
if you're lucky, the API will do what you need (don't hold your breath).

It really comes down to options 2 and 3, and who wants to double all
their work when you know damn well that 4.x is going to be abandoned now
that 5.x shows the promise it does. And I mean that with absolutely no
disrespect for the people working hard on maintaining 4.x for the
community. Will 4.x be maintained forever? I highly doubt it, once 5.x
stabilizes and upgrade paths are figured out we'll certainly want those
developer resources moved to 5.x right?

About code comments:
I'm in no position to preach about code comments, but I am getting
better at it (code comments that is :). What I think we could use _way_
more than code comments is a sane API with at least _some_
standardization and logic to it. But I don't have the time to do it or
fix the millions of things that will break, so I'll just shut up now.

Matt



_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt 
Reply | Threaded
Open this post in threaded view
|

Re: An Impassioned Plea from an VTiger Integrator

Richie-4
In reply to this post by Dennis Grant
I take all your comments with eyes closed.
Kindly expect the changes asap. Please do refer to my prev mail.
Comment as an afterthought is like a Thank You after a day the event has occured, utterly worthless.
So, yes, this 'utterly worthless' post-coding comments will have to be lived with for now.

The instructions have been sent to have all the on-the-fly comments to be integrated as much as possible, as relevant as possible.

Richie




---- Dennis Grant<[hidden email]> wrote ----



> I think many of us who are working on the periphery with vtigercrm
have
> pet peeves about the formatted representation of the source code.

I am actually fairly agnostic when it comes to code FORMAT. I think it's
possible to waste a great deal of heat & light arguing over things like:

if ($foo) {

 bar;
}

vice

if ($foo)
{
 bar;
}

vice

if ($foo) { bar; }

I really don't care one way or another, and attempting to force people
into an alien code format just for the sake of uniformity is really not
worth the effort. It's a freakin' if statement testing if $foo is set
and if it is, it executes bar - that's what matters.

I don't even care if the database access API (for example) is the same
everywhere - as long as I can figure out what is going on, I don't
particularly care about HOW you do it.

I'm a big boy, and I've written and maintained a ton of code. I can
adopt.

What I DO care about is that code is commented AS IT IS WRITTEN - not
after the fact, but as it goes into the code. I, as an integrator, need
to know how the code functions so I can quickly track down bugs, find
where features reside so I can modify them, and identify places to hook
into for integration.

I need to know WHY something is the way it is, and the only way to do
that is through comments.

> No few persons (rightly) want to clean up a fraction of the code
> when new checkins aren't guaranteed follow the same standards.

I (mostly) disagree - every comment is worth its weight (figuratively
speaking) in gold. I'd love it if somebody went through and commented
the entire codebase, but I understand that's a lot of work - and while I
think the dividends that pays are big enough to make the pain
worthwhile, I also understand that it's not very sexy and so not likely
to happen without somebody explicitly funding it.

(Hell, fund ME, and I'LL do it)

But I **DO** think that we can at least stop the bleeding by requiring
that all NEW code be properly commented. It takes a miniscule amount of
effort on the part of the coder and the check-in authority, and it pays
such enormous dividends for later maintenance that we really cannot
afford NOT to do it.

> keep posting patches to the trac please...
> the people managing the 4.x branch have been very responsive and are
> doing a good job...

I have submitted a variety of patches to a variety of places, including
this list, and to the best of my knowledge, not a single patch has made
it into the core.

Some of this may be my fault, and as I mentioned in my first message, I
intend to revamp my own code maintenance process to operate more like a
private fork of the Linux kernel, such that I can generate actual diff
patches, with the intent of making the incorporation of my changes into
the core (when it applies - it doesn't always have universal utility)
easier.

> There was a point in this project where you could come along, see a
> project with a fairly vibrant community forming, an interesting
product
> being developed and a complete lack of direction and management. This
> type of environment is ripe for internal forks and the fact that the
> project didn't fork into a new OSS project is nothing short of a
miracle
> (seriously!).

Actually, I think with VTiger you are going to see a lot of private
forks, because individual businesses have their own needs and wants that
are supersets of core VTiger functionality that simply don't apply to
other businesses.

My life is easier the smaller the delta is between the vanilla VTiger
core and my own fork, so I intend to try and get as many of my changes
put into the V5x core as possible - but the bottom line is that there
will be things that my management want in our CRM that nobody else in
the world will want, and that's fine.

> Stand behind the OSS project in all
> it's glory and be at the mercy of a project with no direction or
leadership, or fork and be in charge of their own destiny.

I literally had no choice. I was directed to make the CRM do certain
things (after all, I have the source code) and "it doesn't do that out
of the box" was NOT an acceptable answer. Even "that's coming in the
next version of the CRM" is increasingly hard to justify, given how long
it has taken for 5.0 to solidify.

Some of the things I have done are really very pretty. Others are
horrible, horrible hacks (my version supports localized currencies, with
exchange rates, but you don't want to know how....)

Other changes are less obvious. For example, I was required to modify
the Quote engine so that it preserved the order that products were added
to a quote and printed them out accordingly - totally cosmetic, but our
sales guys had a valid need for that to happen, so I did it.


> It really comes down to options 2 and 3, and who wants to double all
> their work when you know damn well that 4.x is going to be abandoned
now
> that 5.x shows the promise it does. And I mean that with absolutely
no
> disrespect for the people working hard on maintaining 4.x for the
> community.

Bingo. As far as I am concerned, 4.x is a dead tree being maintained
only as long as necessary to get 5.x established, after which it will be
dropped.

But the habits that NEED to be carried into 5.x MUST be established NOW.

Comment your code.

Every IF has an ELSE - even if that ELSE should never ever execute.

Simple simple simple; but yet they pay enormous dividends later on.

DG

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt 
Reply | Threaded
Open this post in threaded view
|

Re: An Impassioned Plea from an VTiger Integrator

Richie-4
In reply to this post by Sergio A. Kessler-2
Well, well, /sak, hold on!
We do have interest in the 4.2.x series. Have a heart sak, it is well enuf difficult to maintain 5.x ;-)!

Richie




---- Sergio A. Kessler<[hidden email]> wrote ----

Mat,

v4.x would not be abandoned while there is people interested in
maintaining it, that's all needed in open source, interested and
executive people...
it can be mantained forever while this condition is met...

and I agree with you that there was (is ?) an utterly lack of
receptive response to community developers from the core team, and the
project was crying for a fork, but all those people creating private
forks also lacked the balls to create a serious *public* fork...

I mean, if you are going to fork, then fork in all it's glory...

those people that never submitted a patch, never figthed for more open
development, created their own private branch, and then came up here
whining, are ... well, whiners IMO

those who want to mantain v4.x just need to step up and do something about it...

cheers,
/sergio

On 7/11/06, Matthew Brichacek <[hidden email]> wrote:

> > [snip]
> > >
> > > Our current installation is a heavily-modified (and I do mean HEAVILY)
> > > modified 4.3.2 installation. To be honest, I painted myself into a bit
> > > of a corner with the way I implemented our code changes, such that
> > > upgrading to newer versions is a formidable challenge.
> >
> > this is a mistake many people do.
> > you have choosed to fork the project instead of trying to work with
> > the community.
> >
> > and all this people end up in the same corner as you... :-)
> >
> While I would normally agree 100% with Sergio on this point, I think we
> need to take the history of this project into consideration and maybe
> look at the bigger picture.
>
> There was a point in this project where you could come along, see a
> project with a fairly vibrant community forming, an interesting product
> being developed and a complete lack of direction and management. This
> type of environment is ripe for internal forks and the fact that the
> project didn't fork into a new OSS project is nothing short of a miracle
> (seriously!).
>
> I think Dennis is just the first one to cry out for help publicly, there
> are probably many more out there like him (I know of 6). The system
> integrators had a choice to make... Stand behind the OSS project in all
> it's glory and be at the mercy of a project with no direction or
> leadership, or fork and be in charge of their own destiny. While in
> most cases I would say you're loony for privately forking a strong OSS
> project, in those cases I would say it was a justifiable move (i'm
> biased of course).
>
> Ok, so there have to be a _ton_ of cool features and ideas floating
> around in all these private forks and I think the project managers
> should make a full effort to get these integrators back into the
> community and help them get their features in 5.x. Why not put them in
> 4.x? Here are the options as far as I see them for people who have
> forked from 4.x:
>
> 1) Keep running with your own 4.x fork even after the community drops
> 4.x in favor of 5.x. Good luck, have fun, and let us know how that
> works out :).
>
> 2) Submit patches for all your features into 4.x, get them integrated,
> then submit them for 5.x (or hope some wonderful soul did it for you).
> If you have to submit them yourself after you've done 4.x, chances are
> you will miss the final release of 5.x and will be in a stable period
> that may be harder to get your features into.
>
> 3) If not already done, stabilize your 4.x fork and get busy forward
> porting everything to 5.x. You'll need to create your own upgrade path
> for your company/customers but IMHO you're chances of success are better
> in this case. Some of your features may not be accepted, but maybe the
> underlying framework that you need to enable those features can be, or
> if you're lucky, the API will do what you need (don't hold your breath).
>
> It really comes down to options 2 and 3, and who wants to double all
> their work when you know damn well that 4.x is going to be abandoned now
> that 5.x shows the promise it does. And I mean that with absolutely no
> disrespect for the people working hard on maintaining 4.x for the
> community. Will 4.x be maintained forever? I highly doubt it, once 5.x
> stabilizes and upgrade paths are figured out we'll certainly want those
> developer resources moved to 5.x right?
>
> About code comments:
> I'm in no position to preach about code comments, but I am getting
> better at it (code comments that is :). What I think we could use _way_
> more than code comments is a sane API with at least _some_
> standardization and logic to it. But I don't have the time to do it or
> fix the millions of things that will break, so I'll just shut up now.
>
> Matt
>
>
>
> _______________________________________________
> Get started with creating presentations online - http://zohoshow.com?vt
>
_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt 
Reply | Threaded
Open this post in threaded view
|

Re: An Impassioned Plea from an VTiger Integrator

Richie-4
In reply to this post by Jeff Kowalczyk
Ok Jeff. This is new to me.
Guide me on this.

Richie




---- Jeff Kowalczyk<[hidden email]> wrote ----

Dennis Grant wrote:
> Actually, I think with VTiger you are going to see a lot of private
> forks, because individual businesses have their own needs and wants that
> are supersets of core VTiger functionality that simply don't apply to
> other businesses.

This is one of the reasons why I care about making the source more
merge-friendly (particularly short, vertically formatted SQL statement
string lines).

If we can get the codebase to the point where branching and merging is a
manageable burden, customization branches have a fighting chance to be
maintained in the repository. Or use a distributed repository such as
bazaar-ng can be used (bzr has a trac backend now).


_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt 
Reply | Threaded
Open this post in threaded view
|

Re: An Impassioned Plea from an VTiger Integrator

Richie-4
In reply to this post by Matthew Brichacek
I agree with you Matt. I will post a separate mail to have the private forkers to have their codes submitted for integration to whichever trunk needed.

Richie




---- Matthew Brichacek<[hidden email]> wrote ----

On Wed, 2006-07-12 at 10:48 -0300, Sergio A. Kessler wrote:
> Mat,
>
> v4.x would not be abandoned while there is people interested in
> maintaining it, that's all needed in open source, interested and
> executive people...
> it can be mantained forever while this condition is met...
It could, but I just don't see it happening after 5.x is stable and
usable. This is just my opinion based on past experience.

>
> and I agree with you that there was (is ?) an utterly lack of
> receptive response to community developers from the core team, and the
> project was crying for a fork, but all those people creating private
> forks also lacked the balls to create a serious *public* fork...
>
> I mean, if you are going to fork, then fork in all it's glory...
Because maintaining a proper OSS project with little to no support from
the community (and abandoning the core team) is no small task, esp. when
the boss is breathing down your neck to get X,Y,Z features enabled ASAP.
Other things.. the community was building quickly, features were
storming into the forums (even though they didn't get used) and the code
was a complete cluster fuck. The pros of a fork barely outweighed the
benefits and for mere mortal to come along and try to tackle it would
have been near suicidal.
Also, in some cases the choice to fork may have been the career saving
moment after the boss found out you decided to deploy the company on
project that was abandoned over night with no warning or word of upgrade
paths, bug fixes, etc.

>
> those people that never submitted a patch, never figthed for more open
> development, created their own private branch, and then came up here
> whining, are ... well, whiners IMO
Most of them did submit patches and fought for more open development and
when they were ignored simply took their patches and went home. Some of
us were a little more vocal about it but the only reason that worked is
because the critical mass needed to make a real change had already built
up from the people who came before us.
This really was my point in the last thread. I would normally agree
with you 100% on this issue but I think this project had a period where
there was a sign on the front door saying "Open for business..
Developers Welcome.. and Trespassers will be ignored (or shot)" all in
the same breath.

>
> those who want to mantain v4.x just need to step up and do something about it...
My argument wasn't really for 4.x maint. I think the current
maintainers are doing a fine job of keeping the release afloat for the
community (no thanks to me mind you). My point was that we should find
a way to welcome these wayward forks back to the fold. How? I dunno..
but I think it's worth investigating as I am pretty sure that many many
private vtiger4.x forks are floating about. Personally I am going
gangbusters to try and get all of our 4.x features into 5.x since I
despise being forked from a project but asking all of these integrators
to do that is not nice, nor is it standard operating procedure for an
OSS project.. I firmly believe that much less of this would have
happened if this project was following a true OSS format during the 4.x
devel and hadn't gone off half-cocked to start 5.x. Do I think 5.x was
worth the wait and headache of what happened to 4.x? Not even remotely
close, we could have added smarty, campaigns and all the AJAX fluff to
4.x in less time IMO.

So after the wind clears.. my point really comes down to getting all
these folks who are working on private forks to come back to the
community project, regardless of their justification (or lack of) for
the fork. In an OSS project your most valuable resource is your
developers and if we can find a way to get them back it will be well
worth it IMHO.


Matt

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt