Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

Jonathan Reinink Software developer from Canada. Been writing PHP for over 16 years. Marketing agency for over a decade. Started contract development this year. I <3 open source.

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

What is a package?

Slide 5

Slide 5 text

Packages are important because they provide code we don’t have to write.

Slide 6

Slide 6 text

Today there are 92,000 PHP package available on Packagist.

Slide 7

Slide 7 text

Packages are a BIG part of what makes a language successful.

Slide 8

Slide 8 text

Please consider contributing a PHP packages to the community, or even simply helping on an existing one.

Slide 9

Slide 9 text

Share your unique way of solving a problem.

Slide 10

Slide 10 text

I promise it will be of benefit to you.

Slide 11

Slide 11 text

Contributing to an open source package will push you as a developer. GIT GitHub Issues Pull Requests Rebasing Testing TDD Semantic Versioning Code Coverage Composer Packagist Coding Standards PHP-FIG PSR DocBlocks Travis Scrutinizer CI Changelogs Licensing Code Sniffer Jekyll Shields.io Code Quality Milestones Releases Dependency Injection Coupling Cohesion

Slide 12

Slide 12 text

Creating packages can be a little intimidating.

Slide 13

Slide 13 text

Introducing The PHP Package Checklist. phppackagechecklist.com

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

Designed for open sources packages, but applicable to any PHP package.

Slide 17

Slide 17 text

Pick a name wisely

Slide 18

Slide 18 text

Ensure that there is a unique identifier in your package name.

Slide 19

Slide 19 text

“Calling a spec for JSON API’s “JSONAPI” is just the worst. Searchability: zero.” — Frank de Jonge

Slide 20

Slide 20 text

Twig Guzzle Monolog Flysystem Swift Mailer Eloquent Blade Aura

Slide 21

Slide 21 text

Ensure the name isn't already used by another project.

Slide 22

Slide 22 text

Maintain consistency between this name and your PHP namespace.

Slide 23

Slide 23 text

// Good: namespace Glide; namespace League\Glide; // Bad: namespace Images; namespace ImageManipulations; namespace PHPGlide; namespace YoloImages;

Slide 24

Slide 24 text

Avoid using last names or personal handles in your PHP namespaces.

Slide 25

Slide 25 text

Host source openly

Slide 26

Slide 26 text

Hosting your code openly encourages: • Contributions • Downloads • Code Reviews • Bug Reports

Slide 27

Slide 27 text

Recommendation: GitHub

Slide 28

Slide 28 text

Even if you prefer Bitbucket, SourceForge, or Google Code, your end users most likely won’t.

Slide 29

Slide 29 text

GitHub shines as social coding platform.

Slide 30

Slide 30 text

GitHub has an insane number of integration options.

Slide 31

Slide 31 text

GitHub is free to use for public projects.

Slide 32

Slide 32 text

Alternatives: Bitbucket

Slide 33

Slide 33 text

Autoloader friendly

Slide 34

Slide 34 text

Use a PSR-4 compatible autoloader namespace.

Slide 35

Slide 35 text

Place code in the /src folder.

Slide 36

Slide 36 text

Distribute via Composer

Slide 37

Slide 37 text

$ composer require league/glide

Slide 38

Slide 38 text

{ "name": "league/glide", "require": { "intervention/image": "^2.1", "league/flysystem": "^1.0", "php": "^5.4 | ^7.0", "psr/http-message": "^1.0" }, "autoload": { "psr-4": { "League\\Glide\\": "src/" } } }

Slide 39

Slide 39 text

List on Packagist, the main Composer repository.

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

Official Website https://getcomposer.org/ Laracasts https://laracasts.com/series/laravel-5-fundamentals/episodes/1 Sitepoint http://www.sitepoint.com/php-dependency-management-with-composer/ Code Mentor https://www.codementor.io/php/tutorial/composer-install-php-dependency-manager

Slide 42

Slide 42 text

Framework agnostic

Slide 43

Slide 43 text

Don't limit your project to just one framework.

Slide 44

Slide 44 text

Offer framework specific support for your package using service providers.

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

Follow a coding style

Slide 47

Slide 47 text

Highly recommended that you adhere to the PSR-2 coding style guide.

Slide 48

Slide 48 text

A familiar coding style makes open source code easier to contribute to.

Slide 49

Slide 49 text

Do this quickly with an automated code fixer like PHP Coding Standards Fixer.

Slide 50

Slide 50 text

You can also use services like Nitpick or StyleCI to help you with this.

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

Write unit tests

Slide 53

Slide 53 text

Aim to cover the majority of your code.

Slide 54

Slide 54 text

PHPUnit is the de facto testing framework in PHP.

Slide 55

Slide 55 text

Alternatives: phpspec, Behat, atoum, Codeception.

Slide 56

Slide 56 text

DocBlock your code

Slide 57

Slide 57 text

/** * Set source file system. * @param Filesystem $source Source file system. */ public function setSource(Filesystem $source) { $this->source = $source; }

Slide 58

Slide 58 text

DocBlock serve as inline documentation.

Slide 59

Slide 59 text

They can also improve code completion in IDEs, like PhpStorm.

Slide 60

Slide 60 text

Can be automatically converted into API documentation, see phpDocumentor.

Slide 61

Slide 61 text

Use semantic versioning

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

Follow the pattern: MAJOR.MINOR.PATCH BREAKING.NEW-FEATURES.BUG-FIXES

Slide 64

Slide 64 text

Semantic versioning allows developers to upgrade code safely, without worrying about breaking changes.

Slide 65

Slide 65 text

semver.org

Slide 66

Slide 66 text

Remember to tag releases in a timely manner!

Slide 67

Slide 67 text

Keep a changelog

Slide 68

Slide 68 text

Show notable changes that have been made between releases.

Slide 69

Slide 69 text

Consider following the Keep a CHANGELOG format, see keepachangelog.com.

Slide 70

Slide 70 text

No content

Slide 71

Slide 71 text

{% for release in site.github.releases %} ## [{{ release.name }}]({{ release.html_url }}) - {{ release.published_at | date: "%Y-%m-%d" }} {{ release.body | markdownify }} {% endfor %}

Slide 72

Slide 72 text

Use continuous integration

Slide 73

Slide 73 text

Use a service to automatically check coding standards and run tests.

Slide 74

Slide 74 text

No content

Slide 75

Slide 75 text

No content

Slide 76

Slide 76 text

Write extensive documentation

Slide 77

Slide 77 text

“Tests are hard so we practice to get better. Docs are hard… so we don’t write any and complain.” — Steve Klabnik, Senior Technical Writer (maintainer of the official Rust documentation)

Slide 78

Slide 78 text

Don’t release an open source package unless your committed to writing good documentation.

Slide 79

Slide 79 text

The formula to awesome docs.

Slide 80

Slide 80 text

Consider hosting documentation on GitHub Pages.

Slide 81

Slide 81 text

Alternatives: Read the Docs.

Slide 82

Slide 82 text

Include a license

Slide 83

Slide 83 text

See choosealicense.com. Most PHP projects use the MIT License.

Slide 84

Slide 84 text

The MIT License Copyright (c) Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Slide 85

Slide 85 text

At a minimum, include a LICENSE file with your library.

Slide 86

Slide 86 text

Welcome contributions

Slide 87

Slide 87 text

Have a CONTRIBUTING file, welcoming contributions to the project.

Slide 88

Slide 88 text

No content

Slide 89

Slide 89 text

Thanks! Follow me on Twitter at @reinink. Please rate this talk at joind.in/talk/f499d.