Matthew Weier O'PhinneyPush-to-Deploy with AWS CodeDeploy (30.6.2016, 19:10 UTC)

AWS CodeDeploy is a tool for automating application deployments to EC2 instances and clusters. It can pull application archives from either S3 or GitHub, and then allows you to specify how to install, configure, and run the application via a configuration specification and optionally hook scripts. When setup correctly, it can provide a powerful way to automate your deployments.

I started looking into it because I wanted to try out my site on PHP 7, and do a few new things with nginx that I wasn't doing before. Additionally, I've accidently forgotten to deploy a few times in the past year after writing a blog post, and I wanted to see if I solve that situation; I'd really enjoyed the "push-to-deploy" paradigm of OpenShift and EngineYard in the past, and wanted to see if I could recreate it.

Enrico first pointed me to the service, and I was later inspired by a slide deck by Ric Harvey. The process wasn't easy, due to a number of things that are not documented or not fully documented in the AWS CodeDeploy documentation, but in the end, I was able to accomplish exactly that: push-to-deploy. This post details what I found, some recommendations on how to create your deployments, and ways to avoid some of the pitfalls I fell into.

Preparing for CodeDeploy on AWS

The first thing you need to do is setup a whole slew of profiles, roles, and policies on AWS. The AWS CodeDeploy Getting Started guide walks you through the various details of that. While it's not trivial or easy, I was able to get everything ready without any real stumbling blocks.

Create an EC2 instance

Once you've setup your IAM (Identity and Access Management) profiles, roles, and policies, you can start enabling CodeDeploy on your EC2 instances. While you can assign an IAM policy to an existing EC2 instance, I recommend using a new instance, to ensure that you can troubleshoot and debug without affecting a running application.

I went and selected an Ubuntu 16.04 AMI (specifically, ami-32b6515f), as I want to use the latest LTS, and I'm familiar with both Ubuntu and Debian systems. (This turned out to pose a few issues, which I'll detail later.)

When I created the instance, I tied it to the IAM policy I created for CodeDeploy, ensuring I'll be able to use it with that service.

Setting up the EC2 instance

If you don't install the official Amazon Linux AMI, you won't have the various tools in place needed to run the CodeDeploy agent. Among other things:

  • The www-data user is setup such that it cannot use a shell, which means it cannot run scripts — which poses a problem for running deployment scripts or cronjobs as the user.
  • You need to install the CodeDeploy agent on the instance, and it may need some dependencies installed depending on the AMI you use.

www-data

The www-data user exists by default. However, it has the login shell set to /usr/sbin/nologin. This means that if you specify:

runas: www-data

in one of your appspec.yml hooks, it will fail; this also affects execution of crontab entries. The solution is to update the user to have a real login shell. Run:

$ sudo vipw

vipw is a safer way to edit the /etc/passwd file, and will prompt you for an editor to use before opening it. Find the entry for www-data, change the shell to /bin/bash, save, and exit.

Ruby 2.0

In order to install the code deploy agent on the server, you need to have ruby 2.0 installed; the installer for the agent will not work with any other version at this time.

If you're on Ubuntu 14.04, or if you're on the official Amazon Linux AMI, it's already installed, or can be installed from existing package repositories:

# On Ubuntu 14.04:
$ sudo apt-get install ruby2.0
# On Amazon Linux or Fedora:
$ sudo yum install ruby2.0

If, like me, you decide to use Ubuntu 16.04 (xenial), that version is unavailable (the lowest version available is 2.3), and even some well-known package repositories do not have xenial packages available (if they ever will).

So, I had to create a package, which involves downloading a 2.0 release, using a utility to create a debian package out of it, and then installing it.

To do that, I did the following:

$ sudo apt-get install checkinstall build-essential zlib1g-dev libssl-dev libreadline6-dev libyaml-dev
$ wget http://cache.ru

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

Link
Stefan KoopmanschapThe Speaker Package (30.6.2016, 11:15 UTC)

I've been meaning to write more about speaking recently, so after I wrote about my personal CFP rule, let's write about a very related topic: The Speaker Package.

What is it?

The speaker package is the term used for the package of reimbursements and other advantages you have as a speaker. This may (or may not) include a free ticket to the conference, travel and/or hotel reimbursements, a speakers dinner and some other things.

Why is it important?

When submitting to a conference, it is important to realize what the speaker package consists of. For instance, if you can not pay for your own travel or hotel and don't have an employer that does so, you need to be sure that the conference can cover this. Also, for planning purposes it may be useful to know about speakers dinner, so that you block your calendar so you are able to attend it.

I made the mistake once of making assumptions about the speaker package (in this case: I assumed travel was being reimbursed) when submitting proposals to a conference. I got accepted, but then found out my flight was not covered by the conference. Because of that, I had to cancel that conference. Cancelling a conference is never fun, but especially not because of something like this.

Speaker package unclear? Ask!

If something is unclear about the speaker package, do not hesitate to contact the conference about it. I've found that many conferences these days use OpenCFP for their call for papers. The OpenCFP standard template contains some information about the speaker package, including:

Complimentary airfare/travel (according to conference policy)

Unfortunately, conferences usually do not elaborate on what this conference policy actually is. Since some conferences only give partial reimbursements for airfare, you're never really sure how much of the flight you're going to pay for yourself. If a conference has this standard text and no additional information on their reimbursement policy, just get in touch with them! Get them to clarify this before submitting to their CFP.

Another personal rule

In my previous article I explained about my personal rule to not submit to a conference unless I'm sure I can make it if I get accepted. I have another personal rule, this one concerning the speaker package:

I will not submit to conferences that do not make an effort to reimburse their speakers

Unfortunately, there are conferences out there that do not offer to pay for anything for a speaker. These conferences mostly seem motivated by the idea that "you're already coming to this conference anyway, so become a speaker while you're here". I can sort of understand this sentiment, but I personally feel like this implies a certain lack of respects towards the speakers.

Speakers invest a lot of their time in a conference. They spend hours, sometimes days on preparing a talk, creating slides, rehearsing it, finetuning it, submitting it to conferences. They also spend a lot of time on the conference: car trips or flights, actually being at the conference, talking to people before and after their talk. They even spend money because they come to the conference: They need to eat and drink, park their car, etc. If the speaker is a freelancer or entrepreneur, they'll also miss income because they can not make billable hours while at the conference. All this is a huge investment, to be part of the conference. Speakers are usually passionate and willing to do this, but when conferences do not even make an effort to reimburse at least part of this, this is a reason for me to not submit to a conference.

It is the effort that counts

I'm not saying that all costs should be reimbursed. As I mentioned before, speakers are usually passionate and willing to invest in conference speaking. I know I am more than willing to do this. I've spoken at conferences where travel is not being reimbursed (the best PHP conference in the world does not reimburse travel) and I've spoken at conferences where I offered to pay for travel (because the conference offered sponsorship packages in return for covering travel). All of these conferences have one thing in common: They all offer to pay for (part of) the cost of speaking. And in case of PHPDay, they even offer a valid way out of their reimbursements by offering sponsorship in return for not having to reimburse. It is the effort of trying to cover expenses that counts to me.

So now what?

Next time you open the CFP page for a conference, look for the speaker package information and make sure that it meets your requirements. If you have an employer, talk to them to figure out if they can perhaps cover part of the cost, so you can help make the conference an even bigger success. If anything is unclear in the speaker package information, get in touch with the conference to clarify before submitting. And if it doesn't meet your requirements, simply don't submit.

Link
Rafael DohmsLand ho! New challenge ahead. (30.6.2016, 08:16 UTC)

A few months ago I posted about the situation at my former company and the uncertain future of our team. During these 3 months we explored many new opportunities and interviewed with many companies, from startups to consolidated giants, from financial market to education and user feedback, it was an amazing journey.

This journey is now over and I have found my new challenge, but more on that in a bit. Let me tell you a bit more about the journey.

Interviewing as a team

Few months ago Stripe posted an article about hiring teams and the benefits of that, I would like to also mention the benefits of interviewing as a team.

Our team went to many interviews as a full team, either together in big meetings or as individuals. The interesting aspect of this is that since we were a diverse group of people with many different roles, we analyzed companies from various angles, some of which I, in my interviewing experience, may never have thought to look into.

This made for a very fulfilling and unique experience, I got a lot more insights into companies than ever before. How does the business decide on features, how is UX looked after outside of screens, how do you make money and down to our usual questions of code/infrastructure.

If you ever get a chance to coordinate as a group and exchange notes on interviews, I do recommend doing so.

What’s next?

I’m happy to announce my next challenge, not just because I’m very excited to join the company and add to the great work they already do, but also because I was lucky enough to bring Rick Buitenman, my former manager, and Pauline Vos, my former “mentee”, along for the ride.

As of the first of July we will all be part of the Usabilla family!

Usabilla is a big player in the Dutch tech scene, a company built on the belief that continuous user feedback is the key to successful products. Their focus is on providing “Voice of Customer” solutions to help their more than 20K clients improve their user experience, conversions and boost customer satisfaction.

If you have ever used websites like ABN AMRO, KLM, HP, Philips, Vodafone and countless others, you may have noticed a feedback button, that is one of the many tools Usabilla provides.

I’ll be joining them as Lead Backend Engineer, where I’ll be able to focus on my 3 personal passions: coding/architecture, development work flow and growing/mentoring developers. Together we hope to take the platform to new levels of architecture, quality and performance.

Apart from coding, I’ll be working with the development team to take our development practices to even higher levels and make sure we are all learning and growing all the time. I love teaching and exposing people to more knowledge so this should feel right at home for me.

I’m also looking forward to learning from a entire new set of great developers as well as also getting a chance to expand into Golang which is in line with my own personal goals for this year.

I’m very excited to dive into the company and see how I can contribute to a great business and an amazing team.


© Rafael Dohms for Rafael Dohms, 2016. | Permalink | No comments
Want more on these topics ? Browse the archive of posts filed under Career, PHP.

Link
PHP ClassesNotable PHP package: Random Access File (30.6.2016, 07:31 UTC)
By Manuel Lemos
Database management systems use special techniques to find records of data very quickly.

One of those techniques is to make each record of data in table have a fixed length, even when some record fields have a variable length.

This way, to read or write specific records in a table, it is just a matter of knowing the record position and multiplying by the length of each record.

This class takes advantage of this technique to efficiently perform several types of operations to manipulate records of data in table files.

Those operations include not only reading and writing records, but also moving records to different positions or even truncate the table files to make them smaller.

Read this article to learn more details about how this notable PHP package works.
Link
Jordi BoggianoTypo Squatting and Packagist (29.6.2016, 19:20 UTC)

Earlier this month an article was published summarizing Nikolai Philipp Tschacher's thesis about typosquatting. In short typosquatting is a way to attack users of a package manager by registering a package with a name similar to a popular package, hoping that someone will accidentally typo the name and end up installing your version of it that contains malware.

The thesis mentions https://packagist.org as a good example as we use vendor namespaces:

[...] it is much more secure, if a package is named ntschacher/GoogleScraper instead of just GoogleScraper. The reason is: If the package name is misspelled and not the author name, this will not have any consequences, because the typo version cannot be registered in this namespace, since this author name is already reserved. [...] Because package names are much longer with two attributes, it is more likely that users will copy and paste the package name instead of remembering it.

Despite this mitigating fact, it is still technically possible to squat the vendor name, so I wanted to take a look at our repository data and see if I could spot any bad actors. I wrote a script that basically does the following: Read the list of all vendor names which have packages with at least 1000 downloads, as the others are unlikely targets or at least low value targets. Check the levenshtein distance of every vendor name against all others. If the distance is 1, then it checks for package names within those two vendors to see if they have any intersecting names. Those are then candidates for being typosquatters.

What did I find? 21 vendor pairs that conflict to some degree. Only one that looked like an actual typosquatting attempt, momolog/monolog, and it even had in the package description that it was a demonstration of typosquatting. I deleted it along with 5 others packages that were useless, but the others are still in place. A lot of it is just due to people renaming their vendor names, or simply people that picked similar names but don't seem to be abusing anything.

In the future it would be nice to automate this, or prevent the creation of vendors that are too similar to popular ones. However it is reassuring to see that there is no widespread abuse going on.

Link
SitePoint PHPDisco with Design Patterns: A Fresh Look at Dependency Injection (29.6.2016, 17:00 UTC)

Dependency Injection is all about code reusability. It's a design pattern aiming to make high-level code reusable, by separating the object creation / configuration from usage.

Illustration of people's outlines dancing in a disco

Consider the following code:

<?php

class Test {

    protected $dbh;

    public function __construct(\PDO $dbh)
    {
        $this->dbh = $dbh;
    }

}

$dbh  = new PDO('mysql:host=localhost;dbname=test', 'username', 'password');
$test = new Test($dbh)

As you can see, instead of creating the PDO object inside the class, we create it outside of the class and pass it in as a dependency - via the constructor method. This way, we can use the driver of our choice, instead of having to to use the driver defined inside the class.

Our very own Alejandro Gervasio has explained the DI concept fantastically, and Fabien Potencier also covered it in a series.

There's one drawback to this pattern, though: when the number of dependencies grows, many objects need to be created/configured before being passed into the dependent objects. We can end up with a pile of boilerplate code, and a long queue of parameters in our constructor methods. Enter Dependency Injection containers!

A Dependency Injection container - or simply a DI container - is an object which knows exactly how to create a service and handle its dependencies.

In this article, we'll demonstrate the concept further with a newcomer in this field: Disco.

For more information on dependency injection containers, see our other posts on the topic here.

As frameworks are great examples of deploying DI containers, we will finish the article by creating a basic HTTP-based framework with the help of Disco and some Symfony Components.

Installation

To install Disco, we use Composer as usual:

composer require bitexpert/disco

To test the code, we'll use PHP's built-in web server:

php -S localhost:8000 -t web

As a result, the application will be accessible under http://localhost:8000 from the browser. The last parameter -t option defines the document root - where the index.php file resides.

Getting Started

Disco is a container_interop compatible DI container. Somewhat controversially, Disco is an annotation-based DI container.

Note that the package container_interop consists of a set of interfaces to standardize features of container objects. To learn more about how that works, see the tutorial in which we build our own, SitePoint Dependency Injection Container, also based on container-interop.

To add services to the container, we need to create a configuration class. This class should be marked with the @Configuration annotation:

<?php
/**
 * @Configuration
 */
 class Services {
    // ...
 }

Each container service should be defined as a public or protected method inside the configuration class. Disco calls each service a Bean, which originates from the Java culture.

Continue reading %Disco with Design Patterns: A Fresh Look at Dependency Injection%

Link
Nomad PHPStatic Analysis for PHP (29.6.2016, 14:03 UTC)

Speaker: Damien Seguy @faguo

The post Static Analysis for PHP appeared first on Nomad PHP.

Link
PHP ClassesPHP Classes Completed 17 Years: A New Type of Classes (29.6.2016, 09:07 UTC)
By Manuel Lemos
The PHP Classes site has just completed 17 years of age. It is a long time for a site that continues to evolve to serve better its users.

The big news this year is about a new project that is being launched in a separate site that aims to help other developers to learn what to do to create their own software product businesses.

Read this article to learn about the latest developments in PHP Classes,] as well the new project about creating software product businesses.
Link
SitePoint PHPHeroku Alternative: Deploy Apps with Dokku on DigitalOcean (28.6.2016, 22:00 UTC)

When Heroku announced their (quite reasonable) new limits for free apps, I realized that I would have to find another source of hosting for all the small, low-traffic projects that I currently have running on Heroku. Way back in the day, Heroku was totally free for apps that only required one dyno, but after years of abuse from jerks like me, they dropped that to eventually allowing free apps to run for 18 out of 24 hours per day (which is ok for low-traffic prototypes) and as of June 1, granting a shared pool of free hours.

Since I have such an unreasonable number of apps running on Heroku, I thought it was high time to try out Dokku. Dokku is a Heroku-like tool that allows you to deploy complex apps by simply pushing with Git. It supports Heroku buildpacks directly, so you can transition existing apps without difficulty, and has a number of plugins for datastores and other components. And, thankfully, Digital Ocean provides a pre-installed Dokku image that will spare you the trouble of installing Dokku yourself; you can just spin up a server and start Dokku-ing right away! This article will walk you through setting up a Dokku server on DigitalOcean with your own root domain and deploying a simple static site to it.

Differences between Dokku and Heroku

  • Dokku requires at least some comfort level with running your own servers; you may have to modify nginx configurations, manually configure some plugins, or turn to the system tools for debugging.
  • Dokku utilizes Docker, which is a fine platform but can add an extra layer of complexity to a server install.
  • Dokku requires root access to a VPS to install plugins, run commands, etc.

In short, you're going to need to do a bit more command line setup on Dokku than Heroku --- nothing you can't pick up along the way, but you might need to do some light reading.

Creating a Dokku Server on DigitalOcean

DigitalOcean logo

First, log in to DigitalOcean and follow this link to create a new server on DigitalOcean using the preinstalled Dokku app. Dokku requires at least 1GB of RAM, but $10/mo to host all your stuff is a pretty small price.

For your hostname, enter the base domain you want to use to host your apps. Default Dokku apps will appear at . (for example, myapp.example.com). Make sure you own this domain and register it if you need to!

Continue reading %Heroku Alternative: Deploy Apps with Dokku on DigitalOcean%

Link
SitePoint PHPSourcehunt: PHP7-Only Alternative to Laravel, HPKP, and More (28.6.2016, 17:26 UTC)

Time to promote some open source projects again!

Sourcehunt logo

paragonie/hpkp-builder [15 ★]

This library aims to make it easy to build HTTP Public-Key-Pinning headers in your PHP projects, and requires at least PHP 7.

HTTP Public Key Pinning, or HPKP, is a security policy delivered via a HTTP response header much like HSTS and CSP. It allows a host to provide information to a user agent about which cryptographic identities it should accept from the host in the future. This can protect a host website from a security compromise at a Certificate Authority where rogue certificates may be issued for your hostname.

Read more about HPKP here.


Rican7/incoming [137 ★]

Incoming is a PHP library designed to simplify and abstract the transformation of loose, complex input data into consistent, strongly-typed data structures.

// Create our incoming processor
$incoming = new Incoming\Processor();

// Process our raw form/request input into a User model
$user = $incoming->process(
    $_POST,            // Our HTTP form-data array
    new User(),        // Our model to hydrate
    new UserHydrator() // The hydrator above
);

Explaining it to any great detail is outside the scope of this short post, but in essence it allows us to precisely define what kind of input information goes through and hydrates our model, rejecting, filtering, or transforming everything else.

It's like Fractal, backwards. (Fractal makes sure the output matches a set structure, rather than input)

The library currently has one outstanding issue - and it's a discussion around a feature - but could definitely use some users and feedback! Maybe even a SitePoint post about it?

Continue reading %Sourcehunt: PHP7-Only Alternative to Laravel, HPKP, and More%

Link
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP