Subscribe: Ben Ramsey
http://benramsey.com/feed/
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
aws  code  codebuild  company  ebs volume  i’m  i’ve  jenkins  ramsey  shootproof  tek  testfest  tests  volume  work 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Ben Ramsey

Ben Ramsey



Web Craftsman, Author, & Speaker



Updated: 2017-08-16T02:07:01+00:00

 



Announcing PHP TestFest 2017
For those who’ve been around the PHP community for a while, you’ll recall the successful PHP TestFest events that began after a discussion at PHP Quebec in 2008. Many user groups and mentors signed on to host and help with events, and a lot of folks became first-time contributors to the PHP proje... For those who’ve been around the PHP community for a while, you’ll recall the successful PHP TestFest events that began after a discussion at PHP Quebec in 2008. Many user groups and mentors signed on to host and help with events, and a lot of folks became first-time contributors to the PHP project, helping improve our code coverage. It ran strong in a global sense from 2008 to 2010. After that, various groups (particularly the Brazilian groups) have continued the tradition. A few months ago, at php[tek] in Atlanta, I mentioned to Michelangelo that I’d love to bring back PHP TestFest. Sammy had given an excellent talk on writing PHPT tests, and Gemma tweeted a link to the old PHP TestFest wiki page. From there, things snowballed. We’re bringing back PHP TestFest! The PHP TestFest will run for 4 months this year: September through December. This should give groups plenty of time to plan and prepare one or more local events. In early January, we will award prizes; if your organization/company is interested in offering products or services as prizes, let us know (send email to sponsors@phptestfest.org). This time around, I’ve set up a dedicated website at PHPTestFest.org and Google Group for discussion. We also have the #phptestfest channel on Freenode IRC. All are encouraged to contribute to the website and tools repository. We need technical tutorials, as well as tutorials from veteran TestFest organizers on how to lead successful PHP TestFest events. Additionally, I’ve provided a stub for a console application in the repository, and I’d love to see that evolve into a robust tool for helping people write and contribute PHPT tests. I’ll be updating the “Getting Started” page on the PHP TestFest website soon with this information and more, so keep posted. Let’s get to work on improving code coverage of the PHP language! Special thanks to Sammy for letting us use “Wooble” as a testing mascot. This announcement was cross-posted to the php-qa, ug-admins, and phptestfest mailing lists. Ben Ramsey is a web craftsman, author, and speaker. He is a software architect at ShootProof, where he builds a platform for professional photographers. He enjoys organizing user groups and contributing to open source software. Ben blogs at benramsey.com and is @ramsey on Twitter. “Announcing PHP TestFest 2017” was originally published at benramsey.com and is Copyright © 2017 Ben Ramsey. It is licensed for use under a Creative Commons Attribution-ShareAlike license. [...]



Building PHP Projects on AWS CodeBuild
At AWS re:Invent, Amazon announced a new service for building and testing code: AWS CodeBuild. They provide managed environments for Android, Java, Python, Ruby, Golang, and Node. While PHP is missing, it is possible to build PHP projects using the service. Follow along to find out how. I’ve had a great time at AWS re:Invent this week, attending sessions and hanging out with some of the ShootProof team. My favorite part of the week was the “mini con” on containers. I spent Thursday immersed in sessions dedicated to deploying Docker containers on AWS. Of course, the main hightlight of re:Invent is always the keynotes and the new services and features announcements they make during the keynotes. One of the new services caught my attention, and I decided to give it a try. That service is AWS CodeBuild. CodeBuild is designed to be used as part of the AWS CodePipeline, but it may also be used by itself. Additionally, with AWS’s increased focus on their container service (ECS), it’s designed to integrate with ECS to use images you’ve stored in AWS, but it may also use images available on Docker Hub. Out of the box, CodeBuild provides some managed images that you may use to build your projects. These include environments for Android, Java, Python, Ruby, Golang, and Node. PHP is missing from this list, but since you’re able to use other images, I decided to see how easy it is to get up and running on CodeBuild with a PHP project. I chose to try out my ramsey/uuid library for a simple test. Feel free to follow along with me. Getting Started From your Amazon console, search for “CodeBuild” from the AWS Services search box, and choose it from the drop down menu that appears. Figure 1. Search for “CodeBuild” from the AWS console If you’ve not yet begun playing with CodeBuild, you’ll see a page like the one in Figure 2. Click the “Get Started” button to begin. Figure 2. Getting started with CodeBuild Configuring Your Project Figure 3 shows most of the options available when configuring a project, pre-filled for the ramsey/uuid library. I’ll step through each option to explain what’s going on. First, provide a project name. Here, I’ve named the project “ramsey-uuid.” For Source provider, choose GitHub and then click the link provided to connect to GitHub. This will take you through the OAuth dance to grant AWS with access to your GitHub account. Afterwards, the Repository drop-down will be populated with a list of your GitHub repositories. Here, I’ve selected the uuid repository. Next, you need to tell CodeBuild how to build your project by specifying an image to use. To use an image in Docker Hub, select “Specify a Docker image” for Environment image and choose “Other” for Custom image type. For the Custom image ID, I’m using benramsey/composer-uuid:latest to specify the repository, image name, and image tag. You may place a buildspec.yml file in the root of your repository to specify build commands (similar to a .travis.yml file). Since ramsey/uuid doesn’t have a buildspec.yml file, I’m specifying the Build commands directly. While there is an official Composer image on Docker Hub, it is currently based on the php:7-alpine image (see the Dockerfile for reference). The PHP image using Alpine Linux will not run on AWS CodeBuild. Until this is resolved, I recommend using Rob Loach’s composer/composer image, which is what I have used as the basis for my benramsey/composer-uuid image. The full build command I’ve specified for ramsey/uuid is: composer install --no-interaction --prefer-dist \ && ./vendor/bin/parallel-lint src tests \ && ./vendor/bin/phpunit --verbose --no-coverage \ && ./vendor/bin/phpcs src tests --standard=psr2 -sp Finally, I’m not generating any artifacts for this build, so I selected “No artifacts” for the Artifacts type, and I chose to let it automatically create a service role in my account. Our project is now confi[...]



7 Tips for php[tek]
This week, I’m attending php[tek]. This is my seventh php[tek], and the first I’ve attended not as a speaker. It’s one of my favorite conferences, and I didn’t want to miss its first year in a new city: St. Louis. As we gear up for the eleventh php[tek] conference, I thought I’d list my seven tip... This week, I’m attending php[tek]. This is my seventh php[tek], and the first I’ve attended not as a speaker. It’s one of my favorite conferences, and I didn’t want to miss its first year in a new city: St. Louis. As we gear up for the eleventh php[tek] conference, I thought I’d list my seven tips for getting the most out of your php[tek] experience. Hang out in the evenings, after the conference sessions. php[tek] is known for hosting events in the evening, from video games and board games to hackathons. Make sure you you stick around and take part. One of the best features of PHP is its community, and taking part in the events following the day’s conference sessions is a great way to build relationships in this community. After the conference events, follow folks to the bar. Do you have to be a drinker? Nope. There’s much more to a bar than drinking. In Chicago (Rosemont), php[tek] had Shoeless Joe’s, a nearby sports bar, where attendees would congregate each evening following the conference activities. In St. Louis, I don’t know what that place will be, but I’m certain there will be one. This is where relationship-building continues. There’s so much that can come from these relationships—friendships, business opportunities, mentors, and more! I closed down Shoeless Joe’s with @cspruck, @ElizabethN, @derickr, @coderabbi, @JimLindForPope, @dshafik, @ptahdunbar, et al. #phptek— Ben Ramsey (@ramsey) May 23, 2014 Having begun a new job myself, I shared Ed’s sentiment. Last weekend, while at the Madison PHP Conference, we were discussing what developers can do during the interview process to get an idea of the kind of codebase a company has. After all, the developer is interviewing potential employers just as much as they are being interviewed as a potential employee. It would suck to be hired only to find the code is in shambles. Short of signing an NDA and asking to see the their code, what can you do? Here are a few tips I think go a long way in helping determine the state of a company’s codebase. If you have other ideas, feel free to leave them in the comments. Ask what coding standards the company follows. Can they articulate those standards well? Grill them on specifics. Be sure to ask this of the developers and not the managers. Otherwise, you might not get a good picture of how standards factor into their practices. For PHP projects, you should hear something about PSR-2 and PSR-1. If not, then at least the old PEAR coding standards should come up. Ask whether the company uses a dependency/package management tool. Answers to this question are a good indication of whether the company subscribes to a not invented here (NIH) philosophy. Companies that reuse code from a variety of third-party packages tend to—in my experience—have better structured and cleaner codebases. I’m not sure why this is, but I suspect it’s because the developers have more exposure to how others are doing things and pick up on best practices in this way. For PHP projects, you should hear the company talk about their use of Composer. At the very least, they should mention PEAR, but PEAR is waning. Ask how much of the code is covered by tests. There are unit tests, functional tests, integration tests, and acceptance tests. Maybe there are others that I’m not aware of. Start a conversation about which testing strategies the company uses and how many tests they have. For PHP and web projects, there are many [...]



Setting Up Jenkins on Amazon Linux for PHP Testing
One of my first tasks at ShootProof was to set up a Jenkins server for continuous integration and get it ready to run unit tests for PHP and JavaScript code. There are plenty of tutorials around the web to help you do just that. This is yet another one, but it's primarily my cleaned-up notes—and ... One of my first tasks at ShootProof was to set up a Jenkins server for continuous integration and get it ready to run unit tests for PHP and JavaScript code. There are plenty of tutorials around the web to help you do just that. This is yet another one, but it’s primarily my cleaned-up notes—and less of a tutorial—placed here for my future self to find and provided publicly for all to benefit. These instructions are specifically tailored for setting up Jenkins on an Amazon Linux EC2 instance. If that’s not what you’re running, your mileage may vary. These commands should run on RHEL-based systems, and with modifications to the package manager and names of packages, they should work on other Unix-like systems. 1. Launch and Prepare an EC2 Instance The Amazon Linux AMI I used was the latest (at the time) paravirtual, 64-bit, instance store AMI (ami-ed8e9284), but choosing the latest for your region should work just fine. You can use an EBS-backed volume instead and set up regular snapshots of it, or you can follow these directions, create an AMI from your configured instance, and set up regular snapshots of the EBS volume we attach to the instance. Either way will work fine. I just happened to use an instance store with an EBS volume attached. Launch an EC2 instance (use this link to launch one, if you like) Create an EBS volume Attach the EBS volume to the instance you launched SSH to the instance, format and mount the EBS volume (see below) I’m using XFS for the EBS volume’s file system, but you may use what you prefer. We’ll mount the volume at /var/lib/jenkins, so that we don’t have to do any complex trickery with the default jenkins user, home, and permissions. The EBS volume may exist at /dev/xvdf, as it does in the following example, or it may be attached at another point. See also Amazon’s guide to “Making an Amazon EBS Volume Available for Use.” Note: All of these instructions require root access. You may prefix them with sudo, or you may change to the root user. $ yum install xfsprogs $ mkfs -t xfs /dev/xvdf $ mkdir -p /var/lib/jenkins $ mount /dev/xvdf /var/lib/jenkins Now, the volume is mounted at /var/lib/jenkins. We want to ensure it always gets mounted there when we restart the instance, so let’s add a line to /etc/fstab: $ cp /etc/fstab /etc/fstab.orig $ sh -c 'echo "/dev/xvdf /var/lib/jenkins xfs defaults,nofail 0 2" >> /etc/fstab' $ mount -a 2. Install and Start Jenkins Installing and starting Jenkins is fairly simple. We need to add the official Jenkins project repository to the list of yum repos, and then we install with yum, start the service, and ensure that Jenkins starts up on a reboot. $ wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat-stable/jenkins.repo $ rpm --import http://pkg.jenkins-ci.org/redhat-stable/jenkins-ci.org.key $ yum update $ yum install jenkins $ service jenkins start $ chkconfig jenkins on 3. Configure the Server for Running Tests Now, we need to install some stuff on the system so that Jenkins can do its thing. These instructions are intended for tests that use the Template for Jenkins Jobs for PHP Projects. This will give you a basic PHP installation with all the tools necessary to run the template. If you need to use anything that deviates from the stock template, then you’ll need to make changes. $ yum install ant git graphviz gcc gcc-c++ $ yum install php55 php55-devel php55-common php55-cli php55-intl php55-gd php55-pecl-imagick php55-mbstring php55-mcrypt php55-mysqlnd php55-pdo php55-pecl-xdebug $ sh -c 'sed -i "s/^memory_limit =.*/memory_limit = 256M[...]



My First Month at ShootProof
My first day at ShootProof was July 1st, and as I've come to my one-month anniversary with the company, I wanted to share some of the reasons that attracted me to ShootProof and why I'm still excited about it, after a month of working here. It’s difficult to write a blog post about a new gig without coming across as sounding critical of past employers. That’s not my intent, but this first month I’ve spent at ShootProof has been one of the best months I’ve had in a long time, career-wise. My first day at ShootProof was July 1st, and as I’ve come to my one-month anniversary with the company, I wanted to share some of the reasons that attracted me to ShootProof and why I’m still excited about it, after a month of working here. The Team The primary reason I joined ShootProof was for the team. I had worked with Robert Swarthout and Brian DeShong previously at Schematic (now POSSIBLE). We worked well together then, and the opportunity to work with them again was almost too good to be true. On top of that, ShootProof hires the best. With folks like Jenn Downs, Terry Allen, Kevin Bandy, Josh Davies, Colin Breece, and the rest of the ShootProof team, ShootProof really is a dream team. At PHP Tek 2009, my friend Sean Coates gave me some awesome career advice. He said, “You need to work with people who know you.” At ShootProof, I am doing just that, and it’s a great working relationship. Bootstrapped Another thing that attracted me to ShootProof is its funding. As of today, it’s 100% bootstrapped. Ideologically, I’m not one of those who say your company must be bootstrapped or VC funded. There are pros and cons to both types of funding. But having experienced VC funding, a bootstrapped company had a certain appeal to me: all the investors have “skin in the game” in both the monetary investment sense, as well as the agile “pig” sense. What this means for me is that I work on a daily basis with the primary decision makers in the company, and these decision makers answer only to themselves (and our customers). There’s a great deal of freedom and trust in this relationship. Will we always remain bootstrapped? That’s not a question for me to answer or even to presume to know the answer. There are a variety of reasons we may or may not consider funding in the future, and that’s a question for our founders to tackle, but for now, the fact that we’re bootstrapped is important to me. It all comes back to the team. We’re intimate. We’re lean. We’re agile. We’re not tied down by VC money. We work only for our customers and ourselves. Top-notch Support Team After meeting with Colin, I realized that ShootProof not only prides itself in building a great product, but our special sauce is our customer support team. Our loyalty builders will do whatever it takes to ensure the happiness of our customers. I know this makes me sound rather dense and naïve, having worked in the industry for so many years, but after hearing about the work of our customer support team, I realized that customer support is just as much a part of our product as the code that makes up our web properties. I’m proud of the work they do, and I’m excited to be a part of their team. User Experience Along with customer support, ShootProof is working to ensure we have the best possible user experience for our customers. That’s why we have ace UX folks on our team. User experience has always been an important cornerstone of software development to me. How users feel when they interact with your software interface determines whether they want to continue using it or not. Working at Schematic showed me how UX must be a discipline to any software company. I am more than thrilled that ShootProof feels the same way and has made it a crucial tenet of our process. Product As Brian said in his “Joining ShootProof” blog post, I also sought out ShootProof because I love to build pr[...]