Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: website

  • 2.2 Million AOL Dialup Users

    2.2 Million AOL Dialup Users

    InfoSec Taylor Swift tweeted about how a man using AOL’s dialup and AT&T got charged $24,000 for the number he dialed.

    My take away?

    https://twitter.com/Ipstenu/status/593236980848164864

    You see, I read this line and did a double take.

    Eighty-three-year-old Ron Dorff of Woodland Hills is one of the 2.2 million remaining AOL dial-up customers.

    2.2 million people are still on AOL dialup.

    Most of my Twitter followers took my shock the wrong way. Folks, I know that there are many reasons for this. I know that folks in the sticks don’t have other options. I know that it’s cheaper than satellite for people on a budget.

    None of that was my point.

    Or rather, it was but not the way people seem to think about it.

    Woodland Hills is in the LA Metro area. He has other options. Still not my point.

    No, my point is something Eric Mann said at WordCamp Portland 2013 that stuck with me (and my wife). My point is that if only 50% of phones in America are smart phones and that if 2.2 million people in the US use AOL dialup, that’s a lot of people.

    50% of America is 159.45 million.

    2.2 million people is 0.69% of America.

    Interestingly, a Pew survey determined that 3% of Americans use dialup at home. That’s 9 million people.

    My ‘terrifying’ moment had nothing to do with the fact that people are on AOL (though I admit I thought AOL had canned dialup). My moment was entirely because we, the creators of the internet, are making a poor experience for about 9 million people. Realistically, we’re probably making the internet suck for a lot more, with our heavy websites that do a million things and are slow.

    In our push to go forward, we forget about the past, and we forget to take care of the past and degrade nicely. We can’t always support everyone, but 3.18% of Americans on the internet use IE8 (according to statcounter). If we still care about IE 8 (and yes, we do), then we should care about the 3% who use dialup, and the more who are stuck on their cell phones (check out the 7.9% of users who are on the ‘other’ OS for phones, I bet they’re the ones on non-smart phone).

    It’s terrifying how, in our push forward, we forget them.

    The video is 5 minutes. You can watch it.

    InfoSec Taylor Swift favorited my tweet about AOL having that many users on dialup

  • NUX: Setting Up Ghost (Self Hosted)

    NUX: Setting Up Ghost (Self Hosted)

    Once I used Ghost Pro, I thought about self hosting. I have a WP site that’s basically wasted as a WP site. It’s small, it’s static, and it rarely changes. I thought it would be perfect for Node. There are also a couple of small, basically HTML, sites I run in the back of things. This would be fine to manage that.

    But first I had to address a major misconception.

    You Install Ghost on Your Server

    For some reason in my head I had this working like Jekyll, which I would install on my computer and push up to my server. No, I’m not so much installing Ghost as Deploying Ghost.

    But I Installed Ghost On Your Computer

    I decided to do this anyway, just to see what I was getting into.

    To install Ghost you must install Node.js first. Since I have Homebrew, this is two commands:

    $ brew unlink node
    $ brew install node
    

    I had an older version of Node.js installed for whatever reason.

    Sadly I can’t install Ghost this way.

    My Brew output for installing node.js and not Ghost

    Next you download Ghost (I was download 564,730) and at this point I hesitated. The directions don’t tell you where to put the files. It just says this:

    Next, grab the newly extracted ‘ghost-#.#.#’ folder and drag it onto the tab bar of your open terminal window, this will make a new terminal tab which is open at the correct location.

    Since I know that upgrading involves replacing the files, I’m no fool, and I made a new folder setup: ~/Sites/ghost/sitename.com/ That’s where I ran node commands:

    $ npm install --production
    $ npm start
    

    Done. Now I have Ghost up and running locally.

    Install Ghost on My Server

    In a word? Ow.

    The main issue is Node.js and Apache both want to use the same ports. That’s impossible. And I want to keep Apache running port 80 because this VPS runs… well… WordPress. This is where I stopped the first time I tried to do all this and tossed this post into a long draft.

    There are directions on How to Host Ghost on an Apache Subdomain, which luckily is what I wanted to do. Except it was complicated and messy and required root.

    So the NUX here? Absolute crap. It’s just not something a new user would want to do, be able to do, or be able to maintain.

    And that sucks.

    Ghost’s got a great interface, one that I like better than WordPress for blogs and simple sites. It’s nailed simple in a way we crave. But it came at a cost. WordPress’s simple to install is fraught by it’s IDIC complex. Infinite diversity in infinite combinations, with the themes and plugins, lends WordPress amazing abilities but a pretty insane learning curve. Ghost I could sort out in a couple hours but you really can’t do too much with. I wouldn’t use it for a store. I might use it for a blog if I had to start over.

    Except I can’t (easily) self host it because of stupid Node.js.

    If they can sort that out, make it so I can easily, without root, install and manage Ghost, I’ll be back.

    Until then, Managed Ghost Hosting is the way to go. Or WordPress. Take your pick.

  • The Ebb and Flow of Automation

    The Ebb and Flow of Automation

    Repetitive tasks suck. Let’s be honest here, we hate doing them most of the time. But also we’ll forget things and mess up our day. With code that’s pretty terrible.

    Over time, I’ve managed to automate a lot of things. WordPress upgrades itself, including plugins and themes. My code changes are auto-deployed via Git when I update them. I use a cool Coda plugin to automatically generate css from multiple files.

    I’ve now added Grunt to the mix. Grunt runs tasks for you so you can be lazy (efficient) but it’s not perfect. One of the things I love about my other tools is I don’t have to think about them. WordPress takes care of itself, git has hooks to know what it’s doing, and Coda monitors my files. I don’t have that for Grunt.

    What you have, instead, is ‘grunt watch’ which is great but it only runs while you’ve told it to watch. You have to remember to activate it every time. And I understand why. Watching is a rather expensive (computer wise) tool. But it annoys me because I already struggle to remember that the way a tool I use works, I have to run this to checkout the code: git checkout [tag_name] -b [my_branch_name] (which for some reason my brain thinks is ‘better’ than scripting a zip).

    So why would I use Grunt?

    On a site I run, I have a folder filled with scripts that are used on four separate CMS tools. One is WordPress. I’m often adding new scripts and I like to have the scripts separate because that’s easier for me. But that also means I have to edit all my CMS to add in the new JS. But with Grunt I don’t.

    Instead, I have one simple Grunt file that says “Any js file in /content/code/js/dev/ should be combined into one mondo js file and then uglified to compress it down.”

    Installing Grunt

    I didn’t have Node installed, but I do use homebrew, so this was it for me:

    brew install node
    npm install -g grunt-cli
    

    Okay. Now what?

    My First Project

    I knew I wanted to make a folder in my /content/ folder for this, so I made /content/project/. In that folder I ran the command npm init and answered the questions to generate my package.json file. That was the easy part actually. After that had to decide what I wanted to do.

    1. Concatenate (combine) all my JS files into one.
    2. Compress those files to make them minified.
    3. Watch the files while I was working on them and automate that.

    In order to do that, I need to install three grunt ‘plugins’: concat, uglify, and watch:

    npm install grunt-contrib-concat --save-dev
    npm install grunt-contrib-uglify --save-dev
    npm install grunt-contrib-watch --save-dev
    

    Doing it that way, with the save dev call, automatically adds it to my package.json file so it knows to call that.

    Next I had to make a filed called Grunfile.js and put my actual code in it. I’ve got a copy of the file below but you can break it up into some pretty basic sections. Here’s a sample file:

    module.exports = function(grunt) {  
    
        grunt.loadNpmTasks('grunt-contrib-uglify');
    
        grunt.initConfig({  
            pkg: grunt.file.readJSON('package.json')
    
            uglify: { ... }
    
        });
    
        grunt.registerTask('default', [] );  
      
    };
    

    The first call is to load the npm (node) tasks, which means I’m telling it ‘include these plugins’.

    The second call is my init command which runs when the ‘grunt’ command is used. In there I’ll put the name of my json file, where I’ve defined all my dependancies (not all get loaded by the Grunt file you see) and then I’ll make a ‘case’ for my code. That’s what the uglify: { ... } bit is.

    The last is registering the default tasks. At this point, if I want to do anything I would have to type grunt uglify to do anything, so what you can do instead is make it this:

    grunt.registerTask('default', ['uglify'] );
    

    Now when I run ‘grunt’ it will automagically uglify. If you have multiple steps, put them in order of what you want to happen, and off you go.

    At this point, I’m now a GruntJS rookie, but I can see why it’s amazing. One can use this in plugin development to make it easier to mush up all your code into something smaller to load.

    My Scripts

    For those wondering, here are my scripts:

    package.json

    {
      "name": "jfo-content",
      "version": "1.0.0",
      "description": "JFO Content Scripts",
      "main": "Gruntfile.js",
      "dependencies": {
        "grunt": "^0.4.5",
        "grunt-contrib-uglify": "^0.7.0"
      },
      "devDependencies": {
        "grunt-contrib-concat": "^0.5.0",
        "grunt-contrib-uglify": "^0.7.0",
        "grunt-contrib-watch": "^0.6.1"
      },
      "author": "Mika Epstein <ipstenu@halfelf.org>",
      "license": "WTF"
    }
    
    

    Gruntfile.js

    module.exports = function(grunt) { 
    	
    	grunt.loadNpmTasks('grunt-contrib-uglify'); 
    	grunt.loadNpmTasks('grunt-contrib-concat');  
    	grunt.loadNpmTasks('grunt-contrib-watch');
    	
    	grunt.initConfig({
            pkg: grunt.file.readJSON('package.json'),
    
    		concat: {  
    		    dist: {  
    		        src: '../code/js/dev/*.js',
    		        dest: '../code/js/content.js',  
    		    },  
    		}, 
    
    		uglify: {
    		    build: {  
    		        src: '../code/js/content.js',
    		        dest: '../code/js/content.min.js',
                        }
    		},
    
    		watch: {  
    		    scripts: {  
    		        files: '../code/js/dev/*.js',
    		        tasks: ['concat', 'uglify'],  
    		    }
    		}
    
    	});
      
        grunt.registerTask('default', ['concat','uglify'] );  
      
    };
    

    post_update (git)

    I added in a line here to delete the package folder from my live site. That’s where all my Grunt stuff lives and I really don’t need it. It also nukes the dev folder. Sometimes. In some cases I leave that alone, since it’s not like I’m worried about space.

    #!/bin/sh
    export GIT_WORK_TREE=~/public_html/content/
    git checkout -f master
    rm -rf ~/public_html/content/package/
    rm -rf ~/public_html/content/code/js/dev/
    
  • Rant: Worse than a Popup

    Rant: Worse than a Popup

    I hate popup ads. Everyone does. You’re trying to read an article, perhaps on your phone, and these inline popups show up and obscure the content with ads for things you don’t care about.

    We hate them more when they play music.

    We hate them more when you can’t click on the tiny X on a phone.

    But I have something I hate even more than that and it’s Apple’s fault.

    You see, I use Safari sometimes to read on my phone. This is all well and good until I scroll on a slow site (probably slow because of their abuse of javascript laden social media toolbar crap that we didn’t care about to begin with) and my finger accidently brushes an ad. And then the ad opens the App Store to ask me if I want to download some idiotic game.

    I take deep, calming, breaths and then I close out of the App Store, go back to safari, and I leave the page. Most of the time the article remains unread.

    And why is this Apple’s fault? After all, the fault should lie with the idiots who thought that the best idea for a mobile site would be to have a bajillion ads.

    This is Apple’s fault for two reasons:

    1. There’s no way to tell Safari not to open these
    2. There’s no ‘are you sure?’ message from Safari to let you decline

    In fact, in all my research, the only thing you can do is to clear the browser cache and set Safari to only allow cookies from Current Websites Only. But as Apple warns you, that may cause issues with other sites.

    This can be fixed! Apple can simply make it an option (hidden) to hide this. But also you website designers and developers, if someone says they don’t mind the popup ads and lightbox garbage on the mobile site, I want you do to me a favor.

    Say no.

    The web won’t get better unless you make it better. Please don’t make a website you’d hate too.

    Oh and those ‘cool’ floating sidebars with the tweet links? They look terrible when you zoom in on the teeny tiny text on your website.

    Stop it.

  • Cheap Is As Cheap Gets

    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.

  • The Road to PHP 5.x

    The Road to PHP 5.x

    If you use WordPress, you may be surprised to see that WordPress still supports PHP 5.2

    PHP 5.2 was released in 2006, which is nearly a decade ago, and in the way that the internet ages, an impressively long time. In 2010, only five years ago, the last version of PHP 5.2 was released: 5.2.16. At that point, PHP no longer supported 5.2, but did apply security patches. True end of life hit in January 2011.

    But back in 2006, when WordPress was getting off the ground, a lot of people were still using PHP 4. Not 5, 4. It wasn’t until mid 2010 that WordPress itself dropped support for PHP 4 (and MySQL 4). At that point in time, roughly 11% of WordPress installs used anything lower than 5.2 and this made it a pretty safe bet.

    So why does WordPress still support PHP 5.2? Today if you look at the (not very accurate) WordPress stats, you can see that over 30% of people still use PHP 5.2

    pie chart shows 33.6% of users are on PHP 5.2

    Back in 2010, WordPress was about 10% of the entire web. It’s double that today, so 33% of people on 5.2 is significantly larger than 11% back on pre 5.2, and with those numbers, it’s easy to see why it has to keep supporting PHP 5.2 … for now.

    But the next obvious question becomes why is PHP 5.2 out there? And the answer is that WordPress is only 22% of the internet. Flip that around and remember that 78% of the internet is not WordPress. WordPress is not everything, nor should it be, so the webhosts of the world do have to consider than when they begin to upgrade.

    Most major webhosts are in some state of killing PHP 5.2 with fire (seriously I am very excited for when it’s finally gone from DreamHost). When we upgraded people to 5.4, we found a lot of people who had very odd code out there that just didn’t work on 5.3 or 5.4, and upgrades broke them. We also found a number of people using WordPress who broke, mostly because they’d customized PHP 5.2 and forgotten, but also some who were on things like WP 2.x and were shocked, just shocked, it needed to be upgraded.

    As developers, we want to be able to force everyone into a place where we can upgrade PHP (and WordPress) and have no compatibility fears. We want to use the new features of PHP to allow us to craft better, faster, more efficient code. We want to give users the features they ask for. But we can’t until everyone upgrades. And thus the vicious circle begins.

    Would WordPress dropping support for PHP 5.2 speed up it’s demise? No. Not at all. Because WordPress is a drop in the ocean of the hassle that is upgrades. Do I think WordPress should drop support for PHP 5.2? Yes, but not the way you’re thinking. I would love to see WordPress stop supporting 5.2 in the sense that it should stop testing against it and worrying about backwards compatibility with PHP 5.2. It should check, on upgrade and install, that PHP 5.3+ is used and go from there. Heck, if it had a big alert “Hi, you’re on PHP 5.2, please upgrade!” on the admin page, that would be awesome.

    But I don’t know that there are any PHP 5.3 (or 5.4 … or 5.5 or 5.6) specific features that absolutely require WordPress to be on 5.4 at this time. Frankly, that doesn’t matter at all because the issues with upgrading are far less related to where WordPress is going and more directly the cause of where servers have been. Most hosts grow organically, servers being built following a process and then (eventually) via an automated tool. But because of that, a lot of old servers and operating systems don’t lend themselves well to upgrades because they’ve been built rather … higgeldy-piggeldy one might say.

    It’s that history, the drama of people not seeing the future 10 years ago, that puts many hosts in a position where upgrade is actually going to mean moving users to a new server with new features. And that is not something to be done lightly. We can’t just pick people up when we want and move them. There will be downtime, there will be outages, there will be delays. And because of all that, these moves take longer than you want.

    This is not to say the hosts aren’t doing the right things, just that they take longer than anyone (especially the host) would like. And believe me. No one wants PHP 5.2 gone more than a web host.