Open Sourcing Mental Illness Conference TV

The great nonprofit that I help out with Open Sourcing Mental Illness has an ever increasing presence at conferences. We’ve been stepping up our booth visibility lately by adding a nice tablecloth as well as the purchase of a TV to have a looping video playing on to lure conference goers to our table. Originally we played video from an iPhone or laptop via an HDMI cable. I thought there would be a better way to accomplish this as well as give us some added flexibility in what we can display while still surviving the always variable conditions that are conference venues.

OSMI Promo Video

The normal venue challenges are network connectivity and power. While I can’t solve the power problem without strapping a generator to the TV we can assume we’ll have power at most events. My immediate solution was to run the video off a Raspberry Pi. Raspberry Pi is a super cheap computer. Designed to be hackable and open and promote learning it seemed fitting along with OSMI’s goals of promoting open source ideas and philosophies.

It didn’t take long to get a working solution to using the built in media player OMXplayer. I configured the Pi to auto play the video on reboot via a cron task:

@reboot screen -S video -d -m omxplayer /home/pi/osmi-kiosk.mp4 --loop

This tells the pi to play the video in a screen session every time the computer boots up. The video is played from the local filesystem so we can easily update the video by changing the video. The Pi is also mounted to the back of the TV so we can easily remove it and connect it like a normal computer to a keyboard and wireless network to update the video from the device itself.

For our purposes I wanted something really small that would be easily mountable on the back or side of the TV. The Raspberry Pi zero was the perfect choice:

Raspberry Pi Zero in a case

Raspberry Pi Zero in a case

Raspberry Pi Zero closed case

Raspberry Pi Zero closed case

Raspberry Pi Mounted to the back of the TV

Raspberry Pi Mounted to the back of the TV

php[tek] 2017 Training Day Requirements

I’m excited for php[tek] 2017. This will be my fourth year attending the conference and I always have a blast.

I am again giving a full day of Laravel Training before the main conference. To fully participate in the training exercises you’ll want to follow the directions below. Please reach out to me if you have any issues. Laravel Valet is a fine solution if you’d prefer not to have to install Virtualbox or Vagrant. I will not be able to fully support everyone’s configuration so to create the best experience for all attendees you should use the following as a set up guide if you are not familiar with setting up a web server and related services on your system.

Operating System Support:

If you want to follow along and run all of the examples you will need to bring a laptop running a current version of Linux or Mac OS or Windows.

Applications Installed:

Laravel Homestead

Read and follow the installation instructions in this document – http://laravel.com/docs/5.4/homestead

The most important thing to do before the conference is run this command:

vagrant box add laravel/homestead

Testing Homestead:

Create a new Laravel project and require homestead, make the homestead configuration and then vagrant up.

composer create-project --prefer-dist laravel/laravel test-laravel
cd test-laravel
composer require --dev laravel/homestead
./vendor/bin/homestead make
vagrant up

These commands should run without any errors.

When you’re done, you can destroy the environment by:

vagrant destroy -f
cd ..
rm -rf test-laravel

Thanks for reading, I look forward to seeing you at training day, if you have any problems or errors as you worked through this please feel free to leave me a comment below.

Midwest PHP 2017 Short Recap

I was invited to speak at Midwest PHP 2017 to give my “DevOps for Small Teams” talk. I’m always excited to head up north because I’ve always had amazing experiences with the community there. Also a conference on my birthday weekend this year sounded like a great idea.

The speaker dinner event was fantastic, nice finger food with fellow speakers and getting to know new friends and catching up with long time friends.

The first day of the conference I was mostly working for the day job. I hung out at the Open Sourcing Mental Illness table that we had and got to meet new people and talk about OSMI while I was working on a project for the day job.

OSMI @ Midwest PHP 2017

Gary Hockin’s opening keynote was excellent, this was the second time I was able to see it and it was just as well delivered and entertaining as the first. I highly encourage you to see him speak (on any topic).

After the first conference day there was a big party at a gaming and bowling place in the Mall of America. We had cards to play all the games we wanted, amazing food and bar readily accessible and it made for an amazing after event. I got to spend the evening with old friends and make some new friends that will certainly become old friends.


 

The second day of the conference I was in the first time slot and gave a really great version of my talk. I was really happy with the flow and pacing. I had added about twelve extra slides that morning which did make the talk run slightly long but overall it felt great and got some good feedback on joind.in

The rest of the second day I spent catching up on more day job work and spending time hanging out in the hallway track and at the OSMI table. Everyone I talked to was really enjoying the talks. The organizers did a great job selecting speakers based on the keynotes I saw, and what I heard from attendees.

The closing keynote was Eryn O’Neil talking about “Using our Superpowers for Good”. This keynote is an inspiring gut punch right into the ego of a software developer to make sure you’re aware of all possible outcomes of the code you write. I won’t spoil any of the amazing stories she shares, but I know I’m always looking at my code differently now.

After the conference a few of us went out to dinner. I had part of a large sushi boat and it was incredible.

 

 

 

 

 

The Midwest PHP 2017 venue was incredible. If you were worried about the cold weather, everything was inside. I didn’t have to venture outside for anything. There is a connecting skywalk right into the Mall of America and the food court with dozens of fast food and nice restaurants is only one escalator ride up. There is also an amazing Lego store to bring out your inner child.

I had a great time, thanks to all the organizers, sponsors, speakers, and attendees. Definitely was an awesome event.

Sunshine PHP 2017 – Create Your Own Local Development Environments With Vagrant

Excited to be heading back to Sunshine PHP 2017 in Miami. This year it’s even better since the wife will be joining me again and her birthday is the first day of the conference. I’m not sure who made out better, me getting to go to a conference on my wife’s birthday, or my wife getting a trip to Miami for her birthday? We’ll call it a wash since it’s going to be a great time for both of us.

This year I’m giving a tutorial “Create Your Own Local Development Environments With Vagrant”. You may be thinking: “Why? isn’t docker all the rage?” you’re not wrong, however there are many out there who are still working on applications that aren’t ready to be containerized just yet. Many people are still stuck using MAMP, WAMP, or some other similar tool. This tutorial is for them. People who have never used Vagrant or those who just want to understand how to build their own environment are the target audience for this tutorial.

Since this will be a hands on, follow along tutorial attendees will want to have some things pre-installed to make the most of the tutorial.

Operating System Support:

If you want to follow along and run all of the examples you will need to bring a laptop running a current version of Linux or Mac OS. Unfortunately Windows is unable to run Ansible so you will not be able to run any of the Ansible Playbooks.

Note: Despite Windows 10 Anniversary updating bringing BASH support to Windows, Ansible is still not yet supported.

Applications Installed:

Getting Started, Initial Downloads, and Set Up:

Install some vagrant base boxes. These files may take a few minutes to download, please make sure you run these commands BEFORE traveling to the conference

vagrant box add ubuntu/trusty64
vagrant box add ubuntu/xenial64
vagrant box add puphpet/ubuntu1604-x64
vagrant box add laravel/homestead

Testing Vagrant:

  • Create a new folder to hold your vagrant test
  • Change directory into that folder
  • Create a new Vagrant environment
  • Start the Vagrant
mkdir test-vagrant
cd test-vagrant
vagrant init ubuntu/xenial64

You should see the following output:

A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

Screenshot:
Screenshot 2016-09-05 11.36.15
Now we can start the vagrant

vagrant up

You should see the following output:

Screenshot 2016-09-05 11.42.17

Once you have similar output to the above you can go a head and destroy the vagrant box to free up system resources. Your output may not exactly match the example. If there are any errors please feel free to leave me a comment below.

Destroy the vagrant machine:
Screenshot 2016-09-05 11.44.49

Mocking Swift Mailer – 3 Steps to better code

A few days ago an issue came across my Jira queue that mentioned odd characters showing up in the subject line of our notification system. We use SwiftMailer library which is a fantastic library for sending mail.

The bug report included text similar to:

John Doe Did a thing on John's website

Something was taking our twig template that we use for our email subject and changing the encoding. This is normally done when you want to convert special characters so they’re not interpreted as code blocks. The example above is showing where an apostrophe is converted to “‘”, the ASCII code equivalent.

Step 1: Fix the problem.

When we create our SwiftMailer message and set the subject we change this line:

$message->setSubject($subject);

to

$message->setSubject(html_entity_decode($subject, ENT_QUOTES));

The function ‘html_entity_decode‘ is the opposite of what you’ve probably used ‘htmlentities‘. We’re using the flag `ENT_QUOTES` so that we convert both single and double quotes that may exist in the string. The string in our case being a string of HTML rendered by Twig.

I freely admit that I tried to skip Step 2. I submitted a PR without adding a test to verify the fix. Shame on me! Luckily I have awesome coworkers who call me out.

Step 2: Write the test to verify the fix and prevent regression bugs.

The primary reason I didn’t write a test for this fix was I had spent half the day spinning my wheels at our existing tests around this functionality and couldn’t find a way to verify the rendered subject line after the email was sent.

Step 2.5: Get taken to school by a coworker.

When it comes to testing I’ve always struggled with Mocking things. I’ve never fully understood, it’s never “clicked” for me. The previously mentioned awesome coworker Logan did a quick screen share and mocked up a test for me and we ended up doing a small refactor to inject our instance of Twig (instead of having it in a private method). Once Logan walked me through it and explained everything it all started to fall into place.

Here is our test setup() method:

public function setUp()
{
    $this->email_service = new Email;
    $this->mailer = $this->createMock(\Swift_Mailer::class);
    $this->twig_factory = $this->createMock(TwigFactory::class);

    $this->email_service->mailer = $this->mailer;
    $this->email_service->twig_factory = $this->twig_factory;
}

A neat thing Logan showed me to keep my test method cleaner was to move the assertions into their own method:

public function assertSubjectSet($subject, $data, $result)
{
    $twig = $this->createMock(\Twig_Environment::class);
    $this->twig_factory->expects($this->at(0))
        ->method('make')
        ->willReturn($twig);

    $twig->expects($this->once())->method('loadTemplate')
        ->with($subject)
        ->willReturnSelf();

    $twig->expects($this->once())
        ->method('render')
        ->with($data)
        ->willReturn($result);
}

Now for our actual test:

public function testSubjectLineMatchesExpectation()
{
    $email_data = new EmailData();
    $email_data->from_address = 'john@doe.com';
    $email_data->from_name = 'John Doe';
    $email_data->to_address = 'john@doe.com';
    $email_data->to_name = 'jane@doe.com';
    $email_data->subject = 'John Doe Did a thing on John's website';
    $email_data->body_template = 'Body of the email';
    $email_data->data = [];

    $this->assertSubjectSet($email_data->subject, $email_data->data, $email_data->subject);

    $this->mailer->expects($this->once())
        ->method('send')
        ->with($this->callback(function (\Swift_Message $actual_message) {
            $this->assertEquals('John Doe Did a thing on John\'s website', $actual_message->getSubject());

            return true;
        }));

    $this->email_service->run($email_data);
}

Step 3: Reflect and bask in the tested code glory.

Now we can properly verify that our subject lines aren’t doing any bad things with encoding. No more subject lines with ”’ and I learned some good stuff about mocking.

Thanks for reading. Happy Coding (and Testing!).

Laravel Release Schedule

I always have a hard time figuring out what versions where released when and how much longer we’ll have support for which versions. I decided to do some research and come up with a chart.

General rule is that Laravel will release new version in January and July. (To coincide with Laracon Events) Based on that here’s a current list of Laravel versions and their support dates from Laravel 5.0 to the next 2 planned releases.

Version Released Date End of Bug Fix Updates End of Security Updates
5.0 February 2015 August 2016 February 2016
5.1 (LTS) June 2015 June 2017 June 2018
5.2 December 2015 June 2016 December 2016
5.3 September 2016 March 2017 September 2017
5.4 January 2017 June 2017 January 2018
5.5 July 2017 January 2018 July 2018

Laravel Homestead 4.0 and Box 1.0.1

GO PHP 7.1!

Today we’re releasing Homestead 4.0 and an updated box version 1.0.1 for VMware and Virtualbox. Homestead 4.0 requires box version 1.0.0 or higher since we are making the jump from PHP 7.0 to PHP 7.1.

How to Upgrade

If you have Homestead installed globally:

cd /path/to/homestead
git fetch origin
git checkout v4.0.0
vagrant destroy
rm -rf .vagrant
vagrant up

If you have Homestead installed per project:

Open your projects “composer.json” file and ensure the “laravel/homestead:” line is:

"laravel/homestead": "^4.0"

Then run:

composer update
vagrant destroy
rm -rf .vagrant
vagrant up

You may need to run the Homestead make command again to update your Homestead.yaml:

mv Homestead.yaml Homestead.yaml.backup
php vendor/bin/homestead make

Make sure you copy any changes you may need from Homestead.yaml.backup to Homestead.yaml.

Not ready to go to PHP 7.1 yet? No worries!

If you have Homestead installed globally:

cd /path/to/homestead
git fetch origin
git checkout v3.1.0

You should see the output:

HEAD is now at 7924ab4... version

You are now locked at version 3.1. When you’re ready, just checkout master and git pull to get the latest version

If you have Homestead installed per project:

Open your projects “composer.json” file and adjust the “laravel/homestead:” line to:

"laravel/homestead": "3.1.0"

You may need to run the Homestead make command again to update your Homestead.yaml:

mv Homestead.yaml Homestead.yaml.backup
php vendor/bin/homestead make

Make sure you copy any changes you may need from Homestead.yaml.backup to Homestead.yaml.

Need Help? We have opened the issues once again on the Homestead Repository. Please open a new issue and fill out the issue template.

Use Laravel Shift for your next upgrade

I’ve had an eye on LaravelShift.com since it first made it’s way across my twitter feed some time ago. I’ve also had the pleasure of meeting and talking with it’s creator Jason McCreary at a few conferences over the past year. I think it’s really awesome when community members are able to take a product to market that not only scratches their own itch, but can provide value to the rest of the community as well.

When I’m talking about Laravel console commands with Artisan I often reference a silly project I built on a whim that is still running today: NerdsAreDrinking. The idea is very simple; scan the twitter feeds of my friends and myself then retweet any untappd beer checkin. This was purely an experimental project and I was amused at the results found on the NerdsDrinking twitter feed. Let’s not kid ourselves, this is no mission critical production application. The entire application comes down to one single file.

I built NerdsAreDrinking on Laravel 5.1 because that was the current version at the time. We have seen two more release since: 5.2 and 5.3. The upgrade process isn’t terrible however there is a lot you may need to take into account. Rather than upgrade from 5.1 to 5.2 and then 5.2 to 5.3 I decided to use Laravel Shift to do the 5.1 to 5.2 upgrade for me.

The Laravel Shift process was pretty easy (Especially when I realized I wanted the Application Shift and not the Package Shift) and the response time on the Pull Request being opened was very quick. You can see the Pull Request from Shift here: https://github.com/svpernova09/NerdsAreDrinking/pull/13 I was really impressed at how clean this process was. The instructions are very clear and the comments are concise and easy to understand. Linking to the default version of the files is also invaluable. As you can see I had to manually reset a handful of files to their default values but overall Laravel Shift saved me time and was well worth the $11 I spent on the shift. I still need to upgrade from 5.2 to 5.3 but I’ll certainly use Shift again.

If you’re dreading doing that Laravel upgrade process I highly recommend you give Laravel Shift a try.

Hope this saves you some time. Thanks for reading.

Laravel Homestead Box Updated to 0.6.0

Between the day job and the amazing week I just had at the always great php[world] conference, I finally got around to doing my first Homestead box release. Taylor asked me a couple of weeks ago if I’d be interested in helping build the Homestead box and since the project is near and dear to me I said “Absolutely”

The first task was to build the Virtualbox version of the box and that went just fine so I uploaded the box and released version 0.6.0.

I noticed that there hadn’t been a release for the VMWare provider in a couple of versions. Once I bought Fusion and the Plugin for Vagrant I gave building the VMWare version of the box a spin. It’s been years since I’ve used VMWare and I did run into some issues. The box built without errors and seemed to work on my machine™.

If you are using an old version of Homestead with the VMWare provider please update to 0.6.0 and let me know if you run into any issues. If you do you can easily revert back to the previous version by adding the following line to your Homestead.yaml file:

version: 0.4.4

Then destroy and vagrant up to go back to using the old box version. If you do have to roll back please ping me on Twitter and let me know what went wrong so I can try to resolve the issue.

php[world] 2016 Laravel Training Day Setup

I’m really excited to be going back to Washington, DC for php[world]. I’ll be doing Laravel Training Day. I’m really excited for this because we’ll be covering Laravel 5.3!

To fully participate in the training exercises you’ll want to follow the directions below. Please reach out to me if you have any issues. If you struggle with the Homestead set up you can skip that part as long as you can run PHP locally on your machine and have a way to run MySQL, Redis, and other services locally. The best advice is to follow the set up instructions below.

Operating System Support:

If you want to follow along and run all of the examples you will need to bring a laptop running a current version of Linux or Mac OS or Windows.

Applications Installed:

Laravel Homestead

Read and follow the installation instructions in this document – http://laravel.com/docs/5.3/homestead

The most important thing to do before the conference is run this command:

vagrant box add laravel/homestead

Testing Homestead:

Create a new Laravel project and require homestead, make the homestead configuration and then vagrant up.

composer create-project --prefer-dist laravel/laravel test-laravel
cd test-laravel
composer require --dev laravel/homestead
./vendor/bin/homestead make --aliases
vagrant up

These commands should run without any errors.

When you’re done, you can destroy the environment by:

vagrant destroy -f
cd ..
rm -rf test-laravel

Thanks for reading, I look forward to seeing you at training day, if you have any problems or errors as you worked through this please feel free to leave me a comment below.