What I Use: RSS

I encourage people to subscribe to my site via RSS, when mentioning I have a site on the Facebooks and Twitters and similar. This may seem a little archaic (that is so 2008), but honestly RSS is still one of my go-to solutions for finding worthwhile things to read, watch, or experience.

One of the big reasons you don’t really see RSS mentioned anymore (despite folks actually using it often, without realizing it… looking at you, podcasts) is because Google stupidly shut down Google Reader, which was the de facto standard for reading your feeds. That killed a lot of momentum for its use.

While RSS may be limping along, it’s not dead, and a lot of sites actually do have RSS feeds, still — they just aren’t as prominently noted or advertised or linked anywhere.

Of course, even if you do decide to use RSS, there’s still the hurdle of finding an RSS reader you actually like. A lot of folks go with a web-based option (ala Google Reader), so they can read on whatever device they happen to be on. There’s also some pretty nice apps for sale (for instance, NetNewsWire), if you’re so inclined, and a lot of RSS-adjacent apps (like several web browsers, and even Apple Mail) are available as well. Personally, I use Vienna RSS, which is an open source project made for macOS. I’ve tried a bunch of other apps and methods, and this is the one I keep coming back to (there was a gap where development wasn’t really happening much, so I looked around a fair bit, but regular updates are happening again). It’s fairly fast, robust, and seems to handle a ton of feeds well. If you’re looking for a reader, I’d say it’s worth a try.

I recently went through and cleaned up my RSS feeds, getting rid of dead feeds. I just want to say, to all those bloggers who have continued to post after the blogging fad wore off: I salute you, and I’m still reading.

Extracting a Nested JSON Value in Python

First, some context: I’ve been working on some Python libraries at work that do things with sets of json data. This is generally pretty easy: Python has a nice library for reading json, so it can be worked on as a native dictionary object in Python. This is great for simple json objects, but there’s some pretty complex json data sources out there, whether it’s being returned as part of an API, or is stored in a file. Sometimes you need to access a specific value from a key buried a dozen layers deep, and maybe some of those layers are actually arrays of nested json objects inside them.

While both arrays and dictionaries are native to Python, so you can do this, it’s kind of a pain. Thankfully, many smart people have already been tackling things like this, which is how there are now handy libraries implementing a (pseudo-standard) approach for getting the value given a specific json path. (There’s even an online evaluator to help you craft a good jsonpath.) The one I’ve been using is called jsonpath-rw. When I looked at the docs for jsonpath-rw, I was a little frustrated, and I wanted to take a minute to write out my eventual understanding, in case there are other folks in a similar boat to me.

Note: I’m not primarily a programmer (currently I’m a Technical Writer, and prior to that I was a QA Engineer — mostly exploratory, not automation), so while my example works, there’s probably more robust and pythonic ways to do the same thing. Continue reading “Extracting a Nested JSON Value in Python”

Link: Permanent Redirect

Found via Kottke.org, a simple but clever bit of internet art created by Donald Hanson: the URL to the destination page moves each time it’s viewed, so you end up with a trail of “301 – Permanent Redirect” pages (301 is an HTTP status code, something a server sends when a page has been permanently moved to a new address).

Check out the start here: Permanent Redirect.

Link: Careful Now

Chris Coyler over at CSS-Tricks has a worthwhile response to the “Chrome is the new IE6” article I linked to earlier.

Even more concerning than browser-specific websites is seeing browsers ship non-standardized features just because they want them, not behind any vendor prefix or flag. There was a time when web developers would have got out the pitchforks if a browser was doing this, but I sense some complacency seeping in.

These days, the vibe is more centered around complaining about other browsers lack of support for things. For example, one browser ships something, we see one green dot in caniuse, and we lambast the other browsers to catch up. Instead, we might ask, was it a good idea to ship that feature yet?

Link: How to Fix Facebook

Over at Washington Monthly, Roger McNamee discusses How to Fix Facebook – Before It Fixes Us. It’s a good read, and while I may not agree with all of his suggestions, there’s some very astute observations in there:

This is important, because the internet has lost something very valuable. The early internet was designed to be decentralized. It treated all content and all content owners equally. That equality had value in society, as it kept the playing field level and encouraged new entrants. But decentralization had a cost: no one had an incentive to make internet tools easy to use. Frustrated by those tools, users embraced easy-to-use alternatives from Facebook and Google. This allowed the platforms to centralize the internet, inserting themselves between users and content, effectively imposing a tax on both sides. This is a great business model for Facebook and Google—and convenient in the short term for customers—but we are drowning in evidence that there are costs that society may not be able to afford.

I’m going to try and not keep harping on this — there’s plenty of other things to think about and talk about. I’ve been an advocate for the “indieweb” for a long time, and the current realizations over how algorithmic content curation (with no one driving, no less) through single sources might not have been such a great idea certainly help vindicate the desire for a “smaller,” more independent web. That said, I’m painfully aware of some of the gaps in the indieweb space: many tools have an incredibly high bar for getting started, and several parts of the stack frankly just aren’t getting a lot of attention (the state of web galleries is the source of a semi-annual lament). If we’re going to make a serious stab at “making the internet smaller again,” there’s still a lot for us to do.

Link: Chrome-Only Sites are a Problem

Via the Verge, Chrome is turning into the new Internet Explorer 6. I’ve been saying this for a while, and often get poo-pooed by folks who really like Chrome. Let me expand on that a bit and explain what I mean. (First, go read the article, it lays some good groundwork.)

The big response I hear is “Chrome is standards compliant, so if only Chrome is supported then the others need to catch up!” There are several browsers that claim to be standards-compliant. This is fine, and a good aspiration, but is also a bit of a half-truth: in reality browsers are partially compliant. This is because standards continue to evolve, and it takes time to implement those standards, and literally no browser is actually 100% compliant with current standards. Further, different developers are going to prioritize different parts of the standard, so while Chrome might have one feature implemented, Firefox implemented one Chrome doesn’t have, and Safari might have a different feature than either of them. Each of those features are standards compliant.

Part of the issue, and why articles like the one linked above are starting to crop up, is developers look at the new shiny in Chrome specifically, and develop around that, ignoring all other users and browsers. While there’s room for experimentation and trying out new features, putting sites into production without considering the impact on users that don’t have the features Chrome chose to implement first is bad for the web (and frankly bad for business). This isn’t specifically Chrome’s fault, mind you — the same could be said for sites using features only Firefox or Edge or Safari support, without including a fallback. However, since Chrome has the marketshare, the issue becomes much more prevalent with Chrome.

The other response that comes up is “if it works in Chrome then it’s the others that are broken.” Sometimes that’s the case, I’ll happily concede, but frankly not as often as people make it out to be. There are no shortage of bugs in all browsers, and Chrome is no exception (just in the Chromium public bug tracker, bug IDs are about to crest 800k, of which 57k are still open and active). This means you are going to work around quirks and issues in their implementation of a particular feature, even longstanding parts of CSS or HTML. This is an unfortunate but unavoidable part of web development. The issue (again) is when you only fix the issues around Chrome, or assume Chrome’s incorrect behavior is what should be expected, and leave a broken experience for all other users.

This all leads to a result of sites saying “Best used in Chrome!” or having broken functionality in other browsers without even a note, or even just blocking use with other browsers. That is what people are talking about with Chrome becoming the new IE6. It isn’t really Chrome’s fault it’s turning into IE6, but it doesn’t change the fact that as long as developers treat it as the gold standard and ignore other browsers, that’s what it will become.

(This, of course, isn’t even getting into the shift at Google to start making their newer services Chrome-ONLY, which is the next phase of IE6-ification. Some have received claims of eventual compatibility with other browsers, but others have not. While as a company they’re entitled to make those sorts of decisions, there’s nothing “standards compliant” about that sort of behavior, and earns them every bit of IE6-comparisons they receive.)

Link: The year we wanted the internet to be smaller

Over at The Verge, The year we wanted the internet to be smaller is an article discussing the state of the internet, and how we’re becoming increasingly disillusioned with broad social media (the Facebooks and Twitters and similar), reverting back to blogs, niche communities, and mailing lists. Found via Waxy.org.