Tag: essay

The Perils of Symbol Selection

When I started my little experiment with showing icons on custom taxonomies, I began with a text field. This was because it was the easiest to edit and change right away. Next I changed it to a selection dropdown, based on the content of the folder where the I’d stored my images.

And for the most part, that’s pretty cool. Except for the part where drop-down select boxes can’t show images. This meant I had to show the image name. Generally that’s okay. I know the name of the image I wanted to use. The problem is that I know that because I know the images I uploaded. For someone else, that’s 800 images or so they have to guess at, based on names.

After playing around with selections and forms for a while, I determined there really isn’t a great way to show a list of images natively. No matter what I was going to have to mess with this the un-fun way because the easy way, CSS, failed. You can use background-image in Firefox but not Chrome or anything else that people use.

Good news! As of jQuery UI 1.11, the selectmenu widget exists. Bad news! It’s not actually simple to implement. In fact, I absolutely failed at implementation. Let’s talk about why I failed, because it’s not just a matter of how convoluted the code is.

A large part of my failure in this is due to the scale. If you only have one or two images, it’s less stupid. But when you get around to sets of 800 images, you start to understand why WordPress has a media uploader the way it does.

The biggest factor, though, is that searching ‘visually’ is a difficult system to maintain. Symbology, the art of getting a ‘thing’ to represent another ‘thing’ is incredibly hard to pin down. Look at your WordPress dashboard. Why does a pushpin represent posts when they’re not all that different than the ‘two sheet’ icon of pages in functionality? Why is users a single person icon and not multiple people?

Ask yourself this: if you’re adding in a new menu item, what do you make your icon? Do you make it your brand logo (a G in a circle for StudioPress’ Genesis theme)? Maybe you make it a cloud with a down arrow to indicate downloads (as does Easy Digital Downloads). We wanted to add in a new Custom Post Type for ‘Characters’ and ‘Shows’ for my database site and Tracy, who is amazing at this sort of thing, cheekily picked a video camera for ‘shows’ and a name tag for ‘characters.’

I had a related but slightly different issue when I wanted to use Mark Jaquith’s meta I Make Plugins plugin. I wanted to see my plugins on the sidebar with a more unique icon. I couldn’t use the most logical one, a plug, since we’re already using that for Plugins. I went with a little ‘awards’ icon.

In both cases, we studied the list of Dashicons and picked the ones that made the most sense, but it required a visual study of what we really needed and an understanding of how they all worked. Scrolling down a massive list of all of those is annoying, but necessary. You need to look at your options, think about them, and feel what they mean contextually.

I haven’t yet figured out a perfect solution, but I’ll let you know when I do.

13 May, 2016
The Beta Tester’s Paradox

In a nutshell, the paradox is this:

The more likely a person is to test Beta and RC, the less likely they are to have bad code.

When people wonder why problems like the recent jQuery flub manage to make it all the way into the wild, they tend to assume the issue is not testing enough. They’re incorrect. The issue is not testing enough.

Put the lead pipe down.

What do you think ‘enough’ is? I promise you, the majority of people who have a broken site will say “It needed more time being tested.” And in return, the majority of developers will say “It needed more people with more diverse setups testing.”

So which one is right? They both are. We need more of the right people testing. We need people who are on the edges of ‘normal’ for WordPress. The problem is that the ‘right’ people are the people who have the worst code.

Take a look at WordPress 4.5. Not a single beta tester was using a plugin or a theme that used jQuery improperly. Look at Jetpack 4.0. Not a single beta tester had a server config that broke, but within 12 hours they had over 300 tickets about an error 500 on many sites. In both cases, a significant amount of testing was performed. People banged on the code and outright tried to break it. Just not the right people. And the worst thing is we cannot know who is the right person until after something breaks.

This leads to the other part of the paradox.

Someone whose site breaks after an upgrade is less likely to want to beta test.

This is because we’ve broken the trust. They cannot accept that their site went down, or their computer crashed. Or maybe they can’t afford to be Janie on the Spot and jump every time their site needs a bit of an extra hand when an upgrade goes bibbeldy.

Of course, this is why the people who are testing are less likely to have a problem. They don’t want to waste time debugging stupid code problems, so they put the time in front to make sure they don’t introduce bad code to their environment.

We create a vicious circle, because the only way to get better results from beta is to get more people beta testing. But few people are willing to fully beta test on a live site, and say what you will, there’s nothing quite like live testing on a real, production site. You can’t stress test reality until you get your setup on your server on your design on your everything.

6 May, 2016
Open Source Doesn’t Mean Public

Someone made a vague implication that my post about licenses were shots fired from someone who doesn’t ‘do’ but is only an ‘observer.’

This is quite inaccurate, though I don’t blog about it here and I don’t talk about it anywhere for one simple reason. I can’t. I signed a paper, years ago, that agreed the work I did for them would be private. I would neither reuse the code (which I can’t anyway) nor would I discuss it. In fact, I had to make a phone call to ask if I could blog about it in general. I understand why someone might assume I’m not speaking from experience, but that just makes an ass of you and me.

This isn’t about me refuting or dismissing allegations from someone who, for whatever reason, dislikes me and likes to make their hate public. No, this is about the interesting predicament about what happens when you can’t release information about your code.

Half Open

Here’s your scenario. The front end is an open system, a plugin say, that one installs on WordPress. It’s GPLv2 (or later) compatible because it’s distributed code I want to put on WordPress.org. That right there is a requirement. Alright, so I have one half of a product that is GPL and Open Source. The other half lives on a server somewhere in the world and does all the backend work. The plugin? It just passes API data too and fro as needed.

I just described Akismet.

You and I know very little about how Akismet works on the backend. And here’s the thing, that’s how it should be. We have a lot of information on how to interact with the Akismet API but none about how it actually calculates what is and isn’t spam on the back end. I repeat – this is the way it should be.

Look at what Akismet does. It magically identifies spam. While it’s all well and good to be open source, the very first thing that would happen if they opened up all their code is we would see spammers read it and subvert it.

But then again, we have things like SpamAssassin, an open source product I use on my email servers. Does this mean SpamAssassin is too dangerous to use? Does it mean it should be avoided? No, absolutely not! While it’s far from perfect, SpamAssassin does a phenomenal job at catching and stopping spam. But at the same time, it’s imperfect and being public, it’s more likely to be subverted by clever spammers. Thankfully the things it checks for are parts of email that a clever server admin can protect from and, all in all, it’s useful.

Half Closed

If we accept the fact that having a code base open or closed actually has very little impact on it’s usability, then why do we lock down our systems? That’s easy. Security and profit.

Profit is the easy answer. If a system is closed then you can’t download it and install it for yourself. This means if you want to use it, you have to pay. Again, we can look at Akismet and VaultPress, which I would wager actually are built on open source code, as examples. They don’t have to be free, after all. There’s nothing wrong with being closed, either.

By making a system a closed system that no one sees the backend code for, we create a product where only people who have access to the source code can easily infiltrate. This, of course, offers no assurance that it will never be hacked, only it raises the bar and makes it harder to deal with when it does get hacked. But at the same time, it is harder to hack an unknown than a known, and it does make things somewhat safer.

Of course, if I told you all the ATM code in the world was not only open source but freely distributable and it was out there right now, how would you feel? That probably filled you with a little dread, thinking about how much trouble we already have with card skimmers and ATMs. If we have people who already know how to jack in, how much worse could it be if they knew how to encode software into the fake cards they make, and use them to backdoor your accounts?

Have Your Cake And Eat It Too

Just because the code you work on is open source doesn’t mean you can talk about it in public. Just because the code is closed doesn’t mean you can’t.

I’m not talking about licenses here, though, I’m talking about contracts. I signed a paper about certain code I’ve written that prevents me from discussing it. So while I’d love to tell you everything about everything I’ve worked on, I can’t. But that’s not a bad thing. I’ve been privileged to work on the open and the closed, and it’s given me a greater appreciation and understanding of when we should and shouldn’t open our work. And this comes down to understanding the nature of the risks involved.

Things like ATMs, financial trading, and mortgages should be secured and private. Why? Because the risk is much too high. A license? Well a worst case scenario is that someone figures out how to backdoor a free license for themselves. Another is they figure out how to use someone else’s license to gain access to their information. Those are pretty bad. So if you want to make your license API open but the code behind it not, I support that call.

But. I do think you should have a way to manage your licenses and updates. That’s just business sense.

4 May, 2016
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.

20 April, 2016
On The Fly Checklists
When you do the same thing over and over, the best thing to do is automate it. We all know that.

However there are simply some things you cannot automate. As horrible as that is to say in today’s world, you cannot automate things like “Proofread content for errors.” Why? Well a computer only knows to look for what you tell it to look for. And if you habitually typo homophones, you’re in for a long day.

That’s why we have things like checklists. Do X, check Y, etc etc. They’re there to ensure when we run the automated steps, we do everything properly.

I spent the first half of April generating Pre-Flight Checklists for a lot of things. How to upgrade things at DreamHost, how to update things at WordPress.org, how to migrate from X to Y, and so on and so forth. The sad thing is that I’ve had to do all these for long standing processes which exist mostly in someone’s head.

Here are some tips to how I do it.

Write Your Checklist As You Do It

If it’s a process you know, have a document open (or a piece of paper) and write as you go, enumerating every single step. Be pedantic.
On Your Computer:
1. Generate list of X
  
  Go to Y and click BUTTON
2. Copy list to DOC
3. Run TOOL to output new file
4. Add new file to repository
  
  $ git commit -a FILENAME
  
  $ git push
On Remote Server:
1. SSH to 123.45.67.89 as your ID
2. Go to folder BAR
  
  cd /home/blah/foo/bar
3. Dryrun sync command
  
  sync bar baz –dry-run
You get the idea. Like I said, be specific and get every single thing you do. Don’t worry about getting everything perfect. This is about getting all the information.

Walk Through Your Checklist

Once you have it up, walk through it and do everything (except the actual code push parts). This will show you how you can clean it up and what needs to be explained better. I find it helpful to ask myself “If I was new, would I know what ‘the remote server’ is?” If the answer is no (which it often is), I become more pedantic and specify what server to connect to and exactly how.

For example instead of “Connect to Servername” I’ll put in this:
- Connect to production server
  
  ssh servername — use your ID and password
Using the different font helps me to know it’s a command and not directions. Any time you feel something is vague, explain it. Put in examples of output. Don’t be afraid to break the ‘flow’ of a checklist to ensure clarity.

Ask Someone Who Knows to Proof

If this is a process someone else has done, grab them and have them skim it for anything obviously wrong. Often I’m writing and refining a checklist for something I don’t actually do, but I watch regularly. With that mindset, I’m able to write from a place where I know enough to know what has to be clear to someone new. A place of no assumptions.

That person should question your claims. if you say “Check X” and they come back and ask you “Why are you doing X in step 15? You do the work in step 4. Why not do them together?” That’s a good thing! You want to be clear, but if there’s work that’s duplicated, you can save yourself and the future-you time. Also that person is going to be the one who says “We should explain why we do this…” They’re going to teach you more about the process.

Ask Someone Who Doesn’t Know to Proof

This is harder. You need someone who knows ‘enough’ that you’re not explaining what SSH is, but doesn’t automatically make assumption. This may be why I end up on checklists a lot. I pestered the hell out of my coworker, Mike, and asked him to explain things in broad terms and then nitty gritty. I asked him to walk me through the steps, then I wrote them down and turned around to someone else and asked “Does this make sense?”

Why? Because Mike was too close to it to see the forest for the trees, which is a good thing! He knows it all! I was fairly close to it, enough to possibly get in over my head. By grabbing a total novice, we had the trifecta of brilliance. That third person asked “What is this?” and noted multiple things that might be wrong.

Release and Iterate

You’re going to miss things, so every time you do the process, have the red pen ready.
15 April, 2016
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.

8 April, 2016