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

Slide 1

Slide 1 text

Laura Thomson @lxt I can’t believe you still do it that way: a best practices retrospective 1

Slide 2

Slide 2 text

Overview §What’s a best practice? §Architecture §Security §Scalability and performance §Development practices §Is PHP dead? 2

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Best Practices 4

Slide 5

Slide 5 text

§Best is a strong word §YMMV §“Good practices” Best Prac*ces 5

Slide 6

Slide 6 text

Your PHP should •be simple •get the job done •be secure •be scalable and performant •be producible and maintainable Principles 6

Slide 7

Slide 7 text

Architecture 7

Slide 8

Slide 8 text

•First, do the simplest thing that could possibly work. Rule #1 8

Slide 9

Slide 9 text

Text Separation of concerns 9

Slide 10

Slide 10 text

2001 §Put reused templates in an include ﬁle §Avoid mixing php and html 10

Slide 11

Slide 11 text

2004 §Why are you still putting php in your html? 11

Slide 12

Slide 12 text

2008 §Why are you still putting php in your html? 12

Slide 13

Slide 13 text

2013 §I think we’re learning. §(At least, I hope so) 13

Slide 14

Slide 14 text

Frameworks 14

Slide 15

Slide 15 text

• 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 ﬁve years’ *me. Frameworks and Architectures: use and abuse 15

Slide 16

Slide 16 text

2001 §What's a framework? 16

Slide 17

Slide 17 text

2004 §All frameworks suck 17

Slide 18

Slide 18 text

2007 §They still suck, mostly §Framework shaming starting to decline 18

Slide 19

Slide 19 text

2013 §PHP 5.4 frameworks suck a lot less 19

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

More than the sum 21

Slide 22

Slide 22 text

Decomposition and decoupling #1 part of a good architecture 22

Slide 23

Slide 23 text

2001 §Functions §Include ﬁles 23

Slide 24

Slide 24 text

2004 §Objects 24

Slide 25

Slide 25 text

2007 §Reusable libraries §Services: everything’s an API 25

Slide 26

Slide 26 text

2013 §More libraries and components §More APIs §Better package/dependency injection tools 26

Slide 27

Slide 27 text

Robustness and Resilience 27

Slide 28

Slide 28 text

2001 §Write tests. 28

Slide 29

Slide 29 text

2004 §TDD §Use caching (disk, memcache) to hide service failures §Defensive coding 29

Slide 30

Slide 30 text

2007 §High Availability §Failover §Multimaster (sucks) 30

Slide 31

Slide 31 text

2013 §Minimize and isolate failure effects §Self-healing systems §Resilience: as much of it should work as possible §Feature ﬂagging: turn off parts of your app that are broken or under load 31

Slide 32

Slide 32 text

Security 32

Slide 33

Slide 33 text

• Consider illegitimate uses of your application • Educate yourself • If nothing else, ﬁlter all external data –(From the PHP Security Guide at http://phpsec.org/ projects/guide/) Basic principles 33

Slide 34

Slide 34 text

• 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 ﬁlter input and escape output • Filter input using whitelisting where possible • Escape output according to where it’s going. External Data 34

Slide 35

Slide 35 text

• 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 AGacks 35

Slide 36

Slide 36 text

What’s different? §register_globals and magic_quotes are dead. §Slides got less wordy. §Surprisingly little else. 36

Slide 37

Slide 37 text

Web app security 37

Slide 38

Slide 38 text

2001 §Use SSL §Don't store credit card numbers §Escape output naively (we didn’t know we were naive, honest) §addslashes()/stripslashes() 38

Slide 39

Slide 39 text

2004 §Filter input §Escape output. §Avoid XSS/injections §mysql_real_escape_string() 39

Slide 40

Slide 40 text

2008 §CSRF protection §Parameterized queries/prepared statements §ORM 40

Slide 41

Slide 41 text

2013 §Wider use of frameworks protects devs from mistakes §New developers learning the right way ﬁrst 41

Slide 42

Slide 42 text

Scalability & Performance 42

Slide 43

Slide 43 text

• 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 43

Slide 44

Slide 44 text

•Decouple. •Cache. •Federate. •Replicate. •Avoid straining hard-to-scale resources. •Dev environment needs replication too. Scalability Best Practices 44

Slide 45

Slide 45 text

•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

Slide 46

Slide 46 text

Principles 46

Slide 47

Slide 47 text

2001 §Don’t use CGI §Tune your queries 47

Slide 48

Slide 48 text

2004 §Cache everything §Query cache §Disk cache §memcached 48

Slide 49

Slide 49 text

2007 §Stand back, I’m going to use science §Measure, track, trend, proﬁle, optimize §Build cachable code §Decouple reads from writes (write there, read here) §Replicate, federate 49

Slide 50

Slide 50 text

2013 §Reﬁnement §Graph everything §Message queues to decouple writes §NoSQL/SQL: right data store for the job §DevOps 50

Slide 51

Slide 51 text

Coding Practices 51

Slide 52

Slide 52 text

•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

Slide 53

Slide 53 text

•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

Slide 54

Slide 54 text

•Have and use a coding standard •Zend Framework, PEAR, homebrew •Legacy code always a problem Coding standards 54

Slide 55

Slide 55 text

Code through the ages 55

Slide 56

Slide 56 text

2001 §Write comments. §Make code reusable. 56

Slide 57

Slide 57 text

2004 §Have a coding standard. §Use OO! 57

Slide 58

Slide 58 text

2008 §Make it look as much like Java as possible. §Namespaces §Iterators 58

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

Process 60

Slide 61

Slide 61 text

• 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

Slide 62

Slide 62 text

Process through the ages 62

Slide 63

Slide 63 text

2001 §Test code on your own machine §FTP to production 63

Slide 64

Slide 64 text

2004 §Staging server §Deploy with ‘svn up’! 64

Slide 65

Slide 65 text

2007 §Actual TDD §Instrumentable code! §Repeatable process §Agile §Death of estimation 65

Slide 66

Slide 66 text

2013 §Better tools for everything §Continuous integration and deployment §Test automation and monitoring converge §Commoditization of version control §MTTR vs MTBF 66

Slide 67

Slide 67 text

PHP is Dead?! 67

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

PHP is a toy language. You should use... §Perl §Cold Fusion §ASP 2001 69

Slide 70

Slide 70 text

PHP is no good for enterprise. You should use... §ASP.NET §JSP §J-everything 2004 70

Slide 71

Slide 71 text

PHP doesn’t have a single awesome framework. You should use... §Ruby on Rails 2007 71

Slide 72

Slide 72 text

2013 PHP is for losers. You should use... §Python §Ruby §Node §Scala §Clojure §Erlang 72

Slide 73

Slide 73 text

Slide 74

Slide 74 text

PHP coders... gonna code 74

Slide 75

Slide 75 text

Questions? Laura Thomson laura@mozilla.com @lxt 75