Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: development

  • 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.

  • Git Flow

    Git Flow

    Late as always to these git things.

    In the ever increasing madness to the method of making code easier to do, we come to the automation of git-flow. This is a library of git subcommands that helps automate some parts of the flow to make working with it a lot easier if you’re using Vincent Driessen’s model.

    This model is not bad, if a little confusing at first:

    The git-flow model

    Jeff Kreeftmeijer already has a good primer for it so these are just my quick notes to add in things that should have been obvious. The basic concept for the model is that you have two main branches, master (the ‘current’ version) and develop (where you’re working on the next version).

    Install git-flow

    You have to install it to use it. I use Homebrew so it was brew install git-flow and that was that.

    Add it to your repo

    Again, you have to add it to have it. git flow init is run inside the repo and you’re good, except you may not be.

    Since I’m starting from an existing repository, which was up to date in master, I made a new branch: git checkout -b develop

    Then I ran git flow init which is not the same as it would be on a new repo:

    $ git flow init
    Which branch should be used for bringing forth production releases?
       - REL_3.3
       - REL_3.3.1
       - REL_3.3.2
       - master
    Branch name for production releases: [master] master
    
    Which branch should be used for integration of the "next release"?
       - REL_3.3
       - REL_3.3.1
       - REL_3.3.2
    Branch name for "next release" development: [master] develop
    
    How to name your supporting branch prefixes?
    Feature branches? [feature/]
    Release branches? [release/]
    Hotfix branches? [hotfix/]
    Support branches? [support/]
    Version tag prefix? [] REL_
    

    Should you happen to do as everyone says and ‘accept the defaults’ you get this:

    Branch name for "next release" development: [master]
    Production and integration branches should differ.
    

    Also if you don’t have a develop branch, it punts you out.

    Branch name for "next release" development: [master] develop
    Local branch 'develop' does not exist.
    

    So a couple ooops along the way. It’s not

    Using A Feature

    First you make a feature:

    $ git flow feature start utility_1.0.3
    Switched to a new branch 'feature/utility_1.0.3'
    
    Summary of actions:
    - A new branch 'feature/utility_1.0.3' was created, based on 'develop'
    - You are now on branch 'feature/utility_1.0.3'
    
    Now, start committing on your feature. When done, use:
    
         git flow feature finish utility_1.0.3
    

    Eventually you’ll be done and use that finish command, which merges it all back into ‘develop’ and changes you back to that branch. Which is good for reasons we get to in a moment. Since I work on multiple computers, I do this at the end of my workday:

    $ git push --all
    Total 0 (delta 0), reused 0 (delta 0)
    To ipstenu@example.com:/home/ipstenu/repositories/theme-wordpress.git
     * [new branch]      develop -> develop
     * [new branch]      feature/utility_1.0.3 -> feature/utility_1.0.3
    

    So now when I do my pull later on the other computer, it’ll be easily usable. Provided I remember to install git-flow and init it on my other laptop. But it’s a little more complicated than just that.

    Releasing a Release

    You can only run this from the develop branch, which makes the previous command pretty awesome, right? So now we’ll do this: git flow release start RELEASE

    Once we’re good to go, it’s git flow release finish RELEASE

    What About Two People?

    This is where we want to use publishing. Technically I’m collaborating with myself across two computers, so I always publish my feature to my remote server so it can be used by my other self: git flow feature publish MYFEATURE

    To pull the feature down, git flow feature pull origin MYFEATURE is just as logical. And that’s actually how I handled pulling the feature utility_1.0.3 onto my work laptop.

    $ git checkout master
    Switched to branch 'master'
    Your branch is up-to-date with 'origin/master'.
    $ git branch develop
    $ git flow init
    [snip .. same as before]
    $ git flow feature pull origin utility_1.0.3
    Created local branch feature/utility_1.0.3 based on origin's feature/utility_1.0.3.
    

    There’s a good cheat sheet for help about this called Git Flow Cheatsheet.

    Now there’s nothing but to do it.

  • I Hate Your Framework

    I Hate Your Framework

    The plugin itself was one PHP file and three JS files.

    The framework was over two megs.

    The plugin added in a new setting to select which one of the three javascript files should be called.

    The framework ‘made it pretty.’

    I’m right up there telling people that the WordPress Settings API is a giant bag of wet hair. It’s confusing, it’s cryptic, it doesn’t always play well with everything, and sometimes it makes you feel like the point is to make us have decisions, not options, for our plugins. But I don’t think plugin frameworks are the answer. At least not the way most people seem to be going about them.

    When I say frameworks, I don’t mean the libraries like the AWSSDK for PHP framework that you package up into your plugin and do a proper check for a function, calling yours if the the library isn’t there. No, I mean the plugins that are totally separate plugins but are meant to be called by yours in order to make development easier and more consistent.

    That’s what I hate.

    I love the idea of these frameworks, actually. I think that a boilerplate plugin, similar to _underscores, where I can put in my plugin name, my information, and press a button to have the basic plugin files generated for me is brilliant! But I think most of the libraries out there are doing it in a way that will annoy and upset most people.

    The problem is less the framework and more the people using them as a ‘quick fix’ without properly thinking about what they want to do.

    They’re Too Large

    In the case of this plugin, one file with three settings could just be done with two functions (maybe three) and instead he’s made a download half the size of WordPress core. The zip is large, it makes things take just a little bit longer for people on slow servers to download and upgrade, and the larger you get, the worse you are for the really small shared hosts. I know a lot of people argue with me about this, but remember than a high number of hosts still default you to allow 7M in PHP upload size. That means when your plugin becomes the 30 meg behemoth with all your dev files, you’ve made things pretty bad for some users. But even when you’ve only made your plugin 2 or 3 megs, why would you do that when you have one file of actual code?

    The logic escapes me.

    They’ve Got Too Many Files

    Not the same thing as too large! There are hundreds of files in a framework, and if you’re using only 4, that means you have 96+ files to review for security. You just increased your workload for not enough value. Which is really a major part of my next issue. The point here is you, the developer, are responsible for every single file in that framework. You are expected to know everything about it, where it installs, what it uses, why it uses it, and when to upgrade. This is a pain. It’s a chore. And it’s your job now.

    You Don’t Know How to WordPress

    This is also why I don’t like the idea of making Multisite too much easier. The further you take a developer from writing this code, the further they get from understanding how it all comes together and the harder it is for them to debug their own plugins. If you’re developing a plugin you plan to share with other people, even a teeny tiny one, you need to understand what you’re doing. You need to learn about the way the code interacts with the CMS tool, you need to understand why some things are secure and others are not.

    You Use the Frameworks Wrong

    I said before, I love the idea. And I do. They’re a brilliant idea and, when done right, work perfectly. The problem with them is, a bit, a problem with WordPress, which is we really don’t have a way to handle children plugins. You see, the best thing for a true framework plugin would be to have it be a separate plugin. But without plugin dependency support in core or the directory, it becomes another level of hassle for users.

    For example… if you have the plugin as a separate plugin, these are the issues we’ve see for end-users (not developers):

    • Not recognizing the framework plugin, and thus deleting it (causing the plugin(s) to break)
    • Not recognizing the framework plugin and thinking they’ve been hacked
    • Updating the framework plugin separately from the dependent plugins, possibly leading to breakage
    • Updating a dependent plugin without updating the framework, possibly leading to breakage
    • Different plugins requiring different versions of the framework

    And bearing in mind that the framework and plugin developers are different people, that’s another level of coordination/compatibility issues. Frameworks and libraries should be packaged with each plugin (hopefully in a way that doesn’t conflict with other plugins using the framework or libraries). At least until core supports plugin dependencies.

    But I still think that’s wrong.

    I still think the best framework plugin isn’t a plugin at all, it’s a tool to help you design and build a plugin via your editor of choice. Or maybe a Grunt Script that lets you build it out based on parameters. Time spend making a framework for making the plugin ‘interface’ better would be better spent making the Settings API better.

  • 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/
    
  • Packaging Code

    Packaging Code

    I love that people do it. I hate that they don’t review it.

    The number of projects I review, only to find that the author ran a tool like Grunt to combine files, but forgot to go over what the result was is fairly high. And this is a problem when you consider how many times I have to tell people “Your submission still has demo files, test scripts, and other files that aren’t applicable for distribution.” What happens is that people use the very cool auto-scripts and never stop to make sure that everything’s right. They make sure the code works but they don’t remember to clean up the package.

    So let’s talk about what should never be in your plugins for WordPress.org

    Deployment Scripts

    Now I know a lot of people use scripts to copy their code from GitHub to WordPress’s SVN repo, and I think those scripts are great. They’re helpful, they speed up development, and please keep them out of your plugins. Your script should include a note not to distribute itself. I understand why, when you link us to the GitHub default zip, those scripts are in the review package, and that’s okay. But I do sometimes run a sweep through the repository to see how many people are accidentally including those SH files in their plugin packages. You’ve got to remove those. They don’t matter to the final product and without them, your plugin will be smaller.

    Demo Folders

    Here’s the thing. They don’t matter. A lot of awesome 3rd party tools come with detailed demo files and extensive things you’ll never need. Those demo folders also tend to be where you’ll find all sorts of crazy things like Google Analytics tracking, calls to external resources (like jquery’s JS files), and more. Your users will rarely, if ever, need that sort of thing. They generally don’t notice it, unless you code it into your plugin, at which point you’d be better served by making it look like WordPress.

    Test Scripts

    Your test scripts don’t need to be in your plugin. They’re cool, to make sure that the code is going to work before you push it, but that code doesn’t need to be in the plugin on my site, does it? No it does not. All automated tests should be separate from your plugin code files. People don’t need to see the Travis checks in the code on their sites. If they’re developers, they’ll go look for them at your code’s home, after all.

    Compressed and Uncompressed Files

    Pick one. You don’t need both. When you’re talking about a framework or a library, it’s fine to pull in a minified (but not p,a,c,k,e,r compressed) version of the file as your own version. If there’s no need or plan to edit that file (and there shouldn’t be), you can make the plugin smaller. Of course, I feel that if the JS is all of 7 lines, for goodness sake, it’s fine to leave it all human readable.

    What Else?

    What do people leave in plugin or theme packages that drive you up the wall?

  • A Case For Hello Dolly

    A Case For Hello Dolly

    I like it.

    I never use it, but I like it.

    I delete it, but I like it.

    It’s not professional, it’s not beautiful, and it’s not something that makes WordPress look grown up.

    And I think needs to stay in the core download of WordPress.

    Let me tell you a story of you. Let me remind you of yourself. Not the you of today who knows all amazing things. Remember the you who was young and inventive but inexperienced. The you who knew how to throw a football but couldn’t throw a spiral. Or you knew how to drive a car and not stick shift. The you who delighted when you learned all those things, like a child with a new toy.

    That you was not professional yet. That you needed an example for how to do new things. You had teachers and friends and parents who showed you the ropes.

    That’s what “Hello Dolly” is. Hello Dolly is the Hello World of WordPress, and it makes a plugin suddenly seem like a non-insurmountable task. We can all look at that one file and see either inspiration for code we can make, or a sudden lack of terror for what WordPress is. Like I tell people in training classes, WordPress is just files, folks. A plugin can be just that file. And you can take the idea and run with it. More than just a training tool, it’s the epitome of open source. It’s code, freely given, than serves as a first step for people who come to WordPress with no formal education. It’s free. It embraces the goals we want to see in open sourced code.

    So it needs to stay in WordPress, because you needed it once. Does it make an annoying extra step for you to delete it when you’re installing WordPress for your clients? Maybe, but for me it makes a moment where I can look back at myself from 2009 and see how far I’ve come from the woman who was too scared to speak at a WordCamp to become a WordPress professional.

    I’ll take that one extra step and never forget where I came from.