Bridging the Gap - Laracon 2013

2,311 views

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,311
On SlideShare
0
From Embeds
0
Number of Embeds
53
Actions
Shares
0
Downloads
26
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • - Actually, currently 34 packages at Cartalyst. - PHP League currently has 10 packages. - Invite everybody to come join the PHP league - “If you have an idea or existing package which solves a common problem”
  • - Phil Sturgeon comes yelling to fix Sentry working with PyroCMS - Fuel-PDF (a great example of what would these days be a terrible package)
  • - Ask who started on CodeIgniter, FuelPHP, Zend, others?
  • - Ask for feedback!
  • - Ask for feedback!
  • Bridging the Gap - Laracon 2013

    1. 1. Bridging the Gap Ben Corlett
    2. 2. Me • Ben Corlett • @ben_corlett • Lead Developer at Cartalyst
    3. 3. Me • Director of Webcomm • Freelancer at Kapture • Upcoming Tuts+ Premium Author
    4. 4. Australian • I am not: • Texan • English • Kiwi
    5. 5. Yes, I’ve Been Called All Those Things.
    6. 6. Things I Make Myself Part of • Sentry (with Bruno Gaspar & Daniel Petrie of Cartalyst). • Laravel 4 (currently the biggest code contributor behind Taylor).
    7. 7. Things I Make Myself Part of • Cartalyst’s Platform 1 / 2 • Approximately 1 billion Cartalyst packages • OAuth 1 Client (League of Extraordinary Packages).
    8. 8. Things I Make Myself Part of • PyroCMS • FuelPHP (including various packages) • There’s probably more…
    9. 9. Why Everybody Needs PSR-2 I’m kidding!
    10. 10. Composer! But first…
    11. 11. Pre-Composer
    12. 12. Pre-Composer • You downloaded your framework of choice • The framework did nearly everything - at least it attempted to.
    13. 13. The Framework Always Fell Short
    14. 14. The Framework Always Fell Short • You made it work, by finding: • Modules • Extensions • Packages • Bundles • Let’s call them all “add-ons”
    15. 15. What Went Wrong?
    16. 16. What Went Wrong? More frameworks appeared
    17. 17. What Went Wrong? You switched frameworks
    18. 18. What Went Wrong? • I switched frameworks: • CodeIgniter ~1.4 • Kohana ~3.0 • FuelPHP - days of “Carbon” and the awkwardly named “ThrustPHP” • Laravel ~3.1 • Laravel 4
    19. 19. What Went Wrong? • Your new framework still didn’t do all the things. • You had a bunch of incompatible, near useless add-ons.
    20. 20. Life Went On Your favourite add-ons were forked
    21. 21. Sentry
    22. 22. Sentry • Sentry 1.0 for FuelPHP 1.x • https://github.com/cartalyst/sentry/tree/fuelphp/1
    23. 23. Sentry • Sentry 2.0 for FuelPHP 1.x • https://github.com/cartalyst/sentry/tree/fuelphp/2
    24. 24. Sentry • Sentry 2.1 for FuelPHP 1.x • https://github.com/cartalyst/sentry/tree/fu elphp/2.1/develop
    25. 25. Sentry • Sentry 1.0 for Laravel 3.x • https://github.com/cartalyst/sentry/tree/v1.0.0 • Fork of Sentry 2.1 for FuelPHP
    26. 26. Sentry • Sentry 1.1 for Laravel 3.x • https://github.com/cartalyst/sentry/tree/1.1/maste
    27. 27. OAuth 2
    28. 28. OAuth 2 • Kohana OAuth 2 • https://github.com/managedit/kohana-oauth2
    29. 29. OAuth 2 • CodeIgniter OAuth 2 • https://github.com/philsturgeon/codeigniter-oauth2
    30. 30. OAuth 2 • FuelPHP OAuth 2 • https://github.com/fuel-packages/fuel-oauth2
    31. 31. OAuth 2 • Laravel OAuth 2 • https://github.com/taylorotwell/laravel-oauth2
    32. 32. OAuth 2 • Code diverged • Bug fixes not global • Bug fixed on Kohana didn’t fix CodeIgniter, FuelPHP or Laravel. • API changes meant re-learning add-ons
    33. 33. Scenario • You now work with Laravel • Client asks for you to integrate with Facebook on their legacy CodeIgniter site. • You had to research CodeIgniter add-ons • The job took 3x as long as it should
    34. 34. Scenario • You now work with Laravel • Client asks for you to integrate with Tumblr on their legacy CodeIgniter site. • You can’t find any suitable add-ons • You resort to using PHP’s horrible cURL API • Even worse, file_get_contents(). • The job took 5x as long as it should
    35. 35. That’s Grim.
    36. 36. Composer!
    37. 37. • De-framework • De-couple • Unify code Composer
    38. 38. • 5 flavours to 1 • https://github.com/cartalyst/sentry • Any [or no] framework • Deep integration with 4 major frameworks and native PHP Sentry
    39. 39. • 4 [known] flavours to 1 • https://github.com/php-loep/oauth2-client • No deep integration with any framework • It’s not necessary! OAuth 2
    40. 40. I’m Not Finished
    41. 41. You’re Doing It Wrong. Well, some of you are.
    42. 42. Packagist Says • There’s around 540 packages tagged “laravel” • A good portion of them have laravel/framework listed as a dependency. • Many others are dependent on Laravel, even though it’s not specified.
    43. 43. Why?
    44. 44. Stop! You’re not doing anybody favours.
    45. 45. Scenario You’re a developer.
    46. 46. How DoYou Implement a New Feature InYour App?
    47. 47. 3 Steps to Discovery
    48. 48. Step 1 Find and implement a package and use as-is.
    49. 49. Step 1 • Best-case scenario • Reduce time and workload • Increase productivity
    50. 50. Step 2 Package is missing required features
    51. 51. Step 2 • Send a pull request for missing features • Help improve the package for others • Give back to open source
    52. 52. Step 3 Package works But it’s not easy to setup with your framework
    53. 53. Step 3 • Send a pull request with integration • Service provider • Driver • Bridging package
    54. 54. Why Make Your Own? There are actually reasons for starting fresh
    55. 55. Fundamentally disagree with the API Start a community discussion first (GitHub issue?)
    56. 56. Stability Is the project too stable to accept the radical changes you envision?
    57. 57. Stubborn Are the developer(s) unwilling to consider your suggestion for change?
    58. 58. It’s Okay to Re-Invent the Wheel Taylor Otwell did it.
    59. 59. Laravel • Sits on a lot of Symfony • Symfony is: • Stable • Powerful • Complex • Pure
    60. 60. Laravel • Laravel simplifies a lot • Convention over configuration • Lower learning curve • Elegant, intuitive API
    61. 61. Laravel Would not be anywhere near as good without Symfony.
    62. 62. Reasons Against Making Your Own
    63. 63. Reasons Against Making Your Own • Time consuming • Can split community • Responsibility & obligations
    64. 64. Make It Easier for Me
    65. 65. Tips for Package Development
    66. 66. Forget Your Framework Really.
    67. 67. ForgetYour Framework • Develop outside of your framework • TDD is a great way to develop • Alternatively, native (naked) PHP
    68. 68. ForgetYour Framework • Many packages only use Laravel’s: • Input • Config • Validator
    69. 69. Interfaces
    70. 70. Interfaces • Class and method dependencies should be interfaces. • Allows for any implementation
    71. 71. Example 1 Cartalyst’s “Data Grid” package
    72. 72. Example 2 Sentry
    73. 73. Interfaces • Built package framework-agnostic • Then, integrate with framework through drivers (implementations)
    74. 74. Service Providers
    75. 75. Service Providers • Should be used to setup your package • Reduce work load for consumers • Inject config here
    76. 76. Facades
    77. 77. Facades • Don’t need to be complex • Phill covered in his talk
    78. 78. Example
    79. 79. Facades • Should only be referenced from an app level
    80. 80. Don’t Do That, Do This
    81. 81. Don’t
    82. 82. Do
    83. 83. Don’t Do That, Do This • Never reference Facades in your package • They’re specific to the standard Laravel 4 app. • Inject config values through a service provider.
    84. 84. Don’t
    85. 85. Do
    86. 86. Don’t Do That, Do This • Don’t use dependencies for the sake of using dependencies. • Delegate request-specific code to app • Delegate all app-specific code to app
    87. 87. Don’t
    88. 88. Do
    89. 89. Don’t Do That, Do This • Validator isn’t always required for your packages. • Localise errors in your app
    90. 90. Package Design
    91. 91. Package Design • Drivers • Bridging packages
    92. 92. Drivers • Multiple implementations • Interface-driven (ties into SOLID) • “Plug & Play” • Lower learning curve
    93. 93. Drivers • Expose to larger audience • Examples: • Laravel’s database package • Sentry
    94. 94. Drivers • Multiple implementations • Interface-driven (ties into SOLID) • Examples: • Laravel’s database package • Sentry
    95. 95. Bridging Packages • Tie or glue a package to a framework • Keep core light
    96. 96. Bridging Packages • Examples: • Symfony’s Twig bundle • Laravel’s Mail package
    97. 97. Bridging Packages Are Drivers *Everybody gasps*
    98. 98. Bridging Packages Are Drivers • Same code, different package • It’s impossible to include drivers for all frameworks. • Keeps package core light. Only download what you need.
    99. 99. Why Bother?
    100. 100. Why Bother? • Help the community • Community helps you • Interoperability, and hence; • Productivity
    101. 101. Why Bother? Why not?
    102. 102. It’s Easier to Be Lazy
    103. 103. It’s Easier to Be Lazy • Not in the long run, it’s not • Not for everybody using another framework, it’s not. • Not when the framework changes, it’s not
    104. 104. Two Packages Are Slower
    105. 105. Two Packages Are Slower • No, they’re not • Autoloading doesn’t care if there’s 1 package for each class, it’s relative to the filesystem.
    106. 106. tl;dr • Contribute to existing packages where possible.
    107. 107. tl;dr • Forget all frameworks when making a package: • De-couple packages • Simplify code • Speeds up a developer’s 3 steps of discovery.
    108. 108. tl;dr • Code to allow for easy integration: • Integrate through drivers • Integrate through bridging packages • Strengthen community: • People working to make a package stronger helps everybody
    109. 109. tl;dr • There’s a bunch of valid reasons for starting fresh. • Starting fresh is a per-case basis
    110. 110. Thanks! • Ben Corlett • @ben_corlett • Cartalyst,Webcomm

    ×