Today was my last day at 18F, the startup-like agency inside the U.S General Services Administration I joined back in September 2014. When I joined I wrote: “Working with a team of talented individuals to create a more open, transparent, and accessible government is a cause close to my heart.” That’s still true. It’s also true that, four years in, nobody has used their political clout or tenure to shut it down as was foretold to me by a former colleague.
It might be easy to see my leaving as politically driven by the administration change. It is not. While there are more politically appointed individuals overseeing 18F and TTS’s work than when I started, any notion that the organization was taken over by the White House, or that they are now expected to be White House loyalists, is overblown. We took an oath to protect and uphold the Constitution and that includes the 14th Amendment which promises equal protection under the law. No American should see their government services degraded just because the people who deliver it happen to disagree with the people setting the policy. There’s a broader academic argument but it’s not for this post.
I’m leaving because my term is almost up and when I look back on it, it’s kind of staggering how much I’ve gotten to work on over the last 3 years, 4 months, and 9 days at 18F.
I was part of the team that figured out what the 18F website needed to do for people and rebuilt it basically from scratch to better serve the agencies trying to work with us. I didn’t do much (any?) of the building, but my team knocked it out of the park.
I helped the team that implemented the United States’ first open data law write about how they got every federal agency in the government to report spending data in the same way. It’s called the DATA Act, and it was a massive undertaking. See their work: https://beta.usaspending.gov/#/ and learn more about it: https://18f.gsa.gov/tags/data-act/
More recently I worked with the cloud.gov team build a Platform as a Service designed to comply with federal policy. It’s the first fully open source product to be authorized by FedRAMP. For the layperson reading this, it’s a big damn deal. FedRAMP is the federal cloud services equivalent to a boundary waters outfitter telling you to go with the WeNoNah canoe. You still need to decide if it’s right for you but it’s a strong endorsement.
I learned a lot about how government contracting works, enough to know that I’ll never come close to knowing everything. I scratched the surface working with the team behind CALC, a market research tool that helps contracting officers determine a fair market price for professional services.
And then there’s all the things that happened while I was at 18F. Even if I didn’t get to help build or write about them, it was inspiring to be on the same team as those folks.
The federal government employs some of the most talented individuals I’ve ever worked with. They’re motivated by honest and passionate service to the American public. That was what I signed onto when I joined in 2014 and, though many of the faces behind it have changed, that spirit remains.
As for me, I’m off to Automattic where I’ll continue working for a passionate, open source team helping WordPress.com customers have a great experience with a product I’m passionate about. WordPress helps people around the world tell their story, whether it’s an individual food blogger or a major newspaper.
Since around June, I’ve worked on 18F’s cloud.gov product and this week marked my last quarter on the team. We end every quarter with a so-called “innovation and planning” sprint. The product managers do the planning and the team members do the innovating. Innovating in this context means working on parts of the product that will benefit users that aren’t part of the normal business work. I chose to work on improving the WordPress example app we maintain for our users.
If you’re not familiar, cloud.gov is a Platform as a Service built by federal employees and designed around the specific security and regulatory concerns federal agencies need to consider before they’re authorized to launch a web product. No matter how big or small, whether it has open data or national secrets, all information systems operated by the federal government are required to undergo some kind of evaluation against standards published by the National Institute for Standards and Technology (NIST). The result of this process is the granting of what’s called an “Authority to Operate,” or ATO. Basically, an ATO says that the system meets the requirements outlined by NIST and the agency has accepted any risks the system might present. If an agency runs several websites they end up with a lot of repetitive documentation for components that may be the same across each individual app. cloud.gov attempts to solve this problem by standardizing many of those common components so that the agency only has to worry about the parts of the application that serve their mission directly.
It’s a fully open source and based on the Cloud Foundry PaaS project. Compared to how I’ve launched and managed WordPress sites in the past it’s a pretty big shift in how to think about the product. The main shift is finding ways to not rely on the filesystem.
To do that means pushing your uploaded files straight to S3 or another cloud storage service. It also means session information needs to be stored in a cloud service like redis. Most of the example we cribbed from Cloud Foundry’s example WordPress app but due to slight differences in our infrastructure environment, we needed to make a few alterations. The most significant was the recommended plugin for connecting to S3. Cloud Foundry’s example used a more robust AWS plugin but one that required extra effort for us to connect to Amazon’s GovCloud environment. Using that plugin meant installing two plugins from WordPress and then writing and maintaining our own helper plugin to interface with them. Human Made’s plugin was a drop in plugin that already pulled credentials from the environment and was much simpler to configure for cloud.gov.
Getting this up and running reminded me of the work I did at CFPB getting their then-WordPress site — the last major WP site I worked on — into a stable, easily deployable production environment and how much easier that all would have been with cloud.gov at our disposal.
We configured WordPress very similarly to how cloud.gov arranges the pieces. Uploads were synced to S3 and we heavily cached the site — including the local session. The difference is that we spent weeks, maybe even months, writing and maintaining a Fabric project that could install plugins, update the themes, and manage the version of Core we ran in production and then getting our CI server, Jenkins, to automate the deployment of it all. We ended up with a well-functioning DevOps flow for consumerfinance.gov that didn’t require any of us to be physically around whenever someone needed a deployment to happen. All of that was good and important work, don’t get me wrong, we were rightly proud of what we did. The point is that a product like cloud.gov could have saved us a ton of time because a lot of that orchestration is done behind the scenes.
If we’d had a platform like cloud.gov to start from, we could have saved ourselves a lot of that work and focused on other things closer to our mission.
WordPress was the first open source project I ever worked with and the one that taught me how to be a professional developer. cloud.gov has the potential to make government web applications faster, more reliable, and more secure. The two of them together make up a giant stack of open source code. I’m glad I had a chance to bring these passions together.
I’ve been writing this blog as a Jekyll for quite some time now. There’s a lot I really do love about the idea of static sites, but also a lot I’ve cooled on. One of those things was the writing experience.
My first encounter with Jekyll was at CFPB and I briefly switched to Octopress while I was learning how it worked. At 18F, I decided it’d be prudent to eat my own dog food, as it were, and host my blog the same way we hosted the site I was managing, 18f.gsa.gov. It’s been three years on Jekyll now and while I love a lot about Jekyll and the paradigm of static sites, I’ve grown tied of the work I have to do just to publish a new post. I’ve written about this before and won’t repeat myself but I was hopeful that there would be a product, open source or otherwise, that would give all the advantages of static hosting with a writing and publishing experience that was just as simple and powerful. The fact is, there’s not.
And it turns out easy publishing on a trustable platform is all I really want.
Getting here meant I had to write a Jekyll plugin and a page to generate a WordPress eXtended RSS (WRX) file out of the old Jekyll site. Most of the work was done in the liquid page, except for custom fields which were filled in with the plugin. The only problem I’ve noticed so far was about 22 pages with no title that were in the WRX file — these were Jekyll paginator pages and the WRX file itself also generated as HTML 🤷♂️.
Jekyll has become one of my favorite things lately. At 18F we’re using it to power our website but also our Hub project which includes serving up snippets, our weekly team updates submitted by Google Form, as well as a tremendous amount of information that is a mix of pages restricted to our team and some that is public. The Hub uses Prose to allow people less comfortable with GitHub and Markdown to edit Jekyll pages with something closer to a What you See is What You Get (WYSIWYG) interface than a typical markdown document has. Prose is a great tool, and I’m not just saying that because we use it. But for many static sites haven’t quite gone far enough, and that’s okay.
Early adopters like static sites a lot. People who bought one of the first Blackberries or used WordPress in 2006, for example, might like static site generators a lot. People who like Markdown or other markup languages enjoy static site generators. And some appreciate the simplicity of configuration found in static sites, especially the lack of a database. For many people like me it is a refreshing focus on writing without the complications of The Admin UI that have plagued even the best CMS platforms.
An example of these complications? I recently helped my wife with some settings on her blog and was reminded how confusing the WordPress Admin can be. Where do you think you should go to set your front page to display a page instead of latest posts? Settings > General? Settings > Writing? Settings > Media? The answer: None of the above. It’s Settings > Reading. I guess when I think about it that makes sense, you’re changing a setting that changes the experience for someone reading your site.
At the same time, there are still some things that a CMS does really well that static site generators
lack. At least to me, Jekyll’s simplicity is a feature that forces me to think about the value of, for example, a tag archive or automatic image formatting before implementing it. With a CMS these features are there waiting for you to use or extend. WordPress for example provides a really simple API to extend the WYSIWYG interface with ‘shortcodes.’ All of this comes in handy when you need to create a blog post with images floated left and right and center, or when building that tag archive (easy as it may
be) means taking away time from publishing real content.
If I’m not a developer, needing to become one or hire one just to start writing a blog post is a pretty high barrier to entry. Feeling like I need to become one just to write a blog post is even higher. The reason I became a developer in the first place was that in 2006 when I needed to reboot my college radio station’s website WordPress was insanely easy to install and configure and gave us almost everything we needed (with the right theme and plugins), and in 2009 when I built the first version of HarmsBoone.org and International Underground I didn’t need to learn much beyond CSS and a few WordPress methods. When I eventually needed to know more it was still a fairly low barrier to entry and we always had a website that everybody could edit. In particular, Child themeing is particularly useful for learning WordPress on the fly.
Static sites, for all their simplicies and technical advantages, still have a pretty high barrier to entry, especially if you need to overcome the limitations GitHub pages puts on Jekyll sites. And to be fair, WordPress has significant (read: 8-10 year) head start over Jekyll plus the entire WordPress Core and Automattic teams nurturing the developer base.
Nevertheless, without lowering that bar and adding some of those features it will be really hard to get broader adoption among people who want a Just Start Writing Already. For many, logging in to the WordPress Admin and using the WYSIWYG either to write or to paste in copied text will always be preferable to editing monospaced text with strange formatting signals around it, even if there are buttons to help them out. (Let’s not belittle the bar-lowering power or Prose, Dillinger, and other Markdown helpers, though, for some they may be exactly the right tool.)
It will remain preferable even if they rely on a bookmark in their browser, or an icon on their desktop to get them to the admin screen. Clicking “Preview” will be preferable to navigating to running a shell command and then heading to localhost:4000 because what’s a localhost? What’s that colon all about? And what’s so special about 4000? And clicking “Publish” will definitely be preferable over committing a git workflow to memory.
These are problems Static Site Generators can solve, and part of what makes them beautiful is how they are malleable to each user’s needs. And if you put
a developer on the comms team you’ll be able to build the site you need on the platform that works because you’ll ask your users what they need and how they work. If your users need to
copy and paste blog posts from Google Docs, give them that. If they want a WYSIWYG editor for writing and collaborating on posts, give them that. If the need the full WordPress UI, give them that. I’m not trying to sound flippant. Building a WYSIWYG on top of Jekyll would be a difficult problem, but it’s not
impossible. Using Google Drive as a CMS will also take work, it’s not impossible. Building GUI applications to abstract away the command line is difficult, but not impossible.
There are hundreds of content management
systems and static site generators operating on nearly every language in existence (including FORTRAN). And there are WordPress plugins for nearly everything imaginable at this point, and usually there are three of four of them to choose from. Your mileage will almost certainly vary from one solution to another but go with the solution that will make your content creators most comfortable.
Note: I’m not maintaining this open source project anymore. There was a pretty cool reception to it and I didn’t have time to maintain it for just myself. I still think it’s a good idea, though. 🙂
About five months ago I left the riveting world of WordPress development for the greener pastures of helping a government startup manage its website, and while I’ve become pretty taken with Jekyll lately, there will always be a part of me that loves WordPress. And so, like a good hacker, I started a side project I’m calling rePress (a name that, admittedly, needs work—see below).
The first two of these solutions are WordPress plugins, and the second generates content from an API. This combines the two ideas by creating generator plugin for Jekyll sites that relies on the REST API currently being integrated into WordPress Core. Right now that API is only available as a plugin, but it will one day (soon, I think) require only a clean WordPress installation.
Once you have the API exposed, you need only point Jekyll to the root endpoint and run jekyll build on your server or your local environment. Right now it will grab the 9 most recent posts and parse out the published title, date, tags, authors, and excerpts, and, of course, the post content and generate HTML files with proper Jekyll frontmatter. This has a couple benefits: it allows you to import your WordPress posts without exporting any files and it allows you to choose whether to write Jekyll Markdown or use the WordPress editing interface.
It definitely has a long way to go, but it’s something I’ve been excited about creating pretty much since the REST API project was first announced. I’ll be pushing updates to GitHub, and would love any suggestions you have. In particular, I kind of hate the name I came up with, but all the original ideas like JekyllPress, StaticPress, and Hyde all mean other things related to Jekyll and WordPress. So here I am, with a name that means subdue by force which is not at all what this does or is intended to do. I’m open to name suggestions but know that it’ll probably change at some point.