JavaScript vs. the World

Before I started my backend developer position at WebDevStudios, I needed to buy a laptop. Having worked exclusively on Apple computers since 2004, I bought what was at the time the latest and “greatest” offering, the late 2016 model of the MacBook Pro with Touch Bar.

It has come to be perhaps my biggest regret; I have had nothing but problems with the machine. Occasionally glitchy graphics, power control issues when running dual 4k displays, and start-up/shutdown issues aside, my biggest complaint has to be the keyboard. It’s gotten so bad, in fact, that just yesterday, I finally brought my laptop in to have the keyboard replaced, only to notice beforehand that the “Service Battery” message was displaying.

The tech at the Genius Bar told me I’ll perhaps get the battery replaced for free as part of the keyboard replacement, because apparently the keyboard, battery, and track pad are all one component in these machines. I’ll find out in 7-10 days, but in the meantime, I’ve powered up the ol’ Raspberry Pi that I won as part of a contest at Midwest PHP a couple of years ago.

Adventures in Computing

I’m on vacation until after the new year, and going from a powerfully unreliable machine to a reliably non-powerful machine is a shift. In fact, before I remembered that I even owned this Raspberry Pi, tucked away in a drawer as it was, I thought I might just have to miss out on the coding exploration I’d so looked forward to as part of this vacation.

Last weekend, I spent upwards of 10+ hours scaffolding out a new infrastructure for this site, wrestling with server configurations, learning how to properly register a subdomain, setting up a package server, and otherwise doing the sorts of modern dev-ops-ish sorts of things I do every day at work. Of course, I didn’t intend to spend my whole vacation that way, but I did want to do enough of it that I’d feel satisfied that I learned something new over break. Taking my laptop in for repairs and being told it would be 7-10 days before I saw it again was something I dreaded, but knew I’d deal with. I do, after all, have other devices I can use to browse the web, but nothing else I can use to make it.

After I rediscovered my Raspberry Pi, I dug out all of the things I needed to make it work: a power supply, a wired keyboard and mouse, and an HDMI cable. My first job was to figure out how to uninstall the RetroPie app I’d installed awhile back to play the SNES games I own at my desk. Thankfully, the developers included an uninstall script that did the job, and before I knew it, I was back online browsing in…the Epiphany Web Browser.

Let’s say that this was a less than ideal experience.

Fast forward a couple of hours, and I’ve installed the following on this tiny computer with 28GB of storage and just 1GB of RAM:

  • Git
  • PHP
  • Nginx
  • MySQL
  • Chromium

I’ve also read tutorials that suggest that the IntelliJ editor is installable on Raspberry Pi, and I’m going to give that a go next.

Still, the most fascinating part of all of this is just how unusable the web has become.

Browser Testing

The model of Raspberry Pi I own ships with two web browsers: the aforementioned Epiphany Web Browser, and something called NetSurf. Epiphany is functional, but appears to run an outdated version of WebKit where most websites will tell you you must update it to access their site. I was able to login to Gmail only after watching it crash a handful of times, and even then, I received an HTML-only experience that dates back to a much simpler time. NetSurf is a non-starter, as it doesn’t seem to have an ECMAScript engine to speak of, and of course, the vast majority of the web requires JavaScript to function at all.

After installing Chromium, I was at least able to get a modern web experience, though even writing this post in the new WordPress editor, I’m starting to notice significant lag as more and more blocks come into play. Amazon-owned sites like The Washington Post and Amazon.com both crash after trying to load all of their assets, so clearly they’re not designed for everyone.

It’s been a bit of an eye-opening experience, browsing the modern web with a modern (for educational purposes), but underpowered machine. As a developer who works in the WordPress sphere, it’s especially interesting to think about how “democratizing publishing” has changed so drastically, to the point where it may in fact be much less democratized when factoring in JavaScript rendering engines and accessibility. I hope these are some of the problems we start tackling in 2019, and that we’ll remember that not everyone is viewing our work using the latest and greatest technologies.

Getting Back to the Basics

First things first: I’m writing this in the polarizing new Gutenberg editor that shipped with WordPress 5.0. My site, as little as I update it, is extremely barebones – no metaboxes, no shortcodes, no real extended WordPress functionality to speak of. As such, I knew I could reliably update it without issue, the dangers of updating without first backing up my database be damned. Since I’ve been doing primarily back-end development work for nearly the past two years, I admittedly haven’t had a lot of cause to pay much attention to the state of where Gutenberg was until it actually shipped. It’s finally here, though, and I’ll gladly admit: in just typing this initial paragraph, I’m already enjoying it immensely more than the old TinyMCE editor. 

I never really got into blogging. And though I don’t think this new editor experience is going to change that, one thing that is immediately evident to me with this new WordPress experience is that it’s possible that I might start to do it more. The old experience, clunky as it was even with this minimalist install, felt like a chore. The window was small, even in “distraction-free” mode, and as a result, I could never get the words out even when I felt like writing them. Gutenberg, with all of its flaws, does at least seem to give me some space, to try and get out of my way so I can have fewer distractions between whatever it is I want to say and actually saying it. Kudos to the WordPress Core team for seeing the project through despite the challenges and legitimate accessibility issues. I hope future releases will come more quickly and iteratively address the concerns people have about it, so that over time we can move forward with further enhancing the CMS overall. There are some really big projects underway, and I’m especially excited about the work that’s being done to finally get the minimum version bumped, hopefully to what will eventually be a currently-supported version of PHP.

A Holiday Break

This coming weekend marks the beginning of the first substantial amount of time off I’ve taken since Memorial Day week: 11 consecutive, uninterrupted days of relaxation, spending time with friends and family, exploring personal projects, playing (and designing) board games, and otherwise recharging my batteries after what has felt like a particularly challenging year for me. 

I switched over to full-time backend development upon switching employers in March last year, and in many ways it’s been super rewarding. I’ve learned how to write unit tests in PHP which, in turn, has completely changed my approach to writing object-oriented code. I’ve dug in with Docker, improved my command of the terminal (see what I did there?), and have advocated for the adoption of modern coding practices. More and more, I’m using Composer in my day-to-day work, and this year I gave a presentation about it at WordCamp Minneapolis-St. Paul. Some folks even gave me very nice feedback about it.

I got to do a bit of work-related travel late last year and early this year. I took some vacation time in July to attend a first-year PHP conference in Detroit, where I bonded with great folks in the PHP community that I like and respect a lot. In some ways, I’ve paid it forward, too, having great conversations with folks at and outside of work about my philosophy and approach to writing software for the web, and hopefully giving back as much as I’ve been given. I need to do more  – there’s always more to do – but having the opportunity to bond with others in my community was kind of one of the reasons I got into this thing to begin with. I love talking shop and taking the information I’ve learned and applying it to the next project. In some ways, though, it hasn’t panned out exactly as I’ve hoped.

A Knowledge Gap

I didn’t notice it right away, but ever so often, a problem arises with the presentation of a site that I’m working on. It seems that no matter how much you try to isolate yourself onto one side of the system, in an agency setting, you always get pulled back into the front-end. 

I actually like front-end technologies quite a bit. Back when I did full-stack development in my previous roles, I prided myself on writing clean, semantic markup, making my stylesheets as extensible and reusable as possible, and learning the ins-and-outs of the latest JavaScript techniques. Well, to the best of my ability, at least. I loved the UX aspect of front-end: learning to make elements accessible, making interactions delightful, and making my components reusable. I didn’t care for cross-browser testing and the million media queries required to harmonize a broad collection of components at various viewports.

Still, a lot of those skills are required of me to this day. And, I’m finding out more and more, since I don’t do them on a daily basis, that my knowledge about how to do them well is slipping. I need to dedicate some time during my break and in the new year to catch up. 

I guess that’s a long, roundabout way of saying that I’m glad Gutenberg is finally here. I’m glad I have a vacation coming up, where I’ll have a chance to apply everything I’ve learned about unit testing and behavioral testing and continuous integration and apply it to my personal projects, but also revisit the front-end aspects I don’t get to spend as much time with. 

Into 2019

This next year is going to involve a lot of growth and adaption. I need to learn to set aside time to more regularly exercise the skills I have so I don’t lose them. I need to learn how to adapt to the changes the WordPress project is throwing our way, so that I can continue to be in a position to serve my clients well. I need to keep finding ways to learn from my colleagues and friends in the community, as well as step up to share with others all that I have learned. And, most importantly, I need to continue to grow and adapt and change and learn as much as I can about software development in general: learning new frameworks, new techniques, and even new languages, so that I continue to feel the spark of excitement about this field that I had when I was brand new to the industry.

Four more days. Or, if I change my perspective just a little – tomorrow. It all starts tomorrow.

Some Things I Should Have Said, Vol. II

An Anniversary

This past May, I celebrated five years of working full-time as a web developer. When I first started getting paid to write code, I remember looking forward to a point at some time in the future where I would have a base level of knowledge I could leverage when working on new projects. Five years later, I believe I’ve accomplished that goal, but in that time, I’ve also come to accept that there’s just so much still to learn (and that it will always be this way).

There’s a certain peace that comes with that understanding. Today, when I take on client projects, I may not always know how the work will be done, but I at least have some ideas about where to begin, how it will need to be structured, what kind of functionality I’ll have to write from scratch, what can be imported from elsewhere, where to find the right documentation when I have questions, who to ask when I’m completely stuck, and when to extract something into a library so I don’t have to write the same thing over again later.

It’s been a long, often frustrating journey, but after all this time, I’m more certain than ever that I’ve chosen the right career path. I love writing code, building something out of nothing, and delivering functionality that helps others make their own jobs a little bit easier.

Areas of Interest

In progress game of Century: Golem Edition

Over the past year, and particularly since seeing Chris Tankersley‘s talk about shell scripting at Midwest PHP in March, I have become increasingly interested in developer tooling. I’ve been digging a bunch into Bash scripting, the Symfony Console Component, delivering custom utilities via Composer, and trying to figure out ways I can use my knowledge to create useful tools I can pull into projects to make them more enjoyable to work on. It’s really opened my eyes to all of the possibilities that are out there, and I’m looking forward to seeing what sorts of things I’ll learn over the next five years and where it takes my career.

In addition to the command line, I have become increasingly interested what’s happening in the JavaScript communities, particularly with package development and frontend templating. Because I play a lot of board games in my spare time, I developed a small webapp a couple of years ago to log player scores when pen and paper are neither available nor practical. Recently, I’ve begun refactoring that app on top of React, which has helped scratch the itch for frontend work a bit. I registered a new domain for my blog, too, so that I can separate my more personal writings from the blog here, with the longer-term plan of rewriting this site in Laravel so I get some broader PHP framework exposure.

All in all, it’s been an exciting time for me!

Events and Happenings

While I’m posting, I’ve got quite a few things to look forward to in the coming months that I should probably talk about here. But first, something from the past! On the chance you missed it, I participated in the All About WordPress episode of the PHP Roundtable podcast in May. Tessa Kriesel (Pantheon), David Hayes (WP Shout), Jenny Wong (Human Made), Adam Silverstein and Ryan Welch (10up) all participated in the panel, where we talked about the sorts of things that are top-of-mind for WordPress developers (*cough*Gutenberg*cough*).

That was only my second time participating in a podcast, but I’ll be getting another opportunity on July 24th, when I join my WebDevStudios colleague John Hawkins on an episode of the HawkTalk Podcast. John and I will be talking about board games, hockey, development work, and anything else that comes to mind.

Though I won’t be presenting, I am also looking forward to attending the inaugural PHP Detroit conference in Livonia, MI on July 26-28. The two-track schedule looks very good, with at least one topic of interest to me during every time slot. I haven’t spent any time in Michigan since my music touring days, so it’ll be fun to hang out there for a couple of days.

Lastly, I have been accepted to speak this year at WordCamp Minneapolis-St. Paul for my second time ever. The conference coincides with the Minnesota State Fair, so attendees from outside of the state will get a chance to check out the Great Minnesota Get-Together first-hand. My talk – Modernizing Your Development Workflow Using Composer – will cover the basics of getting started with the Composer command line tool, with an emphasis on using it for WordPress development and the benefits and caveats that go along with it.

Then Comes Dudley

In the process of building custom WordPress themes for various clients over the past few years, I slowly came to realize just how much boilerplate plumbing I’d been doing from project to project. A theme calls for a big hero image with a catchy headline and an intriguing call to action? Make it so. How about an image carousel with options to adjust the delay between frames? Or maybe an list of frequently asked questions, expandable one-by-one until a potential customer has had every single possible question they could think of clarified and addressed?

One of the key tenets of programming is “don’t repeat yourself”, and about a year ago, it finally dawned on me just how much I was. From project to project, I was writing markup for the same exact modules I’d written before, and hooking it all up to the WordPress backend. At that time, I was determined to approach my projects differently; to start cataloging the instances where I was building something I’d built before, and to actually do something with that information, to make something I could reuse instead of reimplement.

In that time, I began to develop a patterns library of sorts, one that worked with the Advanced Custom Fields plugin for WordPress. I approached each new project I took on with my patterns library in mind, and looked for opportunities to improve upon it. I didn’t just want my modules to be reusable, but I wanted them to be extensible, and I wanted to provide anyone who might use it themselves with the ability to work within that framework; to write their own custom modules that they too could reuse and share.

Inspired after attending the final Lone Star PHP conference in Dallas this past April, I decided to brand my work and release it to the wild: Dudley, named after Dudley Heinsbergen, the character from one of my favorite movies, The Royal Tenenbaums. Dudley is a WordPress plugin for developers that allows them to reuse, modify, or write custom, project-specific web components for any WordPress theme. It’s my first real open-source project, and my hope is that, over time, other developers will give it a try, provide feedback about what works or doesn’t work for them, open issues about bugs they find, and otherwise help me understand if what I’ve been thinking about helps them meet a need for some of their most common theming problems. It’s one of the first things I’ve worked on as a web developer that I truly feel proud of. Dudley isn’t without its shortcomings – I’m definitely aware that it began as a tool meant for me and me alone, and I need to make some updates to it to truly open it up to everyone – but I’m excited about where I’ve managed to bring it so far, and I’m hoping that, over time, it will become a tool that other people can incorporate into their projects, as well.

Today, as part of my Five for the Future Day at WebDevStudios, I spent a few hours writing some custom WP-CLI commands for quickly scaffolding some boilerplate files for Dudley. It undoubtedly will need some improvements, but I’m so incredibly thankful for the opportunity to spend some more time improving something that has truly been a labor of love. I hope, with time, others will give it a try and find something to love about it, too.

On Working Remotely

I have been working remotely for nearly 15 months, almost as long as it’s been since I last wrote in this blog. For many who commute five days a week to their employer’s office, working from home sounds like a dream. In a lot of ways, it is. Once you do the math, you realize just how many hours of your life you spend sitting in traffic on your way to and from work, and you perhaps start to think of ways in which you can prevent that from needing to happen.

Many years ago, when I worked in an office in Downtown Minneapolis, I switched to a four-day per week flex schedule: four 10-hour days, three days off. The long weekends were nice; the long workdays, slightly less so. I drove less in rush hour traffic (especially since I would leave two hours later in the day than usual), but I also ended up having far less time to interact with my co-workers. Eventually, I switched back to a regular 9-5 schedule, as being present at the hours when my co-workers were actually in the office and not having to catch up every week and what I missed on that fifth day was more important to me than saving some time on the road.

Lesson learned: I am a social being. I like building relationships with others. I value camaraderie, partnership, and collaboration. I want to be at the table when decisions are made. I want to be present. Traffic is a reasonable exchange for these things.

And, on that note, beginning a career in web development four years ago has been one of the most rewarding and personally challenging decisions I’ve ever made. I absolutely love the work I do. When the problems are hard and I feel like there’s no way I’ll ever figure out how to solve them, and then I do? There are few better feelings in the world.

At the same time, the work can be extremely isolating. In these four years, projects have often been handed off to me once the design phase is completed and the expectation has been that I’ve got things from there. And I have! Hopefully I’ve served my clients well, and have guided their projects skillfully along the full path from local environment setup to deployment, like a true “full-stack” developer. I’m proud of most of the sites I’ve built. The ones I’m less thrilled with were usually due to budget restrictions combined with the requirement that I wear all the hats.

Working remotely can double down on that feeling of isolation. It’s not for everyone. Thankfully, just as I realized I needed to make a change when a four-day week of 10-hour days wasn’t working for me, I understood that I needed to make a change here, as well. As much as I love working on the web, I don’t enjoy the whole process. And, more importantly, I still crave collaboration and interaction; the opportunity to work on projects as part of a team, not just on my own.

Four weeks ago, I began working as a Backend Developer at WebDevStudios. We are a fully-distributed company, which means that every one of our project managers, designers, product managers, and developers works from home. And we work together on big, big projects. When I write code, it’s primarily in a language I enjoy (PHP), and one or more of my colleagues reviews it to make sure it’s up to snuff so that we can deploy with confidence. We discuss potential ways to tackle a problem, we assign tasks, and then we work together to get them done. It’s completely unlike anything I’ve experienced since becoming a developer four years ago, and I’m already hooked.