Tag: open source

How Do You Solve a DB Like Maria?

I was talking to my friend James about upgrading SQL. If you didn’t know, upgrading SQL is a horrifyingly monumental thing, because there’s no way back except restore from a backup. Minor upgrades are generally painless, but the CentOS warning is as follows:

Upgrades to new major releases (the first two digits in the version string) are more involved because there is a substantial risk of data loss.

Data. Loss.

It’s scary when you consider doing it for yourself. It’s horrifying when you consider doing it for a few thousand users.

On top of that is the issue that MySQL is owned by Oracle and they’re not exactly known for being good stewards of OpenSource. Unlike many other Open Source projects, Oracle owns the entire copyright to MySQL. All contributions are done if the developer has signed a “contributor agreement” that assigns ownership to Oracle. This isn’t all that weird, to be fair. When I worked for The Man, that was basically how things worked and it made sense. The work I did for the company belonged to the company.

Where this is weird is that Oracle has said that about a GPL product, even to parts of it the company has not written. Why is that? It’s because all contributors to the code have to sign a “contributor agreement” assigning ownership of the copyright to Oracle, which is not alone in this. Sun before them used contributor agreements to get full source ownership, and many other projects do the same.

Now, James and I looked at the MariaDB vs MySQL compatibility doc and had a laugh.

tl;dr “For all practical purposes, MariaDB is a binary drop in replacement of the same MySQL version,” except for this long list detailing where you’re screwed.

Now when you get down to MySQL 5.5 and MariaDB 10, the issues become very minor and unlikely to cause you migraines, which is a relief, but that list sure is long and daunting.

I’m not yet running MariaDB because it’s an all-or-nothing move. I can’t keep on MySQL, and I have a few old (ancient) bits of non-WordPress code on this server. I always stress that WordPress is not the limiting factors in server upgrades, and it’s still the truth.

I’ve started doing the recon work to make sure MariaDB will work for all situations on my server, for all apps, and I’m currently pretty sure that I’ll be fine, but I do have one way-out-there app to check into. They’re also one of the few people who pay me for hosting, so we may have to have a sit-down anyway to discuss their future.

@Ipstenu Yep!

— Gary (@GaryPendergast) March 24, 2015

The most important question has been answered.

8 April, 2015
Markdown Isn’t All Bad
It’s not a secret I hate markdown. It’s annoying to remember various commands, and one of the things I loved about WordPress from the start was that I didn’t have to learn bbCode or anything beyond the HTML I knew. When Jetpack included Markdown, I was a huge opponent. I thought it was useless and pointless and a waste of space.

I now use it in many of my posts.

You see, I don’t write in the visual editor. I used to, but there are ‘glitches’ with it. Like I couldn’t see the embed for Facebook (it showed up blank for some reason), and I had trouble embedding video content that required me to paste in script code. Then when I starting writing code, like I do on this site, I needed to make sure the formatting didn’t get mangled. It all boiled down to giving me two places where I use the Visual editor, and everything else is text.

That’s all well and good until I fell in love with my iPad mini.

You see I also have a major annoyance with the iOS app for WordPress. It’s too easy to post to the wrong site and it’s problematic when you want to upload featured images or make custom excerpts or have any custom post types. That means I use Chrome or Safari on iOS to write blog posts. If I’m offline, I write it up in Notes or Byword and just have it there until I’m ready to import. But I use WordPress in my browser because that’s where it works ‘best.’

Except HTML on an iPad is a pain in my ass.

It really, really, is. The number of clicks you have to do just to make a header, or strong text, is annoying. It’s three clicks to make an <h2> and it’s not even in the same place. It’s one click to get to the numbers, another (one up from where you hit to get to numbers) to go to advanced characters. Then you can press the button. Any chance I have to minimize my clicks means I can type even fast.

And you bet your bippy I’m fast at typing on my iPad.

Markdown’s syntax is intended for one purpose: to be used as a format for writing for the web.

John Gruber’s Markdown syntax primer is the only place that really took the time to make sense of Markdown to me. Everyone else just said ‘It’s what we use’ or ‘It’s faster’ or (worst) ‘It’s better.’

No. No. No. Better is what works for you. HTML, for the most part, works for me. And for me, a small subset of markdown syntax terms work very, very well to speed up my writing:
```
## Title

### Subtitle

&amp;amp;gt; Blockquote
```
There are a few more, like the codeblock (which I don’t use, since I like pretty formatting better) but the ability to use backticks and say <code> is pretty nice.

So do I like Markdown? No. It’s hard to remember ‘new’ syntax. But the ones I can use without having to close tags makes me a little happier and speeds me up a bit. For that, it’s pretty good. I can use it to enhance my HTML, and I wish that MediaWiki let me use HTML and Markdown instead of their woe begotten WikiSyntax. My kingdom for <table> in MediaWiki. Am I right?

Now. If I could just get John Gruber to increase his font size.
9 March, 2015
A Case For Hello Dolly

I like it.

I never use it, but I like it.

I delete it, but I like it.

It’s not professional, it’s not beautiful, and it’s not something that makes WordPress look grown up.

And I think needs to stay in the core download of WordPress.

Let me tell you a story of you. Let me remind you of yourself. Not the you of today who knows all amazing things. Remember the you who was young and inventive but inexperienced. The you who knew how to throw a football but couldn’t throw a spiral. Or you knew how to drive a car and not stick shift. The you who delighted when you learned all those things, like a child with a new toy.

That you was not professional yet. That you needed an example for how to do new things. You had teachers and friends and parents who showed you the ropes.

That’s what “Hello Dolly” is. Hello Dolly is the Hello World of WordPress, and it makes a plugin suddenly seem like a non-insurmountable task. We can all look at that one file and see either inspiration for code we can make, or a sudden lack of terror for what WordPress is. Like I tell people in training classes, WordPress is just files, folks. A plugin can be just that file. And you can take the idea and run with it. More than just a training tool, it’s the epitome of open source. It’s code, freely given, than serves as a first step for people who come to WordPress with no formal education. It’s free. It embraces the goals we want to see in open sourced code.

So it needs to stay in WordPress, because you needed it once. Does it make an annoying extra step for you to delete it when you’re installing WordPress for your clients? Maybe, but for me it makes a moment where I can look back at myself from 2009 and see how far I’ve come from the woman who was too scared to speak at a WordCamp to become a WordPress professional.

I’ll take that one extra step and never forget where I came from.

9 February, 2015
Overreaction to Negative Reviews

I’ve long since held the belief that our reactions to critical judgement of our work hurts so much because it’s so personal.

This has never been more true than on the Internet. In the world of distributed and isolated development, we often end up writing in a sandbox. We sit down and tune out the world and write code. And then we just deploy it to the masses for real-world testing. Many people are unit testing, which helps a lot, but as we’re such a distributed development world now, we rarely get the sit-down feedback we might with a company.

With that in mind, perhaps the over-reaction of people to their bad reviews (codewise) is a function of this distributed environment.

You’ve seen it, I’m sure. You leave a low-star review on someone’s product, annoyed that it doesn’t do something you think it should, and you’re replied to with vitriol. You’re astounded! You know that a one-star review kinda sucks, but you didn’t expect name-calling or, worse, someone to find your personal contact information and tell you that you deserve to die and you’re an idiot for not understand what code is.

I didn’t make that up. That’s happened. And since it happens, the question is why does it happen?

It comes back to the way we both develop code and the way we share it. The easier we make it to share our code in things like Github or official, public, repositories like the WordPress.org plugin repository, the closer the connection we make between developer and user. If you consider how it ‘used to be,’ the person who wrote the code may never meet any of the people who use the code. I’ve used Safari for years, but I have no idea who wrote it. Conversely, I’ve actually communicated with many of the Chrome developers about issues I’ve see and unexpected results. And goodness knows we all just ‘cope’ with how terrible things can be in Microsoft Word.

We’ve made the world more accessible for people to communicate directly the issues they’re having with software. This is a good thing. It allows us to develop faster and iterate code faster. We make things better faster. At the same time, it opens us up to issues like handling negative reviews.

If you’ve seen the movie Office Space, there’s a character whose job it is to take information from the customers to the developers, because developers are bad with people. We all laughed at that because we all saw the grain of truth. That tiny nugget of truth was that people who can bury their heads in the sand for hours to invent things are kind of weird people, and they don’t always communicate the way the ‘rest of the world’ does. Of course, now it’s 2015 and we know that it’s just not so. We all communicate similarly. Some of us just have more patience than others because we’re used to working with people more often.

Sunday is the 17th anniversary of the term “Open Source” in how we use it today. There was a public call to use ‘open source’ instead of ‘free software’, and we heeded the call. But open source has changed a lot from that day. We’re not just talking about free software that anyone can take and develop but the open lines of communication that allow us to develop it by working with the users in a closer relationship.

While many of us develop in isolation, writing and testing code by ourselves, the moment we release it to the masses we’re terrified. What if it breaks? It will. What if it sucks? It does. What if people hate it? They will. But we do it anyway, and when we, the developers, get that one-star review, it hurts. It punches us in the gut and makes us want to walk away.

Except… it shouldn’t. Certainly some reviews are made by absolute prats who demand the unreasonable. We don’t reply to support tickets for our free software fast enough, or maybe we didn’t refund their money when our store clearly says ‘no refunds.’ Maybe they hated it because we declined to add a feature. Maybe they just wanted to rant at us for 500 to 1000 words.

Yes, those reviews that are clearly full of anger should be ignored. And yes, those will make you feel like total shit. But the other ones, the ones where someone says “I wanted to like this, but the developer pushes an update every week and it really isn’t adding anything useful. This plugin has become bloatware and I’m not using it anymore.” Well hey, that’s actually a very nice one-star review. It’s a sucky one to get, but it’s fair and just.

So why do people often demand we delete those one-star reviews, or reply back that the user has no vision and cannot see how the plugin develops, or that the code is the dev’s and you should thank your stars it’s free? It goes right back to how we develop. We’re not used to the feedback and constant communication with others about our code. We don’t present our code to the masses until it’s at a usable or workable stage. And there are practical reasons why, but it means we just don’t know what it will be like to work with others to develop until it happens, and it seems to always happens in bad way.

What should you do? Keep in mind that the people who hate your code may have a point. Try to be objective and see it fairly. But don’t be a pushover and don’t let the people who are legitimate mean people get you down. It’s not easy, though. It helps if you have other people to work with on your code projects. Trusted beta testers, or even developers who are willing to take a look. Get yourself out of your isolation and you’ll find it’s a whole lot easier to deal with the crazy, if only to have someone to laugh with.

2 February, 2015
GeoIP Options
Thanks to crazy thinks like the EU VAT laws, sometimes we really have to know where people are coming from when they visit our sites. The problem with this is … how?

There’s a cool extension for PHP called GeoIP, which I’ve finally installed on this server (along with my upgrade to PHP 5.5 and some other things, yes, still on Apache, shut up Otto). The extension comes from MaxMind, who also have a pure PHP version you can use. I’m not because the GeoLite2 databases are distributed under the Creative Commons Attribution-ShareAlike 3.0 Unported License and that means I can’t include it in a WordPress plugin.

But that really made me wonder why it was okay not to attribute Maxmind when I used it via Pecl. I mean, technically I should, right? But where and how? I ended up putting a note in my site footer, to say that the site used the Maxmind DBs, but I haven’t included any note about that in my plugin since the DBs are included in the plugin, just called if the functions are found. It’s on you to install and attribute as needed.

Installing mod_geoip

Installing this is simple, from a server admin perspective.

Since you can’t use the yum install on Apache 2.4, I got to use a cPanel Custom Module, which meant running this:
```
wget http://easyapache.cpanel.net/optmods/custom_opt_mod-mod_geoip.tar.gz
tar -C /var/cpanel/easy/apache/custom_opt_mods -xzf custom_opt_mod-mod_geoip.tar.gz
```
And then I ran an EasyApache build. That was fine, I needed to do that anyway. Once that was done, I installed the pecl for GeoIP:
```
pecl install geoip
```
Done. Optionally you can add it to apache in either your .htaccess or (better) a conf file for your whole server:
```
<IfModule mod_geoip.c>
  GeoIPEnable On
  GeoIPDBFile /usr/local/share/GeoIP/GeoIP.dat
</IfModule> 
```
What about upgrades?

Every month you don’t upgrade your geoIP DB, the more your site sucks. Someone quoted a statistic that every month you don’t upgrade the DB, the accuracy drops by 1.5%. I can’t validate that, but I’d believe it.

Upgrades are fairly painless, thanks to geoipupdate, though it doesn’t include the IPv6 files for some reason. Still, being able to toss this into crontab makes my life easier:
```
38 15 * * 5 /usr/local/bin/geoipupdate
```
Of course… I did notice that there’s a new MaxMind DB Apache Module.

If you’re on nginx, you can grab the nginx geoip module too.

What if I can’t install PHP modules?

By request, I’d already added in the GeoIP2 PHP API to my wee little plugin. Not everyone can use mod_geoip or mod_maxminddb, after all, so it’s good to have options. And with this option, you have the question of how to update since geoipupdate won’t work anymore.

If you want to go hardcore, you can Auto-update your GeoIP databases with Cron via that very robust script. Or if you’re simple like me, it’s a geoip.sh script in your ~/scripts/ folder:
```
#!/bin/sh
cd /home/username/public_html/wp-content/edd-pec-geoip
wget -q http://geolite.maxmind.com/download/geoip/database/GeoLite2-Country.mmdb.gz
gzip -d -f GeoLite2-Country.mmdb.gz
```
And then I have this in my crontab:
```
30 22 2 * * /home/username/scripts/geoip.sh
```
Which is a lot easier for a lot of people.
19 January, 2015
Better Headers
I review a lot of code and by extension read a lot of source code files. One of the things that drives me to distraction is trying to sort out what a specific bit of code is licensed. Now, I don’t care about GPL the way a lot of people do. When I’m reviewing plugins for WordPress.org, I only care in that a repository requirement is that all code in your plugin is GPLv2 (or later) compatible. If you’re not hosting on WordPress.org, I only care if I want to use your code and I need to see what the possible restrictions are.

While I’m mostly talking about JS files here, I wish people would remember to put in the right header information for all their code.

Headers I Hate

It absolutely kills me to see this as the header of a JS file:
```
/*! My Awesome JS - v1.0.0 - 2015-01-14
* http://example.com/myawesomejs/
* Copyright (c) 2015 John Doe */
```
Actually, what’s worse is this:
```
/*! My Awesome JS - v1.0.0 - 2015-01-14 */
```
This means I know nothing about your code license. If I have the URL, maybe I can be really lucky and go there, see a link to your full source code, download, open the zip, and maybe you put a license file in there. Most often, however, the answer to that is not. With a lot of newer projects, they link to Github, which is great since I can go and look for that LICENSE file. Github even prompts you about making one when you create a project. Love ’em

Realistically, if you’re releasing code for the world to use then you’ve got to license it. Even if you don’t care about licenses, putting a public-domain clause on your code means it’s free for all nations to use is so easy a caveman could do it.

Headers I Love

Okay, so if you’re making your own JS, what do I think your header should look like?
```
/**!
 * My Awesome JS v1.0.0
 *
 * @copyright Copyright 2015 John Doe
 * @author    John Doe
 * @link      http://example.com/myawesomejs/
 *            http://github.com/johndoe/myawesomejs/
 *
 * @license   Use permitted under terms of CC0 1.0 Universal (CC0 1.0) Public Domain Dedication
 *            https://creativecommons.org/publicdomain/zero/1.0/
 *            http://example.com/myawesomejs#license
 */
```
That’s it. Obviously that’s the non-minified version. If I wanted a minified version it would be this:
```
/*! My Awesome JS v1.0.0 | (c) 2015 John Doe | example.com/myawesomejs#license */
```
There’s an argument to be made about minification and how I shouldn’t have any headers in order to compress the code to the extreme, but let me show you the jQuery minified file’s header:
```
/*! jQuery v2.1.3 | (c) 2005, 2014 jQuery Foundation, Inc. | jquery.org/license */
```
It covers your license and your copyright information there in one go. It protects your interests and makes it plain for everyone to see what’s going on, how to get in touch with you for changes, and all sorts of awesome open-source things.

Picking a license…

In the above example, I picked CC0 for a reason.

That’s the ‘unlicense’ I think you should be using if you’re releasing code to the world and don’t want to be bothered by the hassles of any informal sort of license. Sadly, not declaring a real license can cause problems outside the United States. Here, we would interpret the license based on what the author intends, which is already a bit of a dangerous idea, and presume a license means exactly what it says, which makes them non-copyleft free software licenses and compatible with most other free software licenses. It may make it outright incompatible with commercial software. And worse, other countries have stringent views on the copyright aspects of these licenses.

Now that said, my other favorite ‘For god’s sake, just take my code’ license is the WTFPL license.

For me, if I want to release code that really is free and can and will be used by anyone, I pick the CC0 or WTFPL. It covers this for everyone, as far as I’ve been able to tell, even commercial.

The GNU have their own license recommendations of course, and Jeff Atwood has a good post about picking a license that explains how most of us feel about the headache. Of course, if you’re forking someone else’s code or building on their work, check the license they used to make sure you don’t violate it with your new license. Not all licenses are ‘backwards compatible.’
14 January, 2015