Half-Elf on Tech

Thoughts From a Professional Lesbian

Author: Ipstenu (Mika Epstein)

  • The Purpose of a Case Study

    The Purpose of a Case Study

    Back in early December I gave a talk at WordCamp US about a website I built with Tracy. The talk was titled “Lesbians, Damn Lesbians, and Statistics.” You can watch it here:

    Of all the talks I’ve given, I feel it was the least WordPressy of them all. That is, while I did talk about WordPress and why we made choices that we did, and how they relate to the data design, it wasn’t very code heavy. It was, instead, a case study in how and why and what.

    What

    A case study talk is complicated because you have to address what the topic is beyond WordPress. When you start with WordPress, and you’re at a WordPress convention, you don’t have to lay the groundwork. You can jump in and talk about custom post types and taxonomies. At a WordCamp, everyone knows about WordPress, or at least enough to skip over the basics.

    On the other hand, your case study starts by explaining what the reason was that you built the site in the first place. What’s the purpose of the site and what’s the relation to WordPress. You start with the narrative of “This is my story.” And you have to do it fast because next is the why!

    Why

    Once you have explained what the site is about, you have to explain why WordPress. When you’re doing a normal talk about WordPress things, you skip right over this. Everyone knows why WordPress. Because WordPress! But many times we ask ourselves “Is WordPress the best tool for this job?” We ask “Is it the right tool?” So in a case study, you have to build up your case and explain why.

    This is hard, because you already jumped through those hoops to explain to yourself (and any business partners you’re working with) the rationale. Distilling all of that into a third of your talk, which means maybe ten minutes, is not easy. You summarize, you skip over things, and you still have to hit the main points or people won’t be able to make the connections for the next section.

    How

    Finally you have to explain how you did this. If people don’t understand what you did and why, the how becomes meaningless. This is because the brunt of your talk takes place here. This is the real WordPressy stuff, where you talk about how the what and why came together to be this thing. If people can understand the enormity of the data, they can conceptualize your logic.

    If you’ve built everything up before, people will understand “Oh, she couldn’t make death a taxonomy because the overlap would cause problems and become unwieldy.” They’ll follow you when you explain about faceting searches and moving data.

    Because

    The purpose of all this is to draw people in with a cohesive story that puts the code and the concept together. People remember songs because of the rhythm and pattern. They will remember your case study because of the story. We remember stories.

    The purpose of your case study is to tell a good story that people remember and that connects them to your topic and your code.

  • A Difference of Tone

    A Difference of Tone

    The other day I lamented on Twitter that one day someone would ask me “Why did you use X?” and not “Why DIDN’T you use Y?” in a tech talk.

    Think Different

    When you go into a talk, thinking you know everything about it and what it means, you close your mind. You start by ignoring the possibility that other people can have amazing thoughts and ideas too. You limit yourself. Your preconceived notions color how you think because you limit your experiences to that which you have personally.

    This is much the same as why a number of people seem to lack empathy until they’re personally impacted. That’s why you hear men say things like “I didn’t become a feminist until I had a daughter.” A number of people nod and understand his meaning is that it wasn’t personal. But a number of people also wonder what the hell is wrong with someone not to care about humans in general. Doesn’t that man have a mother? A grandmother?

    Once you allow yourself to accept the simple idea that someone else thinks a different way from you, you open your mind to a new world.

    Hear Different

    There’s a difference between listening and hearing. We all listen. But once you start thinking about what your reply will be, and not listening to what’s behind what the other person said, you limit yourself. I see a lot of people sit in talks and you can tell when they tune out because they’ve decided “I want to know X.” and that will be their question. Instead of writing it down to ask, they block out everything. They concentrate on their reply.

    Notice how I said ‘reply’ and not ‘question’?

    Yeah. There’s a reason.

    Ask Different

    When you go up to ask someone a question based on their talk, you’re not playing Jeopardy. The game isn’t “Phrase my answer like it was a question.” The point is to to ask something to understand a little better how someone else reached a conclusion. It’s the fundamental difference between “Why didn’t you use the Post 2 Posts plugin?” and “What did you use to connect the posts to each other and why?” The first one makes your preference known. It makes an assumption that obviously everyone would use Posts 2 Posts. The second one asks to get into the mind of the speaker, to learn the way another mind works. It assumes the other person is different from you.

    When you ask what someone used, and why, you get an insight into their process, which may help you reflect on your own. You may find new answers, and all you have to do is remove your own ego from the question.

    Learn Different

    The point of this is not to make a speaker’s life easier, but to make yours better. If you change just two small things in how you ask questions, you’ll find you can learn a whole lot more.

    1. Write down the question you want to ask
    2. Ask it without assuming you know the best answer

    You may be surprised how the tone of the ask changes everything.

  • Mindful Development and Misunderstandings

    Mindful Development and Misunderstandings

    I consider myself a mindful developer. I strongly feel that morals and ethics and intent are important. In order to continue making the world better, we have to think about the worst thing our code might be used for and prepare for that. This means I spend a lot of time thinking about usage and intent.

    However, like anyone else, I have my blind spots. And it’s amusing to me that I stumbled right over one when it came to an automated submission check.

    Automation

    I made an Amazon Echo skill that tells you when the last queer female died on TV. In November, we noticed it had three negative reviews, all of which misunderstood the purpose of the application. They all thought we were pro-death. Now to me this meant the description of the skill and the output needed to be modified.

    No big deal, right? I’ll just go in and make an edit and I’ll be done.

    Wrong.

    Your skill contains content that violates our content guidelines. You can find our content guidelines here.

    Specifically, any promotion or praise of hate speech, inciting racial or gender hatred, or promotion of groups or organizations which support such beliefs, such as the Ku Klux Klan are not appropriate for the Alexa Skills catalog.

    My change was rejected because it was hate speech.

    No matter how I wrote the description, or phrased the commands, it was getting flagged as hate speech automatically. That’s right, automatically. There was no human to contact, in fact the email said I had to fill in a contact form and maybe I’d get an answer.

    Instead I went to my cohort in computing, who said she was certain it was the phrase “bury your queers.”

    Documentation

    I’ve had a lot of code reviews in my life. I’ve done a lot. There really two aspects of a review that help you survive it:

    1. A robust, if generic, explanation, with specifics outlined.
    2. Clear documentation to help resolve the specifics.

    Amazon doesn’t give either of those.

    There are no specifics that said, outright, “The problem is your content looks like your promoting the death of a specific type of people.” No matter how I tried to rewrite it, was rejected.

    Finally I realized I was going to have to write it all over again, from the ground up, and explain it all better.

    People over Process

    I get grief from plugin developers for being reluctant to specify what is bad and what is good. This probably stems from my upbringing, where I was taught about right and wrong as relative concepts. Is it alright to kill? No. But if the choice is killing a child or yourself, because your car brakes went out, you have to be able to weigh the situation at hand.

    Computers can’t do this. There is no artificial intelligence that can weigh the soul of a person and know if they’re going to do evil. If there was, the face of air travel and politics would be wildly different.

    And the point I make here is that we cannot simply say “this description hits all our buzz words and triggers for badness, therefor it is clearly a bad thing.” It’s just not the case. In restricting us from being able to speak about such horrible things, we give them room to grow in the darkness.

    But that is neither here nor there.

    A More Positive Message

    As Tracy put it, it was a damn good lesson in perspective.

    She didn’t say damn.

    While the “bury your gays” trope is well known to me, it is not universal. And while I feel queer is a perfectly acceptable term that has been in use for a very long time, others do not. People inside and outside our community are often unaware that one of the first pro-gay posters said “queer power” and not “gay power.” It’s just one of those things.

    So the right path is to go forward in a positive way. I’ve rewritten the code to give you more details than just who died. It will now tell you what was posted, how many characters were added, who’s on the air and who’s not.

    And yes, who died. Because that matters too.

  • Migrating from Post Meta to Custom Post Types

    Migrating from Post Meta to Custom Post Types

    There are, as it happens, a lot of ways to do this. This is a way that I tested and it works, but it’s not the final way I did things. That said, this does work and, if you’re not on a shared server, is just fine.

    The Concept

    I have (roughly) 2200 posts in a custom post type (post_type_characters). Each of those posts has a post meta field for actors (lezchars_actor). The content of the post meta is an array of text fields, that looks something like this:

    Array(
    [0] => "Caity Lotz",
    [1] => " Jacqueline MacInnes Wood (Arrow 1x01 only)"
)

    I wanted to take the post meta and split it into a post for each actor, however I wanted to remove any comments in parenthesis. I also wanted to change the content of lezchars_actor to be the IDs of the new actors pages.

    Did I mention I had 2200 posts? And some actors were there multiple times? And I didn’t want to make a lot of duplicate posts.

    The Code

    If you want to do this with PHP, it’ll look something like this:

    <?php
/*
Plugin Name: Post Bulk Update
Description: Change all the actors to Taxonomy
*/

add_action('wp','post_bulk_update_queers');

function post_bulk_update_queers(){
	$char_queery = new WP_Query( array(
		'post_type'              => 'post_type_characters',
		'posts_per_page'         => '3000',
	) );

	if ( $char_queery->have_posts() ) {
		while ( $char_queery->have_posts() ) {
			$char_queery->the_post();
			$the_ID = get_the_ID();

			// Get the post meta for actor:
			$postmeta_actors = get_post_meta( $the_ID, 'lezchars_actor', true );
			if ( !is_array ( $postmeta_actors ) ) {
				$postmeta_actors = array( get_post_meta( $the_ID, 'lezchars_actor', true ) );
			}
			
			if ( !empty( $postmeta_actors ) ) {

				$posts_actors = array();
				// Create posts if needed:
				foreach ( $postmeta_actors as $actor ) {
					// Make sure the ID isn't numeric as that means we did this...
					if ( !is_numeric( $actor ) ) {

						// Remove content in parens...
						$actor = preg_replace( '/\([^)]+\)/', '', $actor );

						$already_post = get_page_by_path( sanitize_title( $actor ), OBJECT, 'post_type_actors' );
						if ( !( $already_post ) ) {
							// Create post object
							$my_post_args = array(
								'post_title'    => wp_strip_all_tags( $actor ),
								'post_status'   => 'publish',
								'post_author'   => 1,
								'post_type'     => 'post_type_actors',
							);
	
							// Insert the post into the database
							$my_post = wp_insert_post( $my_post_args );
							
							// add post to array
							array_push( $posts_actors, $my_post );
						} else {
							array_push( $posts_actors, $already_post->ID );
						}
					}
				}
				
				// Change the post meta to be numbers
				update_post_meta( $the_ID, 'lezchars_actor', $posts_actors );
			}
		}
	}
}

    Notes

    The reason this really works is this:

    $already_post = get_page_by_path( sanitize_title( $actor ), OBJECT, 'post_type_actors' );

    That actually checks if the page with the slug already exists and if so, uses it to edit the post meta.

    If you don’t have robust hosting, or you have a lot of posts, you’ll need to edit the $char_queery like this:

    	$char_queery = new WP_Query( array(
		'post_type'              => 'post_type_characters',
		'posts_per_page'         => '300',
		'offset'                 => '0',
	) );

    Run it once, bump the offset from 0 to 300, and repeat until you get through all your posts.

  • Data Structure

    Data Structure

    At WordCamp US, Tracy turned to me and said “I want to do something about the actors on our site.”

    Her idea was that, based on the traffic on our sites, people wanted to know a little more about the actors. The way I’d built out the site, you could get a list of all of an actor’s characters, but you couldn’t really get at everything. Tracy explained to me what people were searching for (actors who were queer, or not) and I mulled over the possibilities, sketching out three solutions.

    1. Facet and Smart PHP

    We originally added in actors as a plain-text field, saved as an array, for all names associated with a character. In using this, with FacetWP, it was trivial to look for all characters played by Ali Liebert. We also already had in a repeatable field, so we could put the ‘most prominent’ actor on top (see “Sara Lance”).

    However what was not trivial was the idea of identifying if an actor was queer. You see some characters have multiple actors, and while today all are either queer or not, one day they may not be. I pointed this out to Tracy using the Sara Lance conundrum and Tracy cried ‘Whhhyyyyyyyy?’ and lay down on the floor.

    2. Taxonomies

    Characters already have a bunch of custom taxonomies, and I considered extending that to a new taxonomy for actors. That would immediately provide organizations, and adding new actors is easy on the fly. With auto-complete, we could get away from the drama of my inability to spell names (or autocorrect’s inability to believe me that in this case, I is before C).

    But… Taxonomies lack extendability. Even with a mess of custom meta added in for featured images, we wouldn’t have an ‘easy’ way to track all trans actors. And we wouldn’t have enough of a future.

    3. Custom Post Types

    This is what we actually decided to use. A custom page for each actor. We added in two new taxonomies for actor gender identity and sexual orientation, which are then used to determine if the actor is queer or not. It gives us the most control and extendability of the choices, and the nice permalink.

    There are two significant downsides to this. First, you have to add in a page for the actor before you add in the character page. Second, I had to ‘reproduce’ a loop to list all the characters played by an actor. However I was reusing the same logic as I do for shows which made it easier than it might have been.

    What It Means

    Understanding and predicting an unknown future is hard. It’s near impossible. You have to guess what you want things to be, and as I have said many times with the building out of LezWatchTV, you must be alright with being wrong.

  • Zap a Daily Tweet

    Zap a Daily Tweet

    Last week I told you how I made a random post of a day. Well, now I want to Tweet that post once a day.

    Now there are a lot (a lot) of possibilities to handle something like that in WordPress, and a lot of plugins that purport to Tweet old posts. The problem with all of them was that they used WordPress.

    There's nothing wrong with WordPress

    Obviously. But at the same time, asking WP to do 'things' that aren't it's business, like Tweeting random posts, is not a great idea. WordPress is the right tool for some jobs, but not all jobs, after all.

    What is WordPress' job is generating a random post and setting a tracker (transient) to store for a day. And it's also WordPress' job to output that data how I want in a JSON format.

    The rest, we turn to a service. Zapier.

    A Service?

    Like many WordPressers, I like to roll my own whenever humanly possible. In this case, I could have added an OAuth library and scripted a cron job, but that puts a maintenance burden on me and could slow my site down. Since I have the JSON call, all I need is 'something' to do the following:

    1. Every day, at a specific time, do things
    2. Visit a specific URL and parse the JSON data
    3. Craft a Tweet based on the data in 2

    I dithered and kvetched for days (Monday and Tuesday) before complaining to Otto on Tuesday night. He pointed out he'd written those scripts. On Wednesday, he and I bandied about ideas, and he said I should use IFTTT. Even using IFTTT's Maker code, though, the real tool needed is one that lets me code logically.

    Zapier

    The concept of IFTTT is just "If This, Then That." If one thing is true, then do another. It's very simple logic. Too simple. Because what I needed was "If this, then do that, and tell another that." There wasn't an easy way I could find to do it with IFTTT so I went to the more complicated.

    Example of what the flow looks like - Trigger is every day, action is GET, final action is tweet

    Three steps. Looks like my little three item'd list, doesn't it?

    The first step is obvious. Set a specific time to run the zap. It's a schedule. The second step is just a web hook saying 'Get the data from URL.' And the third step is aware!

    Showing the example of the tweet, with placeholders for the name and URL

    Pretty nice. If you click on the 'add field' box in the message content (upper right), it knows how to grab the variables from the previous steps and insert them. Which is damn cool.