Half-Elf on Tech

Thoughts From a Professional Lesbian

Author: Ipstenu (Mika Epstein)

  • If You Call Yourself a Developer You Should …

    If You Call Yourself a Developer You Should …

    Sometimes people scare me. Mostly it’s people who start a conversation with some variant of “I’ve been a developer for X years and I’ve never experienced a conversation like this…”

    It tends to come up when I kick someone’s code back and remark “Remove your own jQuery, delete the demo folders, and your domain name is a problem so change X to Y.”

    They get upset because I’ve not spelled out, specifically, to the letter, what’s wrong and where. I’ve had those conversations with everyone from a mom-and-pop shop coder to Microsoft and it really only bothers me when people are running dev companies and ask things like “How do I find that?” or “Where is that code?”

    So here are my rules of what a Developer should know:

    Know Logic

    You should understand logic. Not Spock Logic. Math Logic. And Computer Logic. Don’t worry. I don’t think you need to be a math rock star to write code. I think that if you understand basic algebra, which you may be surprised to know you do, then you’re okay. But you have to understand the most basic of logic gates:

    The basic computer logic gates (1/0, Yes/No, Or/Nor, etc)

    Can you look at that and understand the differences? Great. Write some code. Understanding the elementary building blocks of circuits, the A or B, the Yes or No, is the crux of programing. If you can’t logic that out, you should stop and read up on it. Most self-taught programmers have intuited that, but at some point they had a class in Boolean Algebra and learned this. Maybe it wasn’t called that, but most of us had that class in at least High School. You’ll need it.

    Know Grep

    You need to know how to search all the files in your code. If you’re on a linux flavor, grep or ack are your best friends. So when someone says “I see you’re calling domain.com in your code, why?” you know how to find that, even if they don’t give you a line.

    Know What You’ve Got

    You need to know all the packages added to your code. Did you add a library or a sub-module? This is your responsibility to know what they are. That way, when someone tells you to ‘remove the X module’ you’re not surprised. If it’s in your code, you should know what it is.

    Know What You Need

    You need to know what those packages are adding to your site. Did you download a whole jQuery library with all the demo files and a version of jQuery and the help docs? Do you really need all that? Dollars to donuts, you don’t. Don’t let your code be cluttered by what you don’t need. It’s more work to maintain it, and if there’s a security hole in it, you still have to be aware of it. Save yourself time, effort, and a hack. Leave out what you don’t need.

    Know What To Use

    You need to know how to edit the various filetypes. Personally I don’t care what you use. I like Coda. My friends like Sublime. I don’t care. Just make sure you use something that works for you and helps you work better. While you can do all your programing in Notepad, I wouldn’t suggest it. You will need tools to help you keep track of the complex world you’re building. Sometimes you’ll have to use a specialized tool.

    Know How Your Tools Work

    Did you know Github makes a downloadable zip of your code? Did you know that zip doesn’t include submodules? Did you know Github forks aren’t searchable? You should. I have a few awesome tools, like Coda, which lets me search my repositories and find code. I use BBEdit to search zips. I use a new tool to compare folders when I don’t have version control (for whatever reason). But I know how they all work.

    What Else?

    What do you think is imperative for someone who calls themself a professional developer to know?

  • Self Ghosted

    Self Ghosted

    I had to restart everything.

    You see, getting Node.js and apache to work together wasn’t going to fly, so I went and built a new VPS with Ubuntu over on DreamHost. Obviously not everyone has this luxury, but since I do, and since DreamHost made this as easy as clicking on a box, I thought it would be perfect.

    Requirements

    You have to be shell savvy for this. Sorry. There’s no other way. Just accept that and move on.

    You need a VPS. The new Ubuntu SSD VPSes all have a one-click ability for Node.js which makes life easier.

    You should use nginx and not apache.

    Ghost requires Node.js 0.10.x (not 0.12.x). They recommend Node.js 0.10.36 & npm 2.5.0. Of course, DreamHost installs node 0.12.x and npm 2.5.x. You can check by typing node -v and npm -v to see what versions you have. Does this mean you can’t run Ghost? No, it’ll work, but it’s not what they like.

    You’ll also need an ‘admin’ account on your server. From panel, click on “VPS” and then “Manage Admin Users” to add a new user to that box.

    Get Node.js on your VPS

    This is quite simple. First, get an Ubuntu VPS. All the new boxes on DreamHost are Ubuntu, so this is the easy part. Once you have the VPS on DreamHost, make a new domain. I made ghost.elftest.net and in the settings, I checked a box to use node.js:

    Enabling Node on DreamHost is Easy - click a box

    That will force my file path to be ~/ghost.elftest.net/public (normally on DreamHost it’s ~/domain.com you see) but that’s not an issue since this is a new box. That path will be my ‘home’ folder for the domain and where I install everything (if someone asks you ‘where is X installed on your server?’ you tell them that path). That path also means that had I already been using that domain, it would mess up my folders and paths. If you’re doing this on an existing domain, keep that in mind.

    Install Ghost

    Like I said before, you have to install on your server, not your desktop. Every single doc I read told me I HAD to do this as the server admin, someone with sudo access. I really, really, really did not like that. I mean, epic levels of hate for the idea that I couldn’t have my user account own things, and have the code in my darn web folder.

    Me being me, I hatched a plan. I was just going to do it. I was just going to install it in my webfolder and see how it goes. I came up with this theory because when I read How To Install Ghost on DreamHost I noticed it wanted me to have a specific user chown the folders. Not the admin user, but a special ghost user. So what if I just made ‘elftestghost’ the ghost user, and what if I just used ~/ghost.elftest.net/public/ghost/ as my install directory instead of /var/www/ghost/? And this way, I’d be able to pop in and edit things as my normal user.

    So here’s what I did.

    $ curl  -L https://ghost.org/zip/ghost-latest.zip -o ghost.zip
    $ unzip -uo ghost.zip -d ghost
    $ cd ghost/
    $ npm install --production
    

    That’s it. Ghost is installed. I expected that last step to fail and I’m still a little surprised it didn’t. If it does fail for you, run it as your admin account with sudo, and then chown it over to your ‘owner.’

    Configure Ghost

    Now that Ghost is installed, you may wonder where it is. We haven’t finished the install yet as it happens. We need to configure it and to do that, we copy the file config.example.js to config.js and open it up.

    Once you look at it you see that there are multiple ‘config’ options. Since we called --production in our start command, logically we’re going to edit that section. And lo, there’s the bad URL:

    config = {
        // ### Production
        // When running Ghost in the wild, use the production environment
        // Configure your URL and mail settings here
        production: {
            url: 'http://my-ghost-blog.com',
            mail: {},
    

    Change that to the right URL. Mine is http://ghost.elftest.net

    Also look for this:

            server: {
                // Host to be passed to node's `net.Server#listen()`
                host: '127.0.0.1',
                // Port to be passed to node's `net.Server#listen()`, for iisnode set this to `process.env.PORT`
                port: '2368'
            }
    

    Change the host to 0.0.0.0 and save the file. You can also set it to the IP of your server, but as that might change, it’s not required.

    Finally you’ll want to set up mail which can be complex. I set up a special account on my own server.

    Setup Ghost

    Seriously this is not a five minute install. Your site starts with a Hello World type post which tells you all about the glory of Markdown. If you go to your admin page (http://ghost.elftest.net/ghost/) it sends you to http://ghost.elftest.net/ghost/setup/ where you get this:

    Ghost: Create User

    This actually makes more sense than it did on the Ghost Pro site, where I was wondering why I had to make a user and then a user. Here I’m clearly making a user for the site. There I was making a user for their network (Ghost Pro) and then one for my site.

    Setup Nginx Proxy

    Will it never end? The reason we want to do this, and this is why we’re on nginx and not apache, is in order to have a pretty URL without the port number.

    Log in to your server as your ‘normal’ account (the one who owns the domain, not the admin) and make an nginx folder for config:

    cd ~
    mkdir -p nginx/ghost.elftest.net
    

    Then make a file called ghost.conf with the following:

    location / {
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   Host      $http_host;
        proxy_pass         http://localhost:2368;
    }
    

    Restart nginx (which yes, you need the sudo power for so yes, you need an admin account) and it’ll magically work. If you get a “502 Bad Gateway” error, it’s because Ghost isn’t running. Speaking of…

    Make Ghost Always Start

    Okay so I actually do need my admin account. I went with the init script approach to keeping the Ghost always on.

    $ sudo curl https://raw.githubusercontent.com/TryGhost/Ghost-Config/master/init.d/ghost \
      -o /etc/init.d/ghost-elftest
    

    Then I edited the ghost-elftest file:

    GHOST_ROOT=/var/www/ghost
    GHOST_GROUP=ghost
    GHOST_USER=ghost
    

    I changed that to where ghost was really installed, but it brings up an interesting thought. What if I wanted multiple ghost instances? Well that’s actually why I named the file ‘ghost-elftest’ instead of ‘ghost’ (which they recommend). With this setup, I can name an init file for each instance and run the commands as sudo ghost-elftest start and so on. Keep in mind, you also have to pick a custom port for each instance.

    There are three final commands to run in order to force Ghost to start up on reboot:

    $ sudo chmod 755 /etc/init.d/ghost-elftest
    $ sudo update-rc.d ghost-elftest defaults
    $ sudo update-rc.d ghost-elftest enable
    

    Now I can use Ghost to my heart’s content.

    Conclusion?

    A WordPress killer this is not. It’s just not. If they can make it run without the need for admin/root/sudo access, it has a chance. Once it’s set up, it’s quite nice, but the 5 minute install this is not, and it’s going to need that to beat the beast.

  • Mailbag: Ghost Image Errors

    Mailbag: Ghost Image Errors

    Once I got Ghost up and running, I got some errors and there was venting around the usual places. Image uploads were failing. I cried. Then I solved it. Then someone asked a logical question.

    How did you fix the image upload issue?

    What happened was that I found I was getting a Wiggly Cat whenever I uploaded an image. Eventually the upload failed.

    Ghost's wiggling cat

    The cat bounced up and down. My wife eyed it and said “That’s not much of a chuffing SOS now, is it?” (no, she’s not British, but what else can you say about that?). Thankfully, after years of WordPress support I went right into the file system and checked if the images were being uploaded at all. Answer? Sort of.

    $ ls -lah
    total 0
    drwxr-xr-x 2 elfghost elfgroup 131 Apr 15 17:22 .
    drwxr-xr-x 3 elfghost elfgroup  23 Apr 15 17:12 ..
    -rw-r--r-- 1 elfghost elfgroup   0 Apr 15 17:13 f4c134eb021e026414a1bd23d3c5c927-1.jpeg
    -rw-r--r-- 1 elfghost elfgroup   0 Apr 15 17:12 f4c134eb021e026414a1bd23d3c5c927.jpeg
    -rw-r--r-- 1 elfghost elfgroup   0 Apr 15 17:22 unicorn.jpeg
    

    0 bytes isn’t right. But again, WordPress support history to the rescue. I checked my /tmp folder, saw it was full, turfed the entire thing, and the upload worked. Rather fast, too, since it’s not making an image resizes. I will note, had that fix failed, I’d have started playing with folder permissions, but since I got the 0-byte version, I was reasonably sure that wasn’t my issue.

    Two humor tidbits for you.

    Bing thinks I write in Turkish:

    Ghost! What is this cat and the error and the aaaaaaiiahsfdhkjdfgjklhdgkjhfgd? (Bing thinks it's turkish)

    Here’s a cute bouncing cat:

    Pusheen The Cat
    Pusheen The Cat
  • Newsletters Are Still Cool

    Newsletters Are Still Cool

    It started with a mention:

    And I went and looked up TinyLetter

    It’s simple. It’s as easy as writing a blog post and boom, you’ve sent a mail. In so far as that goes, it’s awesome.

    It’s too simple. There isn’t a way to really automate it.

    It’s really cool. It just works and sends out a nice, easy to read, email.

    It’s really annoying. You have to get folks to sign up.

    I really want to like it and use it, but I’m not sure I have a use case. Thanks to Jetpack, I push to LinkedIn, Facebook, Twitter, etc, and my family sees the things. They sign up to Jetpack emails for in-boxes.

    But if I needed a newsletter, I’d use TinyLetter.

  • Update Fatigue

    Update Fatigue

    The week of April 20th saw a lot of WordPress related updates:

    1. WordPress 4.1.2
    2. WordPress plugins with a major security issue
    3. WordPress 4.2 and 4.1.3
    4. A bunch of themes fixing the same issue plugins had
    5. WordPress 4.2.1 and 4.1.4

    I don’t know about you, but even with automated updates, I was tired of all the updates. I was also tired of explaining to people that, yes, those security issues were a massive hole and yes, they did need to be patched. And yes, I know it’s annoying to get all those emails and have to test all the things because not every plugin or theme is created equal.

    In the midst of all that, I noticed one of my plugins had updated 6 times in ten days. That’s pretty much an update every other day and you know what? That’s way too much.

    If I have to update your plugin every few days for minor releases, I’m going to stop using it. Update when you:

    1. have a point release
    2. are fixing really important bugs

    Other than that, if you update every few days for minor changes, I really am stopping using your plugin because you are making my life annoying. You’re why people hate updating. You’re why they stop.

    There are valid reasons for multiple releases in a week, like bug fixes for 0-day security holes that have already been publicly disclosed. But in this case, it was all minor changes, like adding languages and so on.

    That was useless and pointless and annoying. Okay, fine. Maybe not useless or pointless. Those are important things to update. But when should you update them? Not every day, certainly, nor even every week. If you look back on my two simple rules for when you should update, consider them seriously.

    Is this a bug or a new feature?

    New features means new major revision unless there’s a reason not to. My plugin Genericon’d keeps pace with Genericons’ versioning, so while they’re on 3.3, I will update 3.3.1 with a new feature. The majors are at their behest, so I have to take control over minors only. It’s not ideal. I hate it but it’s the best way to make sure people know “Hey, this has version 3.3 of Genericons!”

    New languages aren’t bugs nor are they really features, but they should only be added if there’s a major release. Alternately, you can slip them into a bugfix, but they shouldn’t be your only fix. As for the person who really needs the language? Make them available on git or svn and tell them to download and put it in the /wp-content/languages/plugin/name/ folder. Not ideal, I agree, but it’s a majority/minority issue.

    How often should you patch bugs?

    Is it a zero-day exploit, released in the wild, bug that’s breaking sites right now?

    RELEASE THAT SUCKER!

    Is it a minor bug that annoys you but doesn’t cripple the site? Make a dev branch, fix it, but don’t push the release just yet. Wait until you have a lot of bugs fixed. Or wait until you have the next major release.

    Take a page from how WordPress.org pushes minor releases. Fix the bugs that need fixing. Solve the security problems. But updating every day? Not a great experience for anyone.

    Opps! You missed a critical bug!

    That happens. Update the plugin right away. Yes it sucks but see the bit I bolded above? That’s your exception. If you break something, fix something. We pushed 4.1.3 because we broke sites with 4.1.2. Period. Fix it.

    But you’re sure people really want this new thing!

    Maybe, but people also really don’t want to be hassled and you’re hassling them. People have (understandable) concerns about updates. They worry about bug fixes. They worry about how your change will impact all their other plugins and themes. Keep that in mind before you push a change or a fix.

    Did you update that changelog?

    It’s your code diary. For every good commit message there should be a good changelog entry. Just do it. You’ll be thanked.

  • Mailbag: What’s The Diff?

    Mailbag: What’s The Diff?

    How do you compare two plugins to see if one’s a fork or stolen? What’s the difference between a fork and a clone?

    Sometimes people like to ‘steal’ plugins. This normally happens when someone takes a premium (purchase only behind a firewall) plugin and attempts to give it away for free on WordPress.org. They tend to violate copyright when they do that, but also it’s just not a cool thing to do and I find it distasteful.

    Often we catch these since people who steal like that aren’t always very smart and we recognize code that is generally well known and popular. But more often we don’t catch it because CodeCanyon has 3400+ plugins and WordPress.org has 37k+ and that’s a lot to compare and remember. And that’s when we get an email from a plugin developer who says “So and so stole my work!”

    What do we do? We ask them for a copy of their code, in a zip, and say we’ll compare. Most developers are happy to do that. We’re a trustworthy lot, otherwise we wouldn’t be on the plugin team (yes, being a good, moral, and ethical person is very important). Once I have the zip, I download the claimed-clone and compare them line by line.

    Well. Not really.

    My toy is DeltaWalker.

    With DeltaWalker I can compare two zip files without having to open the zips and look at each line. In the below example, I’ve got Akismet 3.0 vs 3.1.1 and I can see every single change just by tossing the zips in as files to compare:

    DeltaWalker Example: Akismet 3.0 vs 3.1

    DeltaWalker is so good, it helps me compare the readmes so I can easily see that someone has just fiddled with the original and not written their own.

    What I look for is code style, formatting, and naming conventions. Rarely do two separate individuals use the same code formatting (tabs vs spaces vs tabs+space etc), so seeing their additions will jump out. Similarly, the code style, their internal logic, is often wildly different. Same with naming conventions.

    When you look at it, it will jump out at you that generally all anyone does is rename functions or classes. They remove credit and copyright information too, and sometimes they mess with the help docs. Rarely do they add anything of substance. If they do then it’s a legit fork and we’ll push them to restore credit and copyright information.

    But since it’s generally not, we will quickly see that the plugin is a direct, no feature added, copy, and remove it.

    If this happens to you, if your plugin is ‘taken’ and duplicated without any code being added, email pluginsATwordpress.org with a copy of your original plugin (and a link to perhaps prove it’s you) and we’ll look at it. If you get an email where we tell you that your plugin is a copy, take a moment to review your code and feel free to talk with us about it. A ‘one line’ change actually MAY be acceptable as a fork, but it’s rare unless it’s adding in a massive feature, or totally changing functionality.

    Above all, remember this:

    Despite the fact that all plugins in our directory are licensed under the GPL or compatible licenses, we do not allow direct copies of other plugins to be re-listed under somebody else’s name. “Forking” is acceptable only when the resulting fork is of a substantial nature, or when the original plugin is no longer updated or supported.

    Always try to contribute back to the original plugin’s authors if you wish to make improvements to the original plugin, instead of creating an entirely new version and thus creating incompatibilities and duplicated code in the repository.

    Alternatively, write your own plugin to perform the functionality you want to have, drawing on ideas from the original. Ideas can always be copied.