Tag Archives: John Gruber

Gruber and Moltz take on Musk

You may not be into nerdy tech podcasts (although if you’re a reader of this blog it’s probably a higher than average probability), but the first main segment of the latest episode of John Gruber’s The Talk Show, dealing with everyone’s favorite billionaire Elon Musk, is really excellent, for a couple of key points:

1. Musk bought Tesla and SpaceX. He didn’t found them. And both of them seem to be succeeding at their missions largely because they have developed a corporate culture that placates Musk’s whims while largely shielding the companies’ primary objectives from the damage those whims may cause.

2. The Boring Company, however, is not a success, and increasingly seems like it may be intended not to be. It’s easy to see Musk as a “world saving visionary,” if that’s what you want to do. But TBC’s main accomplishment, to date, seems to be squashing large public transportation infrastructure projects. And remember that Musk owns Tesla, too. It’s well established by now that mid-20th century automakers exerted their influence to kill public transportation. (Streetcars used to be everywhere!) And it seems quite plausible that TBC is little more than a front for the same activities on behalf of Tesla in this century.

My thoughts on John Gruber’s thoughts on Neil Young’s thoughts on Joe Rogan’s thoughts (or lack thereof) on Spotify

Some great insights as usual from John Gruber on the Neil Young/Joe Rogan/Spotify situation. I’ve been really bothered about all of this, as a Spotify subscriber (and as someone who does have some of my own music available on Spotify, as insignificant as it is).

Getting Joe Rogan kicked off of Spotify would in no way hinder his freedom of speech. As Gruber notes, his audience shrank when he went exclusive to Spotify. What bothers me right now is that, as a Spotify customer, I am paying Joe Rogan to spout his lies and nonsense. If it’s more important to limit his reach, then keeping him Spotify-exclusive is good. If it’s more important that I not implicitly endorse his garbage with my wallet, then one of us has to go. (And it will surely be me.)

On another level, what really bothers me about this is that Spotify has exclusive “podcasts” at all. That’s not what a podcast is, technically speaking. A podcast is just a blog, an RSS feed, that has an audio (or video) file attached to it. That’s what Gruber means about Apple not “hosting” Steve Bannon’s podcast. Apple doesn’t literally host the files. Their directory just points you to the URL. Spotify owns Joe Rogan’s podcast. It’s not really a podcast at all, because it doesn’t exist outside of Spotify’s ecosystem.

So as I see it, Spotify is doubly wrong here: they’re platforming Joe Rogan, and they’re muddying the average person’s already muddy understanding of how all of this technology works. Boo.

And of course once again I have to end with this.

Mountain Lion. Clever?

Apple just announced the next version of (Mac) OS X: Mountain Lion. And they did so in an rather unusual fashion. Grubes has the scoop:

The recurring theme: Apple is fighting against cruft — inconsistencies and oddities that have accumulated over the years, which made sense at one point but no longer — like managing to-dos in iCal (because CalDAV was being used to sync them to a server) or notes in Mail (because IMAP was the syncing back-end). The changes and additions in Mountain Lion are in a consistent vein: making things simpler and more obvious, closer to how things should be rather than simply how they always have been.

But a lot of the chatter (chirping?) on Twitter concerns the name:

I “get” what Apple’s doing with the name. Mountain Lion (10.8, presumably) is to Lion (10.7) as Snow Leopard (10.6) was to Leopard (10.5): a refinement, a continuation of the same direction in OS X’s evolution as the version that preceded it.

But it is rather odd, if you think about the actual cat names involved, especially since a mountain lion is essentially the same thing as a cougar, also known as a puma or… a panther, which Apple already used as the “big cat” codename for Mac OS X 10.3 way back in 2003.

Beyond that, Lion always seemed like something Apple was building up to… the “king of the jungle.” That version 10.7 was named Lion seemed to suggest the “big cat” lineage, version 10.x of Apple’s Mac OS, and perhaps even the “X” (which is pronounced “ten” after all) was done. And here we have… Mountain Lion? A decisive step backwards in the awesomeness of the big cats. Heck, mountain lions have even been spotted here in Minnesota for crying out loud!

So… anyway… I think the point is: Apple is not taking this whole “big cat” thing too seriously, and neither should we. Mountain Lion looks pretty great. I can’t wait to try it out!

Update: After some research, it turns out Apple already used Puma, too, for 10.1. But as I recall, they didn’t start using the big cat codenames in marketing until 10.2, Jaguar. And I still have the Jaguar mousepad on my desk to prove it!

On the ugly history of early open source CMSes (or why, surprisingly, I did not enjoy listening to Merlin Mann and John Gruber together in a podcast)

It was a perfect idea, or so I thought. Two of my favorite personalities from 5by5 podcasts were going to do a show together: John Gruber (of The Talk Show and Daring Fireball) was going to appear on Merlin Mann’s Back to Work podcast!

Unfortunately, when Merlin Mann’s fire met John Gruber’s ice, the result, like Derek Smalls, was lukewarm water.

Or maybe it was just because they spent the first several minutes of the podcast — all I managed to get through in one sitting (though to be sure, it’s all that’s relevant for this post) — talking about the early days of open source content management systems (CMSes). It maybe wasn’t really their fault. I reflexively dry heave when I hear words like PostNuke or Plone. They’re names I haven’t thought about in years, and haven’t thought about positively… well… ever. I dabbled with both of them in the early early days of CMSes, and quickly ran away.

But then Gruber and Mann (sounds like a comedy duo from the ’60s) got into something that really stings: they started professing love for Drupal (Merlin) and Movable Type (John). I cannot tell you how strongly I dislike both Drupal and Movable Type.

Gruber loves him some Movable Type

It’s been a point of pride for me since becoming a loyal Daring Fireball reader that I do not like Movable Type. The fact that Gruber uses Movable Type for Daring Fireball and is a vocal supporter of the platform, and the fact that I loathe Movable Type, is something I use to prove that I have not just become a devoted Gruber acolyte. I still think independently; I just happen to agree with him on almost everything he writes about.

One of Gruber’s biggest reasons for liking Movable Type, apparently, is the fact that it doesn’t serve content from the database; it publishes the entire site out to static HTML files. This is great for server performance under heavy loads, and has probably allowed him to continue to run Daring Fireball with a much lower-powered server than he’d need if he were using a database-intensive CMS. But in my own experience it also makes the process of using Movable Type a chore. Perhaps that’s because I’ve never actually used it directly myself; my work with it has been limited to setting up templates/themes/whatever-they-call-them-in-MT for other people. MT’s tools for working with stylesheets and templates are cumbersome, MT’s proprietary scripting language is tedious for “non-natives” like me, and having to republish the entire site to see changes to the templates is a real pain in the ass.

On the other hand, Gruber loves to rip on my personal favorite open source CMS (though surely he doesn’t know, nor would he care, that it’s my favorite), WordPress. And it is precisely because WordPress doesn’t publish static pages the way MT does that he hates it so much. He commonly refers to sites that crash under the weight of his referral traffic as being “fireballed” (clever), and sites running a stock installation of WordPress are notorious for this. But there are several caching plugins available for WordPress that can greatly boost its ability to handle peak traffic, in a much less intrusive way than MT’s static HTML publishing process. My plugin of choice these days is Quick Cache. The plugin’s tagline says it all: “Speed Without Compromise.” (I’m not-so-secretly hoping that Gruber links to this post on Daring Fireball, but then again, I’m not sure I want to risk being proven wrong.)

Merlin and Drupal, sittin’ in a tree

And then there’s Merlin, and Drupal. Oh, Merlin. Again my experience with Drupal is fairly limited. I tried using it to run this site for a brief period (which you can probably find if you dig in the archives… I believe it was around early 2006). I very quickly gave up. Drupal’s admin interface was clunky and unintuitive, but it was the fact that my site was almost instantly drowning in comment spam that killed the deal for me. In the time since then the only work I’ve done with Drupal has been focused on helping people move their sites off of it, but the fact that so many people want to do that says enough for me.

I find two major issues with a lot of open source CMSes (like Joomla and MODx, to name two others I’ve tried in the past) that are perfectly exemplified by Drupal and Movable Type.

First, unless you really know what you’re doing and put a lot of effort into it, your Drupal site is going to look like a Drupal site. (Yes, it’s true that as I am writing this I’m using a more-or-less stock WordPress template, so my site looks like WordPress, but that’s not the point; it’s easy to build a completely custom WordPress theme from scratch with little more than basic HTML/CSS skills.)

Second, and I touched on this with Movable Type, many of these systems have their own custom scripting languages or other idiosyncrasies to be learned, such that learning to use these systems is not substantially easier than just learning to code HTML/CSS.

Of course, I know how to code HTML and CSS. That’s my job. I have “visual” mode disabled in the editor in WordPress. A CMS exists not just to shield you from writing code, but to make it easy to manage, organize, and re-organize large amounts of site content, while maintaining a consistent look and feel. But a good CMS goes beyond that. A good CMS puts the power to manage the website in the hands of people who don’t know, and don’t want to know, how to write code.

A little background

As I listened to Merlin Mann and John Gruber wistfully recall the glory days of crappy CMSes, I wondered why they had devoted so much time and attention to learning and working with those systems, while at the same time I had rejected them out of hand. (I also wondered why they were at roughly the same place in their careers as I was at the time, and now they’re “famous,” but that’s beside the point… or maybe not… read on.) Then it hit me: I didn’t like those CMSes because I had already built a few of my own and I liked them better.

Now, it’s true that I liked my CMSes better partly because, well, I had built them. And I think Merlin was spot-on in the podcast when he said that most systems worked great if you thought just like the developer. (Specifically, he said that Basecamp works great if you think like Jason Fried.) That’s a great point, and one I should not overlook. But there’s another aspect to this. Most of these open source CMSes are developed by online communities of… well… geeks. Sure, they take feature requests from users (I assume), but ultimately the main people giving the developers feedback on how the systems should work are other developers.

I’ve built a number of CMSes over my career. They’ve all been built to meet specific client/user needs, and always in direct consultation with those clients/users. Has that made them perfect, or made me impervious to casting my CMSes in my own image? Of course not. But it’s made it harder to hide away in my geek cave and crank out systems that only other geeks can use.

The first CMS I built was in the heady days of early 2000, just before the dot-com bust. I was working for a certain big box retailer’s dot-com subsidiary. (This was back in the days when certain big box retailers believed they could spin off dot-com subsidiaries as independent companies that issued their own stock and everyone got rich yay!!!)

The company had invested 7 figures in some colossal enterprise CMS that was going to take several months and thousands of hours of consultant time to customize to our needs. In the meantime, our staff of writers (yes, we had writers producing informative weekly articles for each “department” of the online store) would deliver their content to me and to the one other front-end developer who was good at HTML (I know, right?), and we were to manually convert them into HTML and put them into the static pages of the site. (As front-end developers, we were strictly forbidden any database access. Because, you know, we were dangerous. We might put HTML in it.)

After a few weeks, I decided this was a ridiculous arrangement, so over the weekend I scraped together a quick-and-dirty, database-free CMS that would allow the writers to enter their content directly. The system would merge their content with prebuilt page templates, and save the output as static HTML pages on the server.

And so a career as a CMS developer was born.

At my next several jobs, I built more CMSes, honing the process each time (and always starting from scratch, since my previous work was the IP of my former employers). And eventually, when I went out on my own in 2008 (not to mention my first failed attempt at full-time freelancing, in 2003, which is going to be the subject of a future post), it was natural that I’d create my own CMS, and this time since I own the IP, I can keep building on it and expanding its capabilities.

Does my CMS have the polish and ease-of-use of WordPress? Probably not, although I’ve had more than one client (more than two, even!) tell me they prefer my CMS over WordPress. But the stock version of WordPress has a fairly limited scope of capabilities (you’ve got your pages and you’ve got your posts and, hey, why would you need anything else?), and my CMS is more modular, with a number of other capabilities (built in event calendar with registration, ecommerce, custom forms, etc.) that can be turned on or off to suit the needs of the client. WordPress is highly extensible with plugins, of course, but I find that, in short, if a client needs a custom solution, they need a custom solution. My CMS is a shortcut to a custom solution.

So that’s why!

Along this mental journey through the littered landscape of dead (or dying) content management systems, I learned a few things. I learned why I never fell in love with those early CMSes. And I think I probably also learned why I’m not “famous” in the field of tech bloggers/podcasters. I’ve been too busy reinventing my own wheel for much of the past decade to have the time to devote to self-promotion (and I don’t mean that as a slight against Gruber and Mann) necessary to achieve that level of recognition.

Fiddly

I got up this morning and, like on most mornings, one of the first things I did was brush my teeth. It’s a simple process, just part of the minutiae of daily life. But as with so many of those little things we do every day, it’s a less-than-ideal experience. After fumbling to pull the toothbrush from the cup — where its bulbous, rubberized handle was wedged against the bulbous, rubberized handles of the other toothbrushes necessary for a household of four — and nearly dumping them all into the sink along the way, I took my frustration to Twitter:

It got me thinking about a recent post on Daring Fireball, where John Gruber expressed his frustrations that some people — even Apple Store “geniuses” — were telling iPhone owners that they need to occasionally force-quit all of the apps in their recently-used items tray. He followed up on that post on his podcast, The Talk Show, where he described the experience of operating systems where you are expected to manually monitor and adjust their states as being “fiddly.”

I’ve been thinking about that word, “fiddly,” a lot since then. I think it applies to a lot more than smartphone OSes. I’ve spent a great deal of my life dealing with overwhelming frustration at the clumsiness, the fiddliness, of everyday objects: cheap plastic toys that break easily, things that stick to other things when they shouldn’t or don’t when they should, tools that cannot adequately perform the tasks they are expressly intended for, etc.

As someone who’s not inclined to tinker with objects, much less invent solutions to their shortcomings, that frustration usually just burns off as simmering rage. But as I pondered the nature of fiddliness, and the ideal of the iPhone as a “non-fiddly” object, a couple of thoughts occurred to me:

1. It is the purpose of design to reduce the fiddliness in the world.

2. Very few makers of physical objects today follow #1.

Gary Hustwit’s documentary Objectified is focused on the design of everyday objects, and those who have excelled at creating objects that are, for lack of a better word, as non-fiddly as possible. Two people featured in the documentary are Dieter Rams, the legendary German designer who led Braun’s industrial design team in the 1950s and 1960s, and Jonathan Ive, the head of Apple’s industrial design team today. Both Rams and Ive share a passion for making objects that work. Form not only follows function, form is function. It’s a seamless integration of purpose and style that makes the objects a delight to use.

And that’s a very rare thing today, indeed.