Your SlideShare is downloading. ×
0
Bridging the Gap
Ben Corlett
Me
• Ben Corlett
• @ben_corlett
• Lead Developer at Cartalyst
Me
• Director of Webcomm
• Freelancer at Kapture
• Upcoming Tuts+ Premium Author
Australian
• I am not:
• Texan
• English
• Kiwi
Yes, I’ve Been Called All
Those Things.
Things I Make Myself
Part of
• Sentry (with Bruno Gaspar & Daniel Petrie of
Cartalyst).
• Laravel 4 (currently the biggest...
Things I Make Myself
Part of
• Cartalyst’s Platform 1 / 2
• Approximately 1 billion Cartalyst packages
• OAuth 1 Client (L...
Things I Make Myself
Part of
• PyroCMS
• FuelPHP (including various packages)
• There’s probably more…
Why Everybody Needs
PSR-2
I’m kidding!
Composer!
But first…
Pre-Composer
Pre-Composer
• You downloaded your framework of choice
• The framework did nearly everything - at
least it attempted to.
The Framework Always
Fell Short
The Framework Always
Fell Short
• You made it work, by finding:
• Modules
• Extensions
• Packages
• Bundles
• Let’s call t...
What Went Wrong?
What Went Wrong?
More frameworks appeared
What Went Wrong?
You switched frameworks
What Went Wrong?
• I switched frameworks:
• CodeIgniter ~1.4
• Kohana ~3.0
• FuelPHP - days of “Carbon” and the
awkwardly ...
What Went Wrong?
• Your new framework still didn’t do all the
things.
• You had a bunch of incompatible, near useless
add-...
Life Went On
Your favourite add-ons were forked
Sentry
Sentry
• Sentry 1.0 for FuelPHP 1.x
• https://github.com/cartalyst/sentry/tree/fuelphp/1
Sentry
• Sentry 2.0 for FuelPHP 1.x
• https://github.com/cartalyst/sentry/tree/fuelphp/2
Sentry
• Sentry 2.1 for FuelPHP 1.x
• https://github.com/cartalyst/sentry/tree/fu
elphp/2.1/develop
Sentry
• Sentry 1.0 for Laravel 3.x
• https://github.com/cartalyst/sentry/tree/v1.0.0
• Fork of Sentry 2.1 for FuelPHP
Sentry
• Sentry 1.1 for Laravel 3.x
• https://github.com/cartalyst/sentry/tree/1.1/maste
OAuth 2
OAuth 2
• Kohana OAuth 2
• https://github.com/managedit/kohana-oauth2
OAuth 2
• CodeIgniter OAuth 2
• https://github.com/philsturgeon/codeigniter-oauth2
OAuth 2
• FuelPHP OAuth 2
• https://github.com/fuel-packages/fuel-oauth2
OAuth 2
• Laravel OAuth 2
• https://github.com/taylorotwell/laravel-oauth2
OAuth 2
• Code diverged
• Bug fixes not global
• Bug fixed on Kohana didn’t fix CodeIgniter,
FuelPHP or Laravel.
• API cha...
Scenario
• You now work with Laravel
• Client asks for you to integrate with
Facebook on their legacy CodeIgniter site.
• ...
Scenario
• You now work with Laravel
• Client asks for you to integrate with Tumblr
on their legacy CodeIgniter site.
• Yo...
That’s Grim.
Composer!
• De-framework
• De-couple
• Unify code
Composer
• 5 flavours to 1
• https://github.com/cartalyst/sentry
• Any [or no] framework
• Deep integration with 4 major frameworks...
• 4 [known] flavours to 1
• https://github.com/php-loep/oauth2-client
• No deep integration with any framework
• It’s not ...
I’m Not Finished
You’re Doing It Wrong.
Well, some of you are.
Packagist Says
• There’s around 540 packages tagged “laravel”
• A good portion of them have
laravel/framework listed as a ...
Why?
Stop!
You’re not doing anybody favours.
Scenario
You’re a developer.
How DoYou
Implement a New
Feature InYour App?
3 Steps to Discovery
Step 1
Find and implement a package and use as-is.
Step 1
• Best-case scenario
• Reduce time and workload
• Increase productivity
Step 2
Package is missing required features
Step 2
• Send a pull request for missing features
• Help improve the package for others
• Give back to open source
Step 3
Package works
But it’s not easy to setup with your framework
Step 3
• Send a pull request with integration
• Service provider
• Driver
• Bridging package
Why Make Your Own?
There are actually reasons for starting fresh
Fundamentally disagree
with the API
Start a community discussion first (GitHub issue?)
Stability
Is the project too stable to accept the radical changes you
envision?
Stubborn
Are the developer(s) unwilling to consider your suggestion
for change?
It’s Okay to Re-Invent
the Wheel
Taylor Otwell did it.
Laravel
• Sits on a lot of Symfony
• Symfony is:
• Stable
• Powerful
• Complex
• Pure
Laravel
• Laravel simplifies a lot
• Convention over configuration
• Lower learning curve
• Elegant, intuitive API
Laravel
Would not be anywhere near as good without Symfony.
Reasons Against Making
Your Own
Reasons Against Making
Your Own
• Time consuming
• Can split community
• Responsibility & obligations
Make It Easier for Me
Tips for Package
Development
Forget Your Framework
Really.
ForgetYour Framework
• Develop outside of your framework
• TDD is a great way to develop
• Alternatively, native (naked) P...
ForgetYour Framework
• Many packages only use Laravel’s:
• Input
• Config
• Validator
Interfaces
Interfaces
• Class and method dependencies should be
interfaces.
• Allows for any implementation
Example 1
Cartalyst’s “Data Grid” package
Example 2
Sentry
Interfaces
• Built package framework-agnostic
• Then, integrate with framework through
drivers (implementations)
Service Providers
Service Providers
• Should be used to setup your package
• Reduce work load for consumers
• Inject config here
Facades
Facades
• Don’t need to be complex
• Phill covered in his talk
Example
Facades
• Should only be referenced from an app
level
Don’t Do That, Do This
Don’t
Do
Don’t Do That, Do This
• Never reference Facades in your package
• They’re specific to the standard Laravel 4
app.
• Injec...
Don’t
Do
Don’t Do That, Do This
• Don’t use dependencies for the sake of
using dependencies.
• Delegate request-specific code to ap...
Don’t
Do
Don’t Do That, Do This
• Validator isn’t always required for your
packages.
• Localise errors in your app
Package Design
Package Design
• Drivers
• Bridging packages
Drivers
• Multiple implementations
• Interface-driven (ties into SOLID)
• “Plug & Play”
• Lower learning curve
Drivers
• Expose to larger audience
• Examples:
• Laravel’s database package
• Sentry
Drivers
• Multiple implementations
• Interface-driven (ties into SOLID)
• Examples:
• Laravel’s database package
• Sentry
Bridging Packages
• Tie or glue a package to a framework
• Keep core light
Bridging Packages
• Examples:
• Symfony’s Twig bundle
• Laravel’s Mail package
Bridging Packages Are
Drivers
*Everybody gasps*
Bridging Packages Are
Drivers
• Same code, different package
• It’s impossible to include drivers for all
frameworks.
• Ke...
Why Bother?
Why Bother?
• Help the community
• Community helps you
• Interoperability, and hence;
• Productivity
Why Bother?
Why not?
It’s Easier to Be Lazy
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 t...
Two Packages Are
Slower
Two Packages Are
Slower
• No, they’re not
• Autoloading doesn’t care if there’s 1
package for each class, it’s relative to...
tl;dr
• Contribute to existing packages where
possible.
tl;dr
• Forget all frameworks when making a
package:
• De-couple packages
• Simplify code
• Speeds up a developer’s 3 step...
tl;dr
• Code to allow for easy integration:
• Integrate through drivers
• Integrate through bridging packages
• Strengthen...
tl;dr
• There’s a bunch of valid reasons for starting
fresh.
• Starting fresh is a per-case basis
Thanks!
• Ben Corlett
• @ben_corlett
• Cartalyst,Webcomm
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Bridging the Gap - Laracon 2013
Upcoming SlideShare
Loading in...5
×

Bridging the Gap - Laracon 2013

1,533

Published on

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

No Downloads
Views
Total Views
1,533
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
24
Comments
0
Likes
1
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!
  • Transcript of "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
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×