1. Bridging the Gap
Ben Corlett

2. Me
• Ben Corlett
• @ben_corlett
• Lead Developer at Cartalyst

3. Me
• Director of Webcomm
• Freelancer at Kapture
• Upcoming Tuts+ Premium Author

4. Australian
• I am not:
• Texan
• English
• Kiwi

5. Yes, I’ve Been Called All
Those Things.

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. Things I Make Myself
Part of
• Cartalyst’s Platform 1 / 2
• Approximately 1 billion Cartalyst packages
• OAuth 1 Client (League of Extraordinary
Packages).

8. Things I Make Myself
Part of
• PyroCMS
• FuelPHP (including various packages)
• There’s probably more…

9. Why Everybody Needs
PSR-2
I’m kidding!

10. Composer!
But first…

11. Pre-Composer

12. Pre-Composer
• You downloaded your framework of choice
• The framework did nearly everything - at
least it attempted to.

13. The Framework Always
Fell Short

14. The Framework Always
Fell Short
• You made it work, by finding:
• Modules
• Extensions
• Packages
• Bundles
• Let’s call them all “add-ons”

15. What Went Wrong?

16. What Went Wrong?
More frameworks appeared

17. What Went Wrong?
You switched frameworks

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. What Went Wrong?
• Your new framework still didn’t do all the
things.
• You had a bunch of incompatible, near useless
add-ons.

20. Life Went On
Your favourite add-ons were forked

21. Sentry

22. Sentry
• Sentry 1.0 for FuelPHP 1.x
• https://github.com/cartalyst/sentry/tree/fuelphp/1

23. Sentry
• Sentry 2.0 for FuelPHP 1.x
• https://github.com/cartalyst/sentry/tree/fuelphp/2

24. Sentry
• Sentry 2.1 for FuelPHP 1.x
• https://github.com/cartalyst/sentry/tree/fu
elphp/2.1/develop

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. Sentry
• Sentry 1.1 for Laravel 3.x
• https://github.com/cartalyst/sentry/tree/1.1/maste

27. OAuth 2

28. OAuth 2
• Kohana OAuth 2
• https://github.com/managedit/kohana-oauth2

29. OAuth 2
• CodeIgniter OAuth 2
• https://github.com/philsturgeon/codeigniter-oauth2

30. OAuth 2
• FuelPHP OAuth 2
• https://github.com/fuel-packages/fuel-oauth2

31. OAuth 2
• Laravel OAuth 2
• https://github.com/taylorotwell/laravel-oauth2

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. 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. 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. That’s Grim.

36. Composer!

37. • De-framework
• De-couple
• Unify code
Composer

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. • 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. I’m Not Finished

41. You’re Doing It Wrong.
Well, some of you are.

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. Why?

44. Stop!
You’re not doing anybody favours.

45. Scenario
You’re a developer.

46. How DoYou
Implement a New
Feature InYour App?

47. 3 Steps to Discovery

48. Step 1
Find and implement a package and use as-is.

49. Step 1
• Best-case scenario
• Reduce time and workload
• Increase productivity

50. Step 2
Package is missing required features

51. Step 2
• Send a pull request for missing features
• Help improve the package for others
• Give back to open source

52. Step 3
Package works
But it’s not easy to setup with your framework

53. Step 3
• Send a pull request with integration
• Service provider
• Driver
• Bridging package

54. Why Make Your Own?
There are actually reasons for starting fresh

55. Fundamentally disagree
with the API
Start a community discussion first (GitHub issue?)

56. Stability
Is the project too stable to accept the radical changes you
envision?

57. Stubborn
Are the developer(s) unwilling to consider your suggestion
for change?

58. It’s Okay to Re-Invent
the Wheel
Taylor Otwell did it.

59. Laravel
• Sits on a lot of Symfony
• Symfony is:
• Stable
• Powerful
• Complex
• Pure

60. Laravel
• Laravel simplifies a lot
• Convention over configuration
• Lower learning curve
• Elegant, intuitive API

61. Laravel
Would not be anywhere near as good without Symfony.

62. Reasons Against Making
Your Own

63. Reasons Against Making
Your Own
• Time consuming
• Can split community
• Responsibility & obligations

64. Make It Easier for Me

66. Tips for Package
Development

67. Forget Your Framework
Really.

68. ForgetYour Framework
• Develop outside of your framework
• TDD is a great way to develop
• Alternatively, native (naked) PHP

69. ForgetYour Framework
• Many packages only use Laravel’s:
• Input
• Config
• Validator

70. Interfaces

71. Interfaces
• Class and method dependencies should be
interfaces.
• Allows for any implementation

72. Example 1
Cartalyst’s “Data Grid” package

76. Example 2
Sentry

84. Interfaces
• Built package framework-agnostic
• Then, integrate with framework through
drivers (implementations)

85. Service Providers

86. Service Providers
• Should be used to setup your package
• Reduce work load for consumers
• Inject config here

87. Facades

88. Facades
• Don’t need to be complex
• Phill covered in his talk

89. Example

92. Facades
• Should only be referenced from an app
level

93. Don’t Do That, Do This

94. Don’t

97. Do

100. 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.

101. Don’t

104. Do

108. 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

109. Don’t

111. Do

113. Don’t Do That, Do This
• Validator isn’t always required for your
packages.
• Localise errors in your app

114. Package Design

115. Package Design
• Drivers
• Bridging packages

116. Drivers
• Multiple implementations
• Interface-driven (ties into SOLID)
• “Plug & Play”
• Lower learning curve

117. Drivers
• Expose to larger audience
• Examples:
• Laravel’s database package
• Sentry

118. Drivers
• Multiple implementations
• Interface-driven (ties into SOLID)
• Examples:
• Laravel’s database package
• Sentry

119. Bridging Packages
• Tie or glue a package to a framework
• Keep core light

120. Bridging Packages
• Examples:
• Symfony’s Twig bundle
• Laravel’s Mail package

121. Bridging Packages Are
Drivers
*Everybody gasps*

122. 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.

123. Why Bother?

124. Why Bother?
• Help the community
• Community helps you
• Interoperability, and hence;
• Productivity

125. Why Bother?
Why not?

126. It’s Easier to Be Lazy

127. 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

128. Two Packages Are
Slower

129. 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.

130. tl;dr
• Contribute to existing packages where
possible.

131. tl;dr
• Forget all frameworks when making a
package:
• De-couple packages
• Simplify code
• Speeds up a developer’s 3 steps of
discovery.

132. 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

133. tl;dr
• There’s a bunch of valid reasons for starting
fresh.
• Starting fresh is a per-case basis

134. Thanks!
• Ben Corlett
• @ben_corlett
• Cartalyst,Webcomm