Thanks to the guys at Engine Yard, I won a free pass to the Lone Star PHP community conference in Dallas, TX this year. Due to the choice of subject matter and presenters, I think I enjoyed this conference even more than last year’s PHPCon in Nashville. Here are some of the highlights.

Day 1

!Normal===Awesome!

Cal Evans inspired us all to go out and build awesome stuff, and that we owe a debt to the giants who came before us and gave, to give to those coming after.

• “This stuff is hard. If it looks easy, it’s because I’m good at it.”
• Get involved somewhere.
• Be a builder, a speaker, a teacher.

Building Testable PHP Applications

Chris Hartjes delivered a really helpful talk on testing applications. One of the big obstacles of unit testing for me was mock objects. Chris did a good job explaining how they are used in the context of PHPUnit. Key takeaways for me:

• Automate test execution.
• Following the law of demeter will make your applications easier to test.
• Code in a framework-agnostic and environment-agnostic way.
• PHPUnit provides methods for setting up mock objects, so you don’t have to actually define those classes.
• Test private/protected methods and properties by using a Reflection hack. Etsy’s PHPUnit extensions can automate this.
• Don’t access the database in Unit tests, use mock objects instead. Filesystem access can be mocked using vfsStream.
• Some applications resist testing, no matter what. If you cannot refactor, you can still automate tests with Behat.
• If you don’t test, Chris will cut you!

See his slides at SpeakerDeck.com.

PHP Extensions for Dummies

Elizabeth Smith laid bare the innards of PHP in her intro to PHP extension development. Much of it was unintelligible to me since I don’t (yet) know C. However, now I know who to go to if I need help compiling an extension! If I can navigate the dependencies, I’d like to try compiling a non-thread-safe Windows build of php_wkhtmltox for a future blog post.

Pixel Punching with PHP

Bob Majdak‘s presentation compared the usage and performance of GD2 and IMagick across a number of common image manipulation tasks. IMagick is better in almost every way.

See his slides at SpeakerDeck.com.

Day 2

It Was Like That When I Got Here: Steps Toward Modernizing a Legacy Codebase

Paul Jones‘ keynote did not disappoint. With insight and humor, Paul dismantled the problems with legacy codebases and presented a logical methodology to improving your life when you are forced to inherit a big stinkin’ pile of spagetti code.

• No matter how bad you want to, resist the urge to throw it out and rewrite.
• You’ve nothing to lose. Either bear the pain of bad code, or bear the pain of refactoring bad code. May as well put the suffering to some use.
• Move class files to a common base directory and autoload, removing require/include calls as you go.
• Change class names as you go, if needed.
• Wrap procedural functions in a class, so that it can be autoloaded.
• Replace globals incrementally, moving them first to the constructor, then replacing them with dependency injection

SOLID – Not Just a State Of Matter, It’s Principles for OO Propriety

Chris Weldon laid out five principles to get the most out of object oriented development.

• Single responsibility: each class should do one and only one thing.
• Open/Closed principle: each class is open to extension, but closed for modification. Don’t break stuff.
• Liskov Substitution principle: replace if…else constructs and prevent exceptions by using typed collections.
• Interface segregation: each interface should be as focused as possible, so that it can be used by as many classes as need it. Similar to the Open/Closed principle, applied to interfaces.
• Dependency Inversion: injection dependencies from the outside, don’t couple on the inside.

Fast, Not Furious: Performance Tuning that Works

Davey Shafik demonstrated how to use xhprof/xh-gui and Memcache to optimize your PHP application.

• 1. Benchmark. 2. Profile. 3. Change.
• Profiling affects performance, similar to quantum observation.
• Benchmarking tests actual runtime, from start to end.
• Namespacing Memcache keys can help overcome the 1MB size limit
• Create new namespaces, don’t clear the cache. Garbage collection will clean up the old unused namespaces.
• “Hardware is cheap, programmers are expensive” only holds when you take care of your hardware.
• Don’t make assumptions, test everything sequentially.