I just put down my copy of Hands-on Testing with PHPUnit How-to by Michael Lively, published through Packt Publishing.
Overall, this is a pretty good book, and covers all of the topics one would expect from a Unit Testing book. Such topics include getting PHPUnit installed via PEAR, writing and running some basic tests, doing some configuration of PHPUnit, how to incorporate PHPUnit into your project, how to generate PHPUnit tests semi-automatically using an existing codebase, fixtures and providers and mock objects, how to setup test dependencies, testing abstract classes and traits, how to expect good exceptions and errors, using output buffering for the purpose of testing CLI scripts, how one tests private and protected members, testing database connections, and making sense of the automatically generated code coverage HTML.
The book flows from subject to subject smoothly, with each new topic building on the knowledge of previous topics, without ever introducing the reader to an overly-complex topic. The reader is guided along with concise code examples and explanations of why everything is happening. The author also covers alternative libraries for making Unit Testing easier whenever possible, most notably when covering different mocking frameworks such as Mockery or the authors very-own Phake. Another appreciated set of alternatives include using SQLite for keeping track of data and how the same thing can be done with XML or YAML.
One thing I did wish the book covered more is the why behind Unit Testing, and how to get the reader into the Test Driven Development (TDD) mindset, however this is undoubtedly outside of the scope of a book in the Packt Instant series. Personally, I find myself lacking in the Unit Testing department. The last two large PHP projects I’ve worked on both had PHPUnit integrated into the codebase and I always find myself writing my Unit Tests at the last minute, well after the code had been finalized.
Several sections of the book did open my eyes to the true potential of PHPUnit, most notably the ability to automatically create unit test skeletons based on existing codebases. This will make for a great way to introduce Unit Testing to existing projects which otherwise lack testing. I was also surprised to see that PHPUnit had a solution for testing Traits, a new feature of PHP 5.4. I did find it interesting that there are standardized methods for testing database connectivity; I had always been under the impression that doing so was taboo.
If you are new to the concept of Unit Testing, and would like to apply it to PHP in particular, I highly recommend picking up a copy of Hands-on Testing with PHPUnit How-to by Michael Lively. It’s a small book, quickly digested, and will make a nice desk-side companion (heck, I’ve already got friends who want to borrow my copy). While the code is thoroughly explained, the content is terse enough to serve as a reference.
Here’s a video I took of an alley that I have to walk through every day to work. It’s pretty obvious that someone is being very sloppy with their grease dumping habits. I’m not positive which company is dumping it. The doorway seen in the video connects to Tomukun, a local restaurant.
This same situation happens weekly. If you look closely at the stained cement, you can see that this has been happening for a long time. The smell is disgusting, and sticks around for days at a time. The grease flows from the Tomukun part of the alley, and runs through a neighboring property (used to be owned by Grand Traverse Pie Company) in their seating area. I’m pretty sure it will require some major pressure washing to fix, and is probably diminishing the property value.
I’m assuming this has gone unchecked for so long because the building in front with the seating area being ruined is currently closed. Obviously, once a business moves in, they will make sure this issue goes away pretty quickly (otherwise their customers would never want to eat outside). I’m posting this on my blog for visibility, in the hopes that I can get whoever owns the grease trap to stop dumping.
Back in the day, The Oatmeal released their Tumblebeasts free to use for the world! And, after spending enough time on Google trying to find them and coming up with nothing, I figure I might as well make them available here!
Here’s the code and notes for a presentation I’m giving this Saturday on PHP and Redis:
Even if you’re not going to presentation, feel free to check it out and give it a try. Redis is pretty simple to use and quite powerful once you get the hang of it.
If you’d like to have the most recent version of Redis installed on your Debian machine, follow along with this guide. Unfortunately, the process of installing it is not as easy as `sudo apt-get install redis`, which you probably already knew since you’re reading this. The current version of Redis, at the time of me writing this, is 2.6.13. Go to the website and copy the download link and be sure to change the version in the URL below:
# Install the required tools to build the source sudo apt-get install build-essential # Download and extract the files wget http://redis.googlecode.com/files/redis-2.6.13.tar.gz tar -xzf redis-2.6.13.tar.gz cd redis-2.6.13 # Compile make install
Now that you’ve got it “installed”, you’re going to want to make it a Debian service (so that it can run on startup, and you can use commands like `sudo service redis start`):
# Create a user account for Redis sudo adduser --system --no-create-home --disabled-login --disabled-password --group redis # Make a writable log file sudo touch /var/log/redis.log sudo chown redis:redis /var/log/redis.log sudo chmod u+w /var/log/redis.log # Make an init script cd /etc/init.d/ wget https://gist.github.com/peterc/408762/raw -O redis sudo chmod u+x redis sudo update-rc.d -f redis defaults # Make a place to store your database sudo mkdir /var/redis sudo chown redis:redis /var/redis sudo chmod u+xw /var/redis
Next, you’ll want to edit the configuration script. Do the following:
sudo mkdir /etc/redis sudo touch /etc/redis/redis.conf sudo chown redis:redis -R /etc/redis/ sudo vim /etc/redis/redis.conf
Here is what I use for my redis.conf file:
daemonize yes pidfile /var/run/redis.pid logfile /var/log/redis.log port 6379 # bind 127.0.0.1 # unixsocket /tmp/redis.sock timeout 300 loglevel verbose databases 16 save 900 1 save 300 10 save 60 10000 rdbcompression yes dbfilename dump.rdb dir /var/redis/ # requirepass foobared
Once that’s all done, run the following to make sure everything was installed properly:
$ sudo service redis start $ redis-cli > INFO
If you see an error when the server is starting, or an error after running the CLI script that it cannot connect, something went awry. Leave a comment and I’ll be sure to lend a hand.
Boy does my Homebrew installation like to get messed up. Pretty much every time I do a big `brew update` I have to repair everything. This is what I typically have to do:
cd /usr/local sudo chown -R USERNAME /usr/local/.git sudo chown -R USERNAME /usr/local sudo chown -RL mysql:mysql /usr/local/mysql/data git pull git reset --hard origin/master brew update
My permissions often end up completely out of whack, and I also get a bunch of garbage in the /usr/local directory. This fixes the permissions and pulls the latest from homebrew and runs the update. Your mileage may vary.
If you’re using my previous method for logging a networks ever-changing public IP to a webserver you control, you can use this simple command to grab the last known IP and SSH into the box that way.
ssh USERNAME@`curl -s http://www.example.com/pong.php`
The `backticks`, when run in a shell, will execute that command and return the results. In this case, it grabs the pong script, reading the IP address it provides, and the SSH’s into it.
<?php $raw_header = "http://location/\r\nBadHeader"; # PHP 5.4: $clean_header = explode("\n", explode("\r", $raw_header))); # PHP 5.3: $no_cr = explode("\r", $raw_header); $no_nl = explode("\n", $no_cr); $clean_header = $no_nl; unset($no_cr, $no_nl); echo $clean_header;
Use this script to take a photo using the webcam on your computer. It makes use of and requires the installation of mplayer. When it takes pictures, it will take 20 of them, and delete the first 19. I have to do this because my netbook has a really crappy camera, and it takes a while to adjust to the light and focus. You might be able to get away with a lower setting, so tweak the number until something looks good.
#!/bin/bash # Take 20 frames worth of pictures mplayer -vo png -frames 20 tv:// # Copy the 20th frame to the webcam directory as the current time mv /home/USERNAME/00000020.png /home/USERNAME/webcam/`date +"%Y-%m-%d_%H:%M:%S"`.png # Delete the first nineteen frames rm /home/USERNAME/000000*.png
I wouldn’t be surprised if mplayer has some sort of command to ‘trim’ the first 20 frames, and specify output location so you don’t have to run this awkward delete, but I wasn’t able to figure it out.
The images will be saved into a folder called webcam, and the filenames will be in the format YYYY-MM-DD_HH:MM:SS.
I’m using absolute paths for everything because I’m running this as a CRON job (to take a picture once per minute). Basically, I use it as a security camera. If you’d like to do the same, feel free to snag this crontab entry (which you can add by running `crontab -e`):
* * * * * /home/USERNAME/webcam/grab.sh >/dev/null 2>&1