Half-Elf on Tech

Thoughts From a Professional Lesbian

Author: Ipstenu (Mika Epstein)

  • Why I Do This

    Why I Do This

    Every once in a while someone makes a few veiled statements about how I must be on some kind of power trip, and that’s why I took control of the Plugin Review team as the rep. It’s not true.

    Why I am a Forum Moderator

    I was helping people and one of the mods asked if I’d join. I said yes. I’m currently still on the team, but I no longer am super active. I’m kind of on the cusp of the requirements for being a moderator, and if they removed me, I’d be okay with that.

    Why I was the Forum Representative

    We were just deciding who should be the very first reps for teams, and I was asked (along with someone else) if I’d be willing to try to help us figure out how we wanted to do this. I stepped down from that responsibility after a few years to lower my personal stress.

    Why I am a Plugin Reviewer

    I had been reporting a bunch of plugins doing bad things, as well as helping the gents figure out some crazy stuff. They abducted me and asked me to help. I did and bit by bit learned how to properly handle reviews. I keep doing reviews because I enjoy it.

    Why I am the Plugin Review Representative

    No one else wanted to do it and we needed someone to take responsibility and make some changes. Like with the guidelines. The directory etc. I still do it because it’s a needed job.

    But … WHY!?

    None of that answers the real question of why I do this at all though. If it’s not apparent, I literally fell into this job by accident and stuck around. I stick around because I enjoy what work I do and I learn from it. Learning about how people write code, the assumptions they make, teach me more about accidental security than all the time I worked at the Bank.

    But also I believe that any social organization that advocates that the means of production, distribution, and exchange should be owned or regulated by the community as a whole. And to that end, I feel that the only right way to make plugin code reviews, or the forums, work is to get the community self-regulating.

    The problem with that theory is that not everyone is altruistic. If people within the community have a desire contrary to the rest of the community, it causes conflict and drama. Therefore, a true ‘socialist’ society requires people willing to be the ‘baddie’ and say things like “No, you can’t do that.” Basically, we need a parent who’s able to explain to the children why putting their hands on the stove is bad, and why throwing rocks at their friend was mean.

    I certainly don’t think I’m the only person who can do this. I just seem to be one of the few willing to do it in a consistent and continuous fashion. And that’s the reason I stick around. I’m trying to build a future where anyone can do technical code reviews for submitted plugins. Anyone. However that comes with a lot of responsibility for the community.

    While there are many people capable of doing a technical review, and many people competent at explaining bad code to developers, and many people wise enough to handle angry developers, that Venn Diagram has a very small crossover. And if you factor in people willing do to it, it gets smaller.

    For example. Everyone complains about the WordPress Plugin Guidelines being too strict and too vague. Last year I undertook the monumental effort of rewriting them for clarity and fairness. I asked people at multiple WordCamps to help. We sat and discussed what the guidelines meant and why they were worded in the way they were. Then I posted on the Make blog asking people to help.

    Of the few hundred people who complained, less than 20 had anything to say.

    From that, and other times I’ve reached out to the community and asked for help, and the results I’ve had, I feel that people aren’t willing to embrace all the aspects of the job. Yet. That’s why I’m slowly, carefully, working my way through the changes. I’m trying to lower the bar for them, to make them more amenable to join.

    It takes time.

    Yes, but that isn’t WHY!

    Oh right. Why do I do this?

    I review plugins because I legit enjoy seeing the crazy code people come up with. I help in the forums for the same reason. I like seeing what people do, and solving problems. I like writing the code to solve the problems too.

    I’m the plugin rep because it’s a dirty job, but someone has to do it, and I’m okay with being hated by people. I know I’m doing it to make code better and safer for users, to encourage developers to engage in ethical and kind business practices, and because I learn from them too.

    At the end of the day, I do this, all of this, because I can, because I enjoy it, and because I feel good when I help people.

    One day that may change. When it does, I’m sure I’ll walk away. That’s just not today.

  • Accepting Failure

    Accepting Failure

    This is a difficult thing to do, so let me share some briefs of recent failures.

    Failure To Launch

    I recently retired a plugin. It’s a good plugin, complex and clever and does things in a wickedly smart way. And its an absolute failure because it lacked the ability to solve one problem, perhaps the biggest problem it was intended to solve.

    The plugin was more complex in ways that it didn’t need to be. I spent a lot of time thinking about one use case, and I never looked far enough to think about the real world, which ended with this plugin only being used by 600 or so people, and most of them grumblingly.

    Accepting my loss, I recognized that I’d coded myself into a hole, wrote uninstall code, and apologized. A lot.

    Failure to Maintain

    I closed my ebook store recently. Quietly. Because it was so much work to update and maintain, and it was draining me. I kept all my books on Amazon, where they sell much better with much less work, and redirected everything.

    The problem was I wasn’t making enough money on it to justify it. While I had intelligently made changes to inspire people to purchase instead of download for free, and I strongly believe in letting them be free when they need to be, it’s just a lot of work. A lot. I was spending time I wasn’t earning on. Nor enjoying.

    Failure to Communicate

    There’s someone who hates me right now. They think I’m a terrible person, that I hate them, that I want them to fail. Because I was unable to explain sufficiently why what they were doing was wrong. I’ve tried appealing to them, offering them more exceptions and time than I usually do (ever) for a fix that should be simple.

    For some reason, we just can’t bridge the gap. They won’t listen. And no matter what I say, they only see hatred in it. I can’t convince them otherwise. And yes, that smarts. It’s a terrible feeling to not have failed myself, but to have failed someone else, to the point they feel they have no recourse.

    Accepting Failure

    Accepting you’ve failed at something is hard. Thankfully in all three cases, I feel like I’ve learned something from them. I learned how to control my temper, how to watch the weight of my words. I’ve learned how to properly write and run an ebusiness, and why I don’t want to. I’ve learned how to gracefully degrade a plugin.

    But knowing I failed still does hurt.

    So all I can do is learn from it and move on.

  • Cron Caching

    Cron Caching

    WordPress' relationship with cron is touchy. It has it's own version, wp-cron which isn't so much cron as a check when people visit your site of things your site needs to do. The problem is that if no one visits your site… nothing runs. That's why you sometimes have posts that miss schedules.

    One possible solution is to use what we call 'alternate cron' to trigger your jobs. That works pretty well as it means I can tell a server "Every 10 minutes, ping my front page and trigger events."

    But in this case, I didn't want that. I receive enough traffic on this site that I felt comfortable trusting in WP cron, so what I wanted was every hour for a specific page to be visited. This would prompt the server to generate the cached content if needed (if not, it just loads a page).

    WordPress Plugin

    I'm a huge proponent of doing things the WordPress way for WordPress. This method comes with a caveat of "Not all caching plugins will work with this."

    I'm using Varnish, and for me this will work, so I went with the bare simple code:

    class LWTV_Cron {
    
    	public $urls;
    	
    	/**
    	 * Constructor
    	 */
    	public function __construct() {
    
    		// URLs we need to prime the pump on a little more often than normal
    		$this->urls = array(
    			'/statistics/',
    			'/statistics/characters/',
    			'/statistics/shows/',
    			'/statistics/death/',
    			'/statistics/trends/',
    			'/characters/',
    			'/shows/',
    			'/show/the-l-word/',
    			'/',
    		);
    
    		add_action( 'lwtv_cache_event', array( $this, 'varnish_cache' ) );
    
    		if ( !wp_next_scheduled ( 'lwtv_cache_event' ) ) {
    			wp_schedule_event( time(), 'hourly', 'lwtv_cache_event' );
    		}
    	}
    
    	public function varnish_cache() {
    		foreach ( $this->urls as $url ) {
    			wp_remote_get( home_url( $url ) );
    		}
    	}
    
    }
    
    new LWTV_Cron();

    Yes it's that site. This very simple example shows that I have a list of URLs (slugs really) I know need to be pinged every hour to make sure the cache is cached. They're the slowest pages on the site (death can take 30 seconds to load) so making sure the cache is caught is important.

  • Deploying from Github via TravisCI

    Deploying from Github via TravisCI

    When you develop your code on Git, you can automagically (and easily) deploy to places all you want, if the repository is on the same server. If it's not, you can use something like Codeship to automate pushing for you.

    Free Services Have Limits

    Codeship, which I like a lot, has a limit of 100 pushes a month. In October, when Tracy and I finally deployed the newest version of our website, we actually hit that. In part, this is because we don't have a great 'test' environment where we can internally develop and share the results with the other. We both have our own versions of local environments, but you can't show your cohort 3000 miles away what you've done without pushing the code to the private development site and letting her see it.

    After 100 pushes, it's $490 a year for unlimited. While the product claims to be 'free forever' for open source, there's actually no documentation that I could find on how one gets added to that list, or what the qualifications are. Does my personal open source project  qualify? I'll have to email and find out.

    TravisCI Is ‘Free’

    All 'free' services have a paid component. Travis, like Codeship, is free for public, open source, projects. And like Codeship, it doesn't require you to host (and thus) update anything yourself. Which is nice. In fact, it only has a few pre-requsits:

    Sounds like a match made in heaven, except for the part about documentation on GitHub being out of date. I don't begrudge them, as keeping up docs is a pain and if it's with another service it's nigh impossible.

    Awesome. Sign up for Travis, activate your repositories, add a .travis.yml file with the programing language, and you're ready to do… what?

    Writing The Build Script

    This is the weird part. You have to invent a way to push the code. Unlike DeployHQ or Codeship, there's no place to type in the code on their servers. You have to make a file and write the script.

    The scripts look like this (cribbed from Florian Brinkkman):

    language: php
    
    addons:
      ssh_known_hosts:
      - $DEVELOPMENT_SERVER
      - $PRODUCTION_SERVER
    
    before_script:
      - echo -e "Host $DEVELOPMENT_SERVERntStrictHostKeyChecking non" >> ~/.ssh/config
      - echo -e "Host $PRODUCTION_SERVERntStrictHostKeyChecking non" >> ~/.ssh/config
    
    script:
      -
    before_deploy:
      - openssl aes-256-cbc -K $ENCRYPTED_KEY -iv $ENCRYPTED_IV -in deploy_rsa.enc -out /tmp/deploy_rsa -d
      - eval "$(ssh-agent -s)"
      - chmod 600 /tmp/deploy_rsa
      - ssh-add /tmp/deploy_rsa
    
    deploy:
      - provider: script
        skip_cleanup: true
        script: ssh -p22 $DEVELOPMENT_SERVER_USER@$DEVELOPMENT_SERVER "mkdir -p $DEVELOPMENT_PATH_STABLE" && ssh -p22 $DEVELOPMENT_SERVER_USER@$DEVELOPMENT_SERVER "mkdir -p $DEVELOPMENT_PATH_TRUNK" && rsync -rav -e ssh --exclude='.git/' --exclude=scripts/ --exclude='.travis.yml' --delete-excluded ./ $DEVELOPMENT_SERVER_USER@$DEVELOPMENT_SERVER:$DEVELOPMENT_PATH_TRUNK && rsync -rav -e ssh --exclude='.git/' --exclude=scripts/ --exclude='.travis.yml' --delete-excluded ./ $DEVELOPMENT_SERVER_USER@$DEVELOPMENT_SERVER:$DEVELOPMENT_PATH_STABLE
        on:
          branch: DEVELOPMENT
      - provider: script
        skip_cleanup: true
        script: ssh -p22 $PRODUCTION_SERVER_USER@$PRODUCTION_SERVER "mkdir -p $PRODUCTION_PATH_STABLE" && rsync -rav -e ssh --exclude='.git/' --exclude=scripts/ --exclude='.travis.yml' --delete-excluded ./  $PRODUCTION_SERVER_USER@$PRODUCTION_SERVER:$PRODUCTION_PATH_STABLE
        on:
          branch: master

    And to be honest, it's really not that explanatory. I read it a few times and sighed. While I'm (obviously) not opposed to learning new code to do things, I am opposed to all these services making it needlessly complicated.

    One Big Problem…

    You can't (easily) set up SSH keys on Travis for free. That's because they're restricted to the pro version. Now you totally can set it up, but it's incredibly insane and not something I was willing to do in the long term. And since the cost of TravisPro is $69 a month compared to Codeship's $49 or so a month, it was a no brainer.

    I emailed Codeship to ask if I qualified for 'open source.' Most likely they'll tell me no, because I deploy to a closed system, but it doesn't hurt to ask.

  • Indiegogo Embed

    Indiegogo Embed

    Indiegogo doesn't have oEmbed, which means you can't just paste in a URL and expect it to work on a WordPress site. And worse, their directions are "Use an iframe plugin!"

    NO.

    Just say NO to iframe plugins!

    Use a shortcode instead!

    If you're brand new to shortcodes, check out Sal Ferrarello's awesome post about it (I saw him talk at WC Philly 2017 and he's amazing). I'll give you the highlights for this one code though.

    The Code

    /*
     * Embed an IndieGoGo Campaign
     *
     * Usage: [indiegogo url="https://www.indiegogo.com/projects/riley-parra-season-2-lgbt"]
     *
     * Attributes:
     *		url: The URL of the project
     */
    add_shortcode( 'indigogo', 'helf_indiegogo' );
    function helf_indiegogo() {
    	$attr = shortcode_atts( array(
    		'url' => '',
    	), $atts );
    	
    	$url    = esc_url( $attr['url'] );
    	$url    = rtrim( $url, "#/");
    	$url    = str_replace( 'projects/', 'project/', $url );
    	$return =  '<iframe src="' . $url . '/embedded" width="222px" height="445px" frameborder="0" scrolling="no"></iframe>';
    
    	return $return;
    }
    

    What It Does

    The code is as basic as I could made it, and it takes the URL of the campaign, strips out the trailing hashtag, changes projects to project (singular – and yes, that gave me a headache), and punts out an iframe.

    Thankfully they make this easy unlike places like CrowdRise where you have to magically know the ID number in order to pull this off.

  • The Never-ending Progress Bar

    The Never-ending Progress Bar

    When you download a file from Safari, it shows you a progress bar for how it's going along. If you happen to download files to a folder in your dock, you'll see a line grow as it downloads, and then vanish.

    Except… sometimes it doesn't.

    A download bar that won't go away

    And then it gets worse if your bar changes size…

    A download bar that looks worse becuase it's not connected to the folder

    Well great. Now what?

    To the terminal!

    No really. It's one command:

    killall Dock

    That's it. It restarts the dock, the download bar goes away, and you can relax.