NYCPHP Meetup

[David Krings]

lists at 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