Tag: essay

Why You Can’t (Always) Catch Cache

Or rather, why you don’t want to cache.

When speeding up a site, the first thing we always talk about is streamlining the site. Ditch the redundant plugins, clean up the code, get a lightweight theme, dump the stuff you don’t use, and upgrade. Once you’ve done that, however, we talk about caching, and that is problematic. Caching is tricky to get right, because you can’t cache everything.

Actually you can, but you don’t want to cache everything, and you really shouldn’t.

The basic concept of a cache is ‘take a picture of my website in this moment.’ We think of it as a static picture, versus the dynamic one we use for WordPress. That static picture is not so static, though. You call CSS and JS still, and you call images. But the idea there is not to call PHP or the database and thus your site will be faster, as those are the slowest things.

Great, so why don’t I want you to cache everything?

The obvious answer is latency. If you’re designing a site or making a lot of style changes, you need to disable caching because otherwise you get a lag between edits and displaying text. But there’s also server latency.

When we talk about things like PageSpeed (I use mod_pagespeed my server) to improve web page latency and bandwidth usage, we’re talking about actually changing the resources on that web page to the best practices. This sounds great but we have to remember that by asking the webserver to do the work before WordPress (such as having PageSpeed minify my CSS and JS), we’re still making the server do the work. Certainly it’s faster than having WordPress do it, but there will still be a delay in service.

The next obvious answer is security. There’s some data you flat-out don’t want to cache, and it’s pretty much everything in wp-admin (on WordPress). Why? If you have multiple users, you don’t want them getting each other’s content. Some are admins, some aren’t, and I know I don’t need my guest editor seeing the post about where I’m firing her and why.

Actually, we’ll extend this. Very rarely do I want my logged in users to see a cache at all. They’re special, they’re communicating and making edits on the fly. Having them see cached content, and constantly refresh it, will be more draining on my server than just loading the content in the first place. Remember the extra load caused by PageSpeed (or even your plugins) generating the cache? That would be constantly in progress when a logged in user made a change, so let’s skip it all together.

Tagging on to that, you also don’t want to your admins and logged in users to generate a cached page. This isn’t the same as seeing a cached page, I don’t want non-logged in users to see the version of the site a logged in one gets. A logged in user on WordPress gets the toolbar, for example. I don’t want the non-logged in ones to see it.

Finally we have to round back to security. If I have SSL on my box and I’m using HTTPS to serve up a page, no way no how do I want to cache anything related to users. In fact, I may not even try to cache JS/CSS either. The basic presumption of https is that I need security. And if I need security, I need to keep users out of each other’s pockets. The best example of this is a store. I don’t want users to see each other’s shopping carts, do I? And your store is going to be https for security, so this is just one more feature there of.

Of course, there are still things to cache. I setup PageSpeed on my https site so it will compress images, make my URLs root-relative, and compress and minify HTML/CSS/JS. But I don’t have a traditional cache with it at all. This does mean as we start to look towards an https-only world (thank you Google) we’re going to run into a lot of caching issues. All the quick ways we have to speed up our sites may go away, to be replaced by the next new thing.

I wonder what that will be.

22 October, 2014
Working With A Translator
Well I messed that up.

I’ve never been on a panel before, and I’ve never worked with a live translator before, except once and that was ASL which is different. This time, at WordCamp Tokyo, I was on a panel to talk about the Worldwide Community of WordPress, and other things, and we had a wonderful translator with us, Shinichi Nishikawa. But I’m afraid we made things very hard for him.

My father, who’s more experienced, gave me a critique later and I have some points to share with everyone.
- Speak one sentence, wait for it to be translated, then move on.
- Keep your English simple.
- No cliches, idioms, or slang. Not even technical slang.
- No jokes. They won’t translate. Don’t even try.
- Don’t laugh at yourself either.
It’s remarkably hard to do this. I’m getting a little better at it, because my father’s wife is Japanese. While she understands some English, I would say her English is better than my French, and she’s mostly fluent in French. So we dance between three languages to try to communicate. With that in mind, I find myself trying for the smallest, easiest, most common words when I want to explain something.

For example, at dinner she was trying to say that my father has no sense of direction. This is true, but in Japanese there’s a word to mean ‘you lack this skill.’ You can apply it to anything, and as we were talking about it, she asked what the word was, in English, for someone who has no sense of music. We explained it was ‘unmusical’ or ‘no sense of music’, but I also mentioned ‘tone-deaf.’ This lead to us saying things like “You are tone-deaf in driving!” Where English will put a modifier on the word, the Japanese have a second word to add in front that puts the proper emphasis.

Understanding that one, small, thing changes what words I want to use when explaining WordPress (or anything) to someone who doesn’t speak my language natively. I’ve done this before, with normal conversations and travel, but doing it for WordPress was very hard because we’re used to things like ‘doing_it_wrong()’ and even ‘Howdy, Ipstenu.’ Those are small words we think of as normal and simple, but their concepts are so large they lose something in the translations.

Besides just words, I’ve learned we definitely need to translate our brochures into the language of the country we’re in. Not having the pamphlet be in Japanese was a killer. Also our little DreamHost Robots need names!

Everyone thought our mascots were adorable, but they needed names. Since we have three stickers, one of them being tiny, I said we should call the little one “Yume-chan” because Yume (夢) means Dream in Japanese, and ‘chan’ is a diminutive. My father calls me ‘Mika-chan.’

Just for an example, Wapuu is the mascot of WordPress in Japan. So really anything small and cute like this needs a name.

Knowing that, I feel more prepared next time not just should I come again to Japan, but also in general for how I present at a WordCamp. Every time I come to one, I learn a little more and a little more about myself, WordPress, and how we all communicate.

WordPress democratized publishing in more than just your website, after all.
20 October, 2014
Automatic Geolocation

Traveling outside the USA always reminds me of how annoyed I am when I go to websites.

Like most of you, I have a bevy of websites I visit regularly. In my case, a large number of these sites are image or video related, and due to the legality of those things, I find myself restricted based on my current location. It annoys me, because if I pay for a service like my cable TV, why can I not watch it outside my home? Restricting my content based on my location is frustrating. I get CSI at home, but I can’t watch it while I’m here in Japan. This, of course, leads to things like illegally downloading movies, because there simply is no easy, quick, efficient way to acquire those things.

But worse than that is the tacit assumption that just because I’m in Japan, I want to visit the .jp version of a site. The number of sites that auto-redirect me to my current location’s language are not few, and most of them don’t have an easy way for me to click back and explain I’m not able to read Japanese.

For many years I’ve told people that forcing a language choice on users based on their IP is improper and unpredictable. It’s for the same reason I tend not to recommend blocking entire countries from your websites. The probability that you will hit innocents with a broad attack is very high. It’s higher than the chance of rain in Southern California.

So how do you do it right? You have to start by asking the right questions.

What language does the computer use?

You can detect that, you know. If my computer uses English, the odds are that I want to use English. Of course, a French speaker might use my laptop, but that’s on them, and one hopes they know to go to google.fr instead of google.com. Speaking of that…

What URL did I type in?

If I go to a URL directly, I may actually want that URL. This goes for you mobile apps too. If I go to Google.com right now, I get this:

That’s a nice, friendly question in English asking if I’m sure.

Have I been here before?

Cookies. When I go to a site, I get cookies. Those cookies can tell you what language I used the last time. So if you have a flag system where I can pick my language, please do try to honor that. There’s nothing a visitor hates more than having to reset their preferences every time. Facebook, this means you.

Where is my IP?

I know I said not to use this, but there’s a reason I want to ask this. If I take into consideration the URL, the browser locale, and the IP, I have a clearer picture of who’s visiting the site and what they want.

15 October, 2014
It’s Not GPL and That’s Okay

I’m probably starting a wildstorm here, but I want to put this out there. I don’t always use 100% GPL products on my sites, and that’s okay.

Please put down your pitchforks!

I am a happy Open Source person. If you give me a choice between two equally good products, one being Open Source and the other not, I’ll pick Open Source any day of the week. But. There’s a reason I use Apple Pages and not Open Office. Pages works for me. It fits my workflow, it fits my brain, and it makes me write more easily. Since I’m often sprawled on the couch writing with my thumbs on my iPad Mini, it makes perfect sense to use Pages and iCloud.

But there’s another place I don’t worry too much about GPL or Open Source, and that’s when I’m coding something that is only ever going to be for me.

I was working on a new site and we were looking for icons to properly represent how we felt. We needed a toaster. We didn’t have one in Font Awesome or Genericons, so I pulled up Symbolicons! The catch? It’s not GPL. But the thing was, we knew we’d never be distributing these icons. It was for one website, so why did it matter?

And the fact is that for this use case, it did not matter at all!

Understanding what I’m doing, who it’s for, and where it’s going to be used is highly important. And understanding what I want to support and maintain is equally important. For the most part, open source doesn’t come with Apple Care or companies like OWC who specialize in bailing people out or helping them extend things. WordPress doesn’t come with that, for good or not, it’s really a ‘figure it out as you go’ sort of product.

There are use cases to consider. Who’s going to use the computer? What do they know? Is it worth teaching them Linux or can they keep using their Mac? Much like I do when I’m mentoring someone, I don’t try to push my ideals on someone, or assume my way and my solution is the only solution. When I look at GPL, yes, it’s my default. I always start there. But I don’t stop there and I don’t let it blind me to what things need to be, because the best solution may not be open source, it may not be GPL, and it may not be WordPress.

So long as you’re not violating a license, use what suits your needs. But do pay attention to those licenses.

13 October, 2014
The Bias of Transparency

When I was in elementary school, we used to go to SeaWorld all the time. I loved seeing the animals, I loved being able to pet and feed dolphins. I loved the whole data dump of the ocean information. I went back in the days where the trainers were in the water with the orcas. I fed one once, and patted it’s nose. I danced with a seal (and sea lion). I really fell for the whole “Humans and animals together!” patter.

And then I grew up and read about how SeaWorld got those animals in the first place.

Your personal feelings on movies like Blackfish aside, even SeaWorld admits today that they were wrong in how they captured orcas back in the day. They were cruel and wrong, and SeaWorld hasn’t done that in 35 years. But the part of me that is upset with them is the part that wants to know why it took Blackfish to make them step up and say that. And the part of me that’s livid is the part who asks why they don’t disclose their history as a learning experience?

Transparency in development is not a new thing. Technology used to be a magical black box, but the more people embrace open source, I feel they’re more willing to express their issues and explain things that have happened. Even when you don’t understand the whole explanation, being told something like “Yes, the outage was caused because some electrical work caught fire” is much more satisfying than “The outage has been resolved.”

When I talked about why an outage didn’t inspire me to change my webhost, much of the reason was because of communication. While it could have been better, my host was transparent with me such that I knew what was going on. Perhaps not as fast as I wanted it, but I did, at all points in time, know what the deal was.

Being up front about problems gets messier when you start to talk about things like security. Earlier in the year, MailPoet had a security vulnerability. They fixed it, pushed the fix, and then it was reported on and everyone found out. People were surprised to find that the exploit was hunted down by people now that the information was in the wild, and others pointed fingers at the reporters for publicizing of the issue.

It’s a double edged sword. If they don’t report on the situation, people don’t understand how important it is to update. If they do make it public, the bad guys know what to look for. That’s why you get things like the accidental DDoS from TimThumb. People knew to attack for it, and they did. It’s the same thing with the HeartBeat vulnerability or the recent Bash issue. Once a vector is found, it will be exploited.

There isn’t a perfect answer here. There isn’t a perfect balance between information and education and secrecy. We want people to know “Hey, fix this!” but we don’t have a way to tell them without telling evil people. This ends up making us want to keep secrets and hide the truth, which just isn’t going to work in the long run. The only practical answer would be to fix this as soon as possible and hope no one hits us in the meantime.

8 October, 2014
Make Your Advice Work

I love Project Runway. Seeing people be that dramatic and traumatic over making clothes is fun, plus I love the design. One of the best parts is when Tim Gunn steps in as a mentor. He rarely tells people exactly what they need to do, but he will give them his opinion. It’s the way he handles critique that makes him impressive. Recently he had a new show called Under the Gunn where he let other people mentor some young designers, and that show was, shall we say, less than spectacular.

One of my favorite designers, Nick Verreos (aka Uncle Nick), was one of the worst mentors. Instead of helping his mentees, he did the work for them and made their designs look more like him. He drew for them, he sewed for them, he even gave them ideas.

That’s not the Tim Gunn way.

COURTESY OF A+E NETWORKS
Tim Gunn (left), host of the new Lifetime show ‘Under the Gunn,’ on set with mentors (second from left to right) Mondo Guerra, Anya Young-Chee and Nick Verreos, all former contestants on ‘Project Runway.’

When people ask you for advice on their work, it’s hard to not insert yourself into the process and put your own self into the work. You, too, are a smart, creative person. That’s why they asked you! So how do you keep yourself out of your advice and let people learn?

Boy that’s hard.

You have to let go of your own ego to do this. You have to be willing to remove your own desires from the equation, and instead of saying “Do this” you have to suggest “What if you did it like this?” It’s a classic case of leading the horse to water, but you really are the one who is going to show them the land where the ideas are and nudge them along.

One of the things I do a lot of is plugin reviews, and many times I see people reinventing the wheel. I don’t often put value judgements on plugins, and in fact I try hard not to do so. But when I see someone taking the hard road of handling a feature, like wanting to put autoplay in all YouTube videos, I wonder why they’re inventing a new oembed and shortcode and not filter oembed_fetch_url and have it check if it’s youtube and, if so, put in the arguments for autoplay?

But… Do I tell them “Here’s the code you want” and give it to them? Will that make them better developers? No, it won’t. Instead, I have to explain why reinventing the wheel isn’t a great idea.

Any time a plugin replicates functionality found in WordPress (i.e. the uploader, jquery), you’ve done something wrong. It’s a security risk, for one, as the features in WordPress have been tested by many more people than use most plugins, so the built in tools are less likely to have issues. But more importantly, you’ve given people too many ways to do one thing. A user doesn’t want to remember seventy shortcodes. They want to know “Hey, I know pasting in my video URL makes it show up on WordPress! I’ll do that!”

They want the easy, and you need to remember to give them the easy.

Similarly, advice on what’s right should lead towards what’s easy. What’s easier for you to maintain, to develop, and support. I know what works for me, but when I’m teaching someone how to update plugins and they ask me “What tool do you recommend?” I say “What do you already use and like?”

That’s my secret, by the way. I teach and mentor by trying to learn what they already know, what they’re already comfortable with, and then explain how to do things better or faster with those systems. But I try not to show them “This is the way to do it.” I stress this is A way to do things, unless what they’re doing really is a reinvention of the wheel, without making the wheel any better.

26 September, 2014