├── episodes ├── 001.md ├── 002.md ├── 004.md ├── 005.md ├── 017.md ├── 023.md ├── 027.md ├── 030.md ├── 033.md ├── 034.md ├── 035.md ├── 037.md ├── 038.md ├── 039.md ├── 040.md ├── 041.md ├── 042.md ├── 044.md ├── 046.md ├── 047.md ├── 048.md ├── 049.md ├── 050.md ├── 051.md ├── 053.md ├── 054.md ├── 055.md ├── 056.md ├── 057.md ├── 058.md ├── 059.md ├── 060.md ├── 061.md ├── 062.md ├── 064.md ├── 065.md ├── 066.md ├── 069.md ├── 073.md ├── 075.md ├── 84.md ├── 85.md └── 86.md └── readme.md /episodes/001.md: -------------------------------------------------------------------------------- 1 | * Everyone goes bonkers over PHP elephpants 2 | * Problems with PHP user groups in Chicago & advice from Cal 3 | * [WurstCon 2014](http://wurstcon.com/) is coming to Chicago! 4 | * Reminiscing about coding on old [Tandy computers](http://en.wikipedia.org/wiki/Tandy_Corporation) 5 | * How [Ruby](https://www.ruby-lang.org/) & [Ruby on Rails](http://rubyonrails.org/) influenced the PHP community 6 | * PHP has lead the pack with a [streams I/O layer](http://php.net/manual/en/intro.stream.php) 7 | * Some talk about [PHP stream filters](http://php.net/manual/en/filters.php) 8 | * [PHPNG](https://wiki.php.net/phpng) gets a mention 9 | * Stuff about [HHVM](http://hhvm.com/) 10 | * It has a [JIT](http://en.wikipedia.org/wiki/Just-in-time_compilation) 11 | * Should we implement it for our project? 12 | * It pushed PHP core team to get back in-gear 13 | * PHP new features and performance 14 | * [Elizabeth Smith](https://twitter.com/auroraeosrose) is awesome 15 | * [Contributing to PHP internals](http://www.phpinternalsbook.com/) ([the internals wiki](https://wiki.php.net/)) 16 | * PHP from the command line - why would we? We're lazy. 17 | * Testing in PHP 18 | * [Test-driven development](http://en.wikipedia.org/wiki/Test-driven_development) is neat but we confess that we don't always do it 19 | * Build an API-first with [apiary.io](http://apiary.io/) 20 | * Grumpy has some [great books on testing in PHP](https://leanpub.com/u/chartjes) 21 | * Various type of tests: unit, functional & integration; oh my! 22 | * Why Cal focuses so much on the community around PHP 23 | * Advice: be part of a local user group 24 | * Learn from the community & pay it forward 25 | * The PHP community is awesome and approachable 26 | * The business of PHP 27 | * Developers are not resources 28 | * The disconnect between managers and developers 29 | * Managing expectations in the context of a web project 30 | * Something old, something new, something borrowed, something deprecated 31 | * Old & Awesome: PHP streams are still awesome 32 | * New & Cool: [PHP variadics](http://php.net/manual/en/functions.arguments.php#functions.variable-arg-list) & [the splat operator](http://www.lornajane.net/posts/2014/php-5-6-and-the-splat-operator) 33 | * Borrowed: [PHP generators](http://php.net/manual/en/language.generators.overview.php) 34 | * Deprecated: [Globals need to be deprecated](http://php.net/manual/en/language.variables.scope.php#language.variables.scope.global) 35 | * [Michelangelo van Dam](https://twitter.com/DragonBe) is amazing -------------------------------------------------------------------------------- /episodes/002.md: -------------------------------------------------------------------------------- 1 | * Sammy's B.S. in Linguistics does not help him pronounce [Jeremy](https://twitter.com/jmikola)'s last name properly. 2 | * How to wrap our heads around functional programming: 3 | * "Functional programming is to imperative programming as a curve is to a derivative." 4 | * There is no such thing as a point on a curve, but there are approximations. 5 | * "State" doesn't exist in real life so we don't use it in functional programming 6 | * SammyK has amazing show notes. 7 | * What is state? 8 | * State is holding data around in memory 9 | * Mutable vs Immutable 10 | * Mutable: can be changed 11 | * Immutable: cannot be changed 12 | * Unix piping in the command line is an example of functional programming 13 | * Closures are [anonymous functions](http://php.net/manual/en/functions.anonymous.php) that can be assigned to a variable 14 | * Functional programming 15 | * Functional programming can be done with an imperative programming language like PHP, but there are native functional programming languages like [Haskell](https://wiki.haskell.org/Haskell). 16 | * State happens in a very small context 17 | "[Functional Programming in PHP](http://code.tutsplus.com/tutorials/functional-programming-in-php--net-35043)" by Patkos Csaba says there are three guidelines to functional programming in PHP: 1. **No assignments.**, 2. **No mutable state.**, and 3. **No `while` or `for` loops**. 18 | * Glen mentions [referential transparency](http://en.wikipedia.org/wiki/Referential_transparency_(computer_science)) and minds explode. 19 | * Persistent data sources get a "pass" in functional programming since they store state. 20 | * Immutable values 21 | * Immutable values make testing easier. 22 | * DateTime has an [immutable version](http://php.net/manual/en/class.datetimeimmutable.php). 23 | * [Primitives in PHP](http://php.net/manual/en/language.types.intro.php) are essentially value objects. 24 | * To change the state of an immutable object, create a new one. 25 | * Recursion 26 | * Recursion 27 | * [Recursion](http://en.wikipedia.org/wiki/Recursion_(computer_science)) is used instead of `while` or `for` loops in functional programming. 28 | * We take a PHP elePHPant break. 29 | * [Mojolicious](http://mojolicio.us/) has a [Failraptor](http://blog.kraih.com/post/43196557952/failraptor). 30 | * [ReactPHP](http://reactphp.org/) is an event-driven, non-blocking I/O library. 31 | * The name comes from the [reactor pattern](http://en.wikipedia.org/wiki/Reactor_pattern). 32 | * We compare ReactPHP to [Node.js](http://nodejs.org/). 33 | * [Non-blocking I/O](http://en.wikipedia.org/wiki/Asynchronous_I/O) vs [multi-threading](http://en.wikipedia.org/wiki/Multithreading_(computer_architecture)) 34 | Examples of using non-blocking I/O: q web server, a web scrapper & other apps that use other web protocols (not just * HTTP) like [Ratchet](http://socketo.me/). 35 | * PHP is a great language to run from the command line. 36 | * Some discussion on how single-threaded languages make use of an [event loop](http://en.wikipedia.org/wiki/Event_loop) to perform non-blocking I/O. 37 | * What we use ReactPHP for: 38 | * Jeremy uses it to communicate with child processes in the MongoDB PHP diver test suite. 39 | * Most common uses are web socket apps. 40 | * It's possible to use it for MySQL driver communications. 41 | * In PHP 5.6, the [PostgreSQL driver supports asynchronous connections and queries](http://php.net/manual/en/migration56.new-features.php#migration56.new-features.postgresql). 42 | * We talk about how ReactPHP can help us program functionally in PHP. 43 | * [Igor](https://github.com/igorw) has some great functionally programmed repos. 44 | * Something old, something new, something borrowed, something deprecated 45 | * Old & Awesome: PHP streams (again lol) 46 | * New & Cool: Anything off of [Nikita Popov's blog](https://nikic.github.io/). 47 | * Borrowed: PHP steals pretty much everything 48 | * Deprecated: [Pear](http://pear.php.net/) -------------------------------------------------------------------------------- /episodes/004.md: -------------------------------------------------------------------------------- 1 | All about web api's, it's a very broad term...Application Programming Interface...it covers a lot of things but today we are talking about web api's. We're going to be exploring terms like REST and JSON, what you need to do to consume an api from a php perspective, and from a client side perspective, and moving app domain logic into the client side, Single Page Applications (SPA) - tend to be very JavaScript intensive. 2 | 3 | * What is an [api](http://www.webopedia.com/TERM/A/API.html)? 4 | * Fundamentally, the way two pieces of software talk to each other. 5 | * [REST](https://en.wikipedia.org/wiki/Representational_state_transfer) Principles 6 | * At a high level, it's like a contract, it's a defined set of rules and language. 7 | * Breaking backwards compatability, but you're breaking the contract. 8 | * Why build an api? 9 | * Everything is connecting to something else, so if you build an app, you will need to connect to some other service. 10 | * api first design 11 | * as the world grows, connection is what it's all about now. 12 | * Some developers, don't realize that they're using an api due to the api being buried in a package. Like [AWS S3 Package](https://aws.amazon.com/sdk-for-php/). 13 | * Consuming an API vs designing an API 14 | * Creating an API allows for more flexibility, you can create a mobile version that consumes an api as well as a desktop or it allows another service to connect with your app. 15 | * Consuming an api differs from a database because it forces you to account for situations where the api may fail. Apis tend to have more exceptions than a DB layer like PDO, so you need to be more aware when programming. 16 | * What does a web api look like? 17 | * [HTTP Protocol](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol) 18 | * GET 19 | * POST 20 | * PUT/PATCH 21 | * DELETE 22 | * [Response Codes](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes) 23 | * Request and Response headers 24 | * The body of the headers 25 | * The HTTP Protocol verbs are intended for specific purposes and you need to understand them and use them accordingly 26 | * Using the proper response codes. 27 | * APIs are distributed systems, meaning latency comes into play 28 | * You have to design for failure big time 29 | * Design an api based on failure cases (they're the hard ones), success cases are the easy ones. 30 | * When working with apis, error handling is no exception. (buh dum tiss) 31 | * (Give it a REST @jmikola) 32 | * The podcast descends into punfest 33 | * 16:20 - 18:00 - general discussion about how apis work (getting data, updating a resource, delete) 34 | * 18:30 - 20:20 - Good discussion about what happens in an api request. Headers are sent, the api reads the headers and determines if it can respond, then proceeds, then it processes the request and returns the content...general browser users never see the headers of an API...but basically everything is determined by the headers. 35 | * 21:20 - 24:40 - Talking through a server request, one guy acts as server another as browser and basically talk through what they want to do from the perspective of the technology that they are representing. 36 | * 24:40 - 25:00 - Talking through an invalid response, props to knowing the server code for a 'too large request' code 37 | * 25:00 - 25:40 - Talking about what the [status codes](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes) 38 | * 200s - Success status 39 | * 300s - Deal with Redirecting 40 | * 400s - Deal with errors 41 | * 26:15 - 26:45 - Why is [JSON](https://en.wikipedia.org/wiki/JSON) better than [XML](https://en.wikipedia.org/wiki/XML)? 42 | * In php world, JSON is way easier to parse than XML 43 | * 26:45 - 27:30 - [URL vs URI](http://stackoverflow.com/questions/176264/what-is-the-difference-between-a-uri-a-url-and-a-urn)? What's the difference? 44 | * URI - Is more proper, stands for Uniform Resource Identifier, it's an ID, not necessarily a location 45 | * They're pretty much interchangeable 46 | * URL - Universal Resource Location 47 | * 27:30 - 32:00 - [REST](https://en.wikipedia.org/wiki/Representational_state_transfer) - What is it? Why is it important in API design? 48 | * Different types of APIs, [SOAP](https://en.wikipedia.org/wiki/SOAP) and REST are just two of the types. 49 | * Most APIs are not RESTFUL 50 | * 28:35 - [HATEOAS](https://en.wikipedia.org/wiki/HATEOAS) - Stands for Hypermedia As The Engine Of Application State 51 | * Think of it as a "Choose your own adventure" book 52 | * Github is an example of a HATEOAS API 53 | * 32:00 - REST and RESFTUL. HATEOAS is the extreme form of REST or as REST api people say "The correct form of REST" 54 | * 32:18 - RPC style of api 55 | * 33:00 - REST was designed to give you longevity with your api 56 | * REST gives more flexibility than RPC or SOAP 57 | * 33:41 - 35:00 - [RPC](https://en.wikipedia.org/wiki/Remote_procedure_call) stands for Remote Procedure Call 58 | * local functions that map one to one with remote functions in the api 59 | * REST is more resource oriented and RPC is more function or feature oriented 60 | * 35:00 - APIs are not limited to data, although that is how most of the web thinks of them. 61 | * 36:00 - SOAP requires a lot of information in the request that doesn't seem relevant to what you need to get, making it a bit of a pain to work with. 62 | * 37:30 - JSON tends to be preferred because it is faster than XML, usually because the payload is less to transfer. Additionally SOAP has a lot of payload in the headers. 63 | * JSON is great for the mobile concern of payload, which translates to data transfer. 64 | * 39:12 - [Roy Fielding](https://en.wikipedia.org/wiki/Roy_Fielding) - father of REST 65 | * Knee slapper by @jmikola - I gave up on SOAP API, it was a wash. 66 | * 40:00 - 41:00 - [Richardson Maturity Model](http://martinfowler.com/articles/richardsonMaturityModel.html) 67 | * First level is XML of HTTP...although now JSON is probably preferred. 68 | * Nouns, thinking of your api as a series of resources that are interconnected, that have relationships that can be interacted with one at a time, like named resources 69 | * Verbs, using the HTTP verbs correctly, GET, POST, PUT, DELETE...maybe Head. 70 | * Hypermedia controls. (Choose your own adventure book) 71 | * 42:19 - Matt Frost book on oAuth 72 | * 42:45 - 45:30 - discussion about how oAuth works. 73 | * 46:00 - [Basic Auth](https://en.wikipedia.org/wiki/Basic_access_authentication) 74 | * Avoid probably, transmits password in plain text. 75 | * 48:30ish - Talking about using a secret key and hashing the request so that the server can decrypt based on your key. 76 | * 53:20 - [RAML](http://raml.org/) - REST API MODELING LANGUAGE 77 | * Supposed to allow the ability to wireframe an API 78 | * Advantage is that you can sort of test an api without having to write code...or invest a lot of time to begin testing an api that would require you to be committed once you begin being able to test the api. 79 | * It's basically a spec 80 | * 56:40 - [SWAGGER](http://swagger.io/) - Another API modeling language 81 | * It's darn right impossible to change an api after it's been developed 82 | * Swagger seems to be more about documenting an api that you have already created, where RAML is more about being able to spec out and prototype an API 83 | * [Semver](http://semver.org/) - semantic versioning 84 | * 58:00 - using semver to version an api 85 | * Designing an api is about solving a business problem...if you're not solving a business problem with your api, you're doing it wrong. 86 | * This is where RAML can be beneficial, so that you don't spend a lot of time writing code, and can focus a bit on what you're api does and how it should work. 87 | * [Apigility](https://apigility.org/) 88 | * [Runscope](https://www.runscope.com/) 89 | * Proxy between you and an api, helps with debugging an api 90 | * Ways to test apis 91 | * [CURL](https://en.wikipedia.org/wiki/CURL) 92 | * HTTPClient 93 | * [Postman](https://www.getpostman.com/) - Chrome extension (Mac App coming soon) 94 | * [HTTPIE](https://github.com/jkbrzt/httpie) 95 | * [Guzzle](http://docs.guzzlephp.org/en/latest/) 96 | * HTTP old, but still awesome 97 | * new [HTTP RFCs](http://http2.github.io/) - new definitions of the spec for HTTP 98 | * 1:21 - End of show, after party begins, hilarity ensues 99 | 100 | 101 | 102 | 103 | -------------------------------------------------------------------------------- /episodes/005.md: -------------------------------------------------------------------------------- 1 | # Quick Description 2 | 3 | PHP Internals, trying to find out how the sausage is made. 4 | 5 | ### Guests: 6 | 7 | * Anthony Ferrara - Author of Password Hashing (added in PHP 5.5) 8 | * Sara Goleman - Huge contrubtor to PHP and HHVM 9 | * Elizabeth Smith - making bad php extensions work on Windows 10 | * Joe Watkins - author of PHP Threads 11 | 12 | ### Show Notes 13 | * 2:00 - Guest Introductions 14 | * 4:00 - Show Begins 15 | * 4:15 - Op code pops up alot in [PHP Internals](http://news.php.net/php.internals). Machine readable version of your script, it's what PHP actually steps through as it is executing your program. 16 | * 5:50 - [PECL](https://pecl.php.net/) - pronounced pickle - PHP Extension Community Library 17 | * 6:25 - [3v4l.org](https://3v4l.org/) - a site that allows you to run your code in a bunch of different versions at the same time. Also shows the op code for php and hhvm 18 | * 7:46 - [Leet speak](https://en.wikipedia.org/wiki/Leet) 19 | * 7:56 - [JIT - Just in time compiler](https://en.wikipedia.org/wiki/Just-in-time_compilation), a description follows but I can't really hear it. 20 | * 9:00 - [PHPPHP](https://github.com/ircmaxell/PHPPHP) - implementation of php written in php instead of C. Should be able to run your code by PHPPHP and get the same output as C 21 | * 10:00 - PHP with JIT is the same sort of thing, it's a separate program whose only job is to run your program. Your program is not running, JIT is running your program. JIT allows your program to run your php directly on the CPU. 22 | * 11:00 - There is discussion of included JIT in PHP, but no one seems to have a good stable one at the moment. 23 | * 12:00 - With [Zend engine](https://en.wikipedia.org/wiki/Zend_Engine), you can run extensions and configure them, with JIT it would be significantly harder to do that unless it was perfectly right. 24 | * 12:50 - [HHVM](http://hhvm.com/) allows you to do things you probably shouldn't be doing. 25 | * 13:20 - PHP is really good at running really bad code, really well. 26 | * 13:30 - Done is better than perfect. 27 | * 13:45 - PHP drinking game introduced by @jmikola 28 | * 14:38 - Userland, refers to people who write php 29 | * 15:30 - What are extensions? 30 | * Extensions are C code that ties into PHP itself. Can either add functionality, change the way the engine runs, or do other bad things that will be kept secret. 31 | * 16:10 - PHP is two things, the Zend engine, that parses the script, and the other side of that is the runtime library. Made up of all these extensions, without the extensions, php would be a really boring language. 32 | * 16:46 - 4,000 extensions ship with php 33 | * 16:55 - You can write your own extensions. 34 | * 17:50 - extensions probably not included in term "userland" 35 | * 18:00 - Talk about where php came from...basically to make writing something in C easier. 36 | * 19:00 - [PERL](https://www.perl.org/) was the only really established language. [Ruby](https://www.ruby-lang.org/en/) was there, but really young, 37 | * 20:30 - PHP - stands for Personal Home Page - first release of php was 1995 38 | * 22:15 - [PHP Museum](http://museum.php.net/) 39 | * 23:00 - Anything from php past that is still plaguing it? Parameter Order 40 | * 24:30 - Funny that php [PSR-2](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md) requires spaces, and the code that runs php (C) uses tabs. 41 | * 25:00 - [FIG - the PHP standards group](http://www.php-fig.org/), where the [PSR-X standards](http://www.php-fig.org/psr/) come from. 42 | * Solving simple problems that are going to be generically useful, is a lot more useful to thee public than trying to build a one-size-fits all solution. 43 | * Fig should build complexity by composing simplicity 44 | * 28:30 - The people behind PHP Internals don't even use PHP. This idea turns out to be false. 45 | * 30:30 - Userland is best used to describe the code that is used to compile php vs php that runs on the process 46 | * 31:00 - Should the people who write the C code that compiles php be concerned with things like PHP FIG? 47 | * 31:20 - Internals should enable php community, but should also listen to community if there is a consensus that arises from usage. 48 | * 33:00 - Talk about [GOTO](http://php.net/manual/en/control-structures.goto.php) being added to php, and some things that surrounded that action. 49 | * The argument basically being that, if it's there and you want to use it, you can, if not, then don't use it. 50 | * An example is made that GOTO solved great, sort of a discussion about the identity of PHP. PHP vs JAVA being a designed language and very academic in its approach. 51 | * 36:00 - premature optimization is the root of evil. 52 | * 37:00 - Why aren't arrays allowed to be a constant? Constants are done at compile time (technical jargon answer). PHP's numbering model is partly to blame. Constants are limited to (what we call) scalar values (null, true, false, integer, floats, string). String is technically not a scalar, but it's close enough that PHP sort of pretends it is one. In php 5.5, the ability to dereference an array entered. 53 | * Arrays are basically mutable structures from the very concept of them. 54 | * 40:00 - [Mutable vs Immutable](http://stackoverflow.com/questions/214714/mutable-vs-immutable-objects) - Basically, mutable means you can change the value when the script runs. Immutable, you can not. Constants are immutable, so making Arrays constants is a little weird. 55 | * 41:10 - Why are [Resources](http://php.net/manual/en/language.types.resource.php) skipped when talking about primitives? Resources are pointers behind a "dark magical curtain". PHP knows nothing about them. The only thing that does are things in that same extension. 56 | * An example of a resource is the File Pointer. Changing the File Pointer to objects would require everyone to rewrite parts of their program. 57 | * If you want to get rid of resources, why not get rid of arrays and replace them with objects? Objects do everything arrays do, plus a little bit. 58 | * 44:30 - An argument is made to figure out a good way to transition from resources to objects. 59 | * 45:10 - Discussion about how to help out with PHP ecosystem that doesn't require person to know C code. PHP.net, tests, and more do not require C 60 | * 47:00 - The code that runs PHP.net is very interesting to look at...some dates back to PHP 3. 61 | * 48:50 - qa.php.net - tools to help write tests for php.net (and other usecases) 62 | * gcov.php.net - code coverage for php.net 63 | * 50:00 - all tests for php are integration tests...no unit tests 64 | * 52:30 - PHP Future - A spec for PHP. A specification that defines everything for PHP. 65 | * 53:00 - PHP's strength is that it is not an academic approach, it is driven by people who need to solve problems and provide solutions. 66 | * Since there is no spec for php, the source code is the spec...which seems to work ok 67 | * 54:30 - [PHPNG](https://wiki.php.net/phpng) 68 | * 55:50 - A PHP spec is probably a good idea, but no one wants to be in that work. 69 | * 57:00 - [0x00 + 2 = 4 in PHP 5.3](https://bugs.php.net/bug.php?id=61095), is one of the "warts" that has been found by someone writing a spec for PHP...that sounds like it was paid for by facebook (sort of). This bug was fixed in 5.3.11 70 | * HHVM has north of 12,000 unit tests. 71 | * PHPT unit tests and unit tests at the C level. 72 | * 62:45 - [RFC process](https://wiki.php.net/rfc/howto) discussed pretty quickly. 73 | * Biggest threat to PHP in terms of what would be a concern that could derail the project? First answer was Apathy. If no one puts in interest, or no new blood joins the project. Eventually, there could be no one to carry the torch. 74 | * 64:00 - The barrier to entry into PHP is both a great thing and a bad thing. You can have complete beginners and very experienced engineers, that a both write PHP. 75 | * [Hacklang](http://hacklang.org/) is a great prooving ground for PHP...but could be considered a threat if it forks compatability with PHP. So you could have an instance where things only work on Hacklang, or only work in PHP. You know would be splitting the group. 76 | * That being said though, it has also helped show how some things could work in PHP and has helped get some RFC's done. 77 | * [WordPress](https://wordpress.org/) accounts for 40% of PHP installs. 78 | * 67:00 - Continued discussion about WordPress and how it's so widely used that it can dictact some of the direction of PHP 79 | * 70:00 - beginning of the show wrap up 80 | * If you want to help out with PHP, hop onto IRC in the PHP mentoring channel and YELL! 81 | * 75:00 - End of show basically. 82 | 83 | 84 | 85 | 86 | 87 | 88 | -------------------------------------------------------------------------------- /episodes/017.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | We discuss practical ways of dealing with legacy codebases and address the question of, "to rewrite or to refactor"? We also talk about how we should manage client expectations when working with a legacy codebase. And finally we discuss some general strategies for refactoring a codebase to good, clean, modern PHP. 3 | 4 | # Guests 5 | * [Paul Jones](https://twitter.com/pmjones) 6 | * [Hugo Hamon](https://twitter.com/hhamon) 7 | * [Franziska Hinkelmann](https://twitter.com/fhinkel) 8 | 9 | Hosted by 10 | * [Sammy Kaye Powers](https://twitter.com/SammyK) 11 | 12 | # Discussion - The panel talks about... 13 | 14 | ## What is legacy code? 15 | * Any code that doesn't have tests 16 | * Code you have inherited from someone else 17 | * Code you wrote yourself several years ago 18 | * In PHP Specifically: 19 | * Include-oriented/page-based (as opposed to object-oriented and front-controlled) 20 | * No separation of concerns 21 | * Everything sits in your webroot 22 | * Multiple rewrite/refactor attempts are obvious 23 | 24 | ## What is technical debt? 25 | * It is like taking out a loan - you cut some corners to get the feature now, but cutting those corners makes it harder to change things later 26 | * "The things that you didn't do that you should have done" 27 | * Technical debt results in duplication of code, or the same thing stored in more than one place 28 | * To fix one thing, you need to make a series of co-ordinated changes across the codebase 29 | 30 | ## What do we need to think about before modernising a legacy codebase? 31 | * Separation of concerns 32 | * Understand the business case for the application and determine some acceptance tests 33 | * High-level integration Tests - if you want to refactor, they'll help to ensure the correct functionality is maintained while changing the implementation details 34 | 35 | ## How do we deal with 'developer ego'? 36 | * Be suspicious of your own developer ego 37 | * Get a second opinion - consult with others 38 | * Look at your own code from one year ago 39 | * Get others to review your code 40 | * Use tools like [Code Climate](https://codeclimate.com/) or [Scrutinizer CI](https://scrutinizer-ci.com/) 41 | 42 | ## Are there any currently-used frameworks that we should consider 'legacy'? 43 | * Version 1 of most frameworks could be considered 'legacy' today, but for different reasons to those discussed so far: 44 | * Best-practices have changed and moved on 45 | * PHP itself has changed, particularly with respect to object-orientation 46 | * Early versions of [Zend](http://framework.zend.com/) and [Symnfony](https://symfony.com/) use singletons extensively 47 | 48 | ## How do we manage a client's expectations when dealing with legacy codebases? 49 | * It is a difficult thing to communicate 50 | * Don't make estimates without looking at the codebase - this is no different from working with any unknown codebase 51 | * In some cases, a client will know they have legacy code because they will be used to code changes taking a long time 52 | * Charge for a 'discovery' process 53 | 54 | ## What tools can we use to evaluate code/technical debt? 55 | * As already mentioned, [Code Climate](https://codeclimate.com/) or [Scrutinizer CI](https://scrutinizer-ci.com/) 56 | * [Sensiolabs Insight](https://insight.sensiolabs.com/) - symfony-oriented 57 | * [SonarQube](http://www.sonarqube.org/) - large setup process, but detailed metrics (including estimated time/cost to fix) 58 | * [phpcpd](https://github.com/sebastianbergmann/phpcpd) 59 | * [phploc](https://github.com/sebastianbergmann/phploc) 60 | 61 | ## Rewrite vs refactor? 62 | * Paul and Franziska agree: Always refactor, never rewrite. [Just ask Netscape](http://www.joelonsoftware.com/articles/fog0000000069.html) 63 | * Rewriting sounds like a good idea, but it will always take longer 64 | * It will be easier to keep evolving a product as you refactor than as you rewrite 65 | * Hugo's opinion on the rewrite is a bit more sympathetic - if you do rewrite: 66 | * Once you start the rewrite, don't touch the legacy codebase 67 | * Re-implement one feature at a time 68 | * Use some kind of 'switch' (mod_rewrite rules, a load balancer, etc) to run both systems in parallel 69 | * Dispatch some requests from the legacy system and some from the new codebase 70 | * As you rewrite and move more features over, dispatch more requests from the new codebase 71 | * This can be difficult if you need to share info like session variables 72 | 73 | ## How do the panel approach modernising a legacy codebase? 74 | Paul mentions [his book](https://leanpub.com/mlaphp). The first few steps in his process are: 75 | 1. Write integration/characterisation tests 76 | 2. Set up autoloading 77 | 3. Consolidate functions and classes so they use the autoloading 78 | 4. Remove globals 79 | 5. Move to using dependency injection 80 | 6. Write unit tests... 81 | 82 | He also brings up [Michael Feathers - Working Effectively with Legacy Code](http://www.amazon.co.uk/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052). 83 | 84 | There are tools that can help: 85 | * [XDebug](https://xdebug.org/) - useful for examining code + working out execution path 86 | * [ACK](http://beyondgrep.com/) - useful for finding all the occurrences of particular code/calls 87 | * [PHPStorm](https://www.jetbrains.com/phpstorm/) 88 | * [phpcpd](https://github.com/sebastianbergmann/phpcpd) 89 | 90 | ## Sammy Kaye wraps up with 91 | * Developer shout-out: Matthew Weier O’Phinney 92 | -------------------------------------------------------------------------------- /episodes/023.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | Inspired by a lively Open Spaces session at [php|tek 2015](http://tek.phparch.com/), we discuss how PHP's ecosystem could be threatened by a not-so-obvious [bus factor](https://en.wikipedia.org/wiki/Bus_factor) and what we can all do to keep things thriving. 3 | 4 | # Guests 5 | * [Samantha Quiñones](https://twitter.com/ieatkillerbees) 6 | * [Davey Shafik](https://twitter.com/dshafik) 7 | * [Chris Tankersley](https://twitter.com/dragonmantank) 8 | * [Michelangelo van Dam](https://twitter.com/DragonBe) 9 | 10 | Hosted by 11 | * [Sammy Kaye Powers](https://twitter.com/SammyK) 12 | 13 | # Discussion - The panel talks about... 14 | ## Intro 15 | * Definition of [the bus factor](https://en.wikipedia.org/wiki/Bus_factor) 16 | * Samantha discusses her talk at php|tek 2015 "Open Sourcing Teams", which provided the inspiration for this podcast topic. 17 | * The panel quickly decides that 'getting hit by a bus' is unnecessarily morbid. For the rest of the podcast, we can read 'getting hit by a bus' as 'retiring' or 'winning the lottery' :) 18 | * How do we measure/express bus factor - does a project with 2 crucial contributors have a bus factor of 2 or 0.5? The panel agrees on 2. A low bus factor is bad, a high bus factor is good. 19 | 20 | ## Which important PHP projects have a low bus factor? 21 | The panel discusses some popular PHP projects and their maintainers/contributors: 22 | * [Matthew Weier O'Phinney](https://mwop.net/) - [Zend](http://framework.zend.com/) 23 | * [Fabien Potencier](http://fabien.potencier.org/) - [Symfony](https://symfony.com/) 24 | * [Taylor Otwell](http://taylorotwell.com/) - [Laravel](https://laravel.com/) 25 | * [Jordi Boggiano](https://seld.be/), [Nils Aderman](http://naderman.de/) - [Composer](https://getcomposer.org/) 26 | * [Sebastian Bergmann](https://sebastian-bergmann.de/), [Stefan Priebsch](http://www.priebsch.de/), [Arne Blankerts](https://twitter.com/arneblankerts) - [PHPUnit](https://phpunit.de/) 27 | 28 | Do these maintainers represent a bus factor of one in the context of these projects? 29 | 30 | ## How does over-reliance on one individual impact developers using a framework/platform? 31 | * If we use these tools in (commercial) projects, there is risk associated with uncertain future of the project 32 | * Reliance on a single maintainer does not represent the only risk associated with building on top of open source frameworks/packages 33 | * One of the advantages of commercial software backed by large companies/organisations is greater stability in this respect 34 | 35 | ## How do we evaluate open source software for use in projects? 36 | * Quality of documentation 37 | * Size/strength of community - network effects 38 | * In a worst case scenario (e.g: the project is abandoned), could we maintain a fork? 39 | 40 | ## How can we identify projects with a low bus-factor? 41 | * This is a hard judgement to make 42 | * The majority of users/developers are not sufficiently involved in the PHP community to make this judgement 43 | * Sometimes projects fail/disappear/fall out of favour due to other reasons (osCommerce and Lithium are cited as examples) 44 | * High bus-factor does not guarantee stability 45 | 46 | ## How can we mitigate against this? 47 | * Projects with clean standards-compliant code will be easier for others to maintain 48 | * Projects where the reasoning/philosophy behind the project is well explained will be easier for others to maintain 49 | * One reason a project maintainer may be forced to step away is financial constraints. In the Ruby community, they attempt to mitigate this risk against core projects with [Ruby Together](https://rubytogether.org/) 50 | * Form/encourage community around projects and contribute to projects 51 | * [PHP Mentoring](https://phpmentoring.org/) 52 | * Companies that depend on open source projects should contribute to those projects - the cost to businesses of contributing now is far smaller than the cost of an important project that they depend on disappearing in future 53 | * Developers and businesses should support open source projects e.g: by buying licences for their premium/commercial services 54 | * Project maintainers should welcome help and contributions from others 55 | * Project maintainers should produce good quality documentation 56 | * Project maintainers should produce contributing guidelines 57 | 58 | ## Does PHP Internals have a low bus factor? 59 | * [PHP Internals](http://news.php.net/php.internals) has many maintainers and contributors, but some specific components have serious problems. For example: 60 | * [PDO](http://php.net/manual/en/book.pdo.php) does not have an active maintainer 61 | * [mcrypt](http://php.net/manual/en/book.mcrypt.php) does not have an active maintainer 62 | 63 | ## Sammy Kaye wraps up with 64 | * Developer shout-out: Derick Rethans 65 | -------------------------------------------------------------------------------- /episodes/027.md: -------------------------------------------------------------------------------- 1 | 2 | At Laracon 2015, panel of people talking. 3 | 4 | ### Guests 5 | * Jeremy Mikola - here because Taylor thinks he is funny. 6 | * Taylor Otwell - creator of Laravel 7 | * Jeffrey Way - creator of Laracasts 8 | 9 | Big thank you to Jeffrey for continuously sponsoring the "Developer Shout Out" on PHPRoundTable, gives PHPRoundTable the ability to give developers lots of money for being awesome! 10 | 11 | Technical difficulties begin happening almost immediately. And the show pretty much wraps...well at least the video version. The audio version is a bit longer and the rest of the notes are from there. 12 | 13 | Jeffrey talks about wearing Bunny Ears and giving out Halloween candy. 14 | 15 | The group discusses Matt Stauffer's talk about how Laravel is great for getting apps out fast. 16 | 17 | Jeremy hosted PHP Jeopardy where a scandal happened in the final round. 18 | 19 | The list of players for PHP Jeopardy was randomized, and a joke was made about using the updated [random functions in PHP7](http://php.net/csprng) that was contributed by PHPRoundTable's own Sammy Kaye Powers. However, that function was not used. 20 | 21 | Was there anything that stuck out in your mind about Laracon? 22 | 23 | Way: Taylor teasing [Spark](https://spark.laravel.com/), but Adam Wathan killed it! A talk on simple, clear code with tests backing it up. The talk was about refactoring. 24 | 25 | Otwell: The best thing I hear is when someone comes up to me and says "because of [Laravel](https://laravel.com/) I can work from home now and be with my kids". The personal stories I can relate to because I have been there. 26 | 27 | Mikola: I liked that there was a good mix between Laravel specific talks and other related things. Not only talks focused on Laravel. 28 | 29 | Otwell: Yeah we try to avoid all talks being about Laravel because otherwise it would be kind of boring. The developer world is so huge and we try to appealing, especially with a single track conference, we try to have something that everyone can take away. 30 | 31 | Powers: I was surprised that almost half the speakers hadn't used Laravel. 32 | 33 | Sammy asks the question to the crowd at the Hyatt 34 | 35 | Otwell talks about Spark and how he came about in building/releasing it. Basically, he saw that all the administration of a SaaS app was annoying and got in the way of releasing an app. So he decided to make a package to release that would allow people to quickly release apps. 36 | 37 | Spark is coupled to Cashier which is coupled to Stripe. 38 | 39 | General consensus is that Spark is awesome! 40 | 41 | The use of Traits in Spark looks great. The traits that are available are `CanJoinTeams`, `UseBillable`, `CanResetPassword`. Helps with Rapid Application Development. Spark has the ability to remove subscriptions. 42 | 43 | [Doctrine](http://www.doctrine-project.org/) was in beta for five years. 44 | 45 | 29:00 - The audio now begins to fail again. 46 | 47 | The rest of the show is the crowd discussing and asking some questions. 48 | -------------------------------------------------------------------------------- /episodes/030.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | 3 | SOA (Service Oriented Architecture) is an architecture that shifts our focus from one big monolithic web app to smaller connected web apps. We discuss what an SOA app looks like in the real world and how it affects our codebases, deployment & DevOps. 4 | 5 | # Guests 6 | * [Yitzchok Willroth](https://twitter.com/coderabbi) 7 | * [Sherif Ramadan](https://twitter.com/sr_googleguy) 8 | * [Samantha Geitz](https://twitter.com/SamanthaGeitz) 9 | 10 | Hosted by 11 | * [Sammy Kaye Powers](https://twitter.com/SammyK) 12 | 13 | # Discussion - The panel talks about... 14 | 15 | ## What is Service Oriented Architecture (SOA)? 16 | * In the PHP community, it is traditionally referred to as the Service Layer 17 | * Recently, the name has changed to Microservices; 18 | * Definition of SAO was introduced by Don Box from Microsoft when talking about [WCF](https://en.wikipedia.org/wiki/Windows_Communication_Foundation) (Indigo project) 19 | * 4 Characteristics of SOA: 20 | * Boundaries between components are explicit 21 | * Services are autonomous 22 | * Service share a schema and contract 23 | * Service compatibility based on policy 24 | * Microservices seems to maintain the first two, but violate the third because they are fully autonomous 25 | 26 | ## What constitutes as a Service? 27 | * A service can be stateless or stateful 28 | * Some examples of stateless services: 29 | * Image resizing 30 | * PDF creation 31 | * Stateful service 32 | 33 | ## Are services a web API or a daemon running in the backround? 34 | * Doesn't have to strictly be a JSON based API, but most traditional services are 35 | * Generally break down into 3 categories: 36 | * core services 37 | * composite services 38 | * API services 39 | * API services expose your system landscape to internal or external consumers 40 | * Core services are busy with persistence. This is where most of your business rules are going to live 41 | * Composite services either aggregate from core services or coordinate the work of various core services. 42 | 43 | 44 | ## If I use AWS for my website and use SQS to send image resizing tasks to another server, is that considered a service? 45 | * The image resizing would be considered a service and Amazon's message queue, SQS, would be considered infrastructure 46 | 47 | ## Is it true SOA was inspired by OO design principals? 48 | * Yes. If you read the gang of four book ([Design Patterns: Elements of Reusable Object-Oriented Software](https://en.wikipedia.org/wiki/Design_Patterns)), everything you learn about design patterns, in general, is pretty closely related to what you do in software architecture. SOA is just a component architectural style. 49 | * A lot of the gang of four book topics like SOLID and the single responsibility principal apply to SOA. For example, a microservice should be doing only one core business thing, etc. 50 | 51 | ## Samantha's recent talk at LaraconUS 52 | * Gave an example of a web app that used SOA. It was a website for a t-shirt company where a user could upload designs and then print the t-shirts on demand 53 | * First explained how to build the website as a monolith where you have users, admins, various products, customer service things, order processing things, etc. 54 | * Showed how easy it was for things to get out of control using the monolith model to build the site 55 | * Then when into how a developer would break it up; where you might have one API to handle users, another to handle orders and customer service, another to handle products, etc. 56 | * You can you the single responsibility principle because you can say a particular API only handles inventory and doesn't need to be concerned with users or a blog 57 | * Slides for talk are published [here](https://www.slideshare.net/SamanthaGeitz1/serviceoriented-architecture-62986976) 58 | * If something seems like it doesn't closely tie to anything else, it is a good candidate to turn into a service. Worker processes are good candidates too. These things can live as their own projects and don't need to live as part of the central codebase and can be run on their own server 59 | 60 | 61 | ## What are some pain points in a monolith that are an indication you need to use SOA? 62 | * One indication is that you have a big team and you are starting to get a lot of merge conflicts 63 | * Another indication is that you have a humongous amount of tests from a big app that takes forever to run 64 | * One more indication is that you are constantly scaling vertically 65 | * Unfortunately, with a monolith, it is easy to not realize that your app is too big until it is too late and you start to run into the issues above 66 | * It can be harder to break up a monolith than to keep some of the SOA design prinicples from the start 67 | * One barometer people use to determine when to break up their app is when the see that components in their system need to be able to scale independently 68 | * Going back to the first point, scaling the development team is important. When breaking up the code, think about having cross-functional teams with each one owning a code base. This can bring a team size down to the Jeff Bezos recommended two pizza size, which usually makes team communication better and more productive 69 | 70 | ## Is the AWS SQS image resize a good example of SOA, or are there some missing pieces? 71 | * It is a good first step, it is a great way to "put your toes into the water" 72 | * Doesn't solve all problems, but implementing some stateless services is a good first step 73 | * If you decide to completely break up your monolith app, first, pull out all the obvious services, 74 | 75 | ## How do you design web APIs for all your services in a way that won't make it horrible to work with? 76 | * You should always compare tradeoffs that you are making to get the architecture you want 77 | * You don't always need a API in front of every service. 78 | * If you clearly define the constraints around your services, it makes it easier for you make changes underneath. It also allows you to have an easier time build your message bus between your services. 79 | 80 | ## How to break up APIs by business logic? 81 | * Think about your database schemas 82 | * If something has a lot of FK constraints, for example orders and shipping or orders and customer service, you know that they are closely coupled and that there will be a lot of related database calls to get those resources. You might want to do it over an API, but you will start to run into latency issues. 83 | * The more you start thinking about database schemas and relationship nesting, it is a good way to start breaking things up 84 | 85 | ## How do you manage a shared set of code all your components would like to use? 86 | * When starting out, you can copy and paste code, but you will want to eventually use [Composer](https://getcomposer.org/) packages 87 | * Composer makes it pretty seamless to keep things synced between projects 88 | * Try not to have shared domain logic. If properly bounded, your services should not be sharing domain logic at all 89 | * Wen components share domain logic, you are no longer clearly defining the constraints between how the components interact with each other 90 | 91 | ## Are aggregates a nice place to start to look for boundaries when moving to an SOA architecture? 92 | * Bounded context are usually more appropriate 93 | 94 | ## How have you used SOA in the real world? 95 | * Samantha: At her employer [Packback](https://www.packback.co/), a digital textbook rental company, they have services to manage users, books, and search. They also have worker processes to gather prices and display books. They have somewhere between 12-15 services. Having experience in the monolith app world and the SOA world, it is so much easier to manage something that uses SOA than a monolith 96 | * Sherif: Recently been working on a remote execution / eval type site. It is kind of like an educational site similar to Codecademy. This site has many services that run unit tests, makes an AST to understand code better, etc. 97 | 98 | ## How are the codebases structured? Do you have a bunch of repos for all your services? 99 | * Yes, Yitzchok's company has over 100 repos and Samantha's company is getting close 100 | 101 | ## Isn't it more complicated to manage that many repos compared to one repo for a monolith? 102 | * Absolutely from an operations perspective 103 | * From an application engineer's perspective, you have reduced the complexity because you made what they have to deal with and think about much smaller 104 | * From an operations perspective, you have dozens to 100s of components that have to work in concert with each other. This leads to issues with deployment, configuration management, security, message tracking, monitoring, logging, service version compatibility and many other things 105 | * With the exception of breaking off the obvious stateless services like image resizing, PDF generation, price querying, etc., it is advised you use strong caution breaking things up, unless you have a strong Devops team 106 | * Some things that impact how difficult managing an SOA based app depends on size of infrastructure, codebase size, number of services, weather or not Agile practices are used, etc. 107 | * There are some 3rd party tools that can help you with the Devops complexities. In the Laravel world, there is [Forge](https://forge.laravel.com) and [Envoyer](https://envoyer.io/). There is also [Blackfire.io](https://blackfire.io/) and [Newrelic](https://newrelic.com/) that can help monitor stuff 108 | 109 | ## Do you ever get confused when pushing repos, or have related issues? 110 | * Try to go for a gated deployment 111 | * Depending on the size of your engineering department, you can build teams around specific services, which makes it easier in terms of deployment. If one team is only responsible for one or two services, then it is less likely that they will make a mistake pushing code 112 | * Sometimes a properly sized and organized team structure is under appreciated when building microservices 113 | * [Conway's law](https://en.wikipedia.org/wiki/Conway%27s_law) is pretty inescapable, so when engineers are grouped by function, for example front-end, server-side, and operations engineers, tend to do well at producing successful layer apps because they are working on a layer that they are comfortable in. But they won't do well when producing microsevices 114 | * Typically a successful microservices team is a cross-functional squad where one person of every type on the team so that you have enough people to work from end to end on a microservice 115 | * In your tests, just like you mock out calls to 3rd party services, you will do the same for the microservices your team uses 116 | 117 | ## It seams that SOA influences how teams are structured, right? 118 | * A small, cross-functional team per service is probably best 119 | * If you work for a small organization or start-up, you might only have 5 people in the engineering department, so you won't be able to build teams around individual services. Just because you don't have individual teams for individual projects doesn't mean you won't be successful with SOA 120 | * Be sure to document your services well 121 | 122 | ## What about SOA and the lone developer / freelancer? 123 | * A developer implementing a PDF generator service or something like that should be fine 124 | * Juggling 4-5 bounded contexts where you have lots of business logic living in separate places and trying to coordinate things is probably not best for a one man shop 125 | * If you still want to do SOA as a one man shop, you probably want to consider a 3 tiered architecture where you can have a PHP framework handling the frontend stuff. Then on the 2nd and 3rd tier, do something with SQS and talking to 3rd party services for stuff like video encoding, PDF generation, etc. This is still kind of SOA, and manageable by one person 126 | * If you are building simple blogs for someone, then SOA is probably not the way to go 127 | * Things like image processing for a stateless service is great for a solo developer because they are usually small, simple, and the code doesn't change often. They can be deploy and forget if well-constructed 128 | 129 | ## How do you handle authentication in a SOA? 130 | * If you are using Laravel / Lumen, you can use [this](https://github.com/lucadegasperi/oauth2-server-laravel) Oauth 2.0 server Composer package by Github user [lucadegasperi](https://github.com/lucadegasperi). Note: Oauth 2.0 support built into Laravel now using Passport. 131 | * It is pretty hard to do authentication well. It is pretty easy to authenticate someone, but you have to think about security. Some things to think about: 132 | * How are you going to do security on multiple tiers? 133 | * Do you want to do end-to-end encryption on the 2nd and 3rd tier? 134 | * Do you want to do authentication across different parts of your application? 135 | * Oauth 2.0 vs some other thing? 136 | 137 | ## CQRS vs SOA 138 | * [Command Query Responsibility Segregation](https://en.wikipedia.org/wiki/Command%E2%80%93query_separation#Command_query_responsibility_segregation) comes out of the domain driven design world 139 | * Are relatively orthogonal concerns in that you can do CQRS outside microservices architecture and also in complement. It is not a one or the other choice 140 | 141 | ## How do you manage environment variables across multiple servers? 142 | * One way to manage it is with Laravel Forge 143 | * If you are sharing environment variables horizontally (like if a service is load balanced), that is cool. But if you are sharing environment variables across different services, then it might smell a little, indicating that you might not have the right boundaries 144 | * Another option to manage environment variables is to use the combination of [HashiCorp's](https://www.hashicorp.com) products [Consul](https://www.consul.io), a service discovery tool, and [Vault](https://www.vaultproject.io) a key secrets management tool. Consul templates is used to publish `.env` files to each service. Vault is used to store the values in the `.env` files. The servers use the `.env` files to populate environment variables 145 | 146 | ## Any latency issues? 147 | * You can't escape physics, so there will always be some additional when implementing services (because it now has to make a network connection) 148 | * Don't get fixated on HTTP as your communication protocols. Obviously, for external users, you must use HTTP, but internally, you can consider other protocols 149 | * Consider [0MQ](http://zeromq.org/) or some other protocol 150 | * Latency is basically an optimization problem. There are probably other things in your app that you need to optimize first before latency becomes an issue. Probably lots of other low hanging fruit in terms of things to optimize. For example: 151 | * Caching 152 | * Getting rid of N+1 database queries 153 | 154 | ## Is there anything in PHP that makes SOA better or worse? Or does it matter what language you use? 155 | * In general, a language you use isn't the barrier to any architectural decisions made 156 | * In terms of PHP, with its primitive concurrency model, it is kind of helpful. Mostly requests hare handled with HTTP, it is stateless, everything starts from nothing on each request, etc. This kind of helps a person think about PHP in terms of API endpoints when experimenting with SOA 157 | * When you start to think about using other protocols besides HTTP for your internal components, then PHP could hinder you and you might want to look at other languages 158 | * For edge components, PHP is definitely a good choice 159 | 160 | ## Final thoughts 161 | * SOA can be intimidating. But it is not really hard to get into 162 | * Not a panacea and not a Pandora's box. Reach out to those who have done and are doing 163 | * Microservices envy is a thing and can be a dangerous thing 164 | * There is a marketing buzz around Microservices. Don't let it confuse you in making architectural choices. 165 | 166 | 167 | ## Sammy Kaye wraps up with 168 | * Contribute [show notes](https://github.com/PHPRoundtable/show-notes) 169 | * Nathan Morgan and Andrew Morgan challenged to start a podcast 170 | * Developer Shout-Out: [Steven Maguire](https://stevenmaguire.com/) 171 | * Shameless Plugs: 172 | * [Grovo](https://www.grovo.com/) 173 | * [Packback](https://www.packback.co/) 174 | -------------------------------------------------------------------------------- /episodes/034.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | A discussion about PHP debugging technology and techniques. 3 | 4 | # Guests 5 | * [Derick Rethans](https://twitter.com/derickr) 6 | * [Colin O'Dell](https://twitter.com/colinodell) 7 | * [Gary Hockin](https://twitter.com/GeeH) 8 | 9 | Hosted by 10 | * [Sammy Kaye Powers](https://twitter.com/SammyK) 11 | 12 | # Discussion - The panel talks about... 13 | 14 | ## Debugging Attitudes 15 | * Developers sometimes assume that their code was written properly 16 | * Instead, you should verify that your code works 17 | 18 | ## var_dump 19 | * [`var_dump()`](http://php.net/var_dump) is still a valid way of debugging 20 | * [Xdebug](https://xdebug.org/) and similar things can make `var_dump()` prettier 21 | * If you are using `var_dump()` to the point that you need to make it look pretty, you should us a step debugger 22 | 23 | ## Logging 24 | * Log interesting things, but don't go overboard 25 | * Include useful information, like IDs 26 | * Events should have the option for logging to be enabled 27 | 28 | ## Step Debugging 29 | * Xdebug helps for step debugging amongst other things 30 | * Step debugging allows you to pause a program at certain lines 31 | * They are very good for debugging someone else's code 32 | 33 | ## Future of Debugging 34 | * Debugging that allows you to view the history of a variable 35 | 36 | ## Sammy Kaye wraps up with 37 | * Contribute [show notes](https://github.com/PHPRoundtable/show-notes) 38 | * Developer Shout-out: Remi Collet 39 | * Shameless Plugs: 40 | * [PHP 7 Book](http://www.php7book.com/) 41 | * [PHP World - Debugging Effectively](http://www.slideshare.net/colinodell/debugging-effectively-phpworld-2015) 42 | -------------------------------------------------------------------------------- /episodes/035.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | [Immutability](https://en.wikipedia.org/wiki/Immutable_object) plays a huge role in functional programming and many languages support immutability directly; like the `readonly` [keyword in C#](https://msdn.microsoft.com/en-us/library/acdd6hb7.aspx). It is possible to create immutable objects in PHP, but the language lacks inherent immutable features for scalar variables and class properties. We discuss how to bring functional programming concepts to PHP and brainstorm some features that could possibly be added to future versions of PHP to offer better immutability support. 3 | 4 | # Guests 5 | * [Larry Garfield](https://twitter.com/Crell) 6 | * [Matthew Weier O’Phinney](https://twitter.com/mwop) 7 | * [Glen Hinkle](https://twitter.com/tempire) 8 | 9 | Hosted by 10 | * [Sammy Kaye Powers](https://twitter.com/SammyK) 11 | 12 | # Discussion - The panel talks about... 13 | ## Intro 14 | * [Immutability](https://en.wikipedia.org/wiki/Immutable_object) 15 | * [The readonly keyword in C#](https://msdn.microsoft.com/en-us/library/acdd6hb7.aspx) 16 | 17 | ## State 18 | * State is a representation of something that exists in the real world 19 | * State is not a bad thing, but we should think in terms of flow rather than in terms of state 20 | * Mutable state makes time a (hidden) input to everything - the order things happen in becomes important 21 | * Abstracting the notion of time means that order is not important and it is easier to reason about individual components of a system 22 | * Where possible, we do not want to consider time. Immutability can help us with this 23 | * "O-O languages deal with state by hiding it inside objects. Functional languages deal with state by implicitly defining it as part of a function call" 24 | 25 | ## An example demonstrating the problems with state - Zend framework test suite: 26 | * They used to run their whole test suite as one job 27 | * Some of those tests made changes to PHP's superglobals (e.g: `$_SESSION`) 28 | * This made the outcome of one test potentially depend on other tests 29 | * Now they run all of their tests in isolation 30 | 31 | ## Functional programming vs imperative programming 32 | * [Imperative languages](https://en.wikipedia.org/wiki/Imperative_programming) (inc. O-O) execute a sequence of statements in order, modifying state 33 | * [Functional programming](https://en.wikipedia.org/wiki/Functional_programming) defines relationships or transformations between inputs and outputs 34 | * An imperative language focusses on the values themselves, whereas a functional language focuses on the relationships between them 35 | * PHP is an imperative language, but we can apply some FP concepts. See [Functional programming in PHP](http://www.functionalphp.com/) and [Functional PHP](https://www.youtube.com/watch?v=M3_xnTK6-pA) 36 | 37 | ## Immutability in PSR-7 38 | * The specification says that any change to a message is a change to the value of the message 39 | * This means that any change to a message object should create a new value/object (as opposed to modifying the existing object) 40 | * This makes it a candidate for use of immutable objects 41 | * Introducing immutability into the implementation of PSR-7 removes a lot of problems (and a lot of code) 42 | 43 | ## Performance 44 | * Performance is sometimes cited as a reason not to use immutable variables 45 | * Because we can't directly change an immutable variable, we must frequently discard a variable and create a new instance 46 | * Benchmarks have shown that the performance hit is marginal 47 | * PHP is very efficient at cloning objects/variables 48 | 49 | ## Database objects/ORMs 50 | * We should separate read and write contexts 51 | * Data reading and data writing should be done with different object types 52 | * SQL already does this: 53 | * The result of a SELECT statement is immutable 54 | * An UPDATE or INSERT statement is an entirely different concept 55 | 56 | ## How could we implement immutable concepts in PHP? 57 | * We can never implement **true** immutability in PHP because reflection and closure binding allow us to break scope 58 | * Service objects should be completely immutable 59 | * For immutability to be useful, objects should not be 'locked' at construction time - we need the ability to easily create a new object based on an existing immutable object 60 | * Value objects should be implemented by replacing setter methods with a `with` statement, not providing objects that only have getter methods 61 | * PHP needs to decide what it wants to be: 62 | * Languages like Haskell or Clojure can do certain things because everything is immutable - PHP can never achieve this 63 | * Should PHP make architectural changes to support immutability, or accept that this is not the direction PHP should go in? 64 | * Is it better to build tools in user space that support immutability (and make changes to core that support them)? 65 | * Should PHP focus on embracing FP concepts in other ways (e.g: [array_map()](http://php.net/manual/en/function.array-map.php) for iterable objects)? 66 | * [readonly properties rfc](https://wiki.php.net/rfc/readonly_properties) 67 | 68 | ## Final thoughts - how can developers start using immutable and FP concepts in PHP now? 69 | * If you need to change something inside a function, ensure this is based on the input to that function 70 | * Try to eliminate temporary variables inside methods - this will force you into writing smaller methods and using less mutable variables 71 | * Never change the input variables to a function directly 72 | * Use message passing rather than state 73 | * Separate service objects and value objects 74 | 75 | ## Sammy Kaye wraps up with 76 | * Developer shout-out: Fabien Potencier 77 | -------------------------------------------------------------------------------- /episodes/037.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | Object-relational mapping (ORM) tools are a great way to model relational databases in your codebase. We discuss the benefits that ORM tools can add to our apps, some problems with the ORM model and where the PHP community seems to be heading when it comes to persisting data. We'll also discuss the opposing active record & data mapper paradigms. 3 | 4 | # Guests 5 | * [Ross Tuck](https://twitter.com/rosstuck) 6 | * [Shawn McCool](https://twitter.com/ShawnMcCool) 7 | * [Marco Pivetta](https://twitter.com/Ocramius) 8 | 9 | Hosted by 10 | * [Sammy Kaye Powers](https://twitter.com/SammyK) 11 | 12 | # Discussion - The panel talks about... 13 | 14 | A variety of stand-alone ORMs are available e.g: 15 | * [Propel](http://propelorm.org/) 16 | * [Doctrine](http://www.doctrine-project.org/projects/orm.html) 17 | * [Spot ORM](http://phpdatamapper.com/) 18 | 19 | Also a lot of frameworks ship with their own bespoke ORM. 20 | 21 | ## Why should someone who has never used an ORM use one? What's the 'elevator pitch'? 22 | * An ORM is a way to deal with relational databases in your O-O code 23 | * You can apply O-O principles to your data model and encapsulate your data logic 24 | * It represents a step up in complexity, but complexity is relative - a good abstraction removes underlying complexity and provides a simpler interface 25 | * Leave the "boring" parts to someone else 26 | * Cleaner code - codebases with a lot of raw SQL are "noisy" 27 | * ORMs separate our objects and the relationships between them from the details of persistence/how we store them. You can focus on the interface, not the data structure 28 | * An ORM lets you forget things: The design of your objects is your job and the process of saving/loading them to/from storage is the ORM's job 29 | * For some type of application, a DBAL like [PDO](http://php.net/manual/en/book.pdo.php) is sufficient or even more appropriate 30 | 31 | ## What do the panel think of the [Repository Pattern](http://martinfowler.com/eaaCatalog/repository.html) with ORMs? 32 | * [Shawn's article on the Repository Pattern](http://shawnmc.cool/the-repository-pattern) 33 | * Sometimes they are the right way to go and sometimes they aren't 34 | * Using the pattern is helpful when you want to construct objects and think about the persistence separately - it is useful to be able to 'hide' the ORM 35 | * Sometimes it is more useful not to abstract so much - it depends on the tradeoffs 36 | * Marco is currently working on an application which doesn't use an ORM at all 37 | * In small projects, the additional abstraction is often not worth it 38 | * It is also about personal preference/barriers to entry 39 | 40 | ## How do the panel approach mutability vs immutability with reference to ORMs 41 | * If mutable objects make things easier, they are fine 42 | * Immutability may be 'technically' superior, but it is often not 'practically' superior 43 | * O-O code generally uses mutable objects. An ORM should fit into its environment 44 | * Using [CQRS](http://martinfowler.com/bliki/CQRS.html) allows the use of different models/data structures for reading and writing (and hence immutable objects can be used for reading and mutable objects can be used for writing). 45 | 46 | The panel discuss their experiences with [Event Sourcing](http://martinfowler.com/eaaDev/EventSourcing.html) 47 | 48 | ## A comparison of how database access patterns scale 49 | * Direct Database Access: Simplest possible technology - basically zero barrier to entry, but complexity quickly rises with application scale 50 | * [ActiveRecord](https://en.wikipedia.org/wiki/Active_record_pattern): Slightly higher introduction cost, complexity still rises with scale, but at a lower rate 51 | * [DataMapper](https://en.wikipedia.org/wiki/Data_mapper_pattern): Setup complexity high, complexity scales just under linearly as application grows 52 | * [Event Sourcing](http://martinfowler.com/eaaDev/EventSourcing.html): Starting complexity is really high (but decreasing), but complexity is nearly constant 53 | 54 | However, this changes over time. 55 | 56 | ## ORMs and Graph DBs 57 | * Marco talks about [Orient DB ODM](http://www.doctrine-project.org/projects/orientdb-odm.html) - an ORM/(OGM?) for [OrientDB](http://orientdb.com/) 58 | * In some ways object-oriented code is closer to a graph DB model than a relational DB model: 59 | * Objects reference other objects with pointers, and this is also what is happening in a graph DB 60 | * In an SQL database, association between entities is defined by indexes, foreign keys, joins, pivot tables, etc not pointers 61 | * There is an entire episode on [Graph Databases](https://www.phproundtable.com/episode/using-graph-databases-in-php) 62 | 63 | ## What performance benefits do ORMs offer? 64 | * ORMs can provide caching in the case of repeated queries, but this is effectively by coincidence rather than design 65 | * An ORM is about abstraction not performance 66 | * Adding a layer of abstraction will usually **decrease** performance 67 | 68 | ## ActiveRecord vs DataMapper 69 | 70 | ### ActiveRecord: 71 | * A record class or object represents a row of data 72 | * It has user-defined methods based on what the object models 73 | * It also has methods implementing DB functionality (for example, it knows how to save itself) 74 | * ActiveRecord defines its own conventions and idioms 75 | * Models and database are tightly coupled 76 | 77 | ### DataMapper: 78 | * A record class or object only models what it represents in your application 79 | * It must be passed to a separate service object (repository) which deals with operations like saving 80 | * This provides separation of concerns 81 | * DataMapper allows more idiomatic use of the underlying language 82 | * Often sacrifices developer experience to gain architectural purity 83 | 84 | ### Comparison 85 | * [ActiveRecord](https://en.wikipedia.org/wiki/Active_record_pattern) is quick with low barriers to implementation, but suffers from some ambiguity between record logic and object logic 86 | * [DataMapper](https://en.wikipedia.org/wiki/Data_mapper_pattern) has a much higher barrier to entry, but provides a more robust abstraction 87 | * In the PHP community, ActiveRecord vs DataMapper often manifests itself as [Eloquent](https://laravel.com/docs/5.0/eloquent) vs [Doctrine](http://www.doctrine-project.org/) 88 | * It isn't as big an issue as some people turn it into 89 | * A lot of it is about personal preference or the right tool for the job 90 | 91 | ## Further Links 92 | * [Konstantin Kudryashov - Min-maxing Software Costs](https://www.youtube.com/watch?v=uQUxJObxTUs&index=12&list=PLMdXHJK-lGoA9SIsuFy0UWL8PZD1G3YFZ) 93 | 94 | ## Sammy Kaye wraps up with 95 | * Developer Shout-Out: Elliot Levin 96 | * Shameless Plugs 97 | -------------------------------------------------------------------------------- /episodes/038.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | New features of PHP get added via the [request for comments process](https://wiki.php.net/rfc). We are chatting with a few RFC authors about what features they are proposing for the next major version of PHP. 3 | 4 | # Guests 5 | * [Phil Sturgeon](https://twitter.com/philsturgeon) 6 | * [Scott Arciszewski](https://twitter.com/voodooKobra) 7 | * [Andrea Faulds](https://twitter.com/AndreaFaulds) 8 | * [François Laupretre](https://twitter.com/flaupretre) 9 | * [Davey Shafik](https://twitter.com/dshafik) 10 | 11 | Hosted by 12 | * [Sammy K Powers](https://twitter.com/SammyK) 13 | 14 | # Discussion 15 | ## Davey Shafik talks about 16 | * [HTTP 2 push requests support](https://wiki.php.net/rfc/curl_http2_push) 17 | * [HTTP 2 support in CLI server](https://wiki.php.net/rfc/cli_server_http2) 18 | * [Combined Comparison (Spaceship) Operator](https://wiki.php.net/rfc/combined-comparison-operator) 19 | 20 | ## Sammy K talks about 21 | * [Class Constant Visibility](https://wiki.php.net/rfc/class_const_visibility) 22 | 23 | Consensus is "how does this not already exist?" 24 | 25 | ## Phil Sturgeon talks about 26 | * We should steal the retry keyword from Ruby for use in try/catch blocks 27 | 28 | Debate about whether this is better or worse than using a goto ensues. 29 | 30 | ## Andrea Faulds talks about 31 | * [Void Return Types](https://wiki.php.net/rfc/void_return_type) 32 | 33 | Discussion about whether this is the same or different to just returning null. 34 | 35 | * [List Reference Assignment](https://wiki.php.net/rfc/list_reference_assignment) 36 | * [Named Parameters](https://wiki.php.net/rfc/named_params) 37 | 38 | ## François Laupretre talks about 39 | * PCS extensions 40 | * [Cache Key Operation](https://wiki.php.net/rfc/streams-is-cacheable) 41 | * Taking over the PHAR project 42 | 43 | ## Scott Arciszewski talks about 44 | * [Deprecating mcrypt](https://wiki.php.net/rfc/deprecate_mcrypt_rand) 45 | * "Boring" cryptography 46 | * [libsodium](https://github.com/jedisct1/libsodium) 47 | * Pluggable crypto library - "PDO for crypto" 48 | 49 | ## Sammy K wraps up with 50 | * [Deprecations for PHP 7.1](https://wiki.php.net/rfc/deprecations_php_7_1) 51 | 52 | Some discussion around poor approaches to cryptography and random number generation including deprecation/removal of [rand](http://php.net/manual/en/function.rand.php) and [srand](http://php.net/manual/en/function.srand.php) and potential pitfalls/issues with this. 53 | 54 | * [Code of Conduct](https://wiki.php.net/rfc/adopt-code-of-conduct) 55 | * Developer shout-out: Paul Dragoonis 56 | 57 | ## Further Links: 58 | * [PHP The Right Way](http://www.phptherightway.com/) 59 | * [PHP Sadness](http://phpsadness.com/) 60 | * [PHP Town Hall: Code of Conduct](https://phptownhall.com/episode-48-code-of-conduct/) 61 | -------------------------------------------------------------------------------- /episodes/039.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | We get an update on status of the project we discussed in [part 1](https://www.phproundtable.com/episode/part-1-turning-an-idea-into-code-for-production) and discuss next steps to take our dance event management app idea to production. 3 | 4 | # Guests 5 | * [Steven Maguire](https://twitter.com/StevenMaguire) 6 | * [Jocelyn Lopez](https://twitter.com/Joclpz) 7 | * Dan Yamamoto 8 | 9 | Hosted by 10 | * [Sammy Kaye Powers](https://twitter.com/SammyK) 11 | 12 | # Discussion - The panel talks about... 13 | ## Intro 14 | * What is [west coast swing](https://en.wikipedia.org/wiki/West_Coast_Swing)? 15 | * Recap of [part 1](https://www.phproundtable.com/episode/part-1-turning-an-idea-into-code-for-production) 16 | * [MVP with fake data](https://www.dancerdeck.com/) 17 | 18 | ## Tech Stack 19 | * [Laravel 5.2](https://laravel.com/) 20 | * [VueJS](http://vuejs.org/) 21 | * [Let's Encrypt](https://letsencrypt.org/) - check out Erika Heidi's articles at Digital Ocean: 22 | * https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-centos-7 23 | * https://www.digitalocean.com/community/tutorials/how-to-set-up-let-s-encrypt-certificates-for-multiple-apache-virtual-hosts-on-ubuntu-14-04 24 | * https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-14-04 25 | * [JSON web tokens](https://jwt.io/) 26 | * [ECMAScript 6](http://es6-features.org/) 27 | 28 | ## Problems Encountered 29 | * Time 30 | * Finding an ORM to work with graph database - [neo4j](http://neo4j.com/) 31 | * The ideal solution vs sticking with what you know 32 | * Building a single page load web app 33 | 34 | ## Where next? 35 | * Review of priorities: 36 | * Event curation: back end done, front end in progress 37 | * Event discovery: done 38 | * Calendar integration: not done 39 | * Participant accounts: back end done, front end in progress 40 | * Event subscription: not started - some discussion around how this should work/feature ideas: 41 | * GitHub terminology ("watch" and "star") vs Facebook terminology ("going" and "like") 42 | * Subscribe by event/subscribe by region 43 | * What events might a user be interested in subscribing to (e.g: venue/accommodation/schedule changes) - could these be handled using Laravel events? 44 | * Live push notifications (schedule events, "milestones") + opt-in or aggregation to avoid spamming users 45 | * Real data: not yet, but this is high priority 46 | * Invitations/partner management: not done 47 | * How do entities in the data model relate to each other - series/groups? Some discussion of polymorphic data model. 48 | * Should endpoints be context-aware? 49 | * What data would API users like to consume? 50 | * Event attendees - stats/badges, biographies 51 | * Event directors - what services are on offer that I could use? 52 | * What goes into the next iteration - long list: 53 | * Finish Event curation 54 | * Participant accounts 55 | * Event subscription/notifications 56 | * Partner management 57 | * Pro Schedule 58 | * Gamification/milestones 59 | * Event rating system 60 | * What goes into the next iteration - short list: 61 | * Finish Event curation 62 | * Participant accounts 63 | * Event subscription 64 | 65 | ## Sammy Kaye wraps up with 66 | * Developer shout-out: Ben Corlett 67 | 68 | ## Further Links: 69 | [Full-Stack Radio](http://www.fullstackradio.com/) 70 | -------------------------------------------------------------------------------- /episodes/040.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | Traditional relational databases like MySQL or Postgres are really good at providing many solutions to the problem of persisting state. But these types of database are really horrible at querying highly connected models in an efficient way. 3 | 4 | Graph databases like [Neo4j](http://neo4j.com/) and [OrientDB](http://orientdb.com/orientdb/) excel at highly connected data. In fact, graph technologies are the backbone of social networks like Facebook and Twitter. We discuss how to think about our data using the graph model and what tools we can use in our PHP projects to interface with them. We also discuss the considerations we'll need to make when deciding whether or not to use a graph database in our next project. 5 | 6 | # Guests 7 | * [Michelle Sanver](https://twitter.com/michellesanver) 8 | * [Ed Finkler](https://twitter.com/funkatron) 9 | * [Jeremy Kendall](https://twitter.com/JeremyKendall) 10 | * Chris White 11 | 12 | Hosted by 13 | * [Sammy Kaye Powers](https://twitter.com/SammyK) 14 | 15 | # Sammy Kaye Introduces 16 | * A classic problem in graph theory: [The Seven Bridges of Königsberg](https://en.wikipedia.org/wiki/Seven_Bridges_of_K%C3%B6nigsberg) 17 | 18 | # Discussion - The panel talks about... 19 | ## Query Languages 20 | Graph DBs don't usually use SQL. The most common query languages are: 21 | * [Cypher](https://en.wikipedia.org/wiki/Cypher_Query_Language) 22 | * [Gremlin](https://github.com/tinkerpop/gremlin) 23 | * [OrientDB](http://orientdb.com/) does allow the use of SQL among other query languages 24 | 25 | ## What are the key concepts of graph DBs and how do they differ from relational DBs? 26 | * Graph DBs are flexible 27 | * Graph DBs use 'nodes' and 'edges'. These can be thought of as 'entities'/'nouns' and 'relationships'/'verbs' 28 | * Graph DBs map more closely to how we might think or draw a diagram 29 | * It is easy to get started, but the complexity quickly ramps up 30 | * Graph DBs are new - there's less information out there. Relational DBs are well studied and well documented 31 | * Graph DB schema can be evolved much more easily than relational DBs 32 | 33 | ## When should I use graph DBs - what are the use cases? 34 | * Highly connected data: If your data model uses a lot of joins, graph DBs may be a good approach 35 | * If your data model uses a lot of one-to-one relationships, or 'get item by id' type queries, graph DBs are not a good fit 36 | * If you don't yet know what sort of queries you want to answer, graph DBs can offer flexibility later 37 | * If your queries are based more around relationships or verbs than objects or nouns, graph DBs may be a good approach 38 | * 'sparse' schemas lend themselves to graph DBs 39 | * There is some debate from the panel around whether graph DBs should work **alongside** relational DBs or **instead of** relational DBs 40 | 41 | ## How should we interact with graph databases? 42 | * Adapt existing ORMs to work with graph DBs like [NeoEloquent](https://github.com/Vinelab/NeoEloquent) 43 | * Throw out the ORM model and build specialised OGMs like [Neo4jrb](https://github.com/neo4jrb/neo4j) 44 | * Write query languages like Cypher/Gremlin/etc directly 45 | * Specialised tools like recommendation engines e.g: [neo4j-reco](https://github.com/graphaware/neo4j-reco) 46 | 47 | ## Other topics 48 | * Security - do we need to worry about 'cypher injection'? Most libraries have named parameters 'out of the box' 49 | * Graphical tools e.g: [neo4j browser](http://neo4j.com/developer/guide-data-visualization/#_screencast_the_neo4j_browser) 50 | * Graph DBs don't give nodes auto increment IDs - how do we identify nodes? 51 | * We can use uuids 52 | * With graph DBs, we are less likely to need IDs 53 | * Some graph DB engines discourage the use of IDs 54 | * Use 'natural' IDs where possible 55 | * Graph DBs can benefit from indexing and unique constraints in much the same way as relational DBs 56 | * Neo4j doesn't have triggers. OrientDB does 57 | * Neo4j is more of a 'pure' graph database. OrientDB combines NoSQL and graph approaches 58 | 59 | ## A Concrete example 60 | Sammy Kaye talks about a problem he is facing with his [DancerDeck](https://www.dancerdeck.com/) project, discussed in episodes [21](https://www.phproundtable.com/episode/part-1-turning-an-idea-into-code-for-production) and [39](https://www.phproundtable.com/episode/part-2-turning-an-idea-into-code-for-production): 61 | 62 | I want to be able to allow a user to subscribe (edge) to an event (node), but manage what sort of notifications are associated with that subscription. Should I use multiple edges between the user and node (an edge for each notification), or one edge (subscribe) with multiple properties (notifications) associated with that edge? 63 | 64 | The panel offer their opinions on both solutions and also propose another solution: represent each notification as a node (rather than en edge or an edge property) and create edges between the user and the notification nodes. 65 | 66 | Ultimately, it depends on how you want to query it. 67 | 68 | ## Sammy Kaye wraps up with 69 | * A return to [The Seven Bridges of Königsberg](https://en.wikipedia.org/wiki/Seven_Bridges_of_K%C3%B6nigsberg) problem 70 | * [PHP Roundtable on GitHub](https://github.com/PHPRoundtable/) 71 | * Developer shout-out: Adam Engebretson 72 | -------------------------------------------------------------------------------- /episodes/041.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | The [PHP-FIG](http://www.php-fig.org/) has really helped the PHP community get onboard the collaboration train with really great standards like the PSR-4 autoloading standard and the PSR-7 HTTP message interfaces. 3 | 4 | We discuss PSR-0 through PSR-13 and the process they go through to become standards. We also discuss where the FIG came from and the possible big changes coming to the organization soon. 5 | 6 | # Guests 7 | * [Cal Evans](https://twitter.com/CalEvans) 8 | * [Paul Jones](https://twitter.com/pmjones) 9 | * [Paul Dragoonis](https://twitter.com/dr4goonis) 10 | * [Chris Tankersley](https://twitter.com/dragonmantank) 11 | * [Evert Pot](https://twitter.com/evertp) 12 | * [Samantha Quiñones](https://twitter.com/ieatkillerbees) 13 | * [Michael Cullum](https://twitter.com/michaelcullumuk) 14 | * [Matthew Weier O’Phinney](https://twitter.com/mwop) 15 | 16 | Hosted by 17 | * [Sammy Kaye Powers](https://twitter.com/SammyK) 18 | 19 | # Discussion - The panel talks about... 20 | 21 | > **Show note merge conflict.** For this episode, both [Chris Shaw](https://github.com/chris48s) and [Ken Guest](https://twitter.com/kenguest) sent in a pull request with the show notes which created quite a merge conflict. :) But I'm very happy for your contributions! Thanks so much Chris and Ken! 22 | 23 | ### Intro 24 | * Misnomers - Phil Sturgeon didn't start the phpfig :lol: (David & Travis were the instigators according to Cal & Paul [53:28](https://youtu.be/tAHfoh641wM?t=3208)). 25 | * Puntastic fun. 26 | 27 | ### What was the PHP Community like before the FIG? 28 | * Poor communication and co-operation 29 | * Frameworks started to establish standards [3:09](https://www.youtube.com/watch?v=tAHfoh641wM&t=189) 30 | * Multiple competing standards/framework-specific standards 31 | * [PEAR](https://pear.php.net/) was the closest thing to a standards body [5:07](https://www.youtube.com/watch?v=tAHfoh641wM&t=307); [5:52](https://www.youtube.com/watch?v=tAHfoh641wM&t=352) and sound like they were used as the main foundation for the first few PSRs[6:15](https://www.youtube.com/watch?v=tAHfoh641wM&t=374). But the PEAR Standards didn't keep up with the changing landscape - autoloaders. Evert sounds like he misses PEAR as it was/is more than just a Coding Standard :( [7:04] (https://www.youtube.com/watch?v=tAHfoh641wM&t=424) 32 | * [PSR-0](http://www.php-fig.org/psr/psr-0/) represented the first step towards the [PHP-FIG](http://www.php-fig.org/), but it wasn't called PSR-0 at the time. It was just 'an autoloading standard' 33 | * Backlash from the general community. [8:27](https://www.youtube.com/watch?v=tAHfoh641wM&t=507) 34 | 35 | ### What is the role of a PHP-FIG secretary? 36 | * Admin tasks 37 | * Vote tracking 38 | * Co-ordination 39 | * Point of contact 40 | * Impartial - not representing a particular project 41 | 42 | ### What process does a PSR go through to become a standard? 43 | * See [PSR workflow](http://www.php-fig.org/bylaws/psr-workflow/) for full process. Core steps are: 44 | * Proposal 45 | * Entrance vote 46 | * PSR is assigned a number 47 | * Draft 48 | * Review 49 | * Final acceptance vote 50 | * Sometimes this takes a long time. [PSR-6](http://www.php-fig.org/psr/psr-6/) took over 4 years to become a standard 51 | 52 | ### Changes in the PHP-FIG's approach 53 | * The PHP-FIG is currently undergoing an identity crisis and drafting new by-laws 54 | * Historically, the FIG has strived to arrive at a 'perfect' standard and set it in stone 55 | * The group is moving towards a model where standards can evolve 56 | * One approach being considered is that a PSR must have 2 interoperable real-world implementations before standardisation 57 | * Standards can now be deprecated - this is a new status. [PSR-0](http://www.php-fig.org/psr/psr-0/) is now deprecated in favour of [PSR-4](http://www.php-fig.org/psr/psr-4/) 58 | * [PSR-12](https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md) will deprecate [PSR-2](http://www.php-fig.org/psr/psr-2/) 59 | * A new status 'abandoned' will also be introduced for standards which are no longer actively being drafted 60 | 61 | ### PSRs currently in draft 62 | * [PSR-5](https://github.com/phpDocumentor/fig-standards/tree/master/proposed) - PHPDoc Standard 63 | * [PSR-9](https://github.com/php-fig/fig-standards/blob/master/proposed/security-disclosure-publication.md) - Security disclosure and [PSR-10](https://github.com/php-fig/fig-standards/blob/master/proposed/security-reporting-process.md) - Security Advisories (related) 64 | * [PSR-8](https://github.com/php-fig/fig-standards/blob/master/proposed/psr-8-hug/psr-8-hug.md) - Huggable Interface (an April fools joke). 65 | * There is actual legitimate debate on whether this should be abandoned or implemented 66 | * Supporters of PSR-8 cite examples such as [IP over Avian Carrier](https://www.ietf.org/rfc/rfc1149.txt) and [HTTP Status code 418](https://httpstatuses.com/418) as grounds to ratify 67 | * [PSR-11](https://github.com/container-interop/fig-standards/blob/master/proposed/container.md) - Container Interface 68 | * [PSR-13](https://github.com/php-fig/fig-standards/blob/master/proposed/links.md) - Hypermedia Links 69 | 70 | ### Why are [PSR-1](http://www.php-fig.org/psr/psr-1/) and [PSR-2](http://www.php-fig.org/psr/psr-2/) different? 71 | * Paul M. Jones explains that PSRs 1 and 2 were once just the one document and split in two to make them more likely to be adopted. 72 | * Coding style is a controversial topic 73 | * Splitting into 2 standards was a way to successfully ratify it 74 | * PSR-1 deals with the most important/least controversial aspects of coding style 75 | * PSR-2 deals with aspects that are less important/more open to interpretation 76 | * The panel talks tabs vs spaces (yeah they went there!) 77 | * Sammy explaining tabs v Spaces to his dance partner [39:30](https://youtu.be/tAHfoh641wM?t=2375) 78 | * [PSR-12](https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md) will deprecate [PSR-2](http://www.php-fig.org/psr/psr-2/) updates PSR-2 to deal with new additions to the language in PHP7 e.g: [Return type hints](https://wiki.php.net/rfc/return_types) 79 | * PSR-1 will not be deprecated 80 | 81 | There is an [entire episode](/episode/psr-7-streams-immutability-middleware-oh-my) on PSR-7 82 | 83 | ### What is the role of PHP-FIG in the community 84 | * The panel discusses the role of the PHP-FIG - there are a variety of opinions, both complimentary and conflicting. 85 | * People want a Standards Body, says Samantha. [59:01](https://www.youtube.com/watch?v=tAHfoh641wM&t=3543) 86 | * Composer born out of the FIG Autoloading PSRs, according to Matthew [56:34](https://www.youtube.com/watch?v=tAHfoh641wM&t=3394) 87 | 88 | ### Where is the PHP-FIG going in future? 89 | * Not officially proposed yet! [1:03:53](https://youtu.be/tAHfoh641wM?t=3837) 90 | * [Member projects](http://www.php-fig.org/members/) vote on PSRs, but there are some problems: 91 | * It is difficult to achieve quorum 92 | * Not everyone is engaged 93 | * Not all of the members are engaged with/knowledgable about every topic 94 | * A new structure aims to solve some of these problems: 95 | * Working group structure: people who know/care about the topic become involved in the working group for that specific PSR 96 | * Core committee 97 | * Specifications are reviewed by the core committee 98 | * They don't handle the **content** of the PSR - just a final QA (e.g: ensure 2 working interoperable implementations) 99 | * The member projects include the community in the FIG and lend weight to the FIG, but they don't all have to have input on every PSR 100 | 101 | ### Mentions 102 | * [Brett Bieber](https://twitter.com/saltybeagle) 103 | * [David Coallier](https://twitter.com/davidcoallier) 104 | * [Helgi Þorbjörnsson](https://twitter.com/h) 105 | * [Larry Garfield](https://twitter.com/Crell) 106 | * [Mike van Riel](https://twitter.com/mvriel) 107 | * [Nate Abele](https://twitter.com/nateabele) 108 | * [Phil Sturgeon](https://twitter.com/philsturgeon) 109 | * [Stefan Koopmanschap](https://twitter.com/skoop) 110 | * [Travis Swicegood](https://twitter.com/tswicegood) 111 | 112 | ### The PSRs 113 | * [PSR-0: Autoloading Standard](http://www.php-fig.org/psr/psr-0/) 114 | * [PSR-1: Basic Coding Standard](http://www.php-fig.org/psr/psr-1/) 115 | * [PSR-2: Coding Style Guide](http://www.php-fig.org/psr/psr-2/) 116 | * [PSR-3: Logger Interface](http://www.php-fig.org/psr/psr-3/) 117 | * [PSR-4: Autoloader](http://www.php-fig.org/psr/psr-4/) 118 | * [PSR-5: PHPDoc Standard](https://github.com/php-fig/fig-standards/pull/169) 119 | * [PSR-6: Caching Interface](http://www.php-fig.org/psr/psr-6/) 120 | * [PSR-7: HTTP message interfaces](http://www.php-fig.org/psr/psr-7/) 121 | * [PSR-8: Mutually Assured Hug](https://github.com/php-fig/fig-standards/blob/master/proposed/psr-8-hug/psr-8-hug.md) 122 | * [PSR-9: Security Reporting Process](https://github.com/php-fig/fig-standards/blob/master/proposed/security-reporting-process.md) 123 | * [PSR-10: Security Disclosure Publication](https://github.com/php-fig/fig-standards/blob/master/proposed/security-disclosure-publication.md) 124 | * [PSR-11: Container Interface](https://github.com/container-interop/fig-standards/blob/master/proposed/container.md) 125 | * [PSR-12: Extended Coding Style Guide](https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md) 126 | * [PSR-13: Link Definition Interfaces](https://github.com/php-fig/fig-standards/blob/master/proposed/links.md) 127 | 128 | 129 | ## Sammy Kaye wraps up with 130 | * Developer shout-out: [Adam Culp](https://twitter.com/adamculp) 131 | 132 | ## Further Links and Shameless Plugs: 133 | * [Day Camp 4 Developers](https://daycamp4developers.com/) 134 | * [Docker for Developers](https://leanpub.com/dockerfordevs) 135 | * [Doctrine](http://www.doctrine-project.org/) 136 | * [Girls Who Code](http://girlswhocode.com) 137 | * [Laravel](https://laravel.com/) 138 | * [Modernising Legacy Applications in PHP](http://mlaphp.com/) 139 | * [PEAR](http://pear.php.net) 140 | * [phpBB](https://www.phpbb.com/) 141 | * [PHP South Coast](http://phpsouthcoast.co.uk) 142 | * [PPI Framework](http://www.ppi.io/) 143 | * [SabreDav](http://sabre.io/) 144 | * [Sculpin; a Static Site Generator](https://sculpin.io/) 145 | * [Stash](http://www.stashphp.com/) 146 | * [Symfony](http://symfony.com/) 147 | * [VueJS](http://vuejs.org/) 148 | * [Zend Framework](http://framework.zend.com/) 149 | -------------------------------------------------------------------------------- /episodes/042.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | The technologies that run the web are constantly changing. We discuss strategies for staying on top of the constant flux with continuous learning throughout your career, having mentors, engaging regularly with your peers, contributing to open source projects, voracious reading, and travel to programming events. 3 | 4 | # Guests 5 | * [Matthew Setter](https://twitter.com/settermjd) 6 | * [Andy Huggins](https://twitter.com/andy_huggins) 7 | * [Henning Glatter-Götz](https://twitter.com/hglattergotz) 8 | * [Tom Oram](https://twitter.com/tomphp) 9 | 10 | Hosted by 11 | * [Sammy Kaye Powers](https://twitter.com/SammyK) 12 | 13 | # Discussion - The panel talks about... 14 | 15 | ## An event that made you realise you weren't staying relevant? 16 | * Popular answer - Not doing unit testing - more than one person talks about the moment they realised they needed to start writing tests 17 | * Discovery that reading books about development (on Kindle) is a great way to stay up-to-date 18 | 19 | ## How does the panel stay up to date? 20 | * Books 21 | * Talking to other devs (user groups etc) 22 | * Podcasts - anyone know of a [good one](https://www.phproundtable.com/)? ;) 23 | * [Twitter](https://twitter.com/) delivers a lot of info very quickly, but has a high signal:noise ratio - [Nuzzel](http://nuzzel.com/) can help 24 | 25 | Sammy asked a bunch of programmers on twitter: What one book made you become a better programmer? Most common answer was [Clean Code](http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882). 26 | 27 | It can be easy to focus so much on doing things the "right" way or the most modern way to the point it becomes a distraction from the core problem solving. 28 | 29 | ## How does the panel avoid becoming "paralysed" into inaction as a result of this? 30 | * Think of code as creative writing - write a first draft, second draft, etc.. 31 | * With so many trends in software development, pick the most important to you and focus on them 32 | * "Mastery" is understanding what level of perfection the task requires 33 | * Another book recommendation: [On Writing Well](http://www.amazon.com/On-Writing-Well-Classic-Nonfiction/dp/0060891548) - a book about creative writing with lessons that are applicable to software 34 | 35 | The next book on Sammy's list is [Refactoring: Improving the Design of Existing Code](http://www.amazon.co.uk/Refactoring-Improving-Design-Existing-Technology/dp/0201485672) 36 | 37 | ## How do the panel approach refactoring? 38 | * Refactor as you go: 39 | * Make small feature branches 40 | * Every few features, do a small cleanup 41 | * Don't treat refactoring as a task in itself 42 | 43 | ## Tools come and go quickly. Techniques are timeless and move slowly. 44 | ### Some timeless techniques: 45 | * Unit(/automated) testing 46 | * Refactoring 47 | * Functional Testing 48 | * Design patterns 49 | * Algorithms 50 | 51 | ## How do the panel become better programmers? 52 | * Ask someone who has been doing it for a while - [PHP Mentoring](https://phpmentoring.org/) can help with that 53 | * Connect with the community - user groups, conferences, workshops, etc 54 | * Speak at a user group 55 | * You learn a lot from talking to/watching/working with other developers 56 | * Code reviews 57 | * Contributing to open source: 58 | * Follow the contributing guidelines 59 | * Get feedback on your code 60 | * Find a project you use yourself - find a bug that needs fixing or a feature that needs adding 61 | * The process associated with getting a PR accepted to a large project is an eye-opener 62 | * Think of submitting a patch as an opportunity to receive a free code review 63 | * Look for issues tagged 'easy' or 'beginner' 64 | * [up-4-grabs.net](http://up-for-grabs.net/#/) - projects 'advertising' easy issues for new contributors 65 | * [First Timers Only](https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.o04s2sjhq) 66 | * [Making your first pull request](http://www.charlotteis.co.uk/making-your-first-pull-request/) 67 | 68 | ## Other resources/links 69 | * [Clean coders video series](https://cleancoders.com/videos/clean-code) 70 | * If you can't get to a conference/user group in your area, check out [Nomad PHP](https://nomadphp.com/) 71 | * [Jeff Carouth's Development Book Club](https://carouth.com/blog/categories/book-club/) 72 | 73 | ## Sammy Kaye wraps up with 74 | * Developer Shout Out: Raquel Vélez [(@rockbot)](https://twitter.com/rockbot) 75 | * Shameless Plugs 76 | * [Lone Star PHP](http://lonestarphp.com/) 77 | -------------------------------------------------------------------------------- /episodes/044.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | Async? Isn't that like AJAX in Javascript or something? Most PHP developers encounter asynchronous code for the first time in Javascript, but not many are aware that PHP can do async too. We discuss asynchronous programming in PHP and how we might be able to implement it in our own projects using various libraries. We also take a look at how async features could be added to PHP core to support async natively. 3 | 4 | # Guests 5 | * [Christopher Pitt](https://twitter.com/assertchris) 6 | * [Sara Golemon](https://twitter.com/SaraMG) 7 | * [Aaron Piotrowski](https://twitter.com/trowski2002) 8 | 9 | Hosted by 10 | * [Sammy Kaye Powers](https://twitter.com/SammyK) 11 | 12 | # Discussion - The panel talks about... 13 | 14 | ## How does asynchronous programming differ from synchronous programming? 15 | ### In synchronous programming 16 | * We issue a statement, 17 | * We wait for it to complete 18 | * ..and then move on to the next statement. 19 | 20 | ### In asynchronous programming 21 | * We issue a statement 22 | * While we are waiting for it to complete, we can perform other tasks 23 | * When it has finished, we run a callback function 24 | 25 | This means we can reduce total execution time using an asynchronous methodology because we minimise the time spent waiting for operations to complete. 26 | 27 | The downside is that often callback depend on callbacks which depend on other callbacks 28 | 29 | ## How can we avoid deeply nested callbacks (Callback Hell)? 30 | * We don't have to use callbacks: 31 | * `async`/`await` in [Hack](http://hacklang.org/) and [C#](https://msdn.microsoft.com/en-us/library/hh191443.aspx) 32 | * [Threads in Java](https://docs.oracle.com/javase/tutorial/essential/concurrency/) 33 | * Use libraries like [cURL](http://php.net/manual/en/book.curl.php) or [Guzzle](http://docs.guzzlephp.org/en/latest/) to help 34 | * [Promises](http://12devs.co.uk/articles/promises-an-alternative-way-to-approach-asynchronous-javascript/) (or 'futures') can help 35 | * Promises don't avoid nesting callbacks - they just provide a nicer syntax to deal with them 36 | 37 | ## What is the difference between multi-threading and asynchronous programming? 38 | * Usually asynchronous code/languages will **use** threads 39 | * This is an implementation detail which is abstracted from the user 40 | * Usually in asynchronous code, all of the core application logic takes place in one thread 41 | * Other threads are usually 'lightweight' and are just waiting for some blocking/IO code to complete 42 | * In true multithreaded programming, core program logic will be executed in many threads 43 | 44 | ## Introducing Asynchronous concepts into PHP 45 | * This is unlike the 'traditional' implementation/libraries we are used to in PHP 46 | * We can use multi-threading in PHP using the [pthreads extension](http://php.net/manual/en/book.pthreads.php) 47 | * This requires [Zend Thread Safety](http://php.net/manual/en/pthreads.requirements.php) 48 | * Threads are not necessary for concurrent execution in PHP - [Process Control Extensions](http://php.net/manual/en/refs.fileprocess.process.php) use process forking 49 | * If we are to write PHP asynchronously, this rules out use of a lot of functions/libraries we like to use, because they block on IO 50 | * These problems are not unique to PHP 51 | 52 | ## Libraries for writing async PHP 53 | * [Icicle](https://github.com/icicleio/icicle) 54 | * [React PHP](http://reactphp.org/) 55 | * On a simple level, it is possible to write asynchronous PHP code by spawning additional processes using [exec](http://php.net/manual/en/function.exec.php) - you don't **need** a library 56 | 57 | ## A PSR for async in PHP 58 | * Find out more at https://github.com/async-interop 59 | * This is not a PSR yet, but these standards will be proposed to the [FIG](http://www.php-fig.org/) in future 60 | 61 | ## PHP 5.5 introduces [Generators](http://php.net/manual/en/language.generators.overview.php) and the `yield` keyword - do these help us to use asynchronous techniques in PHP? 62 | * [Icicle](https://github.com/icicleio/icicle) makes use of this heavily 63 | * This allows us to write asynchronous code that looks more like synchronous code 64 | * We may see an implementation of `async`/`await` in PHP in future, but not soon 65 | * This is similar to the path that [NodeJS](https://nodejs.org/en/) and [Python](https://www.python.org/) have followed or are following 66 | * This will require non-blocking versions of existing blocking functions like [file_get_contents()](http://php.net/manual/en/function.file-get-contents.php) to be written, but this process is underway 67 | 68 | ## Sammy Kaye wraps up with 69 | * Developer Shout-out: Stephen Coakley 70 | * Shameless Plugs 71 | -------------------------------------------------------------------------------- /episodes/046.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | 3 | If you've ever gotten a number of weird looking characters in your database or on your website like, "�" and didn't know why, then this episode is for you. Those bizarre characters called "mojibake", rear their ugly heads when we don't account for a consistent character encoding. Today we discuss what character encoding is, how to accommodate for it in HTML, PHP & your database, and how we can ensure we'll never encounter an unexpected alien character in our web apps again. 4 | 5 | 6 | # Guests 7 | * [Andreas Heigl](http://andreas.heigl.org/) 8 | * [Evert Pot](https://evertpot.com/) 9 | 10 | Hosted by 11 | * [Sammy Kaye Powers](https://twitter.com/SammyK) 12 | 13 | # Discussion - The panel talks about... 14 | 15 | ## What are character encodings? 16 | * Comparison of number systems (base-10, binary, hexadecimal) 17 | * Historical development of character maps and encodings (telegram, ASCII, ISO-8859-1...) 18 | * Unicode and its implementations (UTF-8, UTF-16, UTF-32) 19 | * UTF-8 uses 1-4 bytes per character--shows all Unicode characters while keeping a small file size 20 | * UTF-16 uses 2 bytes per character, so results in larger files 21 | * UTF-32 uses 4 bytes per character, so results in even larger files 22 | 23 | ## Character encodings in PHP 24 | * Some other languages have a UTF-8 core, while PHP stores strings a series of bytes--can result in misinterpretation/mojibake 25 | * Mind the [multibyte string functions](http://php.net/manual/en/ref.mbstring.php): 26 | * E.g., [`strpos()`](http://php.net/manual/en/function.strpos.php) works by counting a number of bytes; this is unreliable for UTF-8, so use [`mb_strpos()`](http://php.net/manual/en/function.mb-strpos.php) for unicode strings 27 | * There is a php.ini setting (named?) which overloads functions like `strpos` with their multibyte versions. This it NOT RECOMMENDED as it can cause weird bugs, whether when switching hosts or when using 3rd-party code that wasn't written with this in mind. 28 | * php7: the [IntlChar class](http://php.net/manual/en/class.intlchar.php) offers many useful static functions, e.g. [`IntlChar::chr()`](http://php.net/manual/en/intlchar.chr.php) and [`IntlChar::isWhitespace`](http://php.net/manual/en/intlchar.iswhitespace.php) 29 | * php7: [`\u` escape for unicode codepoints](http://php.net/manual/de/migration70.new-features.php#migration70.new-features.unicode-codepoint-escape-syntax) in strings 30 | 31 | ## Character encodings in HTML 32 | * HTML5: [``](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta#attr-charset) 33 | * [`Content-Type: text/html; charset=utf-8`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers) HTTP header 34 | * [`