Speaking to a bigger audience

Last week, I had the privilege of giving a lightning talk at WordCamp US in Nashville, TN.

It’s not a surprise that speaking at a much larger event is a very different experience from speaking at my local WordCamp. One thing that stands out as odd is that I really have no idea who was in the room aside from the ten people in the very front. At WordCamp Raleigh, I can see every person in the room, and I remember almost all of them (or it feels that way). With no Q&A after the lightning talk, it felt so much less like a conversation. It was all much more… anonymous.

Continue reading “Speaking to a bigger audience”

Becoming a real WordPress dev

Fall 2014 – Set up a continuous deployment pipeline for our new WordPress install using git, Composer, and Bamboo.

Early 2015 – Figure out CMB2, create our first custom template for pages.

2015 – Implement RAMP, including configuring, customizing, and extending its capabilities over the course of the year-or-so.

2016 – Establish the process for “dark launch” of content, including conceptualization of tools written in WordPress to support the process (tools actually written by co-worker).

2017 – Create “self-healing” templates to get around thorny CMB2 / RAMP issues.

Summer 2017 – Create bash / WP-CLI scripts to automate the duplication, dark launch, and swap-out of a large content area to make the process of major revisions to that area seamless.

Winter 2018 – Create a taxonomy template and use The Loop for the first time. Finally become a Real WordPress Dev.


What I learned about Gutenberg at WordCamp US 2017

Usability testing

I volunteered to proctor Gutenberg usability tests at WCUS. In part, it seemed like an easy way to help out since I've proctored a lot of usability tests over the years for work and I know the drill. But I also had my own interests; I wanted to talk with the people most closely involved in Gutenberg in a place other than a very busy Slack channel, or Trac. Not to come at them with an agenda, or negativity, just a chance to talk and find out more.

Continue reading “What I learned about Gutenberg at WordCamp US 2017”

Deploy and RUN!

I don’t remember how it started. At some point I realized that I was deploying some new code right before going on vacation, leaving for the weekend or… something. The first time I mentioned it on twitter was in March 2015…

Is this confidence in our setup? Is this just stupid? It brings me great delight. I approach it with glee. I’ve even gotten my co-worker S. on board; today our co-worker R. was horrified to realize she’ll be running a couple of big content launches soon, and going on vacation immediately after each one. S. and I just said, “Deploy and run!! YES!!!”

BUT you know the thing is, when you deploy all the time, almost daily, both code and content… it’s going to happen. You can’t hold off on deploying all the time. Most things can be rolled back. Nothing reaches the live site before it has been tested and used by multiple people. When deploying constantly, deploys tend to be small, often with low overall impact to the site. [1]

The other day at work there were signs at both of the main building entrances. The signs were to thank the people involved in a large, multi-year effort to launch a new application. It’s an important application, dealing with customer data, and a lot of people worked on it. They deserved hearty thanks and recognition.

When you deploy and launch constantly, though, there are never signs in the lobby. Each launch flies under everyone’s radar. Deploy and run is fun because it’s bad, long years of IT experience say we’re not supposed to do stuff like that… but with constant small deploys we’ve achieved pretty good stability in the site, and even though it feels like we’re breaking the rules, it’s usually pretty safe.

Today I’m deploying some content using a new process and some new scripts I’ve been writing. It’s a little more complicated than a normal content deploy (and deserves its own blog post). I’ll be touching about 75 pages in one way or another. I’ll be running wp-cli directly on the live site, which gives me pause. Then I’ll be gone for a week, and another critical team member will be out for a few days as well. As deploy-and-runs go, it’s a big one…

Whee! Right?


[1] What would be really perfect is if we used feature flags…