Archiving my Fusion.net posts

Archiving two posts on Fusion.net that I wanted to save for posterity.

The Intro: Davis Shaver

Who are you, and what do you do?I’m Davis Shaver, a journalist-turned-developer on the Fusion technology team. Before joining Fusion, I worked on the operations team at Project Thunderdome (as the Thunderdome joke goes, two men entered and both left) and started the Penn State news website, Onward State. I’ve been in the news industry since summers spent in high school stringing for my hometown newspaper, the Lebanon Daily News. It was a Thunderdome colleague, Daniel Bachhuber, who first told me this fall about the opportunity with Fusion.

Most of my commits these days go towards Fusion’s main WordPress site and our internal analytics dashboard, Glance. I also contribute to Shortcake, our open-source effort to make WordPress shortcodes easier. In general, I see my job as using code and design to make it easier for Fusion’s all-star bench of talent to produce and publish content, and to make it more delightful for our various audiences to enjoy that content. Convergence journalism often entails technical complexity, and minimizing that complexity to end-users takes considerable thought, investment, and effort.

What’s your preferred hardware and software setup?

At my coworking space in Philadelphia, I use a MacBook Pro 13” Retina with two secondary displays, a gorgeous Dell 24” UltraSharp screen and a generic 21” monitor. I also have a TV used occasionally to access the Fusion app through my Apple TV. An iPhone 5S, iPad Mini, and Xbox One round out my personal technology stack. I use a MacBook Air occasionally for travel.

For software, on iOS and Mac: TweetBot, Slack, Spotify, Messages, Hype Machine/Plug, Reeder, Clear, Sunrise, Mailbox, Meldium, and Simplenote. I’d be far less organized without Clear and Sunrise – if I have to do something, it gets recorded or it doesn’t get done.

For development, I switch between Sublime and Atom, running Zsh in iTerm. I use Github.com in a single-site browser created with Fluid (I’d prefer native, but we use issues and milestones extensively for project management). For local development, I run WordPress VIP’s QuickStart stack. Sketch is my go-to design tool, but nothing’s better than laying out a complex systems diagram with Omnigraffle.

How do you consume media? Any favorite formats or publications?

I still pine for the days of Google Reader – it was my proto-Twitter, my friends and journalists I followed sharing and discussing links with each other.

Today though, most of my media comes through Reeder (with Newsblur and Feedly Pro for different feed sets) and Pocket (via Twitter). I’m also a loyal Amazon customer, and it doesn’t take much for me to 1-click order an ebook I see mentioned.

For music needs, I use Spotify, but on runs, I stick to podcasts and Audible audiobooks. Right now I’m going through Bertrand Russell’s History of Western Philosophy, and it’s a delightful counterbalance to the instantaneousness of Twitter.

What excites you most about what’s coming next at Fusion?

Our editorial talent is unreal. Margarita Noriega, Dodai Stewart, Felix SalmonAlexis MadrigalKevin Roose, Tim Pool – a lineup of digital journalists diverse, adventurous, and excellent at what they do. Not to mention broadcast stalwarts like Jorge Ramos and Alicia Menendez.

But on the technology side specifically, our CTO, Hong Qu, and interim director of engineering, Daniel Bachhuber, are laying the groundwork for digital media’s next great technology play. What’s the best way to run a distributed media technology team? How should recruitment and hiring take place for this kind of team? And, perhaps most importantly –– what should we be building?

We want our technology and product culture to rival that of BuzzFeed, Vox, or the New York Times, but with its own unique identity, and it’s super exciting to not simply have that huge of a goal, but also the runway, product vision, and team needed to make it possible.

How we use Github to release quality code at Fusion

Anyway, you’re freshly returned from the first team meetup, and ready to push some code. What next?As a seasoned developer (more Sriracha than salt), you’ve already got a local development environment backed by the WordPress.com VIP Quickstart repository. Your product manager has a nicely groomed Trello ticket ready for development, UX has added the design and interaction notes.

A well-groomed card in Trello. Cards usually represent 2-5 days of effort.

Now – let’s make some web!

1. Create a feature branch

Fixing a bug? Make a new branch!

Adding a feature? Make a new branch!

Changing a style? Make a new branch!

ALL changes to our codebase get put into a branch first. This lets us see specifically what is being changed within a project, and be intentional about what ends up in master.

How do we name branches? We follow this pattern: (number of original Github issue)-followed-by-keywords-describing-the-project. Using this pattern makes it easy to locate branches when there could be dozens in development at once, and later in the process, this branch name is what we’ll give product managers so they can checkout the work to our staging server and vet the design and functionality before release (we use a homemade tool called Git Switch for this).

We built a small plugin for WordPress that makes it easy to switch git branches on a development server. It’s open source, natch.

2. Write commit messages

As you’re changing code, be deliberate about commit messages. Use the commit title to describe the technical aspect of the change. We’ve all done personal projects where the repository ends up looking like this:

Don’t write commits like this.

But doing this in a team environment would classify either as a grave sin, or a stellar troll. We want to be sustainable with our development practices, which means that our production code is abstracted, well-documented, and peer-reviewed. Here’s the type of commit message we like to see in the log – it explains why and what.

3. Publish the pull request

After you’ve got the feature built, or the bug squashed, or the design implemented, then it’s time to publish the pull request. Some development shops will use Hub to create a pull request from the original Github issue, but we prefer a separate pull request because occasionally a specific Github issue is targeted over multiple branches (see that screenshot above).

The description of the pull request should describe the work and include before/after screenshots. The description should also link to the Github issue and Trello cards associated to the work.

By the time you’ve add all that to the pull request, your first run of tests on the Github-connected Travis website will have probably completed. You had a good feeling they were going to pass, as you ran phpunit and jasmine locally before pushing the branch, but it’s always nice to see those green checkmarks light up.

Living dangerously is committing your code without knowing if your test will fail.

4. Go through code review

Let’s recap. You’ve done the deed and pushed your branch to Github to start a new pull request. All tests passed. It’s time to deploy this bad boy.

Except, not quite yet. All code pushed to production goes through at least one code review at Fusion. We’re using WordPress.com VIP’s coding standards, but that’s just the start. When doing code review, we aren’t just checking whether the minimum requirements were met. We are checking whether the spirit of the task was completed; whether the code looks as clean on the inside as the UI/UX does on the outside; whether the release meets our basic criteria of simply not sucking.

Code review ranks at the top of our important team practices list – it’s the form our quality control takes, and also one of the best ways to learn and grow with a codebase.

How do you initiate code review? Just comment on the PR something like this:

If you see something, say something (or even better – make a pull request).

Good code review entails understanding someone else’s code fully. WordPress VIP has guidelines on what they look for, some of which are environmentally dependent, but code review is a strategy that adds value to any collaborative engineering effort. The net result of code review is cleaner, more performative code, and a team that learns from itself while also keeping current with what other people are adding to the codebase.

5. Merge the branch into master

Last step. Now that you’ve got a pull request just raring to go, let’s merge into master. Of course you don’t have any merge conflicts, because you’ve been merging master throughout the development process. No surprises here! As master is merged, the update is also pushed to the Automattic-managed SVN that backs WordPress.com VIP.

Voila. That’s it. A Slack message enters the client, heading straight for the #deploys room:

Not yet built: A keg-bot to pour drafts when we deploy.

You’ve just released your first quality feature to Fusion.net. Mazel.

This process isn’t foolproof. We still make mistakes and occasionally ship bad code into production. But this process makes us more mindful about quality, and you can bet your ass that we remember our mishaps.

Want to build quality digital media products? Check out our available positions. We’re ramping up the Fusion tech + product team in 2015.

Posted Jul. 17 2017, 4:36 pm by davis