A modern approach to PHP development

Slide 1

Slide 1 text

A modern approach to PHP development Joel Clermont @jclermont Tuesday, August 13, 13 No bio slide. If you want to know more about me personally, we can discuss over a beer at Happy Hour tonight.

Slide 2

Slide 2 text

Platinum Sponsors Gold Sponsors Tuesday, August 13, 13

Slide 3

Slide 3 text

Goals Tuesday, August 13, 13 I only have one hour. In order to be effective, we need to establish some clear goals up front.

Slide 4

Slide 4 text

Goals • Expose you to some new ideas and tools Tuesday, August 13, 13 Not a dry “how to do X” technical discussion. There will be some “how”, but focus on the “why”

Slide 5

Slide 5 text

Goals • Expose you to some new ideas and tools • Show you how they solved problems for me Tuesday, August 13, 13 Odds are, you have faced (or are facing) some of the same problems. No solution is “one size ﬁts all” - so take the knowledge and apply it in your speciﬁc project, team and organization

Slide 6

Slide 6 text

Goals • Expose you to some new ideas and tools • Show you how they solved problems for me • Get you interested enough to try it out later Tuesday, August 13, 13 I believe that the topics we cover today can make you more efficient, produce higher quality code and make your development more FUN. To me, less frustration == more fun.

Slide 7

Slide 7 text

What do I mean by modern? Tuesday, August 13, 13 Simplest deﬁnition: something newer than what you are currently doing. (tool, library, technique, language feature, etc)

Slide 8

Slide 8 text

¬ (Newer 㱺 Better) Tuesday, August 13, 13 Translation: Newer isn’t always better. (I love Unicode characters) The Art of Computer Programming is a classic example. These books are decades old but still extremely valuable. Developers tend to like shiny things. We often jump on new tools and technologies But newer isn’t always better. Remember previous disclaimer: I found these newer techniques better in my experience. YMMV

Slide 9

Slide 9 text

Three talks for the price of one!! Tuesday, August 13, 13 Structure will be 3 topics under one central theme I will pause for questions at the end of each section, but don’t wait. Interrupt me at any time (clariﬁcation, disagreement, etc) Interaction makes the presentation more enjoyable for me and more valuable for you.

Slide 10

Slide 10 text

PROBLEM Wasting time setting up or maintaining a local dev environment Tuesday, August 13, 13 Option 1: NO local env. Edit and upload. Test on server (ouch) Option 2: OS X, use system apache/php/mysql (issues upgrading, conﬁguring) Option 3: packaged env like MAMP. Pretty good, but leads to a second problem . . .

Slide 11

Slide 11 text

PROBLEM “Works on my machine!” Tuesday, August 13, 13 Dev environment doesn’t match others on the team. Doesn’t match production Scenario: You’re running MAMP on OS X, everything works. Upload to production (Linux), getting 404 errors on some pages. Files exist. What happened?

Slide 12

Slide 12 text

Solution Tuesday, August 13, 13 January 2010 Solves the issue of time/effort to setup and maintain your local environment Eliminates inconsistencies between team environments AND production environment Best of all, it doesn’t require you to force people to give up their favorite OS or text editor/IDE

Slide 13

Slide 13 text

Uses virtual machines portable, isolated, project-speciﬁc Tuesday, August 13, 13 runs on any major OS doesn’t mess with stock libraries one project can be Nginx with 5.5, other can be Apache with 5.3

Slide 14

Slide 14 text

FREE Tuesday, August 13, 13 nominal cost if you want to use the VMWare infrastructure instead of VirtualBox all the tools I mention are free. Can’t beat the price.

Slide 15

Slide 15 text

DEMO Tuesday, August 13, 13 maybe this all sounds a little too good to be true demo with Drupal (many OSS projects are distributing Vagrant conﬁgs for easy setup/testing) ~/vagrant/drupal

Slide 16

Slide 16 text

Pick a “box” Tuesday, August 13, 13 Minimum conﬁguration is picking a base box: usually a ﬂavor of Linux Vagrant provides several common choices, Community provides many, many others You can even create your own

Slide 17

Slide 17 text

Side note: disk space Tuesday, August 13, 13 You might be wondering about how much space all these VMs are going to take? Vagrant stores one copy of each base box Project has its own copy Most Linux VMs are 200 - 400 MB, not a huge impact

Slide 18

Slide 18 text

vagrant init Tuesday, August 13, 13 this creates your Vagrantﬁle really a Ruby ﬁle - don’t despair if you don’t know Ruby check it into source control

Slide 19

Slide 19 text

vagrant up Tuesday, August 13, 13 boots the machine no GUI, saves on resources

Slide 20

Slide 20 text

vagrant ssh Tuesday, August 13, 13 kick the tires, get full access to the VM, just like any server

Slide 21

Slide 21 text

Oh no, do I have to use vim or emacs? Tuesday, August 13, 13 Remember, I said you didn’t have to give up your text editor or IDE of choice ssh is available, but there is a better way to edit ﬁles your project folder is sync’d into the VM at /vagrant anything you do in the host is sync’d to the VM if performance is an issue, NFS is an option (except on Windows)

Slide 22

Slide 22 text

vagrant suspend vagrant halt Tuesday, August 13, 13

Slide 23

Slide 23 text

vagrant destroy Tuesday, August 13, 13 Nothing is really lost when you do destroy. It will simply rebuild the box from your Vagrantﬁle Project code and data lives in your host OS

Slide 24

Slide 24 text

How do I configure my VM? Tuesday, August 13, 13 Remember, how I mentioned that your Vagrantfile is really a Ruby file? Vagrant has concept of provisioners: Chef / Puppet - learning curve Shell scripts: works, but can be a bit clunky and repetitive Ansible: declarative approach, but still has some learning curve

Slide 25

Slide 25 text

PuPHPet == awesome Tuesday, August 13, 13 awkwardly named, but incredibly useful under the hood, it uses Puppet, but you conﬁgure it with a web UI if you want to learn Puppet, studying the manifests from PuPHPet is a great way to start

Slide 26

Slide 26 text

References • Vagrant http://www.vagrantup.com • Drupal Vagrant box https://drupal.org/project/vagrant • Vagrant commands for the lazy and forgetful: http://codepoets.co.uk/ 2013/vagrant-commands-for-the-lazy-and-forgetful/ • PuPHPet https://puphpet.com Tuesday, August 13, 13

Slide 27

Slide 27 text

Questions? Tuesday, August 13, 13

Slide 28

Slide 28 text

PROBLEM Managing project dependencies is time-consuming and error prone Tuesday, August 13, 13 download a zip ﬁle? clone a git repo? PEAR PHAR ﬁles

Slide 29

Slide 29 text

PROBLEM Vendor code is mixed in with your code Tuesday, August 13, 13 .gitignore ﬁles work, maybe git submodules. requires discipline

Slide 30

Slide 30 text

Solution Tuesday, August 13, 13 Composer makes it easy to declare your dependencies per project AND to keep them up to date (this part can be the trickiest over time)

Slide 31

Slide 31 text

Dependencies, not packages Tuesday, August 13, 13 Easy mistake to make, I even made it in my talk abstract packages are system-level, composer is project-level by default (can be used to install global packages) conceptually very similar to Ruby’s bundler or Node’s npm

Slide 32

Slide 32 text

Easily specify a dependency level Tuesday, August 13, 13 what version of a library do you want? only master/production? dev ok? dev tools? it knows about your dependency’s dependencies (down the rabbit hole)

Slide 33

Slide 33 text

How paranoid are you? $ curl -s https://getcomposer.org/installer | php Tuesday, August 13, 13 The installation instructions take curl output and pipe it into your php executable YOLO i recommend installing it globally in your path no need to manage the composer code per project

Slide 34

Slide 34 text

composer.json { "minimum-‐stability": "dev", "require": { "silex/silex": "1.0.*", "doctrine/dbal": ">=2.2", "knplabs/console-‐service-‐provider": ">=1.0.0", "igorw/config-‐service-‐provider": "*.*.*" } } Tuesday, August 13, 13

Slide 35

Slide 35 text

composer install Tuesday, August 13, 13 looks at composer.json and installs dependencies puts everything in a /vendor folder (easy to exclude from your git repo) creates a composer.lock ﬁle (snapshot of what was just installed) commit composer.json and composer.lock to repo if composer.lock is present, .json ﬁle is ignored and snapshot in .lock is installed

Slide 36

Slide 36 text

Use your dependencies painlessly require 'vendor/autoload.php' Tuesday, August 13, 13 install also builds an autoload ﬁle for you one single point of entry to all your composer managed code

Slide 37

Slide 37 text

composer update Tuesday, August 13, 13 follows rules in composer.json, but updates as far as possible while following rules sidebar on semantic versioning

Slide 38

Slide 38 text

Tuesday, August 13, 13 the real power of composer no need to tell composer where to fetch each package 14,454 packages registered

Slide 39

Slide 39 text

Is Packagist the only way? Tuesday, August 13, 13 you can specify a git (or other VCS) repo in composer.json if the package isn’t composer aware, you can autoload it if it supports PSR-0 if package isn’t PSR-0, use a classmap there is always a way

Slide 40

Slide 40 text

composer create-‐project Tuesday, August 13, 13 Will do a demo later on Silex Basic way to install a framework, CMS, etc with one command

Slide 41

Slide 41 text

Bonus points: create your own packages Tuesday, August 13, 13 you can publish to Packagist host your own internal Packagist or lighter weight tool called Satis

Slide 42

Slide 42 text

References • Composer http://getcomposer.org • Packagist https://packagist.org • Satis https://github.com/composer/satis • Semantic versioning http://semver.org Tuesday, August 13, 13

Slide 43

Slide 43 text

Questions? Tuesday, August 13, 13

Slide 44

Slide 44 text

PROBLEM Ad-hoc project organization lacks structure Tuesday, August 13, 13 300 PHP ﬁles in your public web root I’m sure you’ve never done that

Slide 45

Slide 45 text

PROBLEM Lots of repeated or boilerplate code Tuesday, August 13, 13 content negotiation: should I send HTML or JSON back? setting cache directives introspecting the HTTP request

Slide 46

Slide 46 text

PROBLEM Automated testing is hard Tuesday, August 13, 13 500+ line functions lots of side effects extremely high cyclomatic complexity (fancy way of saying there are too many paths through your code)

Slide 47

Slide 47 text

Solution Tuesday, August 13, 13 MicroPHP Manifesto: January 2012 This could be an hour-long talk on its own, or even a full day workshop You aren’t going to learn how to use Silex, but why a micro framework is worth considering Silex is only one option: Slim is another great one. I’m sure there are others

Slide 48

Slide 48 text

Why a framework? Tuesday, August 13, 13 It can enforce some structure on your project and make it a lot easier to avoid the big ball of mud You can still write complex, untestable, disorganized code with a framework.

Slide 49

Slide 49 text

Why a micro framework? Tuesday, August 13, 13 Micro PHP manifesto Zend and Symfony (full stack) can be useful, but have steeper learning curve. Require higher team buy-in Micro-frameworks can ﬁt almost any type of project I’m a fan of SOA, many single-focused services coordinating together YMMV

Slide 50

Slide 50 text

DEMO Tuesday, August 13, 13 Common complaint: too hard to get started composer create-project fabpot/silex-skeleton silex-demo leverage both composer and vagrant

Slide 51

Slide 51 text

Simple routing Tuesday, August 13, 13

Slide 52

Slide 52 text

Logic before each request Tuesday, August 13, 13

Slide 53

Slide 53 text

Automated testing Tuesday, August 13, 13

Slide 54

Slide 54 text

References • Silex http://silex.sensiolabs.org • Pimple http://pimple.sensiolabs.org • Micro manifesto http://microphp.org Tuesday, August 13, 13

Slide 55

Slide 55 text

Questions? Tuesday, August 13, 13

Slide 56

Slide 56 text

Please TRY this on your own Tuesday, August 13, 13 There will be some learning curve but remember the goals: more efficient, higher quality code, have more fun while developing

Slide 57

Slide 57 text

August 11th – 13th 2014 Same Place, Same Time Tuesday, August 13, 13 Go tell all your fellow PHP devs about next year. I would like to see even more PHP topics and attendees next year. If you think of more questions, find me later or tweet me @jclermont. I’m here all three days