Like many technical specifications on the web, RSS (which stands for Rich Site Summary or Really Simple Syndication depending on who you talk to) has a confusing history that seems to only get more confusing as time goes on. The format became popular in the late 1990’s as the need to standardize information held on websites became a pressing concern with the rise of blogging and dynamic websites. The influx of information and content, all organized in different ways, was exciting, but without a standard way to consume the content, you were left with just a few options:

  • Bookmarks, and lots of them
  • Memorize a handful of URLs and visit only those sites
  • Build a custom web scraper

The goal of RSS (as I see it) was to provide each site that created dynamic content a specification to follow to make that content available at some address so the rest of the internet community could easily monitor this address for updates. For example, this blog’s RSS feed is available at https://www.jsulz.com/feed/. You can take this URL and drop it in Feedly or your RSS reader of choice and every new post I publish will end up there alongside any other blogs you regularly read.

My introduction to RSS feeds was through Google Reader, a feed aggregator similar to Feedly that provided users with a way to compile compendiums of publications and read them all in one place. While aggregation and syndication are the most often cited reasons for using RSS, the use-cases extend much further beyond that. In my mind, RSS’s purpose runs parallel to one of the foundational reasons for the internet’s existence: Communication.

Even with WordPress dominating the online content management game there are still hundreds of systems, all with their own way of structuring webpages and publishing content. Without a standard way to consume this content, each post, page, update, or product stands to get lost in a sea of information. The RSS specification does away with all the page markup, styles, forms, etc and focuses on structuring the content so that it’s easily accessed. Without a standard for communication, there is no way to communicate.

As LexBlog opens its doors to legal blogs and digital publications around the web, my belief that RSS is a standard component of content management systems is being challenged. We’ve found blogs that don’t have RSS feeds, publications with RSS feeds that contain only the name of the site or a handful of posts, and just about everything in-between. I understand that technologies change and that a site built in 2004 may not have considered RSS a core part of blogging (although I may have some questions about why a site delivering dynamic content is being run on the same platform in 2018), and I get that making a piece of technology do something that it wasn’t designed to do is difficult. That said, people charged with managing content on the web are admitting to serious negligence if their publications don’t have an RSS feed and they aren’t doing something for their organizations (or clients) to change that.

It’s unfortunate that at a time when internet technologies have taken off and valuable content is around every corner, that technologists have eschewed standards designed to make that content available. As I wrote this, I was reminded of a recent post by Boone Gorges:

The more worrisome trend is content that’s not available through RSS simply because there’s no feed mechanism. A shamefully large number of my geekier aquantainces have moved their blogs to Jekyll and other static-site-generation tools, which don’t appear to have feed support out of the box; and – this is the “shameful” part – since these folks, geeky as they may be, think so little of RSS, they don’t bother setting up the secondary plugins or whatever necessary to serve feeds. I expect that kind of behavior from lock-up-my-content companies and technically-clueless organizations that rely heavily on proprietary and bespoke software, but not from people who ought to know better.

Could not have said it better myself.

This post was written using Gutenberg, the code name for the WordPress core team’s effort to overhaul the WordPress post editor.

One of the things that we strive to do at LexBlog is help data drive decision making processes. The fetishization of data in business is somewhat akin to the fetishization for new specs and frameworks in development, but data is still a helpful tool (just like arrow functions in ES6) and should not be ignored. And so we track actions in the admin – clicks, navigating to a certain page, performing an action – all the data that a product manager like myself craves. One thing I’ve noticed in watching how our customers use the LexBlog platform is that people post. A lot.

That simple fact shouldn’t be surprising. We run a network of digital legal publications. Lawyers are trained writers, so they write constantly. Basically, if you give a lawyer a blog, be prepared to see them log in, go to Posts -> Add New, and begin writing away. So when I heard that Matt Mullenweg included the editor in the list of primary focuses for the core team, my interest was piqued. When I saw Aaron Jorbin’s post on using Gutenberg last night, I had to try it out for myself.

Continue Reading Gutenberg – The Future of WordPress’s Post Editor

At LexBlog, my team is responsible for keeping a lot of sites up and running. We help manage the reputation of lawyers and law firms, where each pixel matters. As a result, our product team performs a host of functional tests before launching updates, and we lean on test driven development practices to catch things that functional tests cannot.

An unfortunate blind spot is that humans aren’t machines. We’re prone to miss simple things, and after staring at a screen for hours on end, our brains and eyes get tired. To help catch things that we may gloss over, we use an internal application built using Node.js, React, and Selenium that integrates with the WordPress REST API and an external service, Applitools.

Continue Reading Building a Visual Regression Testing Application Using React, Selenium, Node.js, and the WordPress REST API

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)

Continue Reading Nothing on the Web is Easy

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.

Continue Reading WordPress GETS Its REST On…. Sorta

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.

Continue Reading oEmbeds and WordPress

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.

Continue Reading Why Blog? Why WordPress? Why LexBlog?