phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [phpGroupWare-developers] Be funny ... (was: New developers (Was: Ne


From: Benoit Hamet
Subject: Re: [phpGroupWare-developers] Be funny ... (was: New developers (Was: Nested db-objects))
Date: Tue, 27 May 2008 11:42:05 +0200
User-agent: IceDove 1.5.0.14eol (X11/20080509)

Hi all,

That's long time I didn't read so much interesting mails in so few days
on that list. I want to thank new participants to this thread (Alan) for
their external vision of the problem. Before thinking that I'm being
Ironic, please read the following.

Some history :
I began to work on the project (thanks to the GET and C.B.) on the end
of 2003. 0.9.16 was not yet out of the box, and the forked was hold few
months before ... it took me around 6 month before understanding the
part in which I should work (I was a total newbie), into the api. I
needed some "out of the well known way" code, and found / fix some bugs
for making our project working. I contribute these bug fixes when I can,
but let my "enhancement" to .16 out of the branches since it was
"features" freezed ... At that time, the 3 layers (ui bo so) was already
in place, and since I started to code with etemplate ... I couldn't
understand that what I was doing was heretic ... but that's another
story. So this MVC System is on place since at least 5 years ...


Sigurd Nes a écrit :
> Chris Weiss wrote:
>> On Mon, May 26, 2008 at 3:26 PM, Sigurd Nes <address@hidden>
>> wrote:
>>> My problem is that my code base is huge - and I can't keep up
>>> with rapid changes in what is considered proper coding at all
>>> time.
>> 
>> the only change to the coding that standards that has even been 
>> proposed in the last 5 years or more was the line lengths.  We've
>> had a coding standards doc since very early, and IMO the separation
>> of logic and storage is clear, but it's been ignored and allowed to
>> go unchallenged, much to my frustration every time i do try to work
>> on some code.
>> 
>> However, as an example of how "no tolerance" affects smaller teams,
>>  the eGW fork is directly related to putting a foot down on not 
>> following the design goals and standards.  Joomla being a CMS has a
>>  large enough demand that they can afford to do this.  We do it and
>>  loose half the team.
>> 
> Some historical changes along the way:
> 
> Links Initially http-links was created trough a call to a function
> that accepted both strings an arrays. This was changed to only accept
> arrays.
> 
> charset The character set changed from ISO 8859-1 to UTF-8 without
> any option of choice,  which led to unexpected behaviour and a need
> for reworking the code.
> 
> notices The E_NOTICE is useful for debugging while developing /
> coding the system,  but at some point this errors suddenly (and
> shockingly) got echoed to the screen with no option of turning it
> off.
> 
> get_var Suddenly it was changed, and all calls to it had to be
> revised to the new one.
> 
> db-cloning Well - you know the story...
> 
> Sniffer Testing code for good looks. You ought to try it.
> 
> I'm fine with all this except the non-optional debug mode (notices),
> the (lack of) db-cloning and reworking consisting code based on the
> sniffer result.
I'm sorry. I don't understand why you are putting all this changes here.
Why do you expect us to deduce ? That these changes were not discussed
?, that they were made on a "not in a moving base of code" branch ? Take
the following problem :
We have around 30 apps. some thirdparty code in the phpgwapi/inc dir. So
maintain that base of code is hard. We are too few. So the code base
should be "excellent" and easy to undestand to ease the maintenance of
it. PERIOD. That good sense.I fix a lot's of link things in core apps,
was easy most of the time.
get_var ... ouch, When trying to fix it, I fall in case of insanity like
using a value of "all" to see the whole entries and an int to see only
some parts ... yes fixing this kind of stuff is a pita ... but should
have never be written ... or perhaps by a dummy newbie like me.
Charset, don't doing it now and we will die when the 1e9 of chinese will
ask for our beautiful apps.
Notices ... I don't notice anything shocking in it. Yes it killed many
apps ... then we had to fix them good. And when you do deeper in the
code, trying to really fixing it (not just doing a "isset($blah['blah'])
&& $blah['blah'] == 'doh') ... then I get crazy when reading the code
... and understand why some of us are complaining about notices being
displayed ... (who speaks about etemplate ??? you ! there !).
Links is just a KISS sample ... and be able to output validated HTML
...(Who care's about valid HTML, that's for dummies !).
db-cloning ..ah, here we are, that's the main point here. So on the left
I have a guy who wants "stay at it was (6month ago), it broke all my
code and I need 6 month to fix my code" and the right I have a guy who
wants "stay as it is, fix your code, and if your code is not working
it's your fault". In the middle you have a YAFG (yet another french guy)
who try to say: "Wait, lets see what we can do together, we can getting
back as it was for 2 weeks, letting the other guy fix the code and move
along ...". I can say (like the little dummy I am) : you can copy the db
class in your app, and use it instead of the one in phpgwapi the time
you fix your app. But will you have time to fix it anyway ?

I saw many people have red colored faces now ... nice, it's time to be
funny : I've got 4 friends of mine fired for economical reasons in "my"
company; I'm exploding deadlines... So please rant if you want, fight
but at least, keep 2 things in mind : "Easy to understand code" and
"have fun".

Regards,

Caeies.

In the fun we trust !





reply via email to

[Prev in Thread] Current Thread [Next in Thread]