I got a wild bug last week to move my blog to a github page, so here it is. The volume of content that I produce certainly did not warrent a place even on the shared host it was living on. Plus, I’ve been meaning to play around with Jekyll for ages, and really, what better place than this? Please understand that some older posts will be somewhat discombobulated by the conversion process and it’s not likely that I’ll fix them anytime soon.(Continue reading...)
So, php[tek] has come and gone and everyone is hopefully starting to catch up on their sleep. This was my second visit to tek and while it was delightfully familiar, the conference had an entirely different energy compared to last year. From what I hear, this was the largest tek yet, and maybe it was the increased attendance that is responsible for the very different feel. During lunch breaks, the large central atrium at the venue was totally abuzz and each table was packed and lively with conversation. The atrium was pretty well packed, in fact, well in to the night with attendees talking and playing games. Not only was the conference well attended, but I understand that roughly half of the attendees were coming to tek for the very first time. In keeping with the conference’s Star Trek/SciFi theme, each attendee received a color-coded shirt: yellow for speakers (Captains in the chromatic language of the original Star Trek series), blue for repeat attendees, and red for first-timers. The venue was very, very well represented with red shirts!(Continue reading...)
I’ve been in the software engineering business for a long time, but until I was introduced to the PHP community, I never really cared to engage in the social aspect of this profession. I really feel that the PHP community is something unique. It’s rare to find a community that stands on the firm foundation of long-established friendships that is also so incredibly welcoming to newcomers.(Continue reading...)
"What on Earth is a Data Jam?" is precisely the question I asked myself yesterday afternoon when an email inviting me to participate in a White House Data Jam on STEM Workforce Quality, Flow, and Diversity landed in my inbox. Reading through some of the supplied documents made things only a little bit clearer. Despite the confusion and misgivings, I figured being asked if I want to come to a White House anything is a good enough reason to apply the Jim Halpert maxim and simply reply, "absolutely, I do."(Continue reading...)
SkiPHP has been a blast. The organizers have done a fantastic job putting together an amazing conference!
If you're interested in viewing the slides from my talks, they're available on speakerdeck, so please check them out!Continue reading...)
No matter how popular an activity it is, I really don’t like to bash on PHP. Every language has its flaws when you look closely enough, and if PHP wears its idiosyncrasies a little closer to the surface than most, I think it makes up for it in other ways. PHP’s handling of types, however, is confusing at best and at worst completely deranged.
I’ve seen intercity rail schedules that can’t hold a candle to PHP’s type comparison tables. The bizarre and unexpected behaviors that can result from a non-strict comparison has all but rendered the equality operator (==) useless. The typical advice from PHP master to PHP neophyte is, always check for identicality (===) unless you’re very sure what you’re doing.(Continue reading...)
I'll be talking about Service Architectures and REST APIs. Should be exciting! Hope to see you there!
In my last post, I mentioned that where I work, we settled on Bamboo as our continuous integration solution. I love Bamboo, but its built-in notification features are pretty lacking. In fact, your only options out of the box are XMPP messaging (with no conferencing, so meh) or email (yech).(Continue reading...)
Last night at DCPHP, I gave a short "lightning" talk on Continuous Integration and Deployment in the context of PHP applications. I really like the lightning talk format as it forces you to focus on the meat of your topic-- there's no time to get distracted by details. As great as that is, though, I wanted to expand a little on the subject and touch on some of the details that I couldn't include in my presentation.
What is Continuous Integration?
Continuous Integration is a grand-sounding name for a very simple concept. Every time you make a change to your application's code (or, at least, on a very frequent and recurring basis), you build and test the entire application. Each change is integrated in to the application immediately.
Of course building and testing your entire application after each and every commit seems like a big task, and it is. Because we're building so frequently, it's essential that our building and testing happens automatically. Human intervention in the process has to be limited only to occasions when a build fails. When everything builds successfully, it should happen in the background like magic.
What's Wrong With Traditional Build/Deployment Practices?
To answer that question, it's important that we think about everything that usually goes in to building and deploying an application, specifically a web-facing PHP application. Very often there are configuration files that need to be modified. Bootstrap scripts and autoloaders need to be updated. Sometimes we find ourselves writing scripts to move files around, or update databases.
Hopefully part of the process involves running some kind of automated tests.
And once all of that is done, and it's time to deploy, we find ourselves staring at an FTP client. Often we use our VCS as a deployment tool, which is great because typing 'svn update' is so simple, but how many of you have ever left a .git directory or some other VCS artifact hanging out there for the world to see?
Sometimes we're stuck copying and editing files by hand in production, which is the kind of thing that gives me nightmares.
To put it bluntly, building and pushing by hand sucks. It's extremely error-prone and however unintuitive it may sound, the more you do it, the more likely you are to screw something up. When it's two in the morning and you're tired and you've done it a million times before, your attention wanders. You forget a step. You push the wrong thing out to production or forget to run a database update script and now you have a fire on your hands. Several years ago I was manually moving a production application between two servers for routine maintenance. It was something I had done hundreds of times before. I forgot to scp a file over and brought the system up on a month-old copy of the database. It took two days to set things straight again. That was a lesson I don't think I could ever forget.
If that's not bad enough, doing it by hand encourages another kind of laziness. We're developers and when we see problems, it's in our nature to fix them. "It's just a simple fix," we'll tell ourselves. Maybe no one's noticed it's broken yet and a quick edit to that one file will save the headache of a problem report in the morning. Maybe we'll remember to commit the change to the repo as well, or maybe in six weeks that bug will show its ugly face again the next time someone deploys the unedited version of the code from git.
There is a Better Way
Continuous Integration is one of the practices of Extreme Programming and Agile Development. When you think about it, it's a perfect fit. Agile development is all about short, tight iterations. User story, enhancement, build, release. Lather, rinse, repeat. Martin Fowler and Kent Beck first described CI back in the late 90s and Martin's original article is still essential reading for any team looking to adopt the practice.
Before you can get started with CI, though, you need to prepare your codebase. If you don't have automated tests, you're going to need them. Going continuous relies on having confidence in the state of the application and the only way to build that confidence is through automated, repeatable tests.
You're also going to need an environment that's as similar to production as is reasonably possible. Today, thanks to the ease of setting up virtual machines (what up, vagrant and puphpet!?), there's no excuse to develop and test in Windows and then deploy on Linux anymore.
Once your codebase is ready, it's time to start automating your builds. There are tons of tools out there to handle build automation, from ye olde make(1) to rake and phing and ant and maven and so on. I'm personally a fan of phing (which is inspired by ant and php-focused), but feel free to use whatever you're most comfortable with.
While you're evaluating build automation tools, don't forget about your databases! If you use an RDBMS and don't use any database migration tools, start! Database migration tools are like version control for your database, and they provide a framework for deploying database changes in a sane way. Many major PHP frameworks include a migration tool, and there are plenty of standalone tools like dbdeploy, liquibase, and alembic (it's not just for python projects!).
Now the Real Decisions Have to be Made
What does a good build look like? How much code needs to be covered by tests before you feel confident to deploy? Should a build fail because a developer failed to follow a coding standard or forgot to add auto-documentation tags to her comments? Should a build be considered successful even if the number of findings from your static analysis tool doubled since the last release?
These are questions that every team needs to answer for themselves, but when you think about it, having to consider what concrete, objective criteria need to be met before you deliver software is a great problem to have!
This is a good time to start looking at Continuous Integration servers. There are tons of them out there, both free and commercial, but they all perform essentially the same functions. The CI server is the tool that's going to monitor your VCS repository for changes, run your build automation scripts, notify your team when things go poorly, and kick off your deployments.
In a future article, we'll explore each of these stages in more detail, so stay tuned!