li...@nopersonal.info wrote:
Do any of you have recommendations on configuration settings to use?
You may want to take a look at the popular XAMPP packages out there, most
notably that from apachefriends (http://www.apachefriends.org/en/xampp.html).
I think they have a sound and typical configuration. Although they don't
recommend it, I used XAMPP for production use and know that this site still
makes use of it. I never had any issues in the five years I ran with it.
Which packages/extensions/modules should be installed/enabled?
That depends on what you need. I think anything that comes with a stock PHP
install should be assumed to be available.
Should I go ahead and turn off error reporting and enable it via my
scripts, or should I leave it on all the time? If I should leave it on,
at what level should I set it? E_ALL?
For a test server I'd say set it to E_ALL. You may get annoyed at times with
messages, but better you get annoyed than someone else later.
Are there any other settings or extensions that might be helpful someone
like me who's still prone to making rookie mistakes?
I don't think there is a removerookiemistakes extension. What you want to do
is follow the best practices as much as possible and as much as known. That
means make sure to protect against SQL injection, separate presentation from
processing, and - in my opinion - always initialize every variable with a
value at the top of the script (I include counters for loops as well) and add
plenty of commentary. I ran into problems way too many times when I though i
has a value of 1 when in fact it was 0 or something entirely different. I
write the commentary first, typically adding a lot of detail to those areas
that I know are more difficult for me. It helps me figure out what I need to
do and later what I did do. Same way it hopefully helps someone else. You may
want to take a look at the format used by phpdoc. It really is a nice tool and
works magic even with code not commented the expected format. Lastly, whatever
you do, stick with it throughout the project. You may find later that there
are better ways to do things, but I'd first get it working, then optimize
keeping consistency across the board.
Would it be a good idea to use one php.ini file while I'm writing &
debugging my code, and then a second one for testing immediately prior
to moving to a production server? If so, how should they differ?
I'm not the typicaly PHP developer, but I'd think you want your test (and
development?) sytem and production system to be configured the same. What
purpose is there when you test on configuration A when in the end your
production system uses configuration B? You may find things that would have
failed on either configuration, but you really want to test what you are using
in the end, not something else. There may be additions for debuggers or other
tools that the core production use will not need, but unless it is a known
security risk I'd leave it in. In the worst case of all you can still attach
your development environment to the production server and debug from there.
I recommend to listen to those who do more development for the outside world.
I'm a hobbyist and sadly, I seem also to be the only one who consumes my scripts.
Would this be a good time to learn how to use CVS or Subversion?
YES! I'd recommend to go with Subversion, but you want to use some source
control. At least make clearly labeled backups of your scripts. In the end you
deal with flat files that can also be compressed very well, but a source
control system allows you rolling back changes and branching code. Not that
you couldn't do that manually as well, but attaching a project to a source
control system will make you use it. Copy and paste doesn't.
David
_______________________________________________
New York PHP User Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/show_participation.php
