Tag: essay

Cheap Is As Cheap Gets
I have nothing against people on a budget. I understand not being creme-de-la-creme and needing to be careful.

I really boggle at people who want to run a company website, but feel $15/month is ‘too much.’

How much do you spend on your car every month? We’re talking gas, insurance, cleaning, maintenance, and so on. You do that for a reason. You need your car to get you places. It’s an investment in your work. You can’t get to your work without a car so you take care of it to keep it secure, you clean it because it smells, and you pay for insurance in case the worst happens.

Your website is running 24/7 and costs you $15/month and that’s too much for your business? You need to rethink your business model. That’s under $200 a year. That amount of money should be affordable for anyone who’s running a business, even on a shoe-string budget. What really gets me, though, is the person who emailed me saying $200 a year was too much did it from an iPhone. They had the ‘Sent from my iPhone’ signature line still on it. While it’s certainly possible they got a cheap pay-as-you-go plan and a used phone, the reality is they look at the cost and don’t see an immediate value.

Let’s turn this around.

$15 a month is about:
- six gallons of gas (from the Arco down the street)
- five fancy cupcakes from Wildflour Cupcakes
- four grande lattes from Starbucks
- three gallons of milk (probably less in some places)
- two craft beers
- one tin of canned unicorn meat
But we get an immediate value in all those things. We can see the gas, the cupcakes, the unicorn meat, and we see the direct application of our money to a ‘thing.’ A website is different. It is a nebulous entity and floats out there in the cloud. When you’re not selling anything on your website, what’s the point?

Lately I’ve taken to asking people “How much are you planning on spending on advertising a month?” If the answer is ‘nothing’ then I tell them they need to consider it for their company if they plan on getting anywhere. If the answer is a realistic amount, I tell them to allocate $15 a month for webhosting. They need to have a web-presence. It’s 2015, people will want to see who they are, so make a good, informational, site. Don’t put a ‘blog’ up unless there’s a plan to publish to it regularly. Don’t use code you can’t support. Don’t use a host where you can’t get your content back easily (which is really my only issue with things like Wix).

But $15 a month is pennies to the traffic a website can bring you. If you sell three gallons of milk a month, you’ve broken even, after all.
11 February, 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
Mailbag: Tools To Keep Consistent

Meg from Ohio (go Ohio!) asks the following:

You blog three times a week about tech. How do you keep doing that?

I schedule posts.

Chris Lema doesn’t, bless him. I started with about 10 posts I had in mind, sat down one day and made myself a buffer, and thought that it would be better to space them out to every other day. It actually started as twice a week, but then I bumped it to M-W-F, and since I’m kind of wordy, I’ve been able to keep up with it. Sometimes I write a post because I solved a problem, which happens pretty much every day, and sometimes I toss out a remark on twitter that people want to hear more about.

Much of it comes from listening and reading a lot. But I don’t just schedule posts. I use the plugin Editorial Calendar to keep tabs on what my schedule is, when things are being posts, and at what time, because I actually really hate the posts lists.

Here’s your default posts list:

It’s pretty bare bones and functional, but one of the things that’s always bothered me about the whole post list is how useless it is. Don’t get me wrong, it’s a list of posts, and it does that really well. But with the moving target that is what we use WordPress for, it’s become rather frustratingly bare bones for me and it really does impact my ability to get work done when I have to bounce back and forth between multiple screens just to see what the status is, verify I updated everything, and by the way, where are all my posts.

So, in the grand WordPress Tradition, I enhance it with plugins.

Admin Featured Image shows the featured image in the posts list, which is really good for one site to make sure I did too set an image and what it is.

UI Labs I’ve actually forked. I need to remember to ping John about this, because I took his (great) plugin and modernized it. If you’re interested, that code is up on my github UI-Labs repo. It’s slowly being improved to make things a little easier for me and to work on WP 4.0 and up.

Editorial Calendar, as mentioned before, gives me a great view for what’s scheduled and when:

The drag and drop interface lets me reschedule on a whim.

Speaking of… Schedule Posts Calendar fills a void that has pissed me off for years. Just look at the comparison:

First, there’s the calendar by the month, then there’s the date, and finally the epic button ‘today’ to let me fast fix posts messed up by the WP iOS app.

So how do I keep posting so often? You ask questions, I answer them, and I have some tools to make it simpler for me.

6 February, 2015
Professional Utility
It’s well known I hate themeing. I can’t really design and I don’t know how to change thoughts to form like that. Words are my gift.

A year back, I changed this site to using the Utility Theme by Carrie Dils. Since then, I’ve moved on with another theme, for various reasons, but I still found Utility to be one of the nicest, cleanest, themes out there.

Recently, Carrie came out with Utility Pro and as she’s one of the nicest people out there, offered me a discount. The new theme costs more, starting at $69 and going up to $199 for a professional version with a Gruntified theme and source files. It’s a lot more than the $45 Utility cost, but I went ahead and bought the theme, not having a home for it quite yet.

After fifteen minutes looking at it and the code, I knew I wanted to use it.

What Carrie did “differently” with this theme is she made it mobile first. That means the entire site is designed to look good on a mobile device and the breakpoints are used make it look better are larger devices. This is the opposite of what many themes do, designing for large screens and adjusting for smaller. Her ‘media’ section is surprisingly small because of that, and the site resizes quickly and properly with no adjustments needed.

The next thing she did, and the thing that really was a selling point to me, was she made it accessible. One of the concerns I’ve been struggling with in the last year has been making my content accessible, and in specific my slides. I want everyone to be able to take my content and learn from it, and a theme that considers that means I have to worry less.

Finally, and here’s where she won my heart, she decoupled code from her theme. This is something that many theme devs and I agree on. A theme should theme, but code should be code. Which means that I don’t want my theme to include custom post types for example. But also she removed Font Awesome. I love it and use it, but by having it in the theme meant that every time the font upgraded, she had to upgrade the theme. We’re all used to upgrading plugins regularly, but themes rarely. By separating the two, she’s able to give the theme stability and the feature flexibility.

Am I using the theme? Today, yes.

Looks just fine in mobile (Google’s POV is jaded since I block them from scanning things).

It was the work of a few hours to convert a site from Going Green Pro over to Utility Pro. The only reason it took hours is that I picked up the non-developer version sans Grunt, which meant I had to split out the CSS into my desired sass files, fold in some of my custom functions, and finally fix the problem that had prompted the following comment:
```
/**
    This file has been modified by Mika to fit the needs of this.
    If you use it somewhere else, expect breakage. I hard coded
    some things in. Shut up, future me.
**/
```
Future me read that and sighed a lot. Finally I removed all the full calls, making everything relative or using the proper functions in order to dynamically add paths. Also I had to merge a Wiki, a Yourls Site, and a gallery into the look, and that meant some serious theme juggling. It didn’t help that with the new layout I decided to tidy up some of the sidebar content and optimize layouts.

I’ve done very little to rejigger the code. What I’ve messed with is unrelated to what Carrie’s design choices were and more with how Genesis approaches the few things I don’t fully agree with. I’m not yet using the welcome splash screen, since this site people come to for news first, but I plan to use it for major announcements.

Now, for $69, it’s a well made theme. Would I spend the $199 for the full version with the development tools and the Grunt files and the use on as many sites as I want? If I wasn’t me who liked to play with code and files, yes. If I needed this for clients, most definitely. StudioPress itself charges $59.95 for Genesis, and $399.95 for all themes in their repertoire, so from that aspect, this may seem expensive.

Chris Lema and I have some strong opinions on the cost of a WordPress theme. When you consider all the things you’re paying for, all the work of testing on mobile devices, accessibility, colors (which are also accessible), compatibility, plus a year of updates and support, that $200 is an amazing price to use on (say) a dozen websites out there.

I think it’s well worth the price to have this handy in my back pocket for anything I might need it for. And it’s a testament to Carrie how rapidly I realized I did need this and didn’t even know yet.

Check out Utility Pro. You won’t regret it.
4 February, 2015
Beta Testers
There’s a weird aspect to open source that can be hard to explain, and that is the ethos and practicality of Beta Testing. Beta Testing is one of the most important aspects of open source, because it’s only with the beta that we’re able to real-world test products. No matter how much planning and testing and automated tests you write, there is nothing quite as powerful as the real-world. We just can’t reproduce it well enough because, among other things, we can’t yet predict humans very well. Sure, cold reading is a thing because humans can be predictable, but that doesn’t mean we know how a tool will be used 100% of the time.

And being a beta tester is hard work. You have to be both a user and a developer, which are really two totally divergent mindsets. Testing as a user versus testing as a developer is as different as how you and a formula one racer drives a car. Input from both the users and the developers is critical to the growth of a project and the end results. But before we get into how one really betas, we have to ask a very important set of questions.

Should I be a Beta Tester?
- Are you brand new to the project?
- Do you use the products daily (or close enough)?
- Do you know how to manually clean up a bad install without losing your data?
- Do you make regular backups?
- Do you know the basic troubleshooting steps for the product like the back of your hand?
- Are you willing to test on your live site?
If you answered ‘no’ or ‘maybe’ to any of those questions, then you’re not yet ready to be an effective beta tester.

That last one may catch people by surprise. Testing on your live site is something we actually tell people not to do, but I’m here to tell you that the best beta testers are either testing on their live site or on a site they use every single day. Since I have multiple site I use daily, I picked the one I can live with if it dies and I use that for my live-beta.

Guess what? You’re on it right now. It’s a hallmark of how much trust I have in WordPress. I can count the issues I’ve had on one hand since I started this a few years ago. I make a backup every day, twice a day, and I have it in three locations. If my site goes down, I lose at most 12 hours of content, and for what I’m doing here, that’s okay. My other sites, I could not deal with that loss and thus I use stable. But I test with live because… well let me explain.

How do I test?

If you’re going to be a beta tester, then the you install the beta and you use the product.

You were expecting rocket science?

Most projects have a lot of automated tests and they’ll test what they know about and what they can. But absolutely nothing replicates real world use. The whole reason I test with a live site, and why I feel it’s important, is that this is as real as it gets. This site is updated regularly with plugins and theme changes. I add new content five times a week on the same Multisite installation. I add new content multiple times a day on another site. One is on trunk, one is not. This lets me constantly compare the experience between the two and makes me immediately aware that something is different. If it gets my attention, that’s important.

What I do with my site is equally important. I’m writing content, constantly, which means I’m using some of the fundamental, day to day features that WordPress absolutely must have. That kind of user testing cannot be scripted. There is no AI yet that can reproduce what machinations a human gets up to.

I like to tell a story about the time my coworker John and I were testing some tax software for the bank. We ran it through it’s paces, putting in data, and every time we tries to save at a certain point, the software crashed. It crashed hard. We called the vendor and talked to them about it, walking them through what we did, and lo, it crashed again. They couldn’t reproduce it, so we screen-recorded it and sent it over. They were astounded and sent out a tech from New York to Chicago to work on this. He couldn’t solve it, but he did see how we crashed it. Then they sent in their big guns, their lead developer, and he sat down and watched us. As soon as it crashed he said he knew what the problem was.

We were doing it wrong. We were entering bad data in a way no tax professional ever would, the system was trying to process the math and, because the logic was bad, it crashed. I pointed out that people would make mistakes and he agreed, saying it should have alerted us to an error in the form, not try to process anyway. A few days later, he sent us a new version which properly trapped the error.

While a scripted test might have caught that by looking for bad values before mathing, they were doing the obvious check. They checked if it was a number. They neglected to check if it was a permitted number. If you’ve ever heard me nag someone about proper data sanitization and validation, this is why. They made a code change, added it into their scripted tests, and learned and grew. But they couldn’t have done that without a real human thinking in a different, and unexpected way.

We can, and will, improve scripted tests, but they will never improve to perfection because humans are pretty crazy. Which leads us to the next step.

How to I report a bug?

This is generic for a reason.

First, make sure you can reproduce the bug. Get a clean build to test on and go through the steps again. If you’re not sure about the steps, make a note to yourself about generally what you remember and try it again. If you can’t reproduce it, call it a one-off and let it go (and debug for yourself, but that’s different). Once you can reproduce it on a clean build, document those steps.

You’re going to want to answer these questions:
- What were you doing?
- What did you expect to happen?
- What happened?
- What research did you do into the error?
- How do you reproduce it reliably?
Include any error messages. Explain what you did. Don’t say “It didn’t upload.” Instead, say “The upload hung, making no further changes on the page. I waited 15 minutes before hitting refresh. When I checked the media library, I saw the image was uploaded however when I looked at the file server, none of the thumbnails were there.”

This is why you need to know what you’re testing. With a failed image upload on WordPress, you should know that the image uploads and then it makes the resized images. Even if you don’t know that, you should know your images are in wp-content/uploads/2015/02/ and you should look there to see if you can find them. If you have a failed post, you should know to look at the post list page in WP Admin and see if the post is listed there.

You’ll get extra bonus points if you can find your PHP error logs and share pertinent information, but that isn’t always easy. When you reproduce the error, make sure you specify if anything special has to happen. Like if the image upload only fails if you’re uploading a PNG, note that. Or maybe it only fails on pages, but not posts. How weird is that, right? Note it.

Don’t worry about being technical here. Be accurate, be clear spoken, and assume the other person is relatively new at whatever you’ve broken. Don’t assume they know exactly what you mean when you said “Upload an image…” Be specific and say “Create a new post and press the ‘Upload’ button…” If you know there are multiple ways to upload an image, test those other ways. It’s a due diligence thing.

After you’ve reported the issue, keep informed. Make sure you get email alerts for it, make sure you reply to those emails for it. You can’t just report it and walk away, you have to keep tabs and pay attention. People may need you to clarify information and explain problems in different ways. Remember people can’t actually read your mind. What’s clear to you, because you did it, may confuse them.

And finally … be prepared to hear that it’s just not that big of a deal. Sometimes a bug isn’t a bug, but an intended change. You may not like it. Heck, you may despise it, but that doesn’t make it wrong.

What else?

What are your takeaways from beta testing? How do you do it?
28 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