Half-Elf on Tech

Thoughts From a Professional Lesbian

Category: How It Is

Making philosophy about the why behind technical things.

  • Do Robots Dream of Electric Smut?

    Do Robots Dream of Electric Smut?

    In July of 2018, I was informed by Google Adsense that specific content on my site was going to have “restricted ad serving” and I needed to go to the policy centre on Adsense to find out why. There was no link to this centre, by the way, and it took me a while to figure out I went to Adsense > Settings > Policy where I saw this:

    The screen telling me I have adult content on a URL.

    Yes, that image says that the post about Legitimate Porn Plugins was deemed to be sexual content. My guess is that they don’t like the image, because my post about how GPL says Porn is Okay did not get flagged.

    My friend pointed out that it was ridiculously damaging to moderate content (or at least in this case, revenue) by “casting a wide net based solely on the presence of key words” and she’s quite right. Now I did attempt to get Google to reconsider, but like my past experiences with their censorship and draconian view, they don’t give a damn if you aren’t ‘big.’ And even then, important people get slapped by Google all the time.

    History? What History?

    In 1964, there was a landmark case in the US, Jacobellis vs Ohio, about whether the state of Ohio could, consistent with the First Amendment, ban the showing of the Louis Malle film The Lovers (Les Amants), which the state had deemed obscene. During that case, and the reason it became so well known, was not the content matter.

    In fact, the decision remained quite fragmented until 1973 Miller v. California decision in which it was declared that to be smut (i.e. obscene) it must be utterly without redeeming social importance. The SLAPS test addresses this with a check for “serious literary, artistic, political, or scientific value” – and yes, the acronym is hilarious.

    No, everyone knows about the first case because of the following quote by Justice Potter Stewart:

    I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it, and the motion picture involved in this case is not that.

    Tea, Earl Grey, Hot

    When I was very young, maybe six, my father did a talk about artificial intelligence with a slide of Captain Kirk ordering things from the ship’s computer. It stuck with me, which Dad finds amusing, and I’ve often reflected back on it as an understanding of what an AI can and cannot do.

    The ship’s computer on Star Trek can do a great many things, but it cannot make ‘decisions’ for a person. In the end, a human always has to decide what to do with the variables, what they mean, and how they should be used. Kirk has to ask the computer to chill the wine, for example, and if he doesn’t specify a temperature, the computer will go back to what some other human (or more likely Mr. Spock) has determined is the optimal temperature.

    AIs don’t exist. Even as useful as I find digital assistants like Siri and Alexa, I know they aren’t intelligent and they cannot make decisions. They can follow complex if/then/else patterns, but they lack the ability to make innovation. What happens if Kirk just asks for ‘white wine, chilled’? What vintage will he receive? What temperature?

    To a degree, this is addressed with how Captain Picard orders his tea. “Tea, Earl Grey, hot.” But someone had to teach the system what ‘hot’ meant and what it meant to Jean-Luc and not Riker, who probably never drank any tea. Still, Picard has learned to specify that he wants Earl Grey tea, and he wants it hot. There’s probably some poor tech boffin in the belly of Starfleet who had to enter the optimum temperatures for each type of tea. Certainly my electric kettle has a button for ‘black tea’ but it also tells me that’s 174 degrees Fahrenheit.

    Automation Limitations

    My end result with Google was that I had to set up that specific page to not show ads. Ever. Because Google refused to get a human to take a look and go “Oh, its the image, remove that and you’re fine.” But even then a human could look at the image, recognize it’s not pornography, and flag it as clean.

    What we have is a limitation in the system, where in there is no human checking, which results in me getting annoyed, and Google being a monolithic annoyance. Basically, Google has automated the system to their specifications, and then instead of putting humans on the front lines to validate, they let it go.

    This makes sense from a business perspective, if you’re as big as Google at least. It costs less. But we’ve all read stories about people getting locked out of their Google accounts, for a month or more, and facing drama because there’s no way to get in touch with a human being.

    The Heart of It All is Humans

    And that’s really the heart of the problem.

    Have you ever visited a forum or a chat site and it’s full of people acting like decent people to each other? Humans did that. A human sat down, purged the site of the vile content, and had to sit and read it to be sure. They pushed back on trolls and other problematic people, all to help you.

    Don’t believe me? Okay, do you remember the WordPress plugin WangGuard by José Conti? He shut the service down in 2017 because it was giving him a mental break down. The plugin worked so well because he, a human being, evaluated content.

    WangGuard worked in two different ways, one an algorithm that had been perfecting for 7 years, and that was perfecting as the sploggers evolved, so it was always ahead of them. And a second part that was human, in which I reviewed many things, and among them sploggers websites to see their content, improve the algorithm and make sure that it worked correctly both when a site was blocked and not it was. The great secret of WangGuard, was this second part, without this second part, WangGuard would not have become what it was.

    José Conti – The True Reason for the Closure of WangGuard

    Basically, Conti gave himself PTSD trying to make the internet a better place.

    Because the absolute only way to make sure something was evil was to look at it. And the only way to make sure something is porn is to look at it.

    An AI can’t do that yet.

  • You’ll Probably be Fine with Gutenberg

    You’ll Probably be Fine with Gutenberg

    With WordPress 5.0 getting closer and closer, I know a lot of people are worried about Gutenberg and what that will mean for their themes and plugins.

    Most Themes Will Be Fine

    The majority of themes, every single one you can download from WordPress.org, and the ones from reputable theme shops like StudioPress, will be just fine. Nothing will break, and other than getting a new editor experience, there’s no change.

    What will happen, and yes people will call this breaking, is that not all features will be supported. 

    Right now, most themes don’t support some of the more outré block types. And a lot of themes don’t support text columns like this:

    And then again, Genesis? Does!

    This is a left column

    This is a right column

    And every theme is going to support repeatable blocks which means you’ll be able to build out some nice defaults and standards.

    The reason for all this is that if you’re just using Gutenberg as an editor, not a whole lot has changed with your content. It remains the same as it ever was, just with a fresh coat of paint.

    There are exceptions, like themes that rely heavily on features that alter the post editor. I’ll get there in a minute.

    Most Plugins Will be Fine, Too

    Here again, unless your plugin interest with the post editor, you are going to be just fine. You use Jetpack to publicize your posts? Cool. No change. AMP? No change.  Go look at most of your plugins. Caching? No changes. Google Analytics? No change.

    The reason here is, again, most plugins don’t mess with post editing. I should know. I review them.

    I know what you’re thinking, though. What about plugins like Yoast SEO, which add in a bunch of extra boxes at the bottom and sides of a post? The boxes are called Meta Boxes, and they’re already supported. Plus Yoast went to the extra effort of being on the forefront of Gutenberging.

    The colours to indicate how good your post’s SEO is, however, are missing right now. So is the field to customize your Jetpack publicize content. Basically everything that went on that sidebar on the post edit screen (the Publish Box) isn’t done yet.

    Which brings me to…

    The Exceptions Will Hurt

    Okay.  I won’t sugar coat this. If you use a complex post editor, like Visual Composer or Bold Grid, or if you use a plugin with a lot of custom meta boxes, the world will be very different, and probably unhappy.

    Now that said, Visual Composer will work with Gutenberg! And so will ACF and CMB2 is well on it’s way. But. The problem is people who have bundled those plugins in their themes. And those themes will have to update their packages and make sure users update.

    Anyone who just had a mental image of how many premium themes bundle Visual Composer and tried to calculate the number of users who don’t properly update themes regularly… welcome to my world. I’d like to say I’m ‘against’ the bundle, but the reality is that I’m against premium products using libraries and then not managing those libraries properly. Not that it’s easy, and that’s a different topic.

    The problem in the exception is that there will be a non-insignificant number of people who have no idea they’re using a problematic library that needs an update.

    Where Do We Go From Here?

    This problem is WordPress’ own doing, make no mistake. If the ability to add custom meta boxes and settings and the like was less complicated to begin with, we wouldn’t have needed tools like these to work around it. We still have no decent meta box API, and the settings API is something I regularly call “as intelligent as a bag of wet hair.”

    But. Innovation is necessary. We can’t just not move forward because we didn’t do things right the first time. And in WordPress’ defence, there was no way to know or even write the ‘right’ way back 15 years ago when all this started. The best tools didn’t exist. And all those ways we built to hack around the problem made it more clear what the right way needed to be.

    Which brings us here.

    Most of what you do won’t be impacted by Gutenberg. What is adversely impacted won’t break most things, but it will be really annoying. And then those rare edge case exceptions? Well. We’re back to the words (paraphrased) of Hecht.

    When infrequently used systems break, they do so in big ways.

  • Hashtag your Jetpack with Taxonomies

    Hashtag your Jetpack with Taxonomies

    So maybe you read my post about hash tagging Jetpack Publisher posts with a complex check of “Is this tag also a custom post type?” and you thought “Mika, that’s awesome. But I don’t have a database of shows!”

    To my reporter friend who lamented this to me, I have a solution.

    The Real Problem

    I think most of the problem with Jetpack’s custom Publicize message is that it’s (rightly) hidden by default. Most people don’t need it. But those that do want to see it so we remember “and do this…”

    Publicize Settings on your post sidebar

    And let’s be honest, this visibility issue is going to be worse when we move to Gutenberg.

    Again, I don’t think Jetpack is in the wrong here. The majority of users don’t need to be so aggro about their messages. There are a lot of WordPress sites that we would classify as ‘smaller’ sites. And those who aren’t tend to need very bespoke/custom solutions, which is the problem.

    My solution works for me because it’s easily automated and checkable. We’re very pedantic about tags (seriously, Tracy went through all our tags and cleaned them up), we have a great system to match tag to show, and, most significantly, we know that our social media engagement relies on not just content, but the appropriate hashtags. That is, the shows we’re talking about.

    This means there are two types of ways to do this:

    1) Make all your tags (and/or categories) into your hashtags
    2) Make a custom taxonomy for your hashtags

    Since using all the tags might be a bit much, I went with option 2.

    The Code

    <?php
/*
 * Jetpack tweaks
 * @version 1.0
 * @package mu-plugins
 */

class HalfElf_Jetpack {

	public function __construct() {
		add_action( 'publish_post', array( $this, 'custom_message_save' ) );
		add_action( 'init', array( $this, 'register_taxonomy_hashtag' ) );
	}

	public function register_taxonomy_hashtag() {

		//parameters for the new taxonomy
		$arguments = array(
			'label'                 => 'Hashtags',
			'hierarchical'          => false,
			'public'                => false,
			'show_ui'               => true,
			'update_count_callback' => '_update_post_term_count',
			'rewrite'               => false,
		);

		register_taxonomy( 'flf_hashtags', 'post', $arguments );
	}

	public function publicize_hashtags() {
		$post      = get_post();
		$hash_tags = '';

		// If the post isn't empty AND it's a post (not a page etc), let's go!
		if ( ! empty( $post ) && 'post' === get_post_type( $post->ID ) ) {

			update_post_meta( $post->ID, '_wpas_mess', 'test' );

			// First let's add the hashtags
			$post_tags = get_the_terms( $post->ID, 'flf_hashtags' );
			if ( ! empty( $post_tags ) ) {
				// Create list of tags with hashtags in front of them
				foreach ( $post_tags as $tag ) {
					// Change tag from this-name to thisname and slap a hashtag on it.
					$tag_name   = str_replace( '-', '', $tag->slug );
					$hash_tags .= ' #' . $tag_name;
				}
			}

			// Next we add a category in specific situations.
			$post_cats = get_the_category( $post->ID );
			if ( ! empty( $post_cats ) ) {
				// Create list of tags with hashtags in front of them
				foreach ( $post_cats as $cat ) {
					if ( 'MAINCAT' === $cat->slug ) {
						// Change slug from this-name to thisname and slap a hashtag on it.
						$cat_name   = str_replace( '-', '', $cat->slug );
						$hash_tags .= ' #' . $cat_name;
					}
				}
			}
		}

		// Loop back. If there are hashtags, we add them.
		if ( '' !== $hash_tags ) {
			// Create our custom message
			$custom_message = 'New post! ' . get_the_title() . $hash_tags;
			update_post_meta( $post->ID, '_wpas_mess', $custom_message );
		}
	}

	// Save that message
	public function custom_message_save() {
		add_action( 'save_post', array( $this, 'publicize_hashtags' ) );
	}

}

new HalfElf_Jetpack();

    A Little Explanation

    You may notice I added in a bit that looks for a specific category:

    if ( 'MAINCAT' === $cat->slug ) { ... }

    The reason here is that on the specific site I wrote this for, they have four (yes four!) categories:

    1) Announcements
    2) News
    3) Fandom (actually named FOR the fandom)
    4) Miscellaneous

    They wanted item #3 to be a tag, so it would always #JanelleMonae (for example). For them I did a super basic ‘if the fandom, then the hashtag’ but a slightly more common situation would be someone having a category for ‘Fandoms’ and then subcategories our fandom. For that you’ll want something like this:

    foreach ( $post_cats as $cat ) {
	$cat_mom = $cat->category_parent;
	if( $cat_mom > 0 && 'fandoms' === $cat_mom->slug ) {
		// Change slug from this-name to thisname and slap a hashtag on it.
		$cat_name   = str_replace( '-', '', $cat->slug );
		$hash_tags .= ' #' . $cat_name;
	}
}

    Enjoy your hash tagging!

  • Conceptualizing Privacy

    Conceptualizing Privacy

    I know a wonderful human named Heather Burns who cares about privacy and GDPR and has made me quite passionate about understanding what the heck I’m talking about. She’s infectious, smart, and well worded. When she talks I listen.

    Earlier this year, she posted her slides from a speaking event, PHP Yorkshire. One of them resonated with me to the point that I keep thinking about it:

    US vs UK/Europe concept of Privacy
    Source: Heather Burns’ PHP Yorkshire Slides

    I sat and read it a few times, and I realized that I absolutely 100% agree with all of the UK/Europe concepts and only one of the US’s. I won’t touch on all of them, but here are the ones I spend a lot of time pondering.

    Ownership vs Freedom

    In the US, there’s a massive misconception that you have a right to say what you want about what you want without consequences. This is absolutely not true. Freedom of speech, in the United states, does not exculpate me from what happens to me after I say a thing. But we have a big bugaboo here about how our freedoms are fundamental rights. So even though the first few Amendments to the Constitution are quite clearly about their direct applications to ‘against the government’ and ‘in a militia,’ people take them, twist them, and make them apply to everything else.

    This runs into an issue with GDPR and people in the UK and Europe, where the law is that you own your own data. You have a right to it, and to what’s said about you. Yeah hang on there. Folks in the US have a right to say what we want. Folks in the UK/Europe have a right to make us shut up.

    That’s working out about as well as you’d think, mostly because we disagree about this other thing…

    Data Ownership

    Really, it should be pretty simple for the freedom of speech to coexist with the right to be private. If I post lies about you, you are legally within your rights in the US to demand I take them down. If I post information about you that wasn’t public, like I know you like burn Beanie Babies (those are stuffed animals, folks), then in the US you’re kind of out of luck unless you can prove it caused you ‘harm.’ Across the pond? I have to delete it.

    And right there, I agree with the Europeans. If I take privileged information and make it public, I’m a horrible human first of all. I’ve betrayed your trust, and I’ve probably done it for financial gain. On the other hand, if I take public information (like a photo of you from the Associated Press of you burning a Beanie Baby in Central Park) and share it, I’m still a pretty horrible human, but not in the same way.

    As a human, I think I should have the right to own my own data. But this comes with a measure of responsibility. In other words, I’m responsible for what I put out there. If I make it public that I’m a lesbian (which I did), am I legally allowed to demand you remove all references to me being one on your site? In other words, do I get take-backs if I make things public?

    Maybe, but over yonder, I should at least ask first!

    Cooperation Before Court

    There’s a concept called “Assume good faith” and it’s one of Wikipedia’s fundamental principles. It’s related to the concept that we should never attribute to malice that which can be ascribed to ignorance. Generally this comes up when I talk to people about copyright or trademark violations. I never assume people meant to violate those things, just that they were unaware of things.

    The idea that someone has to ask me to remove a thing before suing me would be a lovely thing. The closest I can think of in the US is the way DMCA requests are handled. That is, I can issue a counter notice and either state “Hey, removed it!” argue back that it’s fair use. But that isn’t the same as the idea that we should talk before we go to lawyers. And that’s, you know, respectful.

    I spend a lot of time thinking about this based on two other sites I run, where there is personal information of other people. It’s all public-personal information, but in general if someone asks me to remove data, I’ve complied. There was one instance where I didn’t, and I explained why not and the other person agreed it was a fair representation of the situation.

    What Happens Now?

    Well. A lot of confusion and arguments about who has the right to what and where and when.

    There’s going to be a lot of change in your future.

  • How Many Plugins Is Too Many To Create?

    How Many Plugins Is Too Many To Create?

    That wasn’t the way you expected that title to end, I bet. You were thinking “How many plugins is too many to have on my site” and that’s absolutely not the topic here. No, instead I’m asking how many plugins is too many for a developer to create?

    I Got 99 Problems …

    I think that plugins should be specific. That is, I’m not a fan of a conglomerate of plugins like Jetpack, that do a little of everything. Instead, I like a plugin that does the thing it’s supposed to do, preferably simply and well, and it moves on. That means I often have 20-30 plugins installed on a site, and that’s okay.

    At the same time, as a developer, having to support 20-30 plugins is a drain on my limited resources. Becuase here’s what I have to do:

    1. Keep up with all core changes
    2. Include and test all library updates
    3. Test with every release
    4. Update my readme
    5. Review reviews and support posts to make sure I’m not missing things

    Multiply that by 20 and it’s a lot of work. And is that work I feel like I must do?

    Gimmie One Reason …

    The reality of having plugins for WordPress, or any add on for any project, is that it’s generally thankless work and you will have more bad days than good. That’s true of many things in life, and as depressing as it can be, it’s important to keep an eye on the reality of the situation. 

    Developing software is very analytical art. You create something out of nothing, you design and test and change and tweak, and then present it to the world. Of course those days when people tell you “I don’t like the color” suck, but being humans, we discard that and grab on to the days when someone says “I love the carrot!”

    And the reality of the question at hand isn’t how many is too many, but how many are worth the work and the little reward?

    Bring it Together …

    Lately I’ve been advocating something different. Instead of making 13 separate types of gallery plugins, I’ve suggested people make one plugin for galleries and include those 13 types as display options. The amount of work is roughly the same, but it means I only have one plugin to manage instead of 13 separate readme files to edit and installs to spin up. I also have one place to look for any support posts or reviews.

    Obviously this doesn’t always work. Sometimes you have to split things up. There’s little point it combining a WooCommerce plugin with a NextGen Gallery one (unless the plugin is implementing NextGen with Woo products…). But if you can connect your projects by type, you may find out that there’s crossover. Instead of spreading your user base out over 10 plugins, you can keep them manageable with 5 to 8.

    Working For The Man …

    And what about Jetpack? It’s effectively XX separate types of plugins:

    • Writing
    • Sharing
    • Discussion
    • Traffic
    • Security

    Except when you look at that, it suddenly all connects. When I write I want to share and I want people to discuss. I also want to keep an eye on my traffic and being secure…. Okay that last one might be better off on it’s own, but it’s a suite of related apps. 43 separate apps, but they are all related when you get down to it.

    Which means even if you’re making a plugin for your company, you can probably combine it with other things safely. And that means less access and security concerns for you too, as you only have to keep track of who has access to one plugin instead of 50.

    How Many Is Too Many?

    This is as subjective as all get out, but I’ll say this. Once you personally support 20 plugins for WordPress, take a good hard look at how much time you’re spending and ask yourself… is it worth it?

    It’s okay to say no.

  • Future Proof Names

    Future Proof Names

    The other day I was talking to someone about the name of their plugin.

    No, not about copyright and infringement, though that comes up a lot. I was talking to them about the meaning of the plugin name. They wanted to pick a name that was memorable, meaningful, and descriptive. I wanted them to drop the last one. Or rather, to reconsider the last one.

    Names Aren’t Descriptions

    My name, Mika, is not a description, it’s an identifier. Even my handle, Ipstenu, is an identifier. My domain ‘HalfElf.org’ actually is a bit of a descriptor, but it’s also an identifier. I am a Half Elf Rogue to many people, and that’s as it should be. But a descriptor is “Professional Lesbian” not “Half Elf on Tech” and yes, this matters.

    A good name is memorable (check), meaningful (check), and descriptive without being a description. Because a name is how we identify and remember the weird tech site we went to, versus the tools we use.

    In so far as plugins go, however, you have one more thing to think about, and that’s the plugin slug. The slug is like this post’s URL. Changing it comes at a cost and in the case of plugins, it’s impossible. So while I’m content to allow people to pick some silly names, I’m pretty sticky about the plugin url.

    Woo(Commerce) There It Is

    Whenever people submit plugins named “WooCommerce Thingy” they find their slugs changed to woo-thingy instead of the expected woocommerce-thingy because, well, they’re not WooCommerce. This sometimes incurs their ire, generally because they didn’t read the FAQ, and I’ve become resigned to linking them back to it. Most of the time, people just go “Oh, okay I get it.” and move on. Sometimes when the slug is less easy to ‘correct’ for them, like if they call a plugin “Google Fast Typing” (slug google-fast-typing) I have to email them and sort out a new name (probably “Fast Typing for Google” unless “Fast Typing” is trademarked by the Googs).

    Like I mentioned before, I don’t really push too much about a display name. You can change it as many times as you want, and coming back in a month to remind you “Hey, if you’re not Google, you shouldn’t start your plugin display name with ‘Google.’ They may get snarky at you.”

    But the display name is also very much abused. People use it as an extra ‘short’ description, which really only goes to annoy people who see “Luxembourg – A new plugin that will solve all your woes!” as a plugin name. Thanks. But that’s what the description is for.

    Gutenbye-bye-bye

    Gutenberg is a very popular plugin to make an add-on for these days. And a lot of people want to name their plugins things like “Joe’s Author Blocks for Gutenberg” which nets them the slug joes-author-blocks-for-gutenberg and I don’t know about you, but I find that excessive.

    See, you don’t want to have “Gutenberg” in your plugin slug at all. Unlike WooCommerce (or Google, or Facebook), we know Gutenberg is going to go away. Remember, the goal of Gutenberg is to be in WordPress 5.0!

    So that means naming your plugin author-blocks-for-gutenberg is shortsighted. In another four years, will anyone remember Gutenberg was the project name? Quick way to check, ask people at a local meetup “What’s MP6?” and see who knows.

    Name Better

    Think about the future of your plugin, the project, and the related items. Locking yourself into a name you regret later is one thing, but since a display name can be anything, you can name your plugin anything! Making a feature rich Gutenberg add on? Manutius is a great name! Changing the look entirely? Call it Reformation. Making a simple author block editor? halfelf-author-blocks is an okay slug, but “Block Your Authors” sounds pretty bad.

    Just remember, it’s eye before flea, except after sea.

    Someone carving hieroglyphics, when someone reminds him "It's eye before flea, except after sea."