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

Slightly updated version of this deck for the SkiPHP opening keynote.

Transcript

1. Laura Thomson @lxt I can’t believe you still do it that way: a best practices retrospective 1
2. Overview §What’s a best practice? §Architecture §Security §Scalability and performance §Development practices §Is PHP dead? 2
3. 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-2014 3
4. Best Practices 4
5. §Best is a strong word §YMMV §“Good practices” Best  Prac*ces 5
6. Your PHP should •be simple •get the job done •be secure •be scalable and performant •be producible and maintainable Principles 6
7. Architecture 7
8. •First, do the simplest thing that could possibly work. Rule  #1 8
9. Text Separation of concerns 9
10. 2001 §Put reused templates in an include file §Avoid mixing php and html 10
11. 2004 §Why are you still putting php in your html? 11
12. 2008 §Why are you still putting php in your html? 12
13. 2014 §I think we’re learning. §(At least, I hope so) 13
14. Frameworks 14
15. • 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
16. 2001 §What's a framework? 16
17. 2004 §All frameworks suck 17
18. 2007 §They still suck, mostly §Framework shaming starting to decline 18
19. 2014 §PHP 5.4+ frameworks suck a lot less 19
20. 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
21. More than the sum 21
22. Decomposition and decoupling #1 part of a good architecture 22
23. 2001 §Functions §Include files 23
24. 2004 §Objects 24
25. 2007 §Reusable libraries §Services: everything’s an API 25
26. 2014 §More libraries and components §More APIs §Better package/dependency injection tools 26
27. Robustness and Resilience 27
28. 2001 §Write tests. 28
29. 2004 §TDD §Use caching (disk, memcache) to hide service failures §Defensive coding 29
30. 2007 §High Availability §Failover §Multimaster (sucks) 30
31. 2014 §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
32. Security 32
33. • 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
34. • 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
35. • 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
36. What’s different? §register_globals and magic_quotes are dead. §Slides got less wordy. §Surprisingly little else. 36
37. Web app security 37
38. 2001 §Use SSL §Don't store credit card numbers §Escape output naively (we didn’t know we were naive, honest) §addslashes()/stripslashes() 38
39. 2004 §Filter input §Escape output. §Avoid XSS/injections §mysql_real_escape_string() 39
40. 2008 §CSRF protection §Parameterized queries/prepared statements §ORM 40
41. 2014 §Wider use of frameworks protects devs from mistakes §New developers learning the right way first 41
42. Scalability & Performance 42
43. • 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
44. •Decouple. •Cache. •Federate. •Replicate. •Avoid straining hard-to-scale resources. •Dev environment needs replication too. Scalability Best Practices 44
45. •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
46. Principles 46
47. 2001 §Don’t use CGI §Tune your queries 47
48. 2004 §Cache everything §Query cache §Disk cache §memcached 48
49. 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
50. 2014 §Refinement §Graph everything §Message queues to decouple writes §NoSQL/SQL: right data store for the job §DevOps 50
51. Coding Practices 51
52. •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
53. •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
54. •Have and use a coding standard •Zend Framework, PEAR, homebrew •Legacy code always a problem Coding  standards 54
55. Code through the ages 55
56. 2001 §Write comments. §Make code reusable. 56
57. 2004 §Have a coding standard. §Use OO! 57
58. 2008 §Make it look as much like Java as possible. §Namespaces §Iterators 58
59. 2014 §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! 59
60. Process 60
61. • 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
62. Process through the ages 62
63. 2001 §Test code on your own machine §FTP to production 63
64. 2004 §Staging server §Deploy with ‘svn up’! 64
65. 2007 §Actual TDD §Instrumentable code! §Repeatable process §Agile §Death of estimation 65
66. 2014 §Better tools for everything §Continuous integration and deployment §Test automation and monitoring converge §Commoditization of version control §MTTR vs MTBF 66
67. PHP is Dead?! 67
68. 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
69. PHP is a toy language. You should use... §Perl §Cold Fusion §ASP 2001 69
70. PHP is no good for enterprise. You should use... §ASP.NET §JSP §J-everything 2004 70
71. PHP doesn’t have a single awesome framework. You should use... §Ruby on Rails 2007 71
72. 2014 PHP is for losers. You should use... §Python §Ruby §Node §Scala §Clojure §Erlang 72
74. PHP coders... gonna code 74
75. Questions? Laura Thomson laura@mozilla.com @lxt 75