jsulz


Fueled by coffee, code, and spreadsheets

The Beginnings of A Wallingford Sensor Garden

As a denizen of Wallingford, Seattle much of my time is spent in wonder at the greenness of it all. My time as a child and young adult in Montana did not prepare me for the lushness of Seattle, and Wallingford is no exception. The spring, summer, fall, and winters here are green and if you look closely enough, you’ll see something blooming during all those seasons as well.

JavaScript JavaScript JavaScript JavaScript

This title speaks to my life for the past four months. For years, I’ve known that JavaScript is the language of the present and future on the web and for years, I’ve avoided learning it. It’s easy to chalk this up to a myriad of reasons, but ultimately, the two largest factors were intimidation and motivation.

Intimidation because my entire programming experience is on the server-side using languages that support classical object oriented programing practices. JavaScript is the antithesis of both those paradigms. A language that is compiled in a completely different fashion and relies nearly entirely on the client to interpret and run the code, while also seeming to generally laugh in the face of OOP and passes around functions like it was going out of style.

Ultimately, I had to admit that I didn’t know JS.

Nothing on the Web is Easy

A few weeks ago, Matt Medeiros published a post on the Matt Report that is still making some waves in the comment section on his blog, as well as over on Hacker News. The tl;dr version of the post is that WordPress isn’t easy, in fact very little on the web is, but WordPress confuses the issue by seeming so easy.

On Hacker News, the argument, not surprisingly, is different. In front of a more technical audience, WordPress, and the professional services market that taps into  the software, is quickly the source of derision for any number of reasons:

  • Outdated technology stack
  • Slow (see above)
  • Prone to security issues
  • Spaghetti code programmers
  • Etc., etc., etc. (read the entire thread if you’re interested, but some of the comments are downright silly, so I’m not going to rehash them here)

Selenium, Python, and Managing Hundreds of Blogs

Here at LexBlog, we build, launch, and support a lot of WordPress websites and blogs. In many ways, that’s almost all we do! There are certainly other day-to-day tasks that the technical team takes on, but without a doubt, our most pressing responsibility to our clients is ensuring the stability and availability of their digital properties. This is especially true given that our clients, with the unique position that they have, are often suited to write in-depth analyses faster and more proficiently than a journalist or general content producer, but all that is for naught if their blog is inaccessible.

This is why I take the maintenance of our many sites incredibly seriously. When we perform plugin updates, the update is reviewed by a member of our development team (often a product manager like myself or a developer), a fully replicated staging environment is utilized for smoke testing, and each site is backed up before the update takes place. Unfortunately, when you’re talking about hundreds of sites that make use of various (and endlessly shifting) plugin components and themes, that’s just not enough. Fortunately, we’ve developed a few tricks up our sleeves that greatly simplify matters.

WordPress GETS Its REST On…. Sorta

REST stands for Representational State Transfer. Defined and described by Roy Fielding in his doctoral dissertation while at the University of California, Irvine, REST is the underlying architectural style of the web as we know it today. RESTful systems, specifically APIs (Application Programming Interfaces) in the context of this post, are those that follow four (or five) basic principals:

  • Stateless
  • Make use of HTTP verbs
    • PUT, GET (hence the capitalization of the ‘GET’ in the post title – hilarious, I know), DELETE, POST, UPDATE
  • Provide a uniform structure/interface
  • Properly formatted responses – JSON/XML
  • Responses are cacheable

At LexBlog, we make use of a variety of different RESTful APIs – Cloudflare, Twitter, Typekit, and MailChimp to name a few. These APIs allow us to tap into deeper levels of functionality that are only exposed through APIs – an end user that was not aware or capable of using these systems would have a difficult (or likely impossible) time replicating this functionality.

oEmbeds and WordPress

The oEmbed standard is a wonderful development if you’ve ever had to struggle with taking clunky <script> tags or <iframe> embeds and add them to a piece of content. Essentially, the technology makes it possible for a consumer (that’s you!) to add a request, usually in the form of a link, to the provider (such as YouTube or Twitter) so that a piece of rich media can be displayed within a webpage. In layman’s terms, it means that to embed a YouTube video on a WordPress site, all you have to do is add a link to the post, and voila! You have Rick Astley, making sure you know he’s never gonna give you up.

In WordPress, this standard has been implemented in a pretty slick fashion. Not only does WordPress do all the heavy lifting for you in recognizing when a request is to a known oEmbed provider (you can check out the list of “whitelisted” providers that WordPress supports in the Codex), but the UX for actually adding an oEmbed to a post is fantastic.

Ma Bell and Fostering Innovation

One of my more interesting decisions in life was to major in History (yup, with a capital “H”). Today, the only time that degree gets use is when flipping to one of the many books about the birth of the computer that are stored away on my Kindle.

Recently I’ve been reading The Idea Factory: Bell Labs and the Great Age of American Innovation – if you’re interested in the birth of the communications age then this is the book for you. Bell Labs is a research facility that, at the peak of its influence, helped determine the outcome of World War II, gave us the transistor, and launched the first communications satellite. The way that we live today is in part owed to the people that shuffled through all the various research labs owned and operated by AT&T during the heyday of the company. Today, it is but a shadow of itself, run by Nokia (who, given the resiliency of their older products, are undoubtedly looking for ways to make a phone that can survive the crushing pressure of a black hole), operating mostly in obscurity.

Why Blog? Why WordPress? Why LexBlog?

The order of questions in the title is important. From general to specific. Why blog? Why am I blogging?

First off, I like to hear myself talk. It’s a failing, vanity at its worst, I know, but the sound of my own voice and thoughts is something that’s soothing. A child of Montana, being alone and in my head is a comfort. Blogging, in many ways, affords that same comfort. My internal voice gets a chance to stretch its legs while writing – a meditative exercise.

This is also a natural progression. After working at LexBlog full-time for going on three years, going from Account Manager to Technical Product Manager, my lack of a blog has always struck me as hypocritical – especially since I truly do believe in the power of blogging. For me, this blog is purely about love and knowledge – love of knowledge? Either/or, really. As my understanding of various technologies has grown, so has my desire to keep track of all these bits of information that come my way. Beyond being a place to record my thoughts, this blog is a way for me to grow professionally through writing about the subjects that are near and dear to my hear. Hopefully, if you’re reading this, you feel the same way about these things that I do.