Re: Programs not running
| From: | Karl DeSaulniers | Date: | Sun, 06 Jan 2013 00:14:22 +0000 |
| Subject: | Re: Programs not running | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.db |
| Request: | Send a blank email to php-db+get-48616@lists.php.net to get a copy of this message | ||
On Jan 5, 2013, at 8:52 AM, tamouse mailing lists wrote:
On Sat, Jan 5, 2013 at 12:48 AM, Karl DeSaulniers <karl@designdrumm.comwrote:Oh, ok. Then I was not as lost on the subject as I thought. Being a solo worker who is seeking a job with a team, I thought I may be missing something and would not want to be cut from the team for my lack of knowledge on the subject. I personally do what you all have been saying in response to Ethan's posts. If I hit a snag or have a problem and no error code, I go through and remove functions until I come to the one that is causing the problem. This is a little lengthily of a process, but has proven the best method for me an my lack of php experience. Unfortunately, I do not know or have experience using any php editing IDEs, my code is written in Adobe GoLive... lol Does have syntax coloring, but about as good as Text edit or note pad when it comes to debugging. Basically the same as hand coding.. actually that's what it is.. :) Thank you for your response and the link on command line. I will take a look. Best, Karl DeSaulniers Design Drumm http://designdrumm.comOn Jan 4, 2013, at 8:00 PM, tamouse mailing lists wrote:Not necessarily directly to production, but the beginning of the stream that will take something from development, through testing, staging, and finally into production. The initial point where you merge things is generally shared by all developers on a project, and to break it means you are breaking things for everyone on your team. Note this applies to mulitperson projects; if you do this to yourself on your solo project, not so much of a problem.On Fri, Jan 4, 2013 at 6:09 PM, Matt Pelmear <mjpelmear@gmail.com> wrote:For those of us who have no idea of what you speak, can you elaborate so as we don't make that mistake? Or are you just talking about submitting a file to production without testing it?On 01/04/2013 01:40 PM, tamouse mailing lists wrote:Committing a syntax error which breaks integration is a HUGE HUGE NO NO. Such a person would likely be cast from a dev team, or relegated to some more benign task.One should be able to solve parsing problems without resorting to using a web server. Every time I save a php file, I have my editor set to run it through php -l. Saves lots of angst when I get to the web testing stage.This is a good idea in general. It's also a good trick to check for this problem from the command line when suspecting a parse problem. Most IDEs will make parse errors very obvious while you are editing the file, too. Unfortunately not all members of any given development team can be relied upon to test things in this way before committing ;)I personally have not used command line. It is new to me, but sounds integral. Where can one study its use?You can start with: http://php.net/manual/en/features.commandline.php As for telling your editor to pass the file through php -l, that's something that is extremely editor specific. I can tell how it's done in Emacs, TextMate and Sublime Text 2, but naught else. Using a full-fledged IDE such as Eclipse or PHPStorm will automatigically flag syntax problems. --PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php