Half-Elf on Tech

Thoughts From a Professional Lesbian

Category: How It Is

Making philosophy about the why behind technical things.

  • The Despair of Licensed Updates

    The Despair of Licensed Updates

    I am a massive proponent of people making money off of plugins. I think they can and should find a way to create a business in this ecosystem we’ve created.

    There’s a problem with the approach of some of these products, and in a way we created it ourself, and it hit WordPress 4.5.

    There is a plugin, it doesn’t matter which one, that’s a premium plugin. It’s not available for free on WordPress.org. You have to buy it, get a license, enter the license into the plugin, and in that way get updates. That’s fine. But there’s a complication. Actually a couple.

    Licenses Expire and People Aren’t Informed

    That’s a big ‘no kidding’ moment, but they do expire. And people don’t always notice that their license expired. Even if you post a big sign on the dashboard and email them.

    Worse, people don’t know they have license. One of the major problems with software, when purchased for a company, is ownership. If I buy an app on the company dime, it’s their app. But when I buy an app for someone I’m building a site, and I pay for it myself, even if I charge them for it, who owns it? Who keeps the license? Who has the information for running a site?

    This is an aspect of WebDevelopment where we collapse, regularly. Not just WordPress, every single person who builds websites for someone has screwed this up at least once. Either the information isn’t clear, or it’s not there at all. Regardless, what happens in the end is you have someone who lacks the information they need to keep their company going.

    The Plugin Is Often Bundled in Themes

    This is worse than you think. The official directions for this says that if your theme bundled it, and you need an upgrade, you need to wait for the theme to upgrade or you need to buy a license yourself. That’s perfect, to me, except for the problem I mentioned before. People don’t know. I’m not sure how they should know. But those bundlers, they’re so very problematic because they remove users one more step from the information.

    If I buy a theme, and it has a library inside it, it’s the job of the theme developer to update that theme regularly, test it with WordPress before the new version comes out, and push fixes. If I buy a plugin, ditto. When the stream cross, though, is where we have the drama. Because I know I bought the theme, but I do not know that I bought this mystery plugin, hiding deep inside. Now it’s the theme owner’s job to update and make sure I get the information right away.

    Pretty Much No One Gets It Right

    Not even people I respect get this right all the time.

    Let’s say you’ve written a plugin and have decided to handle all the updates yourself. I buy it, install it, and it works, everyone’s happy. What happens when I stop paying my license? Well I stop getting updates, that’s for sure. But do I still get notifications about them? Do I get an email? Do I even get an update?

    There are some plugins that are free from pay-walled sites, but if you don’t have an active license for that free plugin, you will not get updates. At first I thought it was strange, since if I had a free plugin why wouldn’t I put it up on WordPress.org, right? But then I realized they’re creating the relationship. Once you ‘buy’ the free plugin, you have an account and information in their system. If it’s free, you’re the product.

    All that aside, it comes back to the problem of what happens if that license, free or not, lapses? You could be annoying and pop up on the settings page “Hey! The license expired!” but people hate that and ignore it. You could email, but they ignore that too. There really isn’t a great way to remind people that (a) the license expired and (b) there are updates available.

    Or Is There…?

    What if the updater kept checking, license expired or not, and when you clicked to upgrade it alerted you?

    You license for Foobar has expired. Please renew it in order to upgrade.

    What if you got this email?

    Hey, you bought Foobar back in 2014 and that license lapsed. Normally I’d never bother you, but today I’ve pushed a major security fix. Since this is a security release, I’m offering you a discount. It’s already applied to your account, just log in and you can buy the upgrade at 50% off. If you’re not using Foobar anymore, click here and I’ll have your account flagged so we don’t bother you about this again.

    How happy would you be to find out someone saved your soy bacon?

    This would require the original developers to have your information, which they probably do, and some way to track those two things. That is, did your license lapse and do you care? That’s all they need to track and only one is an ‘extra’ since I’m reasonably sure everyone tracks the license.

    Make It Easy

    If you make it easy for someone to know “This has been expired, here is one click to pay” people will pay. Yes, we love free, but we love easy even more. If you make it easy to pay, people will renew and pay. If you inform them of security issues, they will pay and upgrade. If you push them, the good way, about your updates, and make sure they know, they will be safer.

    And then, when WordPress upgrades, your users won’t hate you.

  • Because Developers Never Typo

    Because Developers Never Typo

    It’s not a problem. Only admins can use this.

    I’d pushed back on a plugin that wasn’t validating their post input wisely. Instead they just slapped sanitize_text_field() around everything and called it a day.

    One of the myriad reasons I’ll push back on a plugin is improper sanitization. When I say that, I mean they need to sanitize, validate, and escape the input. If I see things like update_option('my_cool_options', $_POST['my_cool_input']); I’ll push back and tell them to please sanitize. But really I tell them this:

    SANITIZE: All instances where generated content is inserted into the database, or into a file, or being otherwise processed by WordPress, the data MUST be properly sanitized for security. By sanitizing your POST data when used to make action calls or URL redirects, you will lessen the possibility of XSS vulnerabilities. You should never have a raw data inserted into the database, even by a update function, and even with a prepare() call.

    VALIDATE: In addition to sanitization, you should validate all your calls. If a $_POST call should only be a number, ensure it’s an int() before you pass it through anything. Even if you’re sanitizing or using WordPress functions to ensure things are safe, we ask you please validate for sanity’s sake. Any time you are adding data to the database, it should be the right data.

    ESCAPE: Similarly, when you’re outputting data, make sure to escape it properly, so it can’t hijack admin screens. There are many esc_*() functions you can use to make sure you don’t show people the wrong data.

    I say it often. Sanitize everything (but especially what you save or process), validate input, escape output.

    I understand though, why someone might naively assume that since only admins can do a thing, it’s ‘safer.’ The truth is admins screw up as much as anyone else. Worse, probably, since admins have more power and often think they know better.

    But the point I was trying to make to this guy was that it doesn’t matter who is inputting the data.

    I’ve told this story before. I used to have a job testing software packages for software I didn’t use. We replied on ‘scripts’ from people to know what to test. One day, John C and I were trying to test some new software and every time we hit a certain screen, we’d crash the box. We tried over and over and it failed. So John called the vendor and explained what we were doing. They walked us through it and it crashed. Since we were a VIP, they said they’d send over a couple developers. When the two guys showed up, one watched us very carefully and was shocked.

    The young dev exclaimed, “Why would you ever input wrong data there?!”

    I eyeballed him. “Why would putting in wrong data crash the computer?”

    The older dev chuckled. “We’ll put in an error check there.”

    The lesson I learned is simple. Never trust input.

  • Obviously Oblivious

    Obviously Oblivious

    So I was asked this…

    @binarygary: .‭@Ipstenu‬ I know you aren’t the patent office…but have you ever declined a plugin for “obviousness”?

    I replied, not in jest, that I had declined some for obliviousness.

    Gary’s plugin was obvious in that it did exactly what it was purported to do, and it did it well. And it had a puny name. I quite liked it and approved it pretty quickly. But the crux of the question is interesting. Have I ever rejected plugins for being too obvious?

    Not that I can remember. In fact, I kind of love the plugins that do exact what they claim to do. Like Rickroll which turns your videos into Rickroll or Logout Roulette which gives you a one in ten chance of being logged out. Those are simple and obvious and a little stupid, but they’re perfectly obvious and only the oblivious would be confused.

    An obvious plugin is possibly the best kind of plugin. My buddy Otto once remarked that well named functions don’t need documentation. If you have a function named reset_the_loop it’s pretty obvious what it does. Now you might need to add some docblox to explain how to use it and what parameters you can pass through to it, but in and of itself, it resets the loop!

    On the flip side, here’s rts_reset which is actually a function I saw recently in a plugin. Okay, what does that do? It was in a class named RTSCode which didn’t help at all. And there was no inline documentation. After a while, I traced everything back and sorted out what the heck the code was doing (it was reseting a query, but only if you passed specific params back).

    In general, a WordPress theme and plugin should be painfully obvious. It’s open source, it’s code anyone can look at, and yes, it should be stupid easy to understand what it does and why. That’s the meaning behind ‘open’ in so many ways. Open for everyone. Open to be forked and learned from and studied and made more perfect. Or at least more fun.

    I like obvious things. Obvious is good.

  • Dependency Disaster

    Dependency Disaster

    Over the last few weeks and months, the nightmare that is WordPress plugin dependency hell has waxed and waned with the ire of a thousand burning suns. It flared up when I, perhaps naively, posted a reminder of a rarely called upon guideline to not submit Frameworks for hosting on WordPress’s official plugin repository.

    This brought up the perfectly valid arguments that these repositories are useful as they allow for deployment and updates that were hitherto unavailable when rolled up into one package. And at its heart, I understand their point and agree with them as to the benefits. But since WordPress core doesn’t have true plugin dependencies at this time, it’s exceptionally complicated and a hassle to include them.

    Personally, I feel that the NPM or Composer style development of plugin is the way to go. Development. Not deployment. With few exceptions, I feel the best way to release a plugin is all in one, rolled up together. The exceptions are, of course, plugins that are add-ons to others, like a plugin that adds a new email integration hook to MailChimp, or a new payment gateway for WooCommerce.

    The rest of our plugins should be self contained, reliant on naught but ourselves. I have two plugins which contain the same AWS SDK libraries, written in a way to check if the library is already loaded and to make sure it only loads what’s needed. Why did I do that? Because then someone can have one or the other or both without conflicts.

    The user doesn’t have to care about dependancies. They are invisible. That is as it should be. Users don’t have to care.

    But there’s also a danger with dependancies, as recently came to light in the JS world. Azer Koçulu liberated his modules from NPM after the threat of a trademark based lawsuit had NPM remove one of his projects.

    Sidebar: Open Source has no right to impinge on trademark law. Period. However some lawsuits are frivolous and daft and should be contested. Sadly most communities (NPM, WordPress.org, etc) do not have the money or resources to fight that battle for a developer. If you chose to fight, please contact the EFF.

    As is his right, Azer pulled all his packages from NPM. The fall out from this package removal is that a lot of automated builds failed. This has to do with the way Composer is often bundled. Instead of a wrapped up package like an exe or a dmg, it’s a stub that reaches out and downloads all its requirements on the fly. Just like the TGM Plugin Installer. Right? And what happens when those requirements are missing? The build fails.

    Perhaps worse, by unpublishing the name slugs used can be taken over by anyone else, and used to push more nefarious code. This did not happen. NPM checked everyone and verified they were as decent as one can before handing over the old names to new owners.

    My first thought was “Could this happen to WordPress?”

    Yes and no. First up, we don’t reuse names. If you have the plugin ‘foobar’ and ask to have it closed, the name is still reserved. In extremely rare cases we’ve turned over names to trademarked owners (like how Facebook owns the facebook slug) but always with communication of both parties and always with awareness to how many users might be impacted.

    But could we pull a plugin for trademark infringement and screw up package dependancies? You bet your ass.

    We’ve been lucky that all legal parties involved in similar arguments have been accepting of the ‘grandfathered’ ruling. That’s why we still have plugins with slugs like ‘google-analytics-by-joe’ out there. But it’s also why we don’t allow any more. And yes, when a plugin with a unique name is submitted, we do take the time to check if it’s already trademarked. To spare people this drama.

    But yes. It could totally happen. And since we have to name our dependancies and rely on those slugs, there’s no easy way out.

    I suggest reading the Hacker News thread on the matter. They weigh both sides of the issue, and show you how the pros and cons make this even more complex.

  • The Pressure to Succeed as a Woman Who Codes

    The Pressure to Succeed as a Woman Who Codes

    I feel a disproportionate amount of pressure to succeed in coding.

    I call it disproportionate because it’s only about 1/3rd of my career. The other two are support/training and public speaking. And while I used to have a fear of public speaking, I’ve somehow managed to discard that and I’ve got no concerns at all about screwing up on stage. I might. My talk might flop. My training might not be understood or adopted. My support may be wrong.

    But what scares me to the point of tears is coding.

    It’s not that I’m bad at it. Intellectually I think that I’m pretty good. I’m not the greatest in the universe, but that’s a realistic stance as opposed to anything else. And I enjoy playing with it, inventing new things, seeing how they work, helping people solve problems with code. It’s honestly fun.

    Looking at the Stack Overflow Developer Survey I noticed that only 5.8% of the participants identified as female. Taken a different way, 92.8% of people had no problem saying they were men. Now, SO is aware of the disparity, and mentioned this:

    Our survey results demonstrate a dramatic disparity in tech among men and women. In fact, we know women make up a more significant proportion of the developer workforce than this suggests. According to Quantcast, about 12% of Stack Overflow’s readers are women. (We don’t actively track gender internally.)

    I have a personal theory that gamification appeals more to men than women. This stems from reading about Richard Bartle’s player types way back in the 90s. It was a big thing in MUDs and MUSHes, and the Bartle Test is essentially a series of questions that can be used to identify the classification of a player into one of four types: Killers, Achievers, Socializers, or Explorers.

    Now it helps if you’ve read a little of Hearts, Clubs, Diamonds, Spades: Players who Suit MUDs, but you can get by with the Wikipedia article. The main point is that we can classify people into player ‘types’ based on what they enjoy doing and how they like doing it.

    In general, winning and hacking are associated with Killers and Achievers, while helping and curating fall under Socializers and Explorers. And when I say it like that and you look at things like programming vs support forums (of which I do consider Stake Overflow), lines start to be drawn. These lines are carved in stone when you consider some of the research gamerDNA did into what kinds of player played what kinds of World of Warcraft characters, and what their genders were.

    What does all this have to do with the unrealistic expectations on women who code?

    If one buys in to the hype and typecasting, then one would say that women (nurturers) are more likely to be socializers and explores. Regardless of if this is accurate, there certainly is an expectation on women that they are ‘mothers’ and, from that, they are often unconsciously perceived of being a specific player type. And when someone steps out of what people feel their norm is, they’re often set upon.

    This is not solely endemic to women, of course. Men who express emotions publicly, like crying for example, are also set upon by others for not being manly enough. And that is precisely my point. People who don’t fit the stereotypes of what gender is get pushed back. People who act ‘out of character’ are looked upon as odd.

    Okay, so why do women keep feeling pressured? Because shit like this happens:

    You can look up the ‘fake geek girl’ phenomenon on your own. The fact is that it applies to anything not stereotypically female that a woman does. And it means that, in order to be taken seriously as a coder, we have to achieve great things or all we’ve done is prove we’re only good for the ‘fluff’ of support.

    Eddie Izzard makes a joke in his “Dress to Kill” routine about men who wear dresses and heels:

    You know, if a woman falls over wearing heels, that’s embarrassing, but if a bloke falls over wearing heels, then you have to kill yourself. It’s the end of your life. Its quite difficult.

    And while we laugh at it, the truth is that ‘abnormal’ behavior is treated with incredibly high expectations. Unrealistic ones. Unfair ones.

    I don’t have an answer to this, and for now women shoulder the burden of being expected to be greater than men of identical backgrounds, simply because of how we were born.

  • Project Bloat

    Project Bloat

    Can we have a serious talk about project bloat?

    During the framework kerfluffle, I remarked that I hated seeing a 10 line plugin needlessly include a framework like CMB2 because of the size of plugin it created. Someone remarked that if the library helped them write something in ten lines instead of 100, wasn’t that better?

    And the answer to this is maybe.

    My issue is not using a library when the library is the best solution. My issue is people defaulting to use a library before they think about if it is the best solution.

    And my point is really quite simple and obvious to a large number of developers. I’ve touched on it time and again. I’ve told you how I handle packaging my vendor folders. Simply put, I think that before you include anything in your project, you should evaluate it’s merits and flaws.

    Look. There are always, and will always be, good reasons to use a library. There’s never a reason to use a library thoughtlessly, and that’s what I see every day. By ‘thoughtlessly’ I meant someone who has a plugin that adds one setting, a custom meta field let’s say, into all posts. And in order to do that, they wrap ACF into their plugin.

    For one field.

    One.

    Literally one.

    Jackie Chan WTF Meme Face

    And I get it, I really do. The settings API is a bag of wet hair, and the fields API needs love (so much props to Scott Clark for his work there), and figuring out how to do things can be a comprehensive battle of trial and error vs ‘How much hair do I have left?’ And yes, I do use some of those libraries, like CMB2 and ACF, when the need calls for it. When I’m making a massive custom tool or theme and I need to do a million things. But …

    What I don’t do is use it for one field. Sure I could, but that would make my plugin very large and to no real benefit except it’s ‘easier’ for me. And even that is questionable. When I do use them, and yes I do, I do so thinking about the weight I add to my project.

    A pause here. I say this a lot, the weight of a project.

    Everyone seem to assume I only mean the size (in MB) of a project. I don’t. When I say the ‘weight’ of a project I mean the file sizes, of course. Making your 10kb plugin over 500kb just to add one field (I’m being literal here, folks) is sketchy at best. Making it over a meg is borderline ignorant. But I also mean the weight of how it impacts the speed of the site. Will having the library called make a site slower? It might. And I also mean the weight of technical debt. Am I going to update the plugin and the library every single time? This is my responsibility now, and I have to test and test and ensure I don’t break anything.

    The weight isn’t just the size, it’s the time sink. It’s everything that has to go into keeping a library included in a way that doesn’t conflict with anything else. It’s managing my time so I can test and evaluate changes. It’s making sure I push code that won’t break on new versions of my main project (i.e. WordPress). It’s making sure my changes don’t break other co-projects (like WordPress plugins and themes), by assuming they’ll always work on the newer versions. Backwards compatibility isn’t a requirement for all projects, but when it is, you bear that weight too.

    And the weight is also the fact that I’m robbing myself of a greater understanding of WordPress core. Using a library isn’t ‘cheating’ but it does mean I might be less capable of debugging a conflict, if it’s due to the library.

    That’s the real weight of a library included in your project. If you’re not considering it when you add a library, you’re doing yourself a massive disservice.