Category: How It Is

Making philosophy about the why behind technical things.

Boundaries
My friend and coworker tipped me on to this post about The Asshole Filter which begs the question: “Why is everyone I deal with an asshole?”

The post goes on to talk about how the issue is that if we draw a line in the sand but then allow people to cross that line, or worse reward them for doing that, we’re hurting ourself. In the example, a fellow named Fred used to accept personal emails about a project but now asks them to be sent to a group email.

[…] some people use fredsstaff@fredsconvention.tld and some people use Fred’s personal email.

Who uses the officially designated email address?

• People who feel strongly about following rules.
• People who feel following the rules is generally a good idea.
• People who respect Fred’s request because they’re generally respectful.
• People who respect Fred’s request because they like Fred personally.
• People who don’t want to antagonize Fred.
• People who realize the problem Fred is trying to solve and want to be cooperative to reduce the burden on Fred.
• People who feel it important to respect role boundaries.
• People who are concerned that overwhelming Fred will cause their request to get lost.

Who uses Fred’s personal email address?

• People who can’t be bothered to learn and follow procedures.
• People who feel rules are for other people.
• People who feel they should get to cut in line.
• People who don’t feel keeping track of what other people prefer is all that important.
• People who aren’t troubled by the thought of pissing off Fred, either because they don’t care whom they piss off or because they think Fred is of no account.
• People who feel entitled to get their way.
• People who feel satisfaction when they find an illicit “shortcut” to getting what they want, that “suckers” are too “chicken” to use.

In short, the decent, cooperative, law-abiding people all use the departmental email address, even though it doesn’t work a well as they might like, while the assholes continue emailing Fred directly.

Did that just sound familiar to a lot of you who are thinking “I can just email Mika about plugins…”

People often ask me why I sound angry when I tell you “Please email plugins@wordpress.org, don’t tweet/DM/Slack me asking for status. Just use the email and sit on your hands a bit.” I’m actually not angry. I’m annoyed. There’s a huge difference.

Angry me logs off and calls it a day.

Annoyed me rants a bit to someone who understands, or maybe says something passive/aggressive on Twitter about “Please use the plugins@ email…”

In both cases, though, I probably waste at least an hour of my time not getting to the things everyone wants be to get to. In both cases, I feel incredibly disrespected and used. Yes, used. Because even when my friends say “Hey I have a quick plugin question…” the answer has once been a quick one. That question? Someone asked if he could adopt the plugin of a friend of ours who had died.

First of all, that’s just an unexpected question by anyone’s standards (and it’s why we came up with a policy about handling death among developers). Second of all, it’s a touchy subject on it’s best day, so asking how to handle it was respectful. Third… He actually asked if he should just email the group.

This was someone who clearly understood the reality, the situation, and the fact that there will always be exceptions.

The sidebar of this issue is that, even if I ask someone to email a group, nine times of out ten it’s me who replied.

I can give you a really long explanation, including how I plan to use those emails to train up new reviewers so you don’t have to wait on me, but let me ask you this instead.
- Are you more or less important than everyone else who is waiting for their plugin to be reviewed?
In general, if you get the ‘snippy’ reply of “Dude stop fucking things up and use the right channel” then I’ve already asked you, at least once, to “please” use the email. I’m very careful to ask nicely since I know there’s no possible way for everyone to know things. Mistakes are totally okay in my book. Intentionally trying to jump a queue just makes you an asshole, no matter your intentions. You’re disrespecting everyone, me and every other plugin developer out there, by demanding you get attended to first.

Okay.

So what would be a good reason to ping directly? Well about the only reason people do it that I consider thoughtful and respectful is this:

Hey it’s been a week and I didn’t hear back about X. Did the email get lost or are you guys super backlogged?

And maybe…

I think [plugin reviewer] is treating me unfairly. Can you help or do you know who can?

Both of those are totally perfect reasons to step off book. One is you not being sure if the email was received. The other is an issue with someone who might read the email.

But do you see how they’re both asking, briefly, without a lot of drama or accusations, a simple question? Well. Not a simple question. But they’re asking in a way that shows they understand the situation of the world in general, they understand they’re asking for an exception, and they will respectfully accept the answers.

By the way. The answer to the first one is 90% ‘backlogged’ and 10% ‘goddamn email!’
17 June, 2016
So Take an Upgrade, Maria!

A year ago I asked how do we solve a DB like Maria, and my friend James and I had a good laugh at the long list of issues.

It’s been a year.

I’ve upgraded to PHP 7.

It’s time.

What about Oracle vs Google?

Oh you heard about that? Google won a case against Oracle about GPL code in Android which I want to be really happy about, but it illustrates a major flaw in the judicial system. To whit: The player with the deepest pockets wins.

That case about Java though, not MySQL, which has been a long standing issue with the Open Source Community. The summary? Well it’s kind of like Prohibition. They can try to outlaw it, but we’re going to do our own thing. Which is where MariaDB comes in. It was a fork of MySQL, made in order to stay free and open. I strongly support open source software and so I change to MariaDB.

What Are The Issues?

There aren’t as many for MySQL 5.6 vs MariaDB 10.x as I’d thought. In looking at that, I determined it wouldn’t really impact my sites or setup. In fact, I was certain none of it would be an issue.

How to Upgrade?

I’m on WHM, so first I made a backup: /usr/local/cpanel/bin/backup --force

Then I went into WHM and said “Upgrade Maria!”

I picked the interactive upgrade since I wanted to see what it was doing. Step one went rather quickly and updated everything. It asked me to check my compiled software (which meant two non-WordPress sites that historically act odd when I upgrade). Once that was done, I clicked ‘next’ and was told I didn’t need to do anything else…

Now what?

I ran off to GTmetrix and checked my sites. I had two that were PHP 7 and they had no real change. I then changed another one to PHP 7 and Maria and checked it, and got bigger gains. Speed was up and everything, code wise, appeared to work as needed.

It was entirely a non-event.

10 June, 2016
Is This A Good Name For Your Project?
If the answer to any of the following is not a ‘yes’ then no, you should not use the name for your project.

Again, every answer here should be yes.
1. Did you Google the name?
2. Did you check if the domain name was available?
3. Did you make sure no one else is using it for a similar project?
4. Did you check for trademarks and copyright conflicts?
5. Did you check it against a five year old and made sure they don’t giggle?
Congratulations! You Have a Good Name!

Maybe.

I do a lot of arguing with people over the idea of ‘how’ to name a project, because people want to make add-ons

For example, if you have written an add-on plugin for Microsoft Word, you can’t name your project “Microsoft Word Super Snazzy Map Add-On” but you can name it “Super Snazzy Map Add-On for Microsoft Word.”

Using a name like “My Product for Other Product” is something I consider common sense. Consider the example of Keurig. If you made an eco-friendly brew cup, you could market it “EcoBrew Pod for Keurig” but you could NOT attempt to market it as “Keurig EcoBrew Pod.” The latter implies a direct relationship to Keurig and may be against the law in some countries.

Being Original Is Hard

I don’t mean to dismiss this. It’s hard to come up with a name that is original, descriptive, and unique. It gets harder and harder every day. Consider that a number of today’s companies seem to have ripped their logo out of a 1989 design book

The Beats logo on the right compared to one found in the 1989 design book Tweeted by Spencer Chen.

Now we have long accepted in logos the limitation of language, letters, and combinations. It’s probably not theft, but it’s something you have to be aware of when a new project is named. Similarly, we accept the fact that naming something that is at once unique while still displaying your own flare is problematic.

I can’t offer you an answer that will fit everything, but I can offer you this. When you pick a name for your project, regardless of if you’re the big fish or the little one, it’s your responsibility to check if something even possibly related is already there. If you happen to name things at the same time, that’s an honest mistake, but if you know better going in, don’t be the bad guy.

What About The Bad Guy?

What happens, though, if a year or three down the line, you get an email telling you that your product is infringing on trademarks?

You have two choices:
1. Fight
2. Flight
There are weird issues in the US with Generic Trademarks. Like did you know heroin, thermos, and aspirin are genericized? That means we use the words ubiquitously to mean the general concept of ‘a thermos bottle’ or ‘that horrible drug’ without reference to the trademark holders.

That said, there are terms that are not generic, and yet we use them similarly. Band-Aid, Kleenex, Post-It, and Google. Yes. Google. Google actually has gone to the point of downranking you for terms like ‘googling it’ because they want to protect their brands.

So what happens when you get that email from Johnson & Johnson, telling you that your product “Mika’s Band-Aid for WordPress” is a trademark violation?

Fight or flight.

You can argue that no one would logically think that ‘band-aid’ in this case would ever be confused for their product. Or you can say “Oops, my bad. I was totally trying to leverage the term band-aid.” You can also ask them “Are there circumstances in which I can rebrand this so as to make it clear I’m not intending to violate your trademark while not losing the ground I’ve made with my product?”

I will suggest, if you chose to fight, to get a lawyer who specializes in trademark law.
6 June, 2016
SSD: An Anecdotal Journey

After I upgraded to Ogra, I noticed that my server’s load stats were a little janky. They were pretty high, actually, bouncing between .5 and 2 all the time. Now this isn’t really all that bad, but as I looked at my server, I realized I was paying a little more than I needed, since I’d cut down on space by offloading backups better.

This matters because I needed only 50G of diskspace (I only use about 30 right now for all the sites), and while I did want 2G of RAM, I could easily switch to an SSD on my hosting plan. It was cheaper, and it was as easy as pressing a button. I’ve never really gotten to play with SSD for this site, so I thought “what the hell” and pressed the button.

A weekend later…

The five minute load average shows a massive drop. It’s incredible. The red and blank spots are where I was running the actual migration process and disabled monitoring for a bit. Literally all I did was reboot the server and the move it to SSD. That’s it. It’s insane when you think about it.

By the way, I saved disk space by offloading the backups to Amazon S3. Amazon costs me about $3 a month, and while I detest their interface, the integration is built into WHM. I have an open feature requests to allow arbitrary CEPH destinations as backup so please vote for that if you like the idea.

SSDs had the bonus of changing my backup from taking 2 or 3 hours to taking 15 minutes.

Anecdotally SSD is an incredible improvement of the old bog hard drives.

3 June, 2016
Why I Don’t Use Git Flow Anymore
Please don’t get me wrong. I love git-flow. I think it’s great. But it was great to teach me how to use git. It taught me not to use master for my development, and how to make branches and all that. Git Flow got be in the habit of doing good things and testing and showed me how to work with multiple projects. It was a great crutch to get comfortable with the ideas of Git that (for a long time) confounded me.

But I don’t need it anymore. Instead, I do things very, very simply and my flow is as follows.

$ git checkout master ; git pull

I always start by assuming I’ve forgotten something and need to sync up. This works for me, since I run on two computers.

$ git checkout NewProject

Once I’m in the new project, I start making all my edits, add my code, etc. Now here’s where I get a little silly. If I’m working on my own stuff, it’s Coda, always, so I’ll constantly ‘commit all changes’ and fill in my commit messages and then cancel out. I do this over and over until I’ve reached a point where I think “This code is ready to be tested.” Then I commit for real.

This means my commit logs look like this:
```
Convert Font Icon to SVGs

 - Add new images for social media
 - Optimize CSS for pagespeed
 - Remove unused function.php file
 - Add shortcodes

Fixes #1234
```
There are other ways to do this, of course. I’m a huge proponent of keeping change logs but a commit message should be useful too.

It’s too easy to put in this: git commit -m "Adding new icons"

While it’s more time consuming, just use git commit and put in a good message like I did up at the top. Now, this is not new. A hundred people have all said this before, but it bears repeating.
- The first line is your subject, keep it to 50 characters.
- Capitalize the subject line but don’t use a period
- Use the imperative mode – “Add new icons” and not “Adding new icons”
- Leave an empty line between subject and body
- Explain what you did in the body, keeping lines to 72 characters
- Bullet points are okay – use a space before a hyphen for best compatibility
- Reference any issues at the bottom – “Fixes: #123” or “See Also: #456 #789”
If, like me, you commit and then, before merge, realize you have changes, use git commit --amend to add your new changes to the existing commit.
25 May, 2016
Encrypting Source Code Doesn’t Make It Safer
I’d love to think that’s all I have to say on the matter, that you all will read the subject, go “Yup!” and we’re done.

The reality is that I have to argue this, regularly, with people.

Here’s the code from a plugin out there:
```
<?php ${"\x47L\x4fB\x41\x4c\x53"}["w\x73\x78\x6e\x69\x66\x69\x6f\x71\x6c"]="\x73l_s\x65arch\x61bl\x65\x5fc\x6f\x6cu\x6d\x6e\x73";${"\x47L\x4fBAL\x53"}["\x66\x6b\x78xg\x63\x6ap\x68\x6d\x6ft"]="\x73\x6c\x5fdb";${"\x47\x4c\x4f\x42AL\x53"}["\x65\x62\x67\x79\x6b\x66\x64"]="\x69\x73\x5f\x73\x6c\x5fca\x74e\x67\x6f\x72\x69\x7a\x61\x74\x69\x6fn_\x63\x6f\x6c\x75\x6dn";${"\x47\x4c\x4fBA\x4c\x53"}
```
The whole file is like that. The developer explained it was done that way for ‘security’ — it would make things harder to hack. I pointed out that’s simply not true.

Here’s what having encrypted, hashed, packed code does:
1. It makes your build process take longer.
2. It adds another failure point into your code.
3. It makes it harder for the end users, other developers (who write plugins), web hosts to debug, and you to debug.
4. It makes you look like a developer with evil intents.
5. It sets an expectation with users that this kind of code is ‘normal’ in WordPress.
Recently Sucuri posted about a redirect hack that works by putting junk code in your header.php file which looks rather similar:

The issue here is that an end user, your normal WordPress user, cannot tell the difference between the somewhat safe code I quoted before and this code. They see ‘gibberish’ where as I know they can use a hex decoder to translate ["w\x73\x78\x6e\x69\x66\x69\x6f\x71\x6c"] into ["wsxnifioql"] … which is still pretty terrible.

Well written code, well named functions, are self-explanatory. You see a function called redirect_404_pages() and you have a pretty good idea of what it’s for. You see a function named wsxnifioql() and good luck knowing what the heck that’s for. This goes back to the claim that the code is more secure. It’s not. It’s needlessly complicated, and as I shoed with the hex decoder tool, it can trivially be decrypted and read.

So what is the real point of hiding your code? Who are you trying to protect? What’s ‘safer’ about any of this?

The answer is that it’s about about you, you, you. You don’t want someone to take your great idea.

That’s it. And that’s foolish.

WordPress is GPLv2 (or later). Furthermore, to be hosted on WordPress.org, your code cannot be encrypted or hidden or otherwise non-human-readable. The basic reason is that WordPress’ success is due to it’s understandability and extendability. Anyone can read WordPress’ core code, parse it, learn from it, and enhance it. When you take that away from users, you isolate your code and prevent people from extending it.

This person, this developer, charges upwards of $1000 for the add ons to their code. Yes, a plugin that costs over a grand. It sounds economically sound to try and lock things down so people don’t steal their intellectual property. We can all understand that impetus. I support it. I also feel that part of being in an open source community is being aware of how your actions impact the world at large.

Because WordPress is open and because there is a standard expectation of non-encrypted code (except by evil-doers), the burden moves to developers to not hide their code that is installed on users’ servers. The code that is deployed to an end-user is expected to be human readable. This comes at a risk. I have a copy of a theme I bought, and I could give it away to anyone I wanted. They may not get updates, which means I have to be aware of the risk I’m introducing to my friends when I give them something like a premium theme or plugin.

Similarly, what are the risks of telling people it’s okay to install plugin code in uploads instead of the plugins folder? What are the risks of allowing people to think that encrypted code is generally okay? In and of themselves, neither action seems particularly dangerous. PHP code is PHP code, right? If it runs, you’re good. But the reality is not so. By installing code in uploads I’ve made it so it’s no longer fully protected by WordPress and ‘standard’ security practices. I’ve also made it riskier that my code would even run, since many hosts prevent executable code from running out of that folder for security.

So how do I meet the (assumed) criteria of not having someone rip off my code?

You don’t. Your machinations aren’t preventing it now, and they won’t prevent it tomorrow. Hexcode is easily parsed. Even the Zend framework has to be able to be reversed to be run, so a dedicated person will always find a way around it. And the majority of your users aren’t going to be the problem. It’s those extremes. So what you’ve done is wasted time, effort, and money to annoy the majority to stop the minority. Let people inspect your code. If someone steals it, there are laws to help you handle them. Use them. Theft is theft. The GPL may allow them to take your code, copy and expand on it, but it doesn’t let them violate your copyright.

All the work you’re doing to hiding your code is about as useful as preventing right-click on images. It doesn’t protect the end users, and it doesn’t protect your intellectual property.
23 May, 2016