Category: How It Works

CDN vs Local

Which is better?

I have no idea.

Sorry. That’s not the end of the post, obviously, but really after the time it took to write this, my answer is that I really don’t know. So let’s talk about why I don’t know.

The claim is this: “A CDN is faster!” The idea here is that a CDN will be faster because it lessens the load on your server. Anything that’s being process by another server means less work yours has to do. And that is totally true. Also, many CDNs have worldwide locations, which means someone in India can download your cat video from a nearer server than yours in Michigan. Also, more people have downloaded shared resources (like Google fonts) so it won’t be downloaded again, making their experience faster.

And all that sounds great. But the actual functionality and performance gains are not going to be exactly tit for tat. At first, I thought that since I get a lot of traffic in Brazil, having a CDN that has local servers would be great for them. It was. A little. But it was a lot worse for me. Using my site in the US slowed down measurably. This was because of the latency of the CDN being worse than my own server.

In addition, many site speed tests measure how many URLs you call in your page. Using a CDN ups that by one. It’s minor, but it’s something to consider. There’s also the idea of branding, which a CDN can hurt if you use it wrong (most CDNs will allow you to use cdn.yourdomain.com of course). Using too many servers for a CDN (think of it like cdn1.example.com, cdn2, and so on) can slow down the user experience too and cause overhead with all the DNS lookups.

What’s the alternative? Good caching. And I do think that proper, server side caching is hugely important. But at the same time, the right network for your static files can provide significant improvements. Which is why we always end up back at CDNs.

The real thing to consider is what your content is on that CDN. WordPress is dynamic content and shouldn’t be on a CDN. Images and stylesheets, though, those are perfect for a CDN. You take the traffic and, thus, the load off your server and it becomes faster. Streaming video too.

Which brings us around to the idea of the cloud as a CDN.

But is it faster? Is it better? Is it safer?

Maybe. It certainly can be, but there is no blanket perfect answer for all of us.

Currently I build local but prepare for the possibility of a CDN later on.

21 September, 2015
Mailbag: Debugging .Com

From Wesley:

It’s a one-word question though so I hope it won’t take you too long: my blog is free, which means it’s a .com, not .org [redacted] so I cannot install plugins, right? And an even quicker follow up, there’s no hope for me to erase post revisions so to free space and upload a page that’s over 200K words and refuses to do so, is there? Thank you so much for your attention. Cheers

Your site is hosted on wordpress.com so you can’t install plugins (or themes). Even on VIP you can’t, though they may do it for you. It’s a Multisite thing.

Also you can’t erase post revisions, but you also don’t need to worry about that. It’s not why you can’t upload a page of over 200k words. That’s just WP timing out. I’m assuming it’s hanging and timing out… Hard to know for sure without a description of the error.

Sadly, since it’s on .com and I don’t work for them, you will have to ask how to handle that here: https://en.forums.wordpress.com/

My suggestion would be split the post into multiple posts. I’ve found people rarely read a post longer than 1500 words. If it was a self hosted WordPress, I’d tell you that you should check the PHP error logs, and see if it’s a PHP timeout (which would be my guess) or something else like a mod_security error. If it’s PHP, there’s not a lot you can do unless you’re on a VPS or better, but really ‘adding more PHP memory’ is not the best move.

Storing massive amounts of data is slow. 200k in a post is huge. If you were to space it out, it would make a 580 page book, give or take. I may have done NaNoWriMo before. Anyway, the point is that’s why we invented chapters in the first place. I have a mental image of a guy on an old manual page press, being handed the 580 pages to typeset, and breaking down. He’s sitting in a corner, crying, rocking back and forth.

Today he’s your database. Your database is sitting in a corner with PHP, crying. “Why are you giving me so much to do at once, PHP?” And poor PHP is sobbing. “I don’t know, I can’t even handle it!”

Anyway. Smaller posts. People won’t read 200k in one go. Not even speed readers.

7 August, 2015
It’s Okay To Write Bad Code

We all write Bad Code.

We all write insecure code.

We all can learn.

When I posted about bad code, a reader remarked he’d done those things when he was new. So did I! So does everyone. We learn by copy/paste and seeing “Oh! Hello World actually worked!” Those are wonderful moments where we high-five ourselves and feel like we’re learning something cool.

Everyone makes mistakes. Everyone writes bad code. Everyone misses something. These are all parts of the learning process. So

Bad Code Educates Us

When we write bad code, and someone calls us out on it, we learn something. Negative reinforcement is a terrible thing, but those lessons tend to stick with us better than the best positive ones. We remember the feeling and we do anything we can to avoid it again.

Bad Code Humbles Us

We’re not perfect. You’d think we don’t need a reminder, but our egos can get the better of us. We start to think we’re awesome and know everything and are always right. We’re not perfect. We’ll never be perfect. Don’t use this as an excuse to write sloppy code, but be aware of your inherent imperfections.

Bad Code Inspires Us

When I see bad code, it reminds me to be better and do better. It goes back to the education thing, but really it’s the desire not to be shitty that inspires us to do better. The positive feedback loop being what it is, we really want to be better and have that feeling.

Bad Code Entertains Us

I have a site where all that exists is code that ‘breaks’ your site. It’s funny in a way, to learn how to do things by doing it wrong. When I see how far off I was and how bad it was, I laugh. Because in being educated and humbled and inspired, I find the delight in the universe again and laugh.

What Do You Learn?

What do you learn from bad code?

27 July, 2015
I Love/Hate Font Icons

I really, really, love font icons and emoji. I love being able to express myself with an image. I delight in hearing Siri read me my latest text from my wife and say “smiling pile of poop” six times to inform me that the cats are being absolute shits.

But they have problems.

We use font icons because they scale well on different screen sizes, they’re flexible, they can be styled well, and they require only one resource to be loaded. For people like me, who are effectively monkeys with crayons when it comes to art or design, they’re perfect. I want Twitter in a theme? <i class="fa fa-twitter"></i> and done and done.

So what’s the problem? They’re not accessible. Oh you can make them accessible, but they’re not really easily done. Screen readers have a devil of a time with them. They’re also hard to add to. If I want to add a ‘new’ SVG icon, well I can just upload a new image and be done. SVG icons on the other hand have all the same benefits of font icons, and some more. But this isn’t to say that SVG is perfect.

As mentioned, adding new SVG icons is easy. Far easier than font icons. But that comes with a cost. Using them is not quite as obvious an intuitive as it might be. Just googling for ‘style svg with css’ presents you with a dizzying array of possibilities. This gets worse when you look into do what is (relatively) simple on font icons, like animation.

I’m not saying these things are impossible. In fact, you can do far more with SVG than you can with fonts. The problem is that it’s all still very dev heavy. Don’t believe me? Read Why and how I ditched icon fonts in favor of inline SVG. That post is something I agreed with every step of the way right until we hit this:

There’s a Ruby script that reads the optimized SVG files one by one and generates a Rails helper file with icon_xxxxx methods. These methods can be called from any view to insert the desired icon as inline SVG:

I have no problem with scripting solutions. I love them. They’re just not really simple-user friendly yet. A user knows “I paste a line of code in to include a font, I can use font icons with very little code.” By contrast, SVG is code heavy and comes with too many options.

Uploading an SVG icon to your server’s easy. You can’t do it in WordPress without a plugin to allow those media uploads, but if it’s in your theme folder it’s there.

Once you have the image on your server, you’ll want to call it. It’s an image but you don’t want to use IMG tags for this.

<object type="image/svg+xml" data="my-image.svg">Your browser does not support SVG</object>

or if I want to be clever

<object type="image/svg+xml" data="my-image.svg"><img src="my-image.jpg" /></object>

The idea is to have a fallback (see CSS Tricks’ complete guide to SVG fallbacks) so that people can see things if there isn’t an ability to show SVG because it was in an IMG tag.

In the name of security, browsers disable SVG script interactivity if you use an IMG tag. Interactivity means the stuff you want to do, like style it and make it move. Also some browsers won’t accept SVG in CSS if they’re in a separate file. Awesome.

There’s one other thing to note. SVG can dynamically create images on the fly.

<svg width="100" height="100"> <circle cx="50" cy="50" r="40" stroke="green" stroke-width="4" fill="yellow" /> </svg>

Hey look, ma! No image files! Check out HTML5 SVG from W3Schools for more.

The thing you may notice with these examples, though, is that they get more and more complex as I trip down the line. And when I want to start adding color to things, I end up looking at the <svg> code more and more, and I just don’t find it friendly.

So until SVG sorts out how to be a little dumber for people, I’m going to keep using my icon fonts and (as best I can) properly attribute them a best I can for accessibility, and wait for the future.

22 July, 2015
Trust the Changelog
Recently there were a couple WordPress plugins with fairly major security fixes. But you wouldn’t know it by looking at their changelogs.

The changelog is a section of a product’s readme that describes what changed. For most people, it’s a list of items like this:
- Added feature X
- Corrected typo
- Security fix
The problem many people have is that last one is often left rather vague. I’m guilty of this myself. In a recent fix, I simply said “Security fix: Sanitizing _POST calls to prevent evil.” and “Security Fix: Implementing nonces.”

The primary reason we keep change logs a bit vague is because we don’t want to open the door to alert hackers as to vulnerabilities. People don’t update their code right away, so every time we publicize a security issue, the people who haven’t updated immediately are at greater risk of being hurt.

But if we don’t tell people how important it is to update, how do they know how important it is to update?

There’s the real issue. There’s not yet a proper balance between “You should upgrade as soon as possible” and “You need to upgrade now, or you’re doomed.” My security issue was only accessible by people with admin access. It would be possible to trick an admin, with a cleverly crafted page, but … The effort it took me to apply a nonce check and sanitize things is minimal. From my end, it’s very minor of a fix. From a user’s end, it’s an exceptionally rare hack and unlikely to occur.

The right answer here is “Always upgrade to the latest version of code as soon as possible.” The problem is “as soon as you can” gets bumped out if it’s not mission critical. A patch that adds in a filter? Not a big deal. A patch that secures my site? Should be a big deal. I would argue that any time anyone says “This is a security fix” then you shouldn’t have to concern yourself about how likely the hack is to impact. Instead, security is a watchword to tell you to update the software “immediately.”

Which brings us to two agreements we need to start making with people. The agreement of developers to do things ‘easier’ for users and the agreement of the users to trust developers. If we want people to upgrade, they have to trust us. And if they’re going to trust us, we have to be reliable and consistent.

As developers, we promise not to flag something as a critical security fix that isn’t just security fix. If there’s a major issue with our code, we will push a patch as soon as possible that only deals with that issue. There will be no feature changes, no little fixes, no minor tweaks. A security release will only be a security release.

Furthermore, to enable people to update properly, we will properly use semantic versioning. This will allow us to update minor releases as far back as logical, because you can know that version 1.2.8 is the latest version of the (old) 1.2 branch, and 1.5.3 is the latest of the (current) 1.5 branch. The next time we add in new features, we will properly version our code as 1.6 so that you know what branch is current.

As users, we promise to trust your security-only releases and upgrade our copies of your code when a minor release that is a security issue is released. If you release a version 1.5.4 and not a version 1.4.4, we will trust that either the 1.4 branch is not subject to this security issue, or the fix could not be back-ported. If you inform us that we must upgrade to the 1.5 branch because there’s no way to secure 1.4, we will expedite our upgrade.

In order to enable ease of upgrade, we will not edit our code to make it impossible to change. We will properly use functions and actions and filters and hooks. We will make regular backups as well as immediate ones before upgrading.

Of course… That’s a perfect world. But I’m going to do my part as a developer and start versioning better. If I do that, and if I as a user hold up my other end, then we can get to a place where all disclosures of security issues happen in tandem with a release, as we know that everyone will upgrade immediately.

A place of trust.
24 June, 2015
Editing Content In Ghost Rocks
You may have noticed based on tweets that I’ve been using Ghost daily (mostly) for a little while now, trying to get a feel for it vs WordPress.

You know what? With the exception of wanting to kill people while I was installing it, I really, really, like it for simple blogging.

The editor is a delight, plain and simple. It’s fast. Super fast. There’s nothing dragging it down man. Which ironically is where it loses.

You see, there’s no extendability. It’s like the Old Days of WP, where I have to edit a theme to make widgets. Oh and no apps right now.

Not to mention the drama of installing. It sucks for self hosted. This continues down to installing themes (sucks) and apps (non-existent). You have to reboot the Ghost ‘node’ after every change too. This is not tenable for most people and highlights the need for apps. Oh. Yeah. Apps are a thing that Ghost needs, stat.

Right now, they’ve added in a way to add code to your header and footer without needing to edit themes, which means I was able to put in my Google Analytics code easily.

Ghost is Ghost. WordPress is WordPress. For what I do, WP is right. For plain, simple, blogging, Ghost is good except for the Markdown aspect. I’ve got the hang on it, but it’s been nine years and I doubt it’s ever going to be ‘the thing.’ HTML wins for many reasons.

So what do I want from Ghost into WordPress? That damn editor! Seriously.

The content on the left and preview on the right is great. It live updates and I can see what things look like in the Visual editor while having full code control like the HTML editor. In addition, there’s no place to put in the tags or featured images or anything other than content. Until I click on that gear.

That is slick. And it works great on mobile too. Compared to the fade out and off center DFW editor in WP, which is pretty great, it’s awesome.

Of course I looked at the available plugins for WordPress

Gust Plugin – This looked great, but it doesn’t work on Multisite. On WP 4.2 it threw this:
```
Fatal error: Cannot redeclare get_avatar_url()
(previously declared in
/wp-includes/link-template.php:3414) in
/wp-content/plugins/gust/gust.php on line 202
```
Then there’s Splitdown – Not updated in a year and also errors:
```
Parse error: syntax error, unexpected T_STATIC,
expecting &amp;#039;)&amp;#039; in
/wp-content/plugins/Splitdown-master/Splitdown.php
on line 19
```
Finally we get to PrettyPress – This isn’t a ‘Ghost’ plugin exactly but it makes a second ‘editor’ you can flip into. No save button there, but as an editor it’s rather nice.

At this point, I’m resigned to not having that kind of slick editor in WordPress. I do think it’s a nicer direction than ‘distraction free’ as it’s actually fewer distractions. All I see is my content and a preview.
20 May, 2015