Slightly updated version of this deck for the SkiPHP opening keynote.
I can’t believe you still do it that way:
a best practices retrospective
§What’s a best practice?
§Scalability and performance
§Is PHP dead?
§Disclaimer: Anything with a black header is a vintage slide and
may be dated
§Reading your own old slides is like reading old code :(
§Each topic through the ages 2001-2014
§Best is a strong word
Your PHP should
•get the job done
•be scalable and performant
•be producible and maintainable
•First, do the simplest thing that could possibly work.
Separation of concerns
§Put reused templates in an include ﬁle
§Avoid mixing php and html
§Why are you still putting php in your html?
§Why are you still putting php in your html?
§I think we’re learning.
§(At least, I hope so)
• PHP frameworks are proliferating, and Rails doesn’t help.
• Having an architecture like MVC can be a really good thing, but:
• Everybody has a different idea about how this ought to be
• Some of the ideas are really twisted
• Some make it hard to do very basic things simply
• Code bloat
• Which framework?
• No dominant paradigm yet, ergo little help with
Have a clear, simple, architecture that is easy to add to, easy to explain to new developers, and easy
to remember now or in two or ﬁve years’ *me.
Frameworks and Architectures: use and abuse
§What's a framework?
§All frameworks suck
§They still suck, mostly
§Framework shaming starting to decline
§PHP 5.4+ frameworks suck a lot less
Framework best practices
§Lightweight beats heavyweight (unless it doesn’t)
§CRUD, junior devs, MVP, giant teams
§ORM is a kickstarter: training wheels for your app
§Use what works, and throw it away when it doesn’t
More than the sum
Decomposition and decoupling
#1 part of a good architecture
§Services: everything’s an API
§More libraries and components
§Better package/dependency injection tools
§Use caching (disk, memcache) to hide service failures
§Minimize and isolate failure effects
§Resilience: as much of it should work as possible
§Feature ﬂagging: turn off parts of your app that
are broken or under load
• Consider illegitimate uses of your application
• Educate yourself
• If nothing else, ﬁlter all external data
–(From the PHP Security Guide at http://phpsec.org/
• External data is not to be trusted.
• What’s external data?
• Anything from a form
• Anything from $_GET, $_POST, $_REQUEST
• Some server variables (e.g. $_SERVER['SERVER_NAME'])
• Database query results
• Web services data
• The basic principle is to ﬁlter input and escape output
• Filter input using whitelisting where possible
• Escape output according to where it’s going.
• Some common problems:
• register_globals issues
• XSS (Cross Site Scripting)
• SQL/Command Injection
• Code injection
• Other things to worry about:
• Exposed source code
• Session ﬁxation
• Session hijacking
• Cross site request forgeries (CSRF)
•Cross domain Ajax requests
§register_globals and magic_quotes are dead.
§Slides got less wordy.
§Surprisingly little else.
Web app security
§Don't store credit card numbers
§Escape output naively (we didn’t know we were
§Parameterized queries/prepared statements
§Wider use of frameworks protects devs from
§New developers learning the right way ﬁrst
Scalability & Performance
• Proﬁle early, proﬁle often.
• Dev-ops cooperation is essential.
• Test on production data.
• Track and trend.
• Assumptions will burn you.
General Best Prac*ces
•Avoid straining hard-to-scale resources.
•Dev environment needs replication too.
Scalability Best Practices
•Use a compiler cache.
•Be mindful of using external data sources.
•Avoid recursive or heavy looping code.
•Don’t try to outsmart PHP.
•Build with caching in mind.
§Don’t use CGI
§Tune your queries
§Stand back, I’m going to use science
§Measure, track, trend, proﬁle, optimize
§Build cachable code
§Decouple reads from writes (write there, read
§Message queues to decouple writes
§NoSQL/SQL: right data store for the job
•Above all, code needs to be readable and
•Beware clever code:
–cool design patterns
–obscure performance tweaks
–niche language features
Write good code
•Turn error_reporting up in dev and
display_errors off in production
•Use set_error_handler() and
set_exception_handler() for top level errors
•Whacking all your code in a try…catch block
is not a panacea.
Errors and Excep*ons
•Have and use a coding standard
•Zend Framework, PEAR, homebrew
•Legacy code always a problem
Code through the ages
§Make code reusable.
§Have a coding standard.
§Make it look as much like Java as possible.
§So many nice nice things
§PHP 5.4 generators and anonymous functions and
traits, oh my
§(It’s beginning to look a lot like Christmas Ruby)
§I’m kidding. Kind of.
§Composer! PHPUnit! PHPDoc! Doctrine!
• The process needs managing
• Use a version control system
• Have a testing and release process
• Have an easy way for developers to set up a staging server
• Plan for scale
Web Dev is SoMware Dev
Process through the ages
§Test code on your own machine
§FTP to production
§Deploy with ‘svn up’!
§Death of estimation
§Better tools for everything
§Continuous integration and deployment
§Test automation and monitoring converge
§Commoditization of version control
§MTTR vs MTBF
PHP is Dead?!
PHP is not a best practice
§PHP is an anti-pattern
§Pinnacle of bad design
§All PHP developers are incompetent
§PHP is only suitable for making trivial personal sites
PHP is a toy language. You should use...
PHP is no good for enterprise. You should use...
PHP doesn’t have a single awesome framework.
You should use...
§Ruby on Rails
PHP is for losers. You should use...