Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: essay

  • You’re Not The Priority With Free Support

    You’re Not The Priority With Free Support

    Once in a while, someone flies off the rails when they don’t get a fast enough answer for their question in a freely supported product. They don’t get the right answer, or they get what they feel is a run-around by a total stranger trying to understand the real problem, and basically they feel the service should be better.

    Here’s a cold hard truth.

    When it comes to free support on free products, you aren’t the priority.

    Usually when people get shirty about the ‘lack of quality support’ I point out that (on WordPress.org) support is handled predominantly by unpaid volunteers who are offering sage advice and help out of the kindness of their hearts. This is mostly true. Some of us are paid by our companies to volunteer, others are doing it to master skills (not much teaches you how a product works faster than helping someone else debug it), and others do it because they enjoy it. But as far as WordPress goes, it doesn’t directly pay anyone to do support.

    Sidebar: Automattic isn’t WordPress and doesn’t own WordPress. Automattic is a company who pays for some of their employees to help out in the forums. And it’s making my point. Some of us get paid by our companies.

    When I tell people that they need to scale down their expectations, what I don’t mean is they should expect worse help, but that they should expect slower help. Because they’re not the priority.

    What’s my priority? Number one is my family (hello). But after that you get my paying job. Keeping abreast of everything WP related that impacts us, keeping on top of server changes, looking for patterns in tickets to see if we missed something, and generally knowing everything I possibly can about WordPress at DreamHost. After that my priority becomes the websites I run (like this one) and other hobbies I have.

    That begs the question of when is WordPress public support my priority? When I have the time. I try to carve out at least a couple hours a day to check in. These need to be consecutive hours, a nice block of time to catch up and read and help. I don’t always get it. Sometimes I get thirty minutes. And when I am helping out, I prioritize my time.

    If there’s an alpha/beta of WP out, I check there first. If we just released a new version, I’m over in the general troubleshooting. Then I hit Multisite, because we have a very small amount of people there. If I still have time, I’ll get the ‘Requests and Feedback’ and ‘Misc.’ forums. Next I hit up the dread Ideas forum, clean out the spam, and sort things that are dupes or solved or in the wrong place.

    And then I’ve hit how much free time I have, so I go over to plugins for reviewing those. Anyone who was closed for a security issue comes first. After that, it’s anyone who replied to our emails. Then I close out anyone who didn’t reply in 7 days, check for people with bad plugin names, and finally I can start in on the queue.

    It’s a lot to do on top of a day job. So sometimes you will get a reply from me at 8am and then nothing again for 24 hours, because all of those things are important to people and they all need to be taken care of and you, personally, aren’t my number one priority. It’s the same reason why you may not get immediate replies from anyone volunteering, and its why I tell you to lower your expectations.

    Free support isn’t better or worse, but it does run at it’s pace and that may not be yours.

  • Don’t Be Afraid To Learn In Adversity

    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.

    Toy dinosaurs attacking an action figure
    “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.

  • Whose Responsibility Is It?

    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.

    Caution Minefield sign

    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.

  • Don’t Reinvent the Wheel

    Don’t Reinvent the Wheel

    In WordPress, I punt plugins now and then for doing weird things that can best be described as reinventing the wheel.

    Any time a plugin replicates functionality found in WordPress (i.e. the uploader, jquery), it is frowned upon. It presents a possible security risk since the features in WordPress have been tested by many more people than use most plugins. Simply put, the built in tools are less likely to have issues.

    This was always something a little theoretical. I hadn’t yet run into someone who had broken their code with an upgrade of WordPress just because we updated the core wheel. Until November 20th.

    The shortcode API in WordPress was updated. It was decided that in order to stop breaking on PHP 5.4.8 and under, we needed to apply wptexturize() to shortcodes. This had a fun side effect when people didn’t properly register shortcodes, which of course brought up the logical question … why wouldn’t you register your shortcode?

    What I generally see in plugins is someone’s using a filter to look for their shortcode instead of registering it, so the post content is, in it’s entirety, parsed. That always struck me as foolish, since posts can get pretty long if Chris Lema or I are writing. And the reason people would do it was also odd. Either they were being lazy, they didn’t know about shortcodes (which I can understand, you can’t know everything), or they were trying to get around an ‘issue’ with nested shortcodes.

    For what it’s worth, the shortcode parser correctly deals with nested shortcode macros.

    [tag-a]
   [tag-b]
      [tag-c]
   [/tag-b]
[/tag-a]

    That works fine. This won’t:

    [tag-a]
   [tag-a]
   [/tag-a]
[/tag-a]

    Now I want to note, I’m using a php shortcode around those tags. So yes, it works great. But the problem would be if I wanted to show you the php code in a php shortcode… Doesn’t work that way, and it’s a limitation of the context-free regexp parser used by do_shortcode(). We went for speed over levels, and it can’t match each opening tag with its correct closing tag.

    Obviously the ‘right’ answer is ‘don’t nest same-named shortcodes’ but instead, some plugin authors have chosen the strategy of not registering shortcode names. That way the parser doesn’t try to mess with it. Sounds great, right?

    Not with wptexturize() running.

    [tag-a unit="north"]
   [tag-b size="24"]
      [tag-c color="red"]
   [/tag-b]
[/tag-a]

    That turns into this:

    [tag-a unit="north"]
   [tag-b size=”24”]
      [tag-c color=”red”]
   [/tag-b]
[/tag-a]

    Basically the code is understood to be code and not a quote. That means it would simply output the tags as code and not the tag content.

    And you see why this is a problem.

    There are two answers to fix this. One is to turn off wptexturize for your pseudo-shortcodes (via the no_texturize_shortcodes filters which are not complete, sadly, if you need to unfilter shortcode variables) and the other is to use the Shortcode API as it was intended. I would, personally, suggest you use the API since that prevents your code from breaking like this if another security update happens.

    Which brings us back to why reinventing the wheel is generally foolhardy in robust, well maintained systems. WordPress is constantly being improved, fixed, patched, and secured. The more you work around it by making your own way, the harder it is to fix things when WordPress makes a change. You’d think that people who make their own wheel would be attentive to anything that might break it, but they rarely are. They make their way, forget about it, and get annoyed when their code breaks and blame WordPress for not warning them. That’s a dirty secret about Open Source. No one’s going to tell you that a change will break your code. They expect you to be paying attention.

    The absolutely worst part about all this is that your users will have to decide to either stop using your code (which isn’t always an option) or not to apply an upgrade. In the case of 4.0.1, this is dangerous. This is why I will keep telling you not to reinvent the wheel, unless the wheel really needs it. And if the wheel needs a reinvention, you should consider submitting a patch to WordPress core, because if it’s that bad, everyone should know.

  • Including Assets

    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?

    Github repo for Colorbox has a lot of files

    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.

  • Why I Like Font Icons

    Why I Like Font Icons

    I really like Font Icons and I’m willing to bet there was a period of time you did to, way before we had the Internet on our phones. Do you remember Wing Dings?

    Wing Dings Example

    When I was a kid they were awesome. We used them to print up secret code letters in the ’80s, using the basic letter shift kind of cypher. Wing Dings is, at its heart, a font icon. This means it’s a font that uses shapes instead of letters, but unlike Wing Dings where I could type “cat” and get “hand arrow flag”, a modern font icon has special content terms like “f401” that you use instead. Of course those are hard to remember, and we all like to use shortcuts, which I’ll get to in a second.

    The reason I love them is that I am a monkey with a crayon when it comes to design. Did you ever try to make an image that, when you rolled the mouse over it, it changed color? Like the official Twitter image you wanted to spin when the mouse hit it? We used to do that with images, CSS sprites, and combine all the images into one large image, load it once, and then with the magic of CSS have different bits load at a time. Sprites and Bitmaps can do that, but adding in new icon to the set took time and Photoshop and if you’d lost your designer in the meantime you were out of luck. Font icons lower the bar and make it easier for everyone who can’t design.

    Font icons are easy to style. You can resize, recolor, flip, shadow, and apply rollover effects with just some basic CSS. They also scale well which means they were pretty much born for retina. No matter the size of your device or the quality of your screen, the font icon will never look jagged and blurry.

    So how do we use them? It’s only three steps and the third is beer. Seriously, though it’s really that simple. Include the font family, just like you would a google font, or do it locally. Call the icon, show the icon.

    1. Include the font in your site
    2. Call the icon you want with the span html tag 
      <span class="genericon genericon-aside"></span>
<i class="fa fa-beer"></i>
    3. Drink a beer [ficon family=FontAwesome icon=beer color=brown size=3x]

    That beer is a font icon by the way.

    There are plugins, for most of the popular ones, that will let you insert using shortcodes. Those are easy to use for when you want to put an icon in your post content. I wrote two of them, Genericon’d (which brings Genericons to your site with shortcodes) and Fonticode (which lets you apply shortcodes to most of the major font icons, provided they’re already included in your theme or another plugin). But wait, there’s more!

    As I mentioned, you can use them in CSS, and by that I don’t mean you can style them. What I mean is you can use CSS to call a font icon and put it in a menu, which is a little trickier since you need to use the before call, and that is a little weird. I talked about how to do this before in ShareDaddy Genericons (which is now useless since Jetpack went and did that for everyone) but the point is that you have to mess with CSS and it looks like this:

    div.sharedaddy .sd-content li a::before {
    font-family: 'Genericons';
	font-size: 16px;
	color: #fff;
}

div.sharedaddy a.sd-button>span {
    display: none;
}

div.sharedaddy .sd-content li.share-twitter a::before {
    content: '\f202';
    color: #4099FF;
}

    As an example, this is a pretty basic one. The magic sauce here is that I say “Before all my links, use the font family Genericons with this size.” And then “Before Twitter, I want to show the content \f202″ That happens to be Twitter’s icon. The color I used is also the official Twitter blue. You can get even fancier and I suggest reading Justin Tadlock’s post on Social nav menus.

    The obvious next question is where can you find font icons? Here’s a non-exhaustive list.

    I will note that some of these are not GPL, so it’s on you to check the licenses for what you want to use them for. Like Glyphicons? You can use their Halflings font freely, but not the full Glyphicon pack. Similarly, Icomoon has a couple font packs that aren’t free and for full distribution, but does have one you can use. So please, please, be careful and be aware. You can use the non-GPL ones on your own site (most of the time) but you can’t package them in a theme or plugin.

    Before someone asks, let me talk about Dashicons. That comes in core, so you don’t need to worry about including that. I wouldn’t use it on your site, since it’s meant for the WP Admin back end and nothing more and the size is a little off because of that. You can totally use it on your plugins. So instead of making an image, you can use a Dashicon to be the icon on the menu sidebar. This may one day change, but not today.

    All this love doesn’t mean everything’s awesome. There are some issues, like how Icon Fonts Are Ruining Your Markup. And you should read Ten reasons we switched from an icon font to SVG for some great reasons not to. You also need to keep in mind accessibility, like screen readers, and for that check out Bulletproof Accessible Icon Fonts.

    Nothing’s insurmountable, and the easy of a font icon without having to mess with GIMP or Photoshop or pretend I know what I’m doing with art is worth it all for me.