php-general Digest 24 Sep 2012 22:07:25 -0000 Issue 7978
Topics (messages 319219 through 319239):
Joining a team, where no wiki or docs are available
319219 by: AmirBehzad Eslami
319220 by: Samuel Lopes Grigolato
319221 by: Jim Giner
319222 by: AmirBehzad Eslami
319223 by: Haluk Karamete
319224 by: AmirBehzad Eslami
319225 by: Mihamina Rakotomandimby
319226 by: admin
319227 by: shiplu
319228 by: AmirBehzad Eslami
319229 by: Mihamina Rakotomandimby
319230 by: AmirBehzad Eslami
319231 by: AmirBehzad Eslami
319232 by: AmirBehzad Eslami
319233 by: shiplu
319236 by: Samuel Lopes Grigolato
319237 by: Daevid Vincent
319238 by: David OBrien
319239 by: Daevid Vincent
Re: Day after Friday
319234 by: Tedd Sperling
319235 by: Tedd Sperling
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Hi,
i'm going to join a mid-size company with a few PHP-driven projects
written in procedural PHP, million years old.
At the moment, they don't have a wiki or any documentation about their
projects. For me, the first challenge in probation period is to understand
how their code works.
*
Considering that there is no wiki or docs, How can I see the Big Picture?*
i'm sure this is a common problem for programmers everywhere.
What approach do you use in a similar situation?
Is there a systematic approach for this?
Is there reverse-engineering technique to understand the design of code?
Please share your experience and thoughts.
-Thanks in advance,
Behzad
--- End Message ---
--- Begin Message ---
I would recommend reading this article:
http://www.infoq.com/articles/tips-to-developers-starting-on-large-apps
It's targeted to Java developers, but the concepts are valid to any language.
Hope it helps.
Cheers,
Samuel.
-----Mensagem original-----
De: AmirBehzad Eslami [mailto:behzad.esl...@gmail.com]
Enviada em: segunda-feira, 24 de setembro de 2012 11:05
Para: PHP General Mailing List
Assunto: [PHP] Joining a team, where no wiki or docs are available
Hi,
i'm going to join a mid-size company with a few PHP-driven projects written in
procedural PHP, million years old.
At the moment, they don't have a wiki or any documentation about their
projects. For me, the first challenge in probation period is to understand how
their code works.
*
Considering that there is no wiki or docs, How can I see the Big Picture?* i'm
sure this is a common problem for programmers everywhere.
What approach do you use in a similar situation?
Is there a systematic approach for this?
Is there reverse-engineering technique to understand the design of code?
Please share your experience and thoughts.
-Thanks in advance,
Behzad
--- End Message ---
--- Begin Message ---
On 9/24/2012 10:05 AM, AmirBehzad Eslami wrote:
Hi,
i'm going to join a mid-size company with a few PHP-driven projects
written in procedural PHP, million years old.
At the moment, they don't have a wiki or any documentation about their
projects. For me, the first challenge in probation period is to understand
how their code works.
*
Considering that there is no wiki or docs, How can I see the Big Picture?*
i'm sure this is a common problem for programmers everywhere.
What approach do you use in a similar situation?
Is there a systematic approach for this?
Is there reverse-engineering technique to understand the design of code?
Please share your experience and thoughts.
-Thanks in advance,
Behzad
If you really are joining a team, I would expect that the teammates
would be guiding you through their systems. If only to ensure that you
are becoming productive.
--- End Message ---
--- Begin Message ---
Thanks Samuel.
Actually I'm not going to add features or fix bugs, they're trying a
refactoring process, to improve the design of code. So, I really need
to understand the current design at the outset.
On Mon, Sep 24, 2012 at 5:41 PM, Samuel Lopes Grigolato <
samuel.grigol...@gmail.com> wrote:
> I would recommend reading this article:
> http://www.infoq.com/articles/tips-to-developers-starting-on-large-apps
>
> It's targeted to Java developers, but the concepts are valid to any
> language.
>
> Hope it helps.
>
> Cheers,
> Samuel.
>
--- End Message ---
--- Begin Message ---
I would first start out with checking the code where user input is
taken and then placed into SQL statements from a SQL Injection point
of view, I would also take a look if user input is echoed back without
any treatment to see if there are issues with XSS.
If these checks yield that the previous programming done carelessly, I
would call IT department to an immediate meeting to discuss this
matter.
At that time, you either convince the IT department that the code
needs to be re-written or a great patch work is due. But many times,
writing code from the ground up yields way better results than trying
to fix the problematic code.
I think there are two kinds of programmers. Those with do what they
are told and could not care less the rest and Those who stop their
bosses and guide them in the proper track.
On Mon, Sep 24, 2012 at 7:05 AM, AmirBehzad Eslami
<behzad.esl...@gmail.com> wrote:
> Hi,
>
> i'm going to join a mid-size company with a few PHP-driven projects
> written in procedural PHP, million years old.
>
> At the moment, they don't have a wiki or any documentation about their
> projects. For me, the first challenge in probation period is to understand
> how their code works.
> *
> Considering that there is no wiki or docs, How can I see the Big Picture?*
> i'm sure this is a common problem for programmers everywhere.
>
> What approach do you use in a similar situation?
> Is there a systematic approach for this?
> Is there reverse-engineering technique to understand the design of code?
>
> Please share your experience and thoughts.
>
> -Thanks in advance,
> Behzad
--- End Message ---
--- Begin Message ---
Jim wrote:
>> If you really are joining a team, I would expect that the teammates
would
>> be guiding you through their systems.
True, but based on my experience, most programmers are not good when it
comes
to explain stuff. So, I should rely on my own.
--- End Message ---
--- Begin Message ---
On 09/24/2012 05:19 PM, AmirBehzad Eslami wrote:
True, but based on my experience, most programmers are not good when it
comes
to explain stuff. So, I should rely on my own.
Choose another team?
--
RMA.
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> Hi,
>
> i'm going to join a mid-size company with a few PHP-driven projects written
> in procedural PHP, million years old.
>
> At the moment, they don't have a wiki or any documentation about their
> projects. For me, the first challenge in probation period is to understand
> how their code works.
> *
> Considering that there is no wiki or docs, How can I see the Big Picture?*
> i'm sure this is a common problem for programmers everywhere.
>
> What approach do you use in a similar situation?
> Is there a systematic approach for this?
> Is there reverse-engineering technique to understand the design of code?
>
> Please share your experience and thoughts.
>
> -Thanks in advance,
> Behzad
Behzad,
I would start by mapping their databases structure. Get an
understanding of the data behind the application.
Normally this gives you a better insight into their thought process, providing
they use one.
Now for each page I would map out any functions, statements or includes to a
diagram and documenting explanations for everything.
Because their concept of what the application does may not be the actual
functionality.
This will allow you to see pitfalls, bad coding, and areas of improvement. This
will also allow you do explain to them what the application really does.
Think documentum
--- End Message ---
--- Begin Message ---
If there is no wiki there could be inline comment. If not inline comments
and those are written by your peers, dont join that team.
Even there are inline comments you'll need to understand the architecture
fast. Inline comments will help to understand a small context but not the
whole
For this try run the application with a debugger. And step through it. If
you know debugging well in PHP you'll understand the workflow.
--
Shiplu.Mokadd.im
ImgSign.com | A dynamic signature machine
Innovation distinguishes between follower and leader
--- End Message ---
--- Begin Message ---
That's like erasing the question from the paper, in order to give it a
solution!
I was thinking about this problem for a while, and I've ended-up with this
approach:
#1 Start using the software as an End-User (don't care about the code) to
understand the business-value of the software
#2 Take a look at the database scheme, try to understand the entities and
their relations
#3 As you use the software, you'll become more curious about its features
and how they've implemented.
#4 Start to see how they've implemented common problems, such as:
Authentication, CRUD, etc. How the other interesting features are
implemented
So that's an approach. What do you think?
You can't join a team and ask them: How this software is implemented?
They'll simply stare at you. Instead, *we need to ask smart questions*.
Now where these smart questions come from?
We need to understand some of the design prior to ask questions, right?
With that basic understanding, we can ask good questions, and will gain
benefit
from the answers.
On Mon, Sep 24, 2012 at 5:52 PM, Mihamina Rakotomandimby <miham...@rktmb.org
> wrote:
> On 09/24/2012 05:19 PM, AmirBehzad Eslami wrote:
>
>> True, but based on my experience, most programmers are not good when it
>> comes
>> to explain stuff. So, I should rely on my own.
>>
>
> Choose another team?
>
> --
> RMA.
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Kind regards,
-behzad
--- End Message ---
--- Begin Message ---
On 09/24/2012 05:38 PM, AmirBehzad Eslami wrote:
#1 Start using the software as an End-User (don't care about the code) to
understand the business-value of the software
#2 Take a look at the database scheme, try to understand the entities and
their relations
#3 As you use the software, you'll become more curious about its features
and how they've implemented.
#4 Start to see how they've implemented common problems, such as:
Authentication, CRUD, etc. How the other interesting features are
implemented
#5 install xdebug + geben + emacs and have a look at the call stacks and
bottlenecks.
--
RMA.
--- End Message ---
--- Begin Message ---
+Like.
The idea of mapping the db-structure and logic behind each page is
interesting.
Thanks for sharing.
On Mon, Sep 24, 2012 at 6:06 PM, admin <ad...@buskirkgraphics.com> wrote:
>
>
> I would start by mapping their databases structure.
> Now for each page I would map out any functions, statements or includes to
> a diagram and documenting explanations for everything.
>
> This will allow you to see pitfalls, bad coding, and areas of improvement.
> This will also allow you do explain to them what the application really
> does.
> Think documentum
>
>
>
>
>
>
>
--
Kind regards,
-behzad
--- End Message ---
--- Begin Message ---
Never worked with Emacs or genben. I'm a fan of vim ;)
But thanks a ton, based on your suggestion, I just found vim-dbgp
On Mon, Sep 24, 2012 at 6:27 PM, Mihamina Rakotomandimby <miham...@rktmb.org
> wrote:
>
> #5 install xdebug + geben + emacs and have a look at the call stacks and
> bottlenecks.
>
>
> --
> RMA.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Kind regards,
-behzad
--- End Message ---
--- Begin Message ---
Shiplu,
For debugging, what else do you use beyond xdebug and var_dump() ?
On Mon, Sep 24, 2012 at 6:07 PM, shiplu <shiplu....@gmail.com> wrote:
> If there is no wiki there could be inline comment. If not inline comments
> and those are written by your peers, dont join that team.
> Even there are inline comments you'll need to understand the architecture
> fast. Inline comments will help to understand a small context but not the
> whole
> For this try run the application with a debugger. And step through it. If
> you know debugging well in PHP you'll understand the workflow.
>
> --
> Shiplu.Mokadd.im
> ImgSign.com | A dynamic signature machine
> Innovation distinguishes between follower and leader
>
>
--- End Message ---
--- Begin Message ---
On Mon, Sep 24, 2012 at 9:09 PM, AmirBehzad Eslami
<behzad.esl...@gmail.com>wrote:
> Shiplu,
> For debugging, what else do you use beyond xdebug and var_dump() ?
Netbeans for PHP and Eclipse PDT. Both has good debugger support. An
all-in-one package will server your purpose. Otherwise configuring xdebug
might be painful.
--
Shiplu.Mokadd.im
ImgSign.com | A dynamic signature machine
Innovation distinguishes between follower and leader
--- End Message ---
--- Begin Message ---
What about using visual code coverage instead of callstacks? I think the big
picture is easier to digest. Maybe a combination of both, as code coverage
won't provide the "time" axis of the monster.
Something like http://phpcoverage.sourceforge.net/
-----Mensagem original-----
De: Mihamina Rakotomandimby [mailto:miham...@rktmb.org]
Enviada em: segunda-feira, 24 de setembro de 2012 11:58
Para: PHP General
Assunto: Re: [PHP] Re: Joining a team, where no wiki or docs are available
On 09/24/2012 05:38 PM, AmirBehzad Eslami wrote:
> #1 Start using the software as an End-User (don't care about the code)
> to understand the business-value of the software
> #2 Take a look at the database scheme, try to understand the entities
> and their relations
> #3 As you use the software, you'll become more curious about its
> features and how they've implemented.
> #4 Start to see how they've implemented common problems, such as:
> Authentication, CRUD, etc. How the other interesting features are
> implemented
#5 install xdebug + geben + emacs and have a look at the call stacks and
bottlenecks.
--
RMA.
--
PHP General Mailing List (http://www.php.net/) To unsubscribe, visit:
http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: AmirBehzad Eslami [mailto:behzad.esl...@gmail.com]
> Sent: Monday, September 24, 2012 7:05 AM
> To: PHP General Mailing List
> Subject: [PHP] Joining a team, where no wiki or docs are available
>
> Hi,
>
> i'm going to join a mid-size company with a few PHP-driven projects
> written in procedural PHP, million years old.
>
> At the moment, they don't have a wiki or any documentation about their
> projects. For me, the first challenge in probation period is to understand
> how their code works.
> *
> Considering that there is no wiki or docs, How can I see the Big Picture?*
> i'm sure this is a common problem for programmers everywhere.
>
> What approach do you use in a similar situation?
> Is there a systematic approach for this?
> Is there reverse-engineering technique to understand the design of code?
>
> Please share your experience and thoughts.
>
> -Thanks in advance,
> Behzad
I was in this same situation when I started 2011-03. No wiki. No revision
control. No real process. No documentation. They'd push to production by
copying files manually. When they wanted to create a new website, they'd clone
an existing one and start modifying -- no shared libraries (so they had 50
versions of the same dbconnection.class.php but all just slightly different
since that is also where they housed the configuration user/pass/etc.)!! It was
a clu$terfsck.
Take a day or two to go through every menu item and just see how the thing
works from a user POV. You don't have to memorize it, just be familiar with
concepts, vocabulary, paths, etc.
First thing I did was install Trac
http://trac.edgewall.org/
And of course Subversion. I personally recommend the 1.6 branch and not the
newer 1.7 that uses sqlite. That version seems to always corrupt, especially on
the clients (like in TortoiseSVN).
http://subversion.apache.org/
I would use something to visually map out the database. If it's using MySQL,
there are free tools like MySQL Workbench. But if they don't use InnoDB tables,
it can get painful to draw the lines if it's a large DB.
http://www.mysql.com/products/workbench/
I then started to go through code and use PHPDoc for every major function or
method, especially in classes or include files where the meaty stuff happens,
or very complex portions. I didn't bother with every get_* or set_* unless
there was something obscure about them. Although, over a year later, and we
have pretty much filled them all in now as the other devs started helping once
they saw how easy it is to do a few as you encounter them in your daily coding,
and how awesome that integrates with PDT or Zend Studio (amongst other IDEs).
We didn't generate an actual PHPDoc Web version, there's really no need. The
IDE shows you the important stuff anyways. We're pretty diligent about keeping
these PHPDoc comment blocks updated now.
http://www.zend.com/en/products/studio/
I then started the long tedious process of merging our various different sites
to implement shared libraries (database connections, memecache, various
objects, etc.). If you have only one project, then this is less of an issue,
but if you have > 1 vhost or something then you'll want to do this.
All the while I documented useful tips, tricks, explanations, etc. in the Wiki.
Referencing source code (which is of course committed at this point). Trac
rules in that respect.
Xdebug will give you vastly better call stack and var_dump() alone. I don't use
the breakpoint stuff myself, but that is another benefit perhaps.
http://xdebug.org/
And for the love of [insert deity of your choice here] not EVERYTHING has to be
OOP. Use the best tool for the job!! Nothing pisses me off more than having to
instantiate a new class just to do some simple method that a standard function
would do. If you want to be organized, use static methods then where
appropriate, but don't avoid functions just because some book told you that OOP
is the king $hit.
d
--- End Message ---
--- Begin Message ---
On Mon, Sep 24, 2012 at 3:06 PM, Daevid Vincent <dae...@daevid.com> wrote:
>
> And for the love of [insert deity of your choice here] not EVERYTHING has
> to be OOP. Use the best tool for the job!! Nothing pisses me off more than
> having to instantiate a new class just to do some simple method that a
> standard function would do. If you want to be organized, use static methods
> then where appropriate, but don't avoid functions just because some book
> told you that OOP is the king $hit.
>
>
I'll never forget my first experience with a full blown Zend framework
application.
There were about 13 files and around 15k lines of code included to display
one line of text in the header where just a simple echo would have
sufficed.
--- End Message ---
--- Begin Message ---
That is a good point. We do not do unit tests here. Nothing against them, it’s
just a bit overkill for our needs. We build lots of websites, not one massive
SaaS.
But I’m not saying do not use OOP. I’m just saying not everything has to be
OOP. It’s a subtle but significant difference.
We have OOP classes for our database connection (and of course the helper
routines), memecache access/purging/etc., and then objects for actors, movies,
scenes, search results, HTML templates, email, tickets, etc… again, use the
right tool for the job. When all you have is a hammer, everything is a nail.
Build a toolbox. ;-)
From: AmirBehzad Eslami [mailto:behzad.esl...@gmail.com]
Sent: Monday, September 24, 2012 12:47 PM
To: Daevid Vincent
Cc: PHP General Mailing List
Subject: Re: [PHP] Joining a team, where no wiki or docs are available
Wow. David. That was a great help with every detail !
Thanks for sharing that with us.
One side question:
Without OOP, how do you handle Unit Tests?
Do you know a Testing framework for procedural code?
--- End Message ---
--- Begin Message ---
On Sep 23, 2012, at 10:17 AM, Samuel Lopes Grigolato
<samuel.grigol...@gmail.com> wrote:
> Independent of programming language, good teaching skills will lead to
> self-taught developers with a bunch of best practices under the hood. I hope
> you are such a good teacher =). We need not PHP or Java developers, we need
> good and creative designers that can adapt to new tools.
>
> One language is only a path among others with the same goal, software with
> quality. Remember Brooks (1986, yes, that old!), the real problem (essence of
> software engineering) is capture business requirements as specifications, and
> not translate specifications to software.
>
> The point is, you, as a teacher, has a wider responsibility, you need to find
> and incentive creative talents, not just teach one or another native function.
>
> Cheers.
> Samuel.
I think I have a handle on that.
What I tell my students is "I can't teach you computer programming, it's you
pounding keyboards and seeing how the computer responds is what teaches you
coding."
I also show them the similarities between different languages thus giving my
students the confidence to develop code in any language. After all, programming
languages are constantly changing (or dying) and they all are getting closer
together in syntax and function. IMO, in the future, we'll have one common
computer programming language.
In short, I'll give them the tools, but it is up to them to implement them.
Cheers,
tedd
_____________________
t...@sperling.com
http://sperling.com
--- End Message ---
--- Begin Message ---
On Sep 23, 2012, at 6:28 PM, Paul M Foster <pa...@quillandmouse.com> wrote:
> On Sun, Sep 23, 2012 at 09:33:33AM -0400, Tedd Sperling wrote:
>>
>> It would be nice if administration decisions were made with respect to
>> "what is best for the student"....
>
> You know, I never had much respect for academia...
Academia has it's place, but it often takes someone smarter to figure out what
that is.
Cheers,
tedd
_____________________
t...@sperling.com
http://sperling.com
--- End Message ---
