Bridging the GapBen 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 code contributor behind Taylor).

Things I Make Myself Part of

•Cartalyst’s Platform 1 / 2

•Approximately 1 billion Cartalyst packages

•OAuth 1 Client (League of Extraordinary Packages).

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 them all “add-ons”

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 named “ThrustPHP”

•Laravel ~3.1

•Laravel 4

What Went Wrong?

•Your new framework still didn’t do all the things.

•You had a bunch of incompatible, near useless add-ons.

Life Went OnYour favourite add-ons were forked

Sentry

Sentry

•Sentry 1.0 for FuelPHP 1.x

•https://github.com/cartalyst/sentry/tree/fuelphp/1.0/master

Sentry

•Sentry 2.0 for FuelPHP 1.x

•https://github.com/cartalyst/sentry/tree/fuelphp/2.0/master

Sentry

•Sentry 2.1 for FuelPHP 1.x

•https://github.com/cartalyst/sentry/tree/fuelphp/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/master

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 changes meant re-learning add-ons

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

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

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 and native PHP

Sentry

•4 [known] flavours to 1

•https://github.com/php-loep/oauth2-client

•No deep integration with any framework

• It’s not necessary!

OAuth 2

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

•Many others are dependent on Laravel, even though it’s not specified.

Why?

Stop!You’re not doing anybody favours.

ScenarioYou’re a developer.

How Do You Implement a New

Feature In Your App?

3 Steps to Discovery

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

Step 1

•Best-case scenario

•Reduce time and workload

• Increase productivity

Step 2Package 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 3Package 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

APIStart a community discussion first (GitHub

issue?)

StabilityIs the project too stable to accept the radical

changes you envision?

StubbornAre 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

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

Forget Your Framework

•Develop outside of your framework

•TDD is a great way to develop

•Alternatively, native (naked) PHP

Forget Your Framework

•Many packages only use Laravel’s:

• Input

•Config

•Validator

Interfaces

Interfaces

•Class and method dependencies should be interfaces.

•Allows for any implementation

Example 1Cartalyst’s “Data Grid” package

Example 2Sentry

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.

• Inject config values through a service provider.

Don’t

Do

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

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.

•Keeps package core light. Only download what you need.

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 the framework changes, it’s not

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 the filesystem.

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 steps of discovery.

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

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