Tag: essay

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
Cookie Free Domains and CDNs
After I dropped Cloudflare I went back looking at other ways to speed up my site and what could I optimize things. As I mentioned in Static Content Subdomain, one of the benefits of that mess was to allow me to have a cookie free domain and, in having a cookie free domain, I basically made a domain that could be used as a CDN for my (mostly) static files.

It was noted then that, if you’re a non-www person, you have to actually use a separate domain. I do. I hate www in URLs. So I picked up a free domain for the site where I’m doing all this: ex-static.com. I probably could have gotten it even shorter if I’d tried sitecdn.net but that was short enough for me.

Since I already had everything over at /home/user/public_html/static I created an add-on domain in cPanel and told it to use that as its home.

Then I ran a search/replace on WordPress:
wp search-replace static.example.com/wordpress ex-static.com/wp-content/uploads wp option set upload_path /home/example/public_html/static/wp-content/uploads

Since I’d already changed my media settings, that was all I needed to really run a replace. It changed my media settings too! Since I was planning to move my static content, not just images, I changed the path too, so I had to go back and change upload_path as well, but wp-cli is my friend.

Next up, because of the static content move, I copied my wp-content folder over and added this to my wp-config.php:
```
define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/static/wp-content');
define('WP_CONTENT_URL', 'http://ex-static.com/wp-content');
```
Boom. Everything’s where I want it.

Sadly, it got messy for MediaWiki and ZenPhoto. The later doesn’t allow you to move your themes folder at all so I made a symlink to /home/example/public_html/static/themes/themename/ and called that a day. MediaWiki was a damn dirty lie.

Supposedly you can set this:
```
$wgStylePath        = "http://ex-static.com/wiki/skins";
$wgStyleDirectory   = "/home/example/public_html/static/wiki/skins";
```
As soon as I did that, I got errors all over the place and had to change the directory path back:
```
$wgStyleDirectory   = "$IP/skins";
```
Weirdly named, $IP is set as follows:
```
$IP = "/home/example/public_html/wiki";
```
I did the same thing as with ZenPhoto and made a symlink then I could change the style directory.

Lastly (and this was last for a reason) I changed my .htaccess rule:
```
# CDN
<If "%{HTTP_HOST} == 'example.com' ">
        RedirectMatch ^/static/(.*)$ http://ex-static.com/$1
</If>
```
This was last so that I could not break things mid-flight. And I added in this:
```
# CDN
<If "%{HTTP_HOST} == 'static.example.com' ">
        RedirectMatch ^(.*)$ http://ex-static.com/$1
</If>
```
Everything works as expected. And? I have cookie free domains and I’m ready to move all my data off to a CDN whenever I’m ready for that step. The CDN would only have to cover the ex-static.com domain, to boot!
16 September, 2015
On Site Advertising: Project Wonderful
This is part of a series of reviewing on-site advertising I have used: Project Wonderful, Google Adsense, WordAds.

I found Project Wonderful by accident. It was linked to on some comic book and fan sites I visit. For the most part, Project Wonderful is Project Pretty Good. It’s goofy, it’s silly, and most of the ads you get are for webcomics or ebooks.

Revenue from it is also chancy at best. I average pennies a day, but I have a lot of control and I like that which is part of why my revenue was so low. I set it up so I have to approve every single ad and ad change, which is exceptionally time consuming. This also causes lower revenue, but the primary reason I like it is that control.

I can block users, I can report them for scams or bait-and-switch, and I have a very wonderful rapport with the staff there. They’ve told me before that they appreciate my reports. If I change my mind about an ad, it’s a little tricky but I can go and find it and reject it after the fact.

There’s no plugin for this ad network. You have two bits of code to put on your site, the basic Project Wonderful JS that loads their commands and then the code for each ad-block. It’s pretty trivial to make a plugin for it, and in fact I made a shortcode that allows me to run [pwads id=name], where name is the name of the adbox. It’s a very basic switch check and sanitize and it works fine for me.

This code is also accessible outside of WordPress because the shortcode is calling a separate file (like /secret/ads/projectwonderful.php ) which I can then use with sneaky includes. But that’s another post. What must be known here is that I have it working in and out of WordPress with the same code base.

The biggest problem with Project Wonderful is that it feels like 1999. The site is old and dated. The interface is clunky and has a crappy UX if you’re on a tablet. Don’t bother with a phone.

The welcome page is pretty nice:

You have links to all your ads, you can click on them for more ads:

It’s not bad, it’s just dated. Also they have downtime a little more than I’d like to see. It used to be bad but now it’s once in a while. The real problem with the downtime is it makes my site slow.

Review
- Ease of Registration: 4/5
- Ease of use (on WordPress): 3/5
- Ease of use (non WordPress): 3/5
- Customizable: 5/5
- Control: 5/5
- Analytics: 3/5
- Modernity: 2/5
- Revenue: 1/5
I’m still using Project Wonderful, but the revenue certainly is something hard to accept. I stick with it, mostly, because it’s ethically pleasing.
26 August, 2015
Encrypt My Site, Please!

By now everyone running a website has heard about how Google gives sites running SSL a bit of a bump with search rankings. It’s been a year since they started doing that. The bump is not significant enough to impact most people, but making all the things HTTPS is still a good idea.

It’s really all about security. I personally use HTTPS for the backend of my WordPress sites. Logins and wp-admin are all secure. The same is true for my MediaWiki site and my ZenPhoto gallery. I access things securely because the data I transmit could be important. Sure, it’s just passwords and such, but then you look at my site where I sell eBooks.

That site is on the same server, the same account, and the same WordPress install as this one. You bet your ass I’m making it all secure. But this comes at a cost.

The invention of SPDY aside, HTTPS is rarely as fast as HTTP. It can be difficult to set up caching or implement terminations like via Pound or Nginx in order to cover for the fact that Varnish doesn’t cache SSL. These things aren’t impossible to do. They’re just harder. And they’re generally going to be slower than plain old HTTP.

The question has never been if they can or cannot be done, but if they can by entry-level people. Certainly we can say “If they’re not using SSL for all the things, they’re not ready for a great volume of business” and use it as a demarcation for things. And when we’re communicating our private lives, we should certainly consider this. But then, this site, where only I log in?

Do you need SSL? Would it make you feel better or more secure? All you can do is comment. Do you need the feel-good? Do I need the extra security? If I decide yes, then I have to consider the weight this puts on my site. I have to consider how best to cache the content.

I also have to think about how to get a certificate and SSL certs can be the biggest Internet scam out there.

It’s how much for a multi-domain, including subdomain, SSL cert a year? A few hundred? It’s a bigger hassle than the EU Vat drama. It’s expensive, it’s a hassle to get set up, and install. Now thankfully, next month we’re expecting Let’s Encrypt to show up and they’ll make the cost less prohibitive. It doesn’t make the drama of installing the certs any better, but it’ll lower the bar for people who are trying to make things secure.

Yes, you can get StartSSL for free, but it’s not as simple as all that. When all you need is one certificate, it’s only about $10 a year and that’s fine. When you start getting into the need to secure all the things, it’s a mess.

What has to happen next, though, is for sever software to step up. Apache and nginx are both far faster now than they have been, but they’re our ultimate breakpoint. PHP has to push itself to handle things better and faster, lest we run over to HHVM. We are getting better of course, but if we want everyone to be on HTTPS, we have to make it easy.

Not easier.

Easy.

The bar is still too high for the majority of people, and that’s a problem. Either we start offering hosting services to handle this or we start making the software easier. But we can’t just say “Oh, it’s simple to make your site HTTPS and fast.” because it’s not.

12 August, 2015
Everything Is Vulnerable

Every other day we hear about a tool that has a vulnerability. It’s been the servers we use, Flash, or Silverlight, or the Jeep that was hacked.

This Is Not New

The idea that hacking like this is new or novel is, let’s be honest, naive. In the 1800s, people used to hack into the newly born telephone system. Before that, we didn’t call it hacking, we called it conning. Yes, the confidence games people played to get others to trust them and then rip them off is the same idea as a hack.

A hacker is someone who finds a weakness in a computer system and exploits it to some benefit. Early bank penetration tests, the ones to see if they could get at your money, were as much social engineering as technical skill. A ‘hack’ is simply something taking advantage of an exploitable weakness. This is not new to anyone or anything.

The Scale Has Changed

The primary difference between the hacks of old and the ones today is the scale of those hacks. Hacks used to be very personal for a reason: there was no world wide network. Your hacks had to be local and careful, because no one trusted the stranger. You can to build up credibility before taking your win. Of course, now we have near instant communication with the entire world. That means it’s milliseconds to access the server of someone in Africa, all from your happy NYC Starbucks.

The difference is that now, when someone says “And Flash has a security vulnerability” the number of people impacted is in the millions. And the number of people who can be hurt by it is, similarly, high.

We’ve spend years trying to create a global internet, and in doing so we’ve quickly shared communicable internet diseases with each other.

Nothing Is Unhackable

My boss and I were chatting about the ways one might hack the stock exchange, and he pointed out that one of the ways they slowed down trades was by having a really long cable.

Credit Stefan Ruiz for The New York Times

This cable, and yes it’s real, is literally used to create a small delay in processing of orders, to level the playing field with traders. In short, it makes sure that the trades from across the ocean run at the same speed as the ones for the people in the room of the New York Stock Exchange. Each additional mile of fiber-optic cable adds 8 microseconds to a transaction, which adds up to 304 microseconds. Among other things this is hard to hack. You can’t send a software signal faster than it goes (physics being what it is), so it made things harder to hack.

The next Mission Impossible movie will involve Tom Cruise being slowly lowered into the box with that cable in order to shorten it invisibly. Only Cruise can do it because only he is small enough.

That was my joke. But it’s actually rather demonstrative to the point. You can physically hack things as well.

Analyze The Risk

To quote my father, “What can go wrong? How likely is it? What are the consequences?”

That’s why I don’t own a wifi pluggable garage door or thermostat. Do I think they’re cool? Yes. Do I think they could make much of my life easier? Yes! But they’re new and they’re toys, which means people spend a lot of time poking at them and digging into the underlayer to see how and why they work. Which means people are finding hacks daily.

That means the likelihood of someone figuring out how to use my thermostat to drive my budget through the roof is pretty high. Someone already did that to his ex-wife if that review is to be believed. Of course he had the access in the first place, but it proves one point. If you get access, you can do things.

Change it to my garage door? Or my front door? Say good bye to my things. I know I’d be a target because I’m using the pricy toys to start with.

Educate Yourself

If you can not do stupid things, the odds of you being hacked are low.

By stupid things, I mean using insecure passwords. I mean logging in on public WiFi to do your banking. I mean installing any old plugin on a WordPress site running a store.

The things you know are dangerous.

Don’t be stupid. Make backups. Be prepared for disaster.

10 August, 2015
Don’t Publish Bad Code

I thought it was self evident, but two of my more respected programer friends missed the point or, rather, took notice with one aspect.

So let me rephrase what I meant when I said it was okay to write bad code.

Write all the bad code you can. Learn from it. Make it better. But the code you publish should be the goddamned best damn code you’re capable of writing at that moment in time.

The point I was trying to make was not to let the fear of ‘This code is shit’ stop you from learning and improving. That’s like saying if you can’t play a piece of music the first time out, you should quit. That’s stupid! Few people can do that! The rest of us have to practice and learn and keep going.

And yes. That means sometimes when we give a public performance we screw up. That doesn’t mean we shouldn’t perform. That doesn’t mean we shouldn’t fail.

You’re going to fail, okay? Just give up on that wish. Everyone fails. We fail more times than we succeed, and that failure hurts more than the success feels good.

When you do a thing, do it to the best of your abilities and no less. If you’ve left a comment of “Come back and fix this.” then you damn well go fix it before you release the code. Writing bad code is no excuse to slack off, it’s an acceptance that not everyone gets it right from the start and you’re going to have to learn from it.

So learn.

3 August, 2015