Have you found yourself wondering how to take advantage of what you have developed in the past for current or future projects? Are you tired of copying/pasting then adapting from your previous projects to the new ones? Start developing for the future and contribute to others by developing libraries and sharing them for use. Where do you start? You’ll be guided through this tutorial step by step to include security, tests and all the factors you need to consider when building a library.
4. Christian Varela
➤ I have a wife and 3 daughters
➤ I am from Mexico
➤ Master Degree in Computer Science
➤ 13 years programming with PHP
➤ I live in Miami
➤ I created Conqueror Soft Inc
➤ I play guitar and piano
4
6. Conqueror Soft will take your business to the next Level!
6
www.conquerorsoft.com
info@conquerorsoft.com
facebook.com/conquerorsoft
7. What is this session about?
Have you found yourself wondering how to take advantage of
what you have developed in the past for current or future
projects? Are you tired of copying/pasting then adapting from
your previous projects to the new ones? Start developing for
the future and contribute to others by developing libraries and
sharing them for use. Where do you start? You’ll be guided
through this tutorial step by step to include security, tests and
all the factors you need to consider when building a library.
7
8. Library / Package
A Software Library is a collection of methods, functions, classes,
etc, that provides a particular functionality to be used or reused
partially or in whole as part of a more complex system.
It is independent enough to be integrated as a functional block or
module along with other libraries to achieve a common goal.
It can be used by multiple systems that have no connections or
relations between them.
8
10. Why should I create libraries?
1. They provide reusability
2. They can help open source
3. They are modular in functionality context
4. They are easier to maintain
10
11. Web application
A web application is an application running in the web and
that provides a solution to a particular problem.
The application can have modules, programs, configuration
files, etc, all connected and related in a way that each piece
provides a specific purpose and that all together accomplish a
common goal.
11
12. Web application
1. Served by a server
2. Requested by a user (through a browser)
3. Can interact with DBs
4. Use third party libraries
5. Use private libraries
6. Has configuration files
12
19. Composer
1. Composer is a tool for dependency management in PHP. It
allows you to declare the libraries your project depends on
and it will manage (install/update) them for you.
2. Enables you to declare the libraries you depend on.
3. Finds out which versions of which packages can and need to
be installed, and installs them
19
20. composer.json
1. This is all you need to specify dependencies
2. This file is used when creating libraries and / or projects
3. "require" key specifies which packages your project needs
4. "repositories" key specifies where to find those packages
20
21. composer.json keys (most popular)
1. name
2. description
3. type
4. keywords
5. homepage
6. authors
7. support
8. require
9. require-dev
10.suggest
11.autoload
12.autoload-dev
13.repositories
14.scripts
21
25. packagist.org
Packagist is the main Composer repository. A Composer
repository is basically a package source: a place where you can
get packages from. Packagist aims to be the central repository
that everybody uses. This means that you can
automatically require any package that is available there, without
further specifying where Composer should look for the package.
25
27. packagist.com
Private Packagist is a commercial package hosting product
offering professional support and web based management of
private and public packages, and granular access permissions.
Private Packagist provides mirroring for packages' zip files which
makes installs faster and independent from third party systems -
e.g. you can deploy even if GitHub is down because your zip files
are mirrored.
27
29. Custom repositories
The following repository types are supported:
1. composer: A Composer repository is simply a packages.json file served via the
network (HTTP, FTP, SSH), that contains a list of composer.json objects with
additional dist and/or sourceinformation. The packages.json file is loaded using a
PHP stream. You can set extra options on that stream using the options parameter.
2. vcs: The version control system repository can fetch packages from git, svn, fossil
and hg repositories.
3. pear: With this you can import any pear repository into your Composer project.
4. package: If you depend on a project that does not have any support for composer
whatsoever you can define the package inline using a package repository. You
basically just inline the composer.json object.
29
30. Platform packages
1. Required system packages
2. Not installed by composer
3. Examples:
1. php
2. php extensions (ext-gd)
3. php libraries (lib-curl)
30
31. Autoloading
1. Uses "autoload" key and PRS-4
2. vendor/autoload.php is generated by Composer
3. autoload.php is regenerated with composer dump-autoload
31
32. PSR-4
1. PHP Standard Recommendation 4
2. describes a specification for autoloading classes from file
paths. It is fully interoperable, and can be used in addition to
any other autoloading specification, including PSR-0. This
PSR also describes where to place files that will be autoloaded
according to the specification.
32
34. Versioning (when developing)
1. They can be handled manually in composer.json
2. They can be handled using a Version Control System (VCS,
this is recommended)
1. By using branches
2. By using tags (this is recommended)
3. Use a consistent versioning standard, like SemVer.org (this is
recommended)
34
35. Versioning (when installing dependencies)
1. Use constraints
1. Exact version (1.2.3)
2. Version range (>=2.0 <3.0)
3. with hyphen (1.1.0 - 1.2.0, equals to >=1.1.0 <= 1.2.0)
4. with wildcard (1.1.*, equals to >=1.1 <1.2)
5. with tilde (~1.3.1, equals to >=1.3.1 <1.4.0)
6. with caret (^0.3, equals to >=0.3 <0.4.0)
35
36. SemVer
Given a version number MAJOR.MINOR.PATCH, increment the:
1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-
compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as
extensions to the MAJOR.MINOR.PATCH format.
http://semver.org/
36
41. PSR-2
1. This guide extends and expands on PSR-1, the basic coding
standard.
2. The intent of this guide is to reduce cognitive friction when
scanning code from different authors. It does so by enumerating a
shared set of rules and expectations about how to format PHP code.
3. it helps to have one set of guidelines to be used among all those
projects.
4. There are tools to help to comply with this (php code sniffer is
recommended)
41http://www.php-fig.org/psr/psr-2/
42. PHP Code Sniffer
PHP_CodeSniffer is a set of two PHP scripts; the
main phpcs script that tokenizes PHP, JavaScript and CSS files to
detect violations of a defined coding standard, and a
second phpcbf script to automatically correct coding standard
violations. PHP_CodeSniffer is an essential development tool
that ensures your code remains clean and consistent.
42
44. Changelog
1. it is a file which contains a curated, chronologically ordered
list of notable changes for each version of a project.
2. it makes it easier for users and contributors to see precisely
what notable changes have been made between each release
(or version) of the project.
44
45. Changelog rules
1. There should be an entry for every single version.
2. Same types of changes should be grouped
3. Versions and sections should be linkable
4. The latest version comes first
5. The release date of each versions is displayed
6. SemVer as versioning (recommended)
45
46. Changelog changes
1. Added for new features.
2. Changed for changes in existing functionality.
3. Deprecated for soon-to-be removed features.
4. Removed for now removed features.
5. Fixed for any bug fixes.
6. Security in case of vulnerabilities.
46
48. Travis CI prerequisites
1. GitHub login
2. Project hosted as a repository on GitHub
3. Working code in your project
4. Working build or test script
5. Travis CI .org for public repositories
6. Travis CI .com for private repositories
48
49. Travis CI
1. Sign in to Travis using GitHub account
2. Activate GitHub repositories
3. Add a .travis.yml file
4. Add the .travis.yml file to git, commit and push, to trigger a
Travis CI build
5. Check the build status page to see if your build passes or fails
6. Github will have the service in the web hooks settings.
49
50. Scrutinizer CI
1. Sign in to Scrutinizer using GitHub account
2. Activate GitHub repositories
3. Add a .scrutinizer.yml file
4. Add the .scrutinizer.yml file to git, commit and push, to
trigger a Scrutinizer CI build
5. Check the build status page to see code quality and coverage
6. Github will have the service in the web hooks settings.
50
90. Exercise 3
28.commit to git
git add .
git commit -m "Travis CI integration"
git tag -a v0.1.6 -m "version 0.1.6"
git push -u origin master
git push origin v0.1.6
29. make sure version for phpunit is ^5.7 in composer.json to
support php 5.6
90
91. Exercise 3
30.commit to git
git add .
git commit -m "Phpunit version changed to support php version
5.6"
git tag -a v0.1.7 -m "version 0.1.7"
git push -u origin master
git push origin v0.1.7
91
108. Exercise 3
37.commit to git
git add .
git commit -m "Scrutinizer CI and badges in README"
git tag -a v0.1.9 -m "version 0.1.9"
git push -u origin master
git push origin v0.1.9
38.Make sure there are no type hinting for PHP 7.0 only
108
114. Exercise 3
44.commit to git
git add .
git commit -m "Improvements to README"
git tag -a v0.1.12 -m "version 0.1.12"
git push -u origin master
git push origin v0.1.12
45.Add .gitattributes file to ignore some files or folders when --
prefer-dist is used
114
116. Exercise 3
47.create an account in packagist.org and submit your library using your github
repository
48.Make your package in packagist to be autoupdated on push
49.Add last version in packagist badge to README.md file
[![Latest Version on Packagist][ico-version]][link-packagist]
[ico-version]: https://img.shields.io/packagist/v/conquerorsoft/
my_first_library.svg?style=flat
[link-packagist]: https://packagist.org/packages/conquerorsoft/my_first_library
116
133. Exercise 4
1. cd ~ && mkdir -p phplibrary/my_first_project && cd
phplibrary/my_first_project
2. create a README.md file
133
134. README.md
1 # My First Project #
2
3 This is my very first project I created at php[world].
134
135. Exercise 4
3. git init
4. commit to git
git add .
git commit -m "First commit of my project"
5. Assign a version to your project
git tag -a v0.1.0 -m "version 0.1.0"
6. Create a repository in GitHub
135
136. Exercise 4
7. connect your repository
git remote add origin https://github.com/ConquerorSoft/
my_first_project.git
git push -u origin master
git push origin v0.1.0
8. composer init
9. Provide the next values
136
137. Exercise 4 values for composer.json
1. name: php_library_right_way/my_first_project
2. description: "Project created with composer init"
3. require: php ^5.6 || ^7.0
4. require-dev:
1. phpunit/phpunit latest ^5.7
2. squizlabs/php_codesniffer 3.*
5. type: project
6. License: MIT
7. Author: your name and email
8. Others: leave default
137
147. Exercise 4
21.Add a LICENSE.md file (for this example we chose MIT click
link)
22.Create tests/FirstProjectClassTest.php
23.Create src/FirstProjectClass.php
24.Add the next sections to composer.json
147
154. Exercise 4
28.commit to git
git add .
git commit -m "Travis CI integration"
git tag -a v0.1.5 -m "version 0.1.5"
git push -u origin master
git push origin v0.1.5
29.Change composer.json to use github repository instead of file
system local folder
154
160. Exercise 4
36.commit to git
git add .
git commit -m "Scrutinizer support added"
git tag -a v0.1.8 -m "version 0.1.8"
git push -u origin master
git push origin v0.1.8
37.change composer.json to require version ^1.0.0 for my_first_library
38.composer update
160
161. Exercise 4
39.commit to git
git add .
git commit -m "Using version ^1.0 from my_first_library"
git tag -a v0.1.9 -m "version 0.1.9"
git push -u origin master
git push origin v0.1.9
40.Create contributing files: CONTRIBUTING.md and
CODE_OF_CONDUCT.md
161
162. Exercise 4
41.Add more sections to README
1. Install
2. Change log
3. Testing
42.commit to git
git add .
git commit -m "Improvements to README"
git tag -a v0.1.10 -m "version 0.1.10"
git push -u origin master
git push origin v0.1.10
162
163. Exercise 4
43.submit the package to packagist.org using the github repository
44.Make the package to be autoupdated in packagist on push
1. Go to your GitHub repository
2. Click the "Settings" button
3. Click "Integrations & services"
4. Add a "Packagist" service, and configure it with your API
token, plus your Packagist username
5. Check the "Active" box and submit the form
163
169. Exercise 4
45.Add last version in packagist badge to README.md file
[![Latest Version on Packagist][ico-version]][link-packagist]
[ico-version]: https://img.shields.io/packagist/v/conquerorsoft/
my_first_project.svg?style=flat
[link-packagist]: https://packagist.org/packages/conquerorsoft/
my_first_project
169
170. Exercise 4
46.commit to git
git add .
git commit -m "Instructions to use packagist.org in README"
git tag -a v0.1.11 -m "version 0.1.11"
git push -u origin master
git push origin v0.1.11
170
171. Exercise 4
47.create a gh-pages branch
git checkout -b gh-pages
git push -u origin gh-pages
git checkout master
48.Go to github settings for your repository
49.Choose a theme in GitHub Pages section
50.Your project page is ready now: https://
conquerorsoft.github.io/my_first_project/
171