Category: How It Is

Making philosophy about the why behind technical things.

Don’t Be Afraid To Learn In Adversity

also i’d like you to either never submit pull requests again or at least try to not put harmful code in them

That was what a developer said when I made a derp pull request, adding in a check for 0 that should have been better as a check for not -1.

Regardless of the fact that he and I fundamentally disagree on the usefulness of the code (and frankly, that’s why I assumed he’d be punting my pull request), his reply is something I’m very glad I got now and not 10 years ago.

Like pretty much everyone on the planet, I have moments where I wonder if you’re all going to figure out that I don’t know a damn thing and I’ve been faking it all these years. It’s Imposter Syndrome, and we all suffer from it to a degree. And it’s comments like that developer made that reinforce it.

Now, I know this guy’s history. And I know at first glance his reply may seem terse but not all that bad. Sadly, this is probably the nicest I’ve ever seem him tell someone they sucked. He’s not nice. At all. His support forums are filled with him calling people demeaning names, or saying they’re stupid for not understanding his code, and frankly on the list of humans I would willingly interact with for fun, he’s not there. He’s not even on the reserves. But I still respect his code (though not his documentation, inline or otherwise) and I use it every day. I won’t be contributing to it anymore because I don’t have any need to be in an abusive relationship.

“Curse your sudden, but inevitable, betrayal!”

And that’s what this is! He’s abusive and behavior I don’t care for and wether he means it or not, he’s being mean. It feels silly and petty to put it that way, but that’s what it is. He’s a mean person. I don’t care that he’s mean, and it didn’t actually hurt my feelings though it did make me momentarily angry at him, but I do care that meanness like that will convince someone to stop and never get better at things. Did it hurt my feelings? Yes, it did. It sucks to be told your code sucks, but it sucks more to be told in a way that makes you feel like you’ll never be good enough in any way, which is precisely what many people will read from that comment.

When you ask me “Where does Imposter Syndrome come from?” I say “People like that.” People who reinforce the belief that you’re not good enough, that you’re crap and don’t deserve their time to learn better, and you can go eff yourself.

Is he required to be nice and handhold me through the code and explain why? Hell no! But he made an open source product which he opened to the public, put on GitHub, and allowed for pull requests. He’s naive to think everyone will come to his product knowing everything, and I suspect part of his attitude issue is because he doesn’t want to help people. Which again, is fine. Obviously I don’t feel the same way, but I also don’t think everyone can be good at support. I do think that if you’ve got all this in the open, you’re going to get people who are far less experienced than you are. How you treat them will set the standard for what kind of help you get from your community in the future.

Let’s contrast this. I was talking to people about a change in some laws recently and fiddling with an add on to code I use because of it. When I reached a point at which the code worked, I put it on Github and said “Pull requests and fixes welcome!” I knew the code wasn’t good enough. I knew I wasn’t sanitizing everything yet, some of it was terribly inefficient, and some of it was bad code. I knew this. I knew it wasn’t perfect at all, but I put it up and then pinged a developer for the product I was using. His reply?

mind if I fork that and we distribute it either on [our] site or in (pending yet another round of core team discussion) in core?

Boom. He knew it wasn’t perfect. He saw the value in the attempt and proof of concept, and he ran with it. Naturally I told him to use and enjoy, because I’d licensed it GPL. He also said he’d try and do a pull request to make it so when you used the code, it stopped you from picking the wrong thing. That was something I’ve yet to sort out, even though I’ve been playing with the code some more. I’m learning something new. I’ve never written for that code project before (except a typo fix). This is all new for me.

The difference is pretty bold. One guy pretty much insulted me, one encouraged. The insult, justified or not, discouraged me from wanting to pitch other suggestions or improvements. The encouragement is making me think about an offer they made a while ago more seriously. It also inspired me to sit and study the code, read what it did and why (seriously awesome inline documentation there), and be able to go from zero to add-on in 4 hours while prepping for a holiday dinner.

How you represent yourself, as a developer, creates your community. How you treat others can help or hinder their entire lives. You may not think about your words as having that much power because you’re just someone who helps in a support forum, or you wrote a simple two line plugin, or you translated a file, but they do. Your words matter a lot.

As for the people reading this who don’t code well either, don’t be afraid to code badly. You can’t know it all from the beginning and don’t let people get you down about that. Tell them you’re learning, that you’re trying to be bold and step out, and you won’t get any better in a vacuum. Some of us have to learn by doing, after all. We can’t all read the code and know the answers, and that’s okay.

By the way, yes I’m still using the code from the other guy. I’ve forked it (and now I get to learn about syncing your fork back with master changes) and I’m keeping my one change in there. I’m sure there’s another fix, with a filter perhaps, but given the lack of documentation and assistance, I’ll be stuck with this for a while yet. But you know what? That’s actually okay.

I honestly have no hard feelings on a personal level. I’m not obligated to like him or agree with his choices. He’s not obligated to agree with mine. That’s why open source is great. I can fork it and go. But what won’t happen is that I won’t be afraid to make changes, to get things wrong, and to keep learning.

I’m not an imposter. I’m just still learning.

8 December, 2014
Whose Responsibility Is It?

When WordPress 4.0.1 came out, a small number of sites broke.

For a while, we’ve been touting that minor releases to WordPress core, the ones we auto-upgrade for you, are very safe, very tested, and very important. While all this is true, it has brought a few people complaining to me that obviously I was wrong.

It’s true that the 4.0.1 release broke people. It was an object lesson in why I tell people not to reinvent the wheel. But this upgrade situation does not mean the upgrades aren’t safe, secure or smart. It does bring thoughts to mind, like what my friend David talks about when he considers WordPress at the enterprise level. I know people who are using this failed upgrade scenario as a reason to tout that WordPress isn’t ready for big business, but I think they’re looking at it from the wrong perspective.

Let’s step back.

I used to work for The Man. I’m well aware of the machinations you go through to upgrade anything at a massive enterprise. One of the things they do is a code review. Every single upgrade is checked and tested and a dry-run of the upgrade is run to ensure everything works the way they think it should. By allowing WordPress auto-upgrades, you remove that ability. For a massive corporation? I would turn off the auto-update.

But at the same time, this mythical major company running WordPress would have at least one person who knew WordPress. They would have someone who’s job it was to review every single bit of code that went into their WordPress site. Each plugin would be checked, tested, evaluated for security, and only installed if that WordPress Checker said it was good. Because that’s exactly what you must do in any and all enterprise situations.

David’s viewpoint is that the vetting of a site should be delegated.

My gut reaction to say that they should know better has to be tempered with the fact that no, they should not have to. It’s the job of every site owner to vet their system, but to make a platform that is truly global, that vetting should be delegated. Web hosts and security analysts should vet code for collisions and bugs. Theme and plugin shops should ensure that their products adhere to best practices. Putting accountability for the full stack on each site owner is not only inefficient, but impractical. Inherent trust should exist that code in the official repository maintains a baseline level of code, trust that is eroded when the problems that occurred with a subset of sites on this update occur.

And here, he and I disagree somewhat.

It’s the job of everyone who uses software to be aware of what they’re doing. Vetting the software before it goes in to your system has to be someone’s job. WordPress core does an amazing job of this for you. WordPress core is safe. The 45k plugins and themes in the world don’t always meet the same level of robust checking. Which means when you introduce WordPress to your environment, you absolutely have to seriously review those third party odds and sods you want to use because they’re so shiny and cool.

Web hosts vet code for collisions, sure. We do at DreamHost. That’s part of my and Mike’s jobs! We know what’s going into WordPress and if it’s going to blow things up at DreamHost for our customers. But like the site owner who found her site down one morning because we’d upgraded her from PHP 5.2 to 5.4 and it broke her WordPress 2.5 site, we cannot account for everything.

I think there’s a need for security specialists to review plugins, in a public forum, and point out who’s not doing things in the best way. I also think that there’s a need for developers to remember there’s a reason why we do things a certain way, and while it’s fine not to, you have to keep in mind that it’s now your responsibility to keep a close eye on anything that changes in core that might cause your code not to work as well.

For example. If I wrote a plugin that worked around the shortcode API for whatever reason, I would have a custom query on trac for any ticket related to Shortcodes and have it as an RSS feed to monitor. Or I might even subscribe to the trac firehose and use a filter to pull out anything that so much as mentioned the word. Because I’ve now made a change that I know might be a problem someday.

Every business owner should know the risks of all the software they use, be it website or desktop. This responsibility is the cost of doing business. The size of the business and the importance of the software will change what resources you can afford to allocate to that part of your business, but you absolutely cannot ignore it.

While I really want to say that because WordPress core does due diligence you don’t have to, I would be a lying liar who lies. Even if we do as David suggests and have everyone in the world making sure things are vetted and checked and stamped, it still requires the owners of a site listen to that information and not use the code that’s less optimal. Enforcing that would be impossible unless you wanted to suggest that WordPress outright deactivate code that doesn’t use the proper APIs. That would put a lot of weight on WordPress and slow it down and be pretty annoying for people who are legitimately using non-standard methods of development and implementation.

No matter what, at the end of the day, the person who is responsible for the code quality is the person who wrote and maintains it. But the person responsible for their site is the person using the code. You have to know what code you’re putting into the site and be aware of the risks you’re introducing to your environment by doing so. If your website is your entire business, you cannot afford to be cavalier about these things.

Disasters happen. Understanding the risks will prepare you for dealing with them when they do.

5 December, 2014
Including Assets

I’ve noticed a trend in plugin reviews that people are including third party assets with their code.

This is great. Heck, I do it on a couple of mine. Why should I reinvent the wheel when I’m including code? If I need to use some existing code like a GPL friendly lightbox file, I’ll just grab Colorbox and be happy. But have you ever really looked at your assets?

The above image shows you all the files and folders included in Colorbox. If I was including the entire git repository in my plugin, it would take up about a meg of space. The unminified js file is only 29 KB. For me, it’s a no-brainer again. Grab just the js file (making sure the header has the license info and the URL) and toss that in my code. Why would I include a meg of data I’m not using just for the ‘ease’ of a git clone?

And really I think that’s what’s happening. We’re all so excited to use a git pull or a submodule for the ease of inclusion, we stop thinking about exactly what we’re including in our code and how much weight we’re accidentally adding to it by dumping the whole library in there. Some libraries, like Complexify are really small. Then you have Twemoji, which weighs in at 135 MB, give or take.

Do you really need the whole thing in your plugin, or can you just call their JS remotely from their CDN? That’s one of those things I’d certainly recommend for most people. Sure, I’m the biggest complainer about people off-loading code, but I also am reasonable and logical. Having everyone load a 130+ meg plugin isn’t sustainable, when Twitter’s made a nice way to do it remotely. That’s a service like a font that’s okay and understandable. After all, I hate that WordPress has to call the new fonts on the dashboard from Google, but at the same time including all the fonts for all the languages would make WordPress 11 megs more. That’s just crazy.

Mind you, I had the shower idea that we could make WordPress download the fontpack when it downloaded the language packs, but we’re not anywhere near that yet. Still, that would kill two birds with one stone in my mind. It’s also illustrating the point of being thoughtful and reasonable about the assets we include in our plugins. You don’t need all the documentation files for a js plugin or most php ones either. It’s certainly easier to just drop the whole package into place, but it’s not always best. If one of those example files has a vulnerability, great, you just shot your user base in the foot.

Limit what you put in your plugins. It’ll be easier that way.

21 November, 2014
WIRED Doesn’t Use Multisite

At WCSF this year, WIRED engineer Kathleen Vignos talked about moving WIRED from 35ish blogs to one blog.

They didn’t use multisite at any point along the way.

Now part of this was that back in 2008, when they started, the concept of multisite wasn’t really there. But that left them in a strange world with 35 separate blogs, separate installs, and an psychotic update system that was headachy and roundabout and involved 35 separate sites. But you could understand why they didn’t in the past, since there wasn’t a way to do it back then, but it brings up the question today.

Why not multisite now?

That was my question after her talk, and I promise you angels sang from the heavens when she said that multisite was intended for siloing data, and she needed to share data between ‘subjects.’ So for them, to have categories and just post articles in the appropriate ones (yes, plural) was exactly what they needed.

I have been saying this for a few years now. Multisite is great, except when it’s not, and there are reasons to use it and reasons to not. WIRED properly looked at their sites and said “We need to share data, Multisite may not be the best.” They also said “We need to make it easier to add users to a site, so maybe not Multisite.” Every single reason they picked to not use Multisite was 100% exactly the right one.

Multisite is simply not what you want if you need to share data between sites and you’re on a big site. Had WIRED used Multisite, they would have been miserable and have to write not just plugins to migrate the data, but ones to join the tables and display data in an ongoing way. What a pain.

Kathleen talked about the hurdles of merging the sites, and the tools they invented in order to make their Pangea happen. They had to worry about logical things, like keeping User A out of a category, and made use of plugins like Restrict Categories to do just that. Custom fields in the author profiles were use to assign a ‘default beat,’ and they made extra roles to allow people to manage the sites. They used template files to make various categories look different, which is often the main pain point.

By doing this, they were allowed to share and segregate data in an efficient and effective way.

WIRED wins my hat-tip for the best talk at WCSF about Multisite, simply by not using it.

You can see the slides here:

WordCamp SF 2014 – WIRED Migration Project from kvignos

And the video here:

[wpvideo n4wrIVIU]

10 November, 2014
WordPress iOS App: Good for Bloggers

This is a big distinction.

The app is great. I love using it to write a blog post when I’m on the go, and save for my annoyance that it wants to default to publish and even if I move it to draft, it saves the date and time that moment in time, it’s a good app.

But it’s not great for non-bloggers.

Let me step back. I run a little database site on WordPress. It’s a listing of TV shows and characters and while it has a blog, it has a bunch of custom post types. Want to know what you can’t write on the iOS app? Pages and CPTs. You also can’t add new users or plugins or anything like that. All I can do is write up a blog post about things. Sure, I can upload pictures but I can’t add them to the library in general, just to posts (and yes, I care about that sometimes). Uploading and setting a featured image is also more complicated than it should be. I often end up with the image uploaded twice.

Realistically, I look at the iOS app and I’m not sure who the target audience is. It’s very easy to add my WordPress.com account and view my reader there, but that’s a different group of people than the ones who want to blog. Then there’s the thought of actually blogging. If you’re on WordPress.com, you can’t add custom post types, so that issue is null, but you still can’t edit pages or Portfolios (which comes with all .com blogs now).

It makes you start to wonder if there should be separate apps, for WordPress.com and self-hosted people, and to that I think not. I’m always going to be logged in to WordPress.com on my iPad because of Jetpack and a desire to see my stats. But at the same time, I really don’t care as much about my WordPress.com blogs. I should, but over time I’ve merged them all into my self-hosted sites because it’s easier for me to go to one place. It’s with that in mind I think we should just have one place for all our WordPress iOS/app needs.

Then you have to consider what the use-case is of a WordPress app. For me, it’s that I want to work on a draft post while on the go and save it offline, only to have it magically get tossed up onto my blog when I’m online. I think of it like Numbers and iCloud. I can edit my archery spreadsheet on my iPhone while I’m at the range and it’s automagically updated on my laptop when I next open Numbers there. Of course, WordPress blogs don’t really work that way.

But at this point, that’s all the iOS app is good for, because I can’t administer my site from it. This isn’t so bad, since people like Boren are rabid mobile-first devs for the WordPress admin dashboard. At the same time, we’ve only had it be mobile responsive since 3.8 or so, and it’s been spotty for doing ‘everything’ due to OS limitations, which makes it imperfect. As much as I’m a fan of using WordPress to WordPress, it’s the simple things that make me look at Desk for my laptop. Someplace to write.

Except for that, the iOS app still fails because I can only write a blog post, and most WordPress sites are more than just blogging now.

At WordCamp San Francisco 2014, I heard more and more people refer to their sites as ‘A WordPress’ than ‘A WordPress blog.’ Every day at work I hear people asked if they would like to setup a WordPress on their site. We’ve verbified the word, but we haven’t verbified the app yet.

5 November, 2014
Why You Can’t (Always) Catch Cache

Or rather, why you don’t want to cache.

When speeding up a site, the first thing we always talk about is streamlining the site. Ditch the redundant plugins, clean up the code, get a lightweight theme, dump the stuff you don’t use, and upgrade. Once you’ve done that, however, we talk about caching, and that is problematic. Caching is tricky to get right, because you can’t cache everything.

Actually you can, but you don’t want to cache everything, and you really shouldn’t.

The basic concept of a cache is ‘take a picture of my website in this moment.’ We think of it as a static picture, versus the dynamic one we use for WordPress. That static picture is not so static, though. You call CSS and JS still, and you call images. But the idea there is not to call PHP or the database and thus your site will be faster, as those are the slowest things.

Great, so why don’t I want you to cache everything?

The obvious answer is latency. If you’re designing a site or making a lot of style changes, you need to disable caching because otherwise you get a lag between edits and displaying text. But there’s also server latency.

When we talk about things like PageSpeed (I use mod_pagespeed my server) to improve web page latency and bandwidth usage, we’re talking about actually changing the resources on that web page to the best practices. This sounds great but we have to remember that by asking the webserver to do the work before WordPress (such as having PageSpeed minify my CSS and JS), we’re still making the server do the work. Certainly it’s faster than having WordPress do it, but there will still be a delay in service.

The next obvious answer is security. There’s some data you flat-out don’t want to cache, and it’s pretty much everything in wp-admin (on WordPress). Why? If you have multiple users, you don’t want them getting each other’s content. Some are admins, some aren’t, and I know I don’t need my guest editor seeing the post about where I’m firing her and why.

Actually, we’ll extend this. Very rarely do I want my logged in users to see a cache at all. They’re special, they’re communicating and making edits on the fly. Having them see cached content, and constantly refresh it, will be more draining on my server than just loading the content in the first place. Remember the extra load caused by PageSpeed (or even your plugins) generating the cache? That would be constantly in progress when a logged in user made a change, so let’s skip it all together.

Tagging on to that, you also don’t want to your admins and logged in users to generate a cached page. This isn’t the same as seeing a cached page, I don’t want non-logged in users to see the version of the site a logged in one gets. A logged in user on WordPress gets the toolbar, for example. I don’t want the non-logged in ones to see it.

Finally we have to round back to security. If I have SSL on my box and I’m using HTTPS to serve up a page, no way no how do I want to cache anything related to users. In fact, I may not even try to cache JS/CSS either. The basic presumption of https is that I need security. And if I need security, I need to keep users out of each other’s pockets. The best example of this is a store. I don’t want users to see each other’s shopping carts, do I? And your store is going to be https for security, so this is just one more feature there of.

Of course, there are still things to cache. I setup PageSpeed on my https site so it will compress images, make my URLs root-relative, and compress and minify HTML/CSS/JS. But I don’t have a traditional cache with it at all. This does mean as we start to look towards an https-only world (thank you Google) we’re going to run into a lot of caching issues. All the quick ways we have to speed up our sites may go away, to be replaced by the next new thing.

I wonder what that will be.

22 October, 2014