I'm going to go on the record and say, for this first part of the process, if you want to have the quickest, start to finish, least amount of resistance approach to working with PHP to build a basic web site, a VM with EasyPHP may very well fit the bill nicely. With it you get the latest PHP, MySQL, Apache Server and a host of other nice features to help you navigate and manage what you need to do. All of which will help give you spare cycles to actually build a site using PHP.
The first few weeks have been looking at PHP and understanding where I can use it, and why I might want to. At the absolute simplest level, it's a great way to template base pages with pieces that you know you will use over and over again. Headers and footers? Not likely to change very much, so why copy and paste a bunch of code? Make a base php script that echo's out what you want to have appear, and have that item appear in the location you want it to on each page. Change the script, and it instantly changes everywhere it's being called. Seems really obvious after you do it, but there's that moment where you realize "Wait, are you serious? It CAN'T be THAT simple!" Actually, yes it can be!
Another nice thing that you can do with PHP is make your database connection strings, as well as your common SQL commands, and store them in a script. By inclusion, you don't have to go and edit a bunch of scripts to issue the same commands over and over, or change statements in a bunch of files. This is where that whole "red, green, refactor" aspect of Test Driven Development can be felt, and wow, it's kinda' cool.
Another thing that I like about EasyPHP, as opposed to working with the live site that I was playing with, is that the debugging process is much quicker. On my live site, I would get errors and have no clue what was happening. I'd have to comb through several log files to figure out what was going on. Here, the system is set up to put all debug messages to your response pages. May seem a bit obtrusive, but really, it's hugely helpful.
Also, programmers, I've always known this, but the past couple of weeks have reminded me of it again. Debugging programs can be a real challenge, and you can go through what look to be identical programs, line for line, and you cannot for the life of you figure out what the heck is wrong. I had one of those situations this week where I kept looking at why I couldn't update my database with a submission from a page, and it took me 45 minutes to realize I'd posted a comment with a contraction. Perfectly normal thing for someone to do, and yes, the answer is to make a substitution and escape character to handle the single quote, but that's where I ended up losing 45 minutes of my life wondering "why won't this thing work?!!" This emphasizes why programmers are often the worst testers when it comes to their own code. It's the same reason that writers/bloggers are often the worst proofreaders of their own posts (and oh, am I ever guilty of THAT).
So have you had enough of me prattling on about all this? Where's my site? What did I put together? OK, here ya' go :).
Please, contain your excitement (LOL!).
Yes, I know what a lot of you are thinking. "Seriously? You spent three weeks and this is the best you could come up with?" Correction. I spent three weeks trying to make sense out of what PHP can do, reading up on it, practicing it and playing around with it, while I spent a week getting a MySQL instance to try to behave itself, and then gave up and created an environment from scratch (EasyPHP, from start to finish, install to fully up and running, a total of fifteen minutes. I kid you not).
OK, but the results look a little... well... 1995!
- Want to have a particular part of your site appear at a particular time or set of days?
- Want to have a number of simple components, like your header and footer, be 100% predictable?
- Want to have a single place to put SQL variables and a collection of commonly used queries, and only have to change the function calls and parameters based on input?
In fact, with enough forward thinking, almost all of a site's content could be made up of just include and require statements.
Again, these are simple steps, nothing Earth-shattering going on here, but they show that, with a little bit of work, and maybe stashing of some syntax examples to use later, you can get a feel for what to do to make a site that is mostly using PHP scripts for content creation.
So what can be gleaned from the first part of this series?
- Technical testers need to realize that programming, any kind of programming, really does take a different mind set and paradigm than manual or exploratory testing does. A tester looks at a finished Lego model and says "how can I see the structure?" A programmer takes a bunch of pieces and thinks "how can I take all of these pieces and put together the finished Lego model?" Programming requires an ability to string small pieces together, and the patience to "accrete" something from very small components into a larger whole. Testers tend to take items in their larger whole and break them apart to get to their individual components and find the relationships. I've intuitively known that, but these past few weeks have made that a lot more obvious.
- PHP alone gives a site programmer some neat tools to gather up ideas and make little bits of reusable code that can appear in lots of places, or create contexts in which the code can be used in a variety of ways. The syntax and the mechanics are similar to many other languages, and getting the feel for the language and what it can do can be done in a fairly short order just by working through the examples at Codecademy. Syntax alone, though, doesn't do much for you. You need to start looking at your pages and start thinking "hmmm, could I use PHP there?" As I've found out, the answer is, well, yeah, just about anyplace, and for a whole variety of things.
- PHP does give you the ability to automate some controls, send and receive information from a database, display data on the page, and do a number of cool manipulations. Without CSS or other "sweeteners", though, it looks jut like old school raw HTML of yesteryear. We could embed CSS statements inside of PHP, but that gets ugly really quickly, and then it makes it murder to change later. PHP is good for quite a few things, but style isn't one of them. Fortunately, I'll get the chance to play with style in the upcoming week.
Oh, one other mention, and I'm going to do a full review on it in the next couple of days. While the point of these posts is to highlight things that are free, open source or easily obtainable through a web search, I do want to mention that I found the "Head First PHP & MySQL" book to be very valuable for this part of the process. The individual concepts for things like configuring Apache, using MySQL and getting syntax for PHP can all be handled with a Google search, but the Head First book gives a variety of little projects to do, all of which help to get the programmer into the mode of coding up working examples, including mistakes that can be fixed, designs that can be refactored, and projects that can be easily ported to other uses. I have some other comments, both pros and cons, but you'll just have to wait for my more complete review ;).
The wheels are now on the car, I have a little bit of gas in the tank, the vehicle starts and can be driven, at least a little. Now let's see if we can clean it up a bit and make it a bit more presentable. Hope you'll join me as I continue the journey :).