Upgrade to Pro — share decks privately, control downloads, hide ads and more …

I can't believe you still do it that way: PHP best practices retrospective

I can't believe you still do it that way: PHP best practices retrospective

Closing keynote from LoneStarPHP 2013.

Laura Thomson

June 29, 2013

More Decks by Laura Thomson

Other Decks in Programming


  1. Laura Thomson @lxt I can’t believe you still do it

    that way: a best practices retrospective 1
  2. Format §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-2013 3
  3. Your PHP should •be simple •get the job done •be

    secure •be scalable and performant •be producible and maintainable Principles 6
  4. • 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 implemented • 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 maintainability 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  five  years’  *me. Frameworks  and  Architectures:  use  and  abuse 15
  5. 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 20
  6. 2013 §Minimize and isolate failure effects §Self-healing systems §Resilience: as

    much of it should work as possible §Feature flagging: turn off parts of your app that are broken or under load 31
  7. • Consider illegitimate uses of your application • Educate yourself

    • If nothing else, filter all external data –(From the PHP Security Guide at http://phpsec.org/ projects/guide/) Basic  principles 33
  8. • External data is not to be trusted. • What’s

    external data? • Anything from a form • Anything from $_GET, $_POST, $_REQUEST • Cookies • Some server variables (e.g. $_SERVER['SERVER_NAME']) • Database query results • Web services data • Files • The basic principle is to filter input and escape output • Filter input using whitelisting where possible • Escape output according to where it’s going. External  Data 34
  9. • Some common problems: • register_globals issues • XSS (Cross

    Site Scripting) • SQL/Command Injection • Code injection • Other things to worry about: • Exposed source code • Session fixation • Session hijacking • Cross site request forgeries (CSRF) •Cross domain Ajax requests AGacks 35
  10. 2001 §Use SSL §Don't store credit card numbers §Escape output

    naively (we didn’t know we were naive, honest) §addslashes()/stripslashes() 38
  11. • Profile early, profile often. • Dev-ops cooperation is essential.

    • Test on production data. • Track and trend. • Assumptions will burn you. General  Best  Prac*ces 43
  12. •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. Performance 45
  13. 2007 §Stand back, I’m going to use science §Measure, track,

    trend, profile, optimize §Build cachable code §Decouple reads from writes (write there, read here) §Replicate, federate 49
  14. •Above all, code needs to be readable and maintainable •Beware

    clever code: –cool design patterns –obscure performance tweaks –niche language features Write  good  code 52
  15. •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 53
  16. •Have and use a coding standard •Zend Framework, PEAR, homebrew

    •Legacy code always a problem Coding  standards 54
  17. 2008 §Make it look as much like Java as possible.

    §Namespaces §Iterators 58
  18. 2013 §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! §We’re living in the promised land 59
  19. • 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 61
  20. 2013 §Better tools for everything §Continuous integration and deployment §Test

    automation and monitoring converge §Commoditization of version control §MTTR vs MTBF 66
  21. 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 68
  22. 2013 PHP is for losers. You should use... §Python §Ruby

    §Node §Scala §Clojure §Erlang 72
  23. 73