SitePoint PHPMail Logging in Laravel 5.3: Extending the Mail Driver (23.9.2016, 16:00 UTC)

Laravel Logo

One of the many goodies Laravel offers is mailing. You can easily configure and send emails through multiple popular services, and it even includes a logging helper for development.

Mail::send('emails.welcome', ['user' => $user], function ($m) use ($user) {
    $m->to($user->email, $user->name)->subject('Welcome to the website');
});

This will send an email to a new registered user on the website using the emails.welcome view. It got even simpler with Laravel 5.3 using mailables (but the old syntax is still valid). Here's an example:

# Generate a new mailable class
php artisan make:mail WelcomeMail

// app/Mail/WelcomeMail.php

class WelcomeUser extends Mailable
{

    use Queueable, SerializesModels;

    public $user;

    public function __construct(User $user)
    {
        $this->user = $user;
    }

    public function build()
    {
        return $this->view('emails.welcome');
    }
}

// routes/web.php

Route::get('/', function () {
    $user = User::find(2);

    \Mail::to($user->email)->send(new WelcomeUser($user));

    return "done";
});

Laravel also provides a good starting point for sending mails during the development phase using the log driver, and in production using smtp, sparkpost, mailgun, etc. This seems fine in most cases, but it can't cover all the available services! In this tutorial, we're going to learn how to extend the existing mail driver system to add our own.

To keep our example simple and straightforward, we're going to log our emails to a DB table.

Continue reading %Mail Logging in Laravel 5.3: Extending the Mail Driver%

Link
Nomad PHPRobust Second-factor Authenticationwith PHP (23.9.2016, 15:19 UTC)

December 2016 - US
Presented By

Tim Lytle
December 15, 2016
20:00 CST

The post Robust Second-factor Authentication
with PHP
appeared first on Nomad PHP.

Link
Christian Weiskeshpub - micropub client for the shell (23.9.2016, 11:52 UTC)

Over the last weeks I have been working on shpub, a Micropub client for the shell. It allows you to publish blog posts, replies/coments and likes from the shell or programmatically.

Instagram

I wrote it because I needed a way to archive Instagram posts to a self-hosted blog. The internet-hater Instagram requires one to get approval for API clients, and only approves those that fall into a very narrow set of categories.

But thanks to the great new all-is-javascript world, Instagram data don't have to be scraped at all - simply adding ?__a=1 to one of its URLs gives you the data in JSON. Downloading all data wasn't a problem now, I only had to find a way to put the photos and videos into a blog now..

I first experimented with wp-cli, the WordPress command line interface. It kind of worked, but the theme didn't look nice, and there were some limitations I could not get around. Known on the other hand had all features I needed, a nice-looking layout - and no own API, but a Micropub endpoint.

Micropub

Micropub is a protocol for creating, updating and deleting all types of content on a server: Blog posts, replies/comments, likes, bookmarks, event reservations and more. It's backed by the W3C and currently in Draft status.

The goal is to have a standardized API to post content to your website, and you may use the client that's most suited for the job.

Currently we have generic clients like Quill, feed readers like Woodwind that have in-built commenting support, very specific ones like the Pushup-counter iOS app, an XMPP bot and more. See the Micropub client list for more information.

There are even services that act as Micropub client. For example, OwnYourGram instantly posts your own Instagram images to your blog. OwnYourCheckin does the same for Fourquare checkins.

On the other hand, there are micropub endpoints that act as proxy for other websites: silo.pub allows you to use a Micropub client to write comments on Github, Facebook or Twitter.

shpub

I needed a way to send Micropub requests to the Known instance, and there was no tool for it. So I sat down and wrote shpub with the goal to make a command line interface I can use from my instagram2micropub script.

During the process I learned a lot, found many bugs in Known's micropub endpoint and in the Wordpress micropub endpoint, and got to know Known's internals.

After some documentation work, the IndieWeb wiki now has a comparison of Micropub servers and Micropub clients.

shpub was the second Micropub client to support Media endpoints, and is - as far as I know - the only one that supports updates. It's almost feature-complete and works fine with instagram2micropub.

Get it from its homepage or github.

Link
PHP ClassesPHP and JavaScript Innovation Award Report September 2016 Edition - June 2016 nominees (23.9.2016, 07:41 UTC)
By Manuel Lemos
This is the September edition of the Innovation Award podcast hangout recorded by Manuel Lemos and Arturs Sosins to comment on the outstanding features of all the past month nominees and winners PHP and JavaScript packages, the prizes that the authors earned, starting with the nominees from the month of June 2016.

Listen to the podcast, or watch the hangout video to learn why the nominated packages were considered to be innovative, as well the current rankings of the Innovation Award Championship by author and by country.
Link
Nomad PHPRFCs of the Future: Array of Hope (21.9.2016, 20:39 UTC)

Speaker: Cal Evans @calevans In this episode of RFCs From the Future, we take a look at three RFCs that attect how arrays work in PHP 7.1

The post RFCs of the Future: Array of Hope appeared first on Nomad PHP.

Link
PHP ClassesHow Can I Get Users to Try my Software Product for the First Time (21.9.2016, 10:36 UTC)
By Manuel Lemos
Before you announce the software product that you developed, nobody knows about it. Actually if you are starting in the business, maybe nobody knows you yet.

So you need to start attracting people to at least try your product, demonstrate that you understand about the user problems and how your product can solve them.

Watch this video of a consulting session to learn about means to start attracting a list of people potentially interested in your product, so you can sell it later to them.
Link
Planet PHPPHP-FIG Alternatives: The Pros and Cons of Various Visions - SitePoint PHP (20.9.2016, 18:00 UTC)

In his article The Past, Present and Future of the PHP-FIG, Larry Garfield gives a whirlwind tour of his impressions of the FIG, from its founding to one of its possible futures. I encourage you to read it in its entirety before continuing.

Herein, I will attempt to address some of the errors and omissions in Larry's article, and offer two other possible futures for the FIG.

Fist fight illustration

PHP-FIG 3.0: Too Revisionary?

I have stated elsewhere that what I have called the "founding" vision of the FIG was to focus on member projects, find commonalities among them, and codify those commonalities. Larry condemns my statement as "revisionist history" and asserts the true founding intent was more in line with what I have called the "grand" vision (that is, an overarching standards group for all PHP coders, member projects or not).

To support his position, Larry quotes David Coallier's post of Brett Bieber's meeting notes.

The goal of this meeting was to develop a set of common standards which PHP projects can strive towards adopting.

Each project may have specific standards which may extend and further define how these standards should be used, but the goal being a set of PHP standards provided as a resource for all PHP developers.

Larry also draws from Travis Swicegood saying something similar. I will quote a little more of Travis's post than Larry did:

Below is what my vision is. It’s my vision and mine alone, but this is where I’m coming from. ... I’d love to see an officially sanctioned standard come out of our work. ... When code is published for public consumption in a year, I would love it if the first comment on blog posts or mailing list messages announcing the new code is "wow, that’s great, but you should run it through phpcs."

At first, this appears to be substantial evidence of Larry's claim. However, one should remember that a "goal going into" a meeting is not the same thing as a "result coming out of" a meeting.

So it may well be true that some of the participants had something more like the "grand" vision in mind when they first arrived. But, having been at that initial meeting myself, I personally recall the decision by the end was not to pursue the "grand" vision. Instead, it was to adopt the more limited, "for the group members" approach.

To provide more support than my own memory of the discussion, I submit the following:

  • Travis himself says in the same post linked above, "We decided to form an official group of our projects to oversee the creation of this standard and work toward better, more widely adopted standards across our projects."

  • Cal Evans, also present at the meeting, presents a summary narrative:

    • "To paraphrase the goal of this group, we are saying 'Hey, we are all agreeing that we are going to code this way and we'd like you to do it to.'" (Does that mean Larry has it right after all? No, Cal corrects himself in a later email, stating "That should have read: To paraphrase the goal of this group, we are saying 'Hey, we are all agreeing that we are going to code this way.'")

    • In that same later email, Cal also says, "This group is not setting itself above all others saying we know best. We are trying to find common ground between a lot of projects so that PHP developers world-wide can move between the code in those projects and not have to re-learn standards each time. ... While I would love to see the the standards agreed upon by this group be widely adopted by the PHP community at large, that is not a goal of the group."

  • Matthew Weier O'Phinney says, "We represent a large number of component libraries and frameworks, with many thousands, if not millions, of users. We are representing those users within this group. ... Third, these standards are not compulsory. You can adopt them or not. We are simply recommending them, and also committing that our representative projects will be using them. ... If anything, we're keeping a very close eye on the community, and involving them as much as possible

Truncated by Planet PHP, read more at the original (another 2060 bytes)

Link
SitePoint PHPPHP-FIG Alternatives: The Pros and Cons of Various Visions (20.9.2016, 18:00 UTC)

In his article The Past, Present and Future of the PHP-FIG, Larry Garfield gives a whirlwind tour of his impressions of the FIG, from its founding to one of its possible futures. I encourage you to read it in its entirety before continuing.

Herein, I will attempt to address some of the errors and omissions in Larry's article, and offer two other possible futures for the FIG.

Fist fight illustration

PHP-FIG 3.0: Too Revisionary?

I have stated elsewhere that what I have called the "founding" vision of the FIG was to focus on member projects, find commonalities among them, and codify those commonalities. Larry condemns my statement as "revisionist history" and asserts the true founding intent was more in line with what I have called the "grand" vision (that is, an overarching standards group for all PHP coders, member projects or not).

To support his position, Larry quotes David Coallier's post of Brett Bieber's meeting notes.

The goal of this meeting was to develop a set of common standards which PHP projects can strive towards adopting.

Each project may have specific standards which may extend and further define how these standards should be used, but the goal being a set of PHP standards provided as a resource for all PHP developers.

Larry also draws from Travis Swicegood saying something similar. I will quote a little more of Travis's post than Larry did:

Below is what my vision is. It’s my vision and mine alone, but this is where I’m coming from. ... I’d love to see an officially sanctioned standard come out of our work. ... When code is published for public consumption in a year, I would love it if the first comment on blog posts or mailing list messages announcing the new code is "wow, that’s great, but you should run it through phpcs."

At first, this appears to be substantial evidence of Larry's claim. However, one should remember that a "goal going into" a meeting is not the same thing as a "result coming out of" a meeting.

So it may well be true that some of the participants had something more like the "grand" vision in mind when they first arrived. But, having been at that initial meeting myself, I personally recall the decision by the end was not to pursue the "grand" vision. Instead, it was to adopt the more limited, "for the group members" approach.

To provide more support than my own memory of the discussion, I submit the following:

  • Travis himself says in the same post linked above, "We decided to form an official group of our projects to oversee the creation of this standard and work toward better, more widely adopted standards across our projects."

  • Cal Evans, also present at the meeting, presents a summary narrative:

    • "To paraphrase the goal of this group, we are saying 'Hey, we are all agreeing that we are going to code this way and we'd like you to do it to.'" (Does that mean Larry has it right after all? No, Cal corrects himself in a later email, stating "That should have read: To paraphrase the goal of this group, we are saying 'Hey, we are all agreeing that we are going to code this way.'")

    • In that same later email, Cal also says, "This group is not setting itself above all others saying we know best. We are trying to find common ground between a lot of projects so that PHP developers world-wide can move between the code in those projects and not have to re-learn standards each time. ... While I would love to see the the standards agreed upon by this group be widely adopted by the PHP community at large, that is not a goal of the group."

  • Matthew Weier O'Phinney says, "We represent a large number of component libraries and frameworks, with many thousands, if not millions, of users. We are representing those users within this group. ... Third, these standards are not compulsory. You can adopt them or not. We are simply recommending them, and also committing that our representative projects will be using them. ... If anything, we're keeping a very close eye on the community, and involving them as much as possible

Truncated by Planet PHP, read more at the original (another 2060 bytes)

Link
Raphael StoltAnatomy of a dope PHP package repository (20.9.2016, 17:32 UTC)
While contributing to Construct, maintained by Jonathan Torres, I gathered some insights and learnings on the characteristics of a dope PHP package repository. This post summarises and illustrates these, so that PHP package develeopers have a complementary guideline to improve existing or imminent package repositories. Jonathan Reinink did a good job in putting the PHP package checklist out there which provides an incomplete, but solid quality checklist for open-source PHP packages.

I'll distill the characteristics of a dope PHP package repository by looking at the repository artifacts Construct can generate for you when starting the development of a new PHP project or micro-package. The following tree command output shows most of the elements this post will touch upon. The artifacts in parenthese are optional and configurable from Construct but can nonetheless have an import impact on the overall package quality.

├── <package-name>
│ ├── CHANGELOG.md
│ ├── (CONDUCT.md)
│ ├── composer.json
│ ├── composer.lock
│ ├── CONTRIBUTING.md
│ ├── (.editorconfig)
│ ├── (.env)
│ ├── (.env.example)
│ ├── (.git)
│ │ └── ...
│ ├── .gitattributes
│ ├── (.github)
│ │ ├── CONTRIBUTING.md
│ │ ├── ISSUE_TEMPLATE.md
│ │ └── PULL_REQUEST_TEMPLATE.md
│ ├── .gitmessage
│ ├── .gitignore
│ ├── (.lgtm)
│ ├── LICENSE.md
│ ├── (MAINTAINERS)
│ ├── (.php_cs)
│ ├── (phpunit.xml.dist)
│ ├── README.md
│ ├── (docs)
│ │ └── index.md
│ ├── src
│ │ └── Logger.php
│ ├── tests
│ │ └── LoggerTest.php
│ ├── .travis.yml
│ ├── (Vagrantfile)
│ └── vendor
│ └── ...

Definition of a dope PHP package repository

Before jumping into the details, let's define what could be considered as a dope package repository. Therefor, being lazy, I'm going to simply reword this classic quote from Michael Feathers
> Clean code is code that is written by someone who cares.
to
> A dope PHP package repository is one that is created and maintained by someone who cares.

Artifact categories

The next shown pyramid illustrates the three main categories the artifacts of a package repository will fall into.
First and most important there's the main sourcecode, it's tests or specs, and the documentation which could be dependent on it's size reside in a README.md section or inside a dedicated docs directory. Using a docs directory also allows publishing the documentation via GitHub pages. Other aspects of a package which should be documented are the chosen license, how to contribute to the package, possibly a code of conduct to comply with, and the changes made over the lifespan of the package.

Second there's the configuration for a myriad of tools like Git, GitHub, EditorConfig, Composer, the preferred testing framework, the preferred continuous inspection / integration platform such like Scrutinizer or Travis CI, and so forth.

The final category includes tools which ease the life of maintainers and potential contributors equally. These tools can be helpful for releasing new versions, enforcing coding standard compliance, or commit message quality and consistency.

Consistency

Truncated by Planet PHP, read more at the original (another 14468 bytes)

Link
PHP ClassesNotable PHP package: PHP Domain Driven Design (20.9.2016, 13:54 UTC)
By Manuel Lemos
In simple terms, Domain Design Design is an approach for software development that departs from an evolving model of the problem to the implementation.

This package provides a demonstration of the application of the model driven design.

It provides a set of classes that demonstrate how to implement domain logic with example models, services, strategies, as well specific data type object and mapper classes to use in the demonstration scripts.

Read this article to learn more details about how this notable PHP package works.
Link
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP