Half-Elf on Tech

Thoughts From a Professional Lesbian

Category: How It Is

Making philosophy about the why behind technical things.

  • Thimking About Security

    Thimking About Security

    It's been a while since I last talked about security and WordPress plugins, so I thought it was a good time to do it again.

    I still don't use any. But we'll get to that in a minute.

    Don’t Be ‘Stupid’

    My mother is one of the few people I know who has almost completely conquered the will to be stupid.

    Miles Vorkosigan on his mother, Cordelia Naismith Vorkosigan
    Brothers in Arms by Lois McMaster Bujold

    Understanding what makes something secure or insecure is not as obvious as I wish it was. I often say that the trick to being secure is not being stupid. Of course that's easier said than done, and I know it.

    Still, my record holds true that the one time I was hacked, it was from my own stupidity. I knew it was wrong and foolish and I did it anyway. And my guiding principal of security remains a constant reminder "Don't be stupid."

    But what is stupid? Every time you leave your house, you lock your doors, right? You do the idiot walk, as my grandmother Taffy called it. Keys, wallet, phone? Is the gas off? Is the heat on? Are the windows closed? You check the normal things and then you lock the door and off you go.

    Of course, we all have been an hour into an 8 hour drive and panicked "Did I close the garage!?" And for some people, even the simple act of locking the door is an arduous journey of 10 or 30 or 55 checks. In order to say 'don't be stupid' we have take ourselves honestly and seriously, and remember that 'stupid' just means 'don't not think.'

    THIMK

    That was not a typo. Nor was the title of this post.

    While we all make fun of IBM and MAD Magazine, I recall reading "Welcome to the Monkey House" by Kurt Vonnegut, and Ma Kennedy had the sign over her desk. At the time, I was unaware of the MAD magazine spoof on the matter. THINK was a sign folks at IBM had, and THIMK was the spoof.

    When I read it in Vonnegut, and bear in mind I was young and naive, I found it far more compelling than the idea of telling someone to THINK. With the letter changed, it forced me to reassess my assumptions of what the meaning was. After all, telling someone to THINK means, well, think. But telling someone to THIMK is a different matter.

    Eating the Elephant

    You know that old joke? How do you eat an elephant? One bite at a time. Well. That's security.

    I've been a loud opponent of the TSA, the way it's implemented in the US currently. It makes us feel better by making us think (N) that something is being done. And, yes, the TSA has found problems. But their job is to look through a thousand small things and find the odd-one-out. They're looking for the weird.

    When we perform a security audit over anything, be it a plugin or a server, or a door, we look for what we know is likely wrong. When I review a plugin, I look for the common issues. I skim for them, or grep for them, because I know what I'm looking for, and my eyes are trained to find it.

    But then, once I see the major and common issues aren't there, I read the whole thing. I look at the plugin as a whole entity, and I think. What does the code mean? What is it's intent?

    Metaphysical Security

    Without the ability to spy into the soul of the developer and glean an understanding of their raisons d'être, we're left with monitoring actions and making best guesses. And we're going to be wrong from time to time.

    It's no secret that last year, the WordPress security world found a new villain in the despicable people who buy plugins and slip backdoors into them. I saw some complaints that this sort of vulnerability wouldn't exist in [insert your CMS here], except … it will. It can and it will.

    We are all vulnerable because we choose to trust. We trust the developer to have good intentions. We trust the reviewers to be good people and care more about the security and sanity of code than themselves (which is a whole different ball of fish). We trust the ongoing development not to be handed over to evil people.

    That last one is unavoidable. People trust me to review code and react in the 'best' way for the community. But what if someone found my asking price and bribed me? What if I let bad code like backdoors into the WordPress Plugin directory? It would probably get caught, eventually, but still. Even if we locked down plugins to specific users accounts and didn't let anyone but admins (like me and Otto) add users, we would still at the end of the day remain vulnerable to humanity.

    Security Is Ongoing

    The truth is this.

    We are always, every day, insecure and vulnerable.

    Having a website that is your 'life' or career or business or even just a passion-project is dangerous.

    You should treat your website with as much thought and security as you do your own home. Check the gas. Check the lights. Make sure the door is locked. Get a security system. Hire someone to review the site and the server. But take it seriously. 

    Your website is 'you' on the Internet. And it deserves as much care as locking your car and not parking it in a shady part of time.

    Summary?

    Pay attention to what you put on your website.

    Trust no one. Not even me.

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

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

  • Data Based Sites

    Data Based Sites

    Designing your website involves understanding the structure of the data within. Designing your data comes down to how you store it. At its base level, everything on your site is a post, but the way you handle the data WITHIN the posts is how you can plan for growth, adaption, adoption, and the future. Building a site today involves making sure the data is easily consumable by multiple formats, like AMP, JSON APIs, and Alexa Echo Skills. And it all starts with understanding the data you’re using. Even if that data is from TV.

    Television is chewing gum for the eyes

    I love television. I love books, I’m always reading and writing, and I love radio. I like movies. But TV is something weird and wonderful. TV is escapism when a story brings you someplace new and amazing.

    One of the reason I love tv is that I see myself reflected in media. I’m a Jewish lesbian. Growing up, I didn’t see a lot of me on TV. Any, really. If I think about it, the first Jewish Lesbian I can remember seeing is Willow Rosenberg from Buffy. Yeah. I was out of college by then.

    Representation Matters

    In the entirety of television, world wide, there are about 2000 queer females. Total. Yeah. 2000. That’s on about 600 shows. There are not a lot of them, and I know the numbers because I run, with Phillys very own Tracy, a site that uses WordPress to record all of them. That’s right, I have the data.

    Data Driven Design

    This isn’t about themes. I can’t design themes. I don’t. I’m bad at it, I know that, sorry Tracy. And when we set about making this site, we had some lofty goals and ideas and we learned some lessons by prejudging the data. Originally we wanted to simply list shows and if you should watch them or not, and list the characters but…

    Somewhere around 100 characters and fifty shows, it became clear that the datasets we’d defined were underestimated and over-complicated and over-simplified. We had to consider what made a show good or bad. We had to consider the situation. And we had to make changes.

    When you build out any site, you have an idea of what you want. Maybe like us you make a massive list of everything you want to track and get dragged down into the weeds fast. Maybe you make a small list and have to go back and edit. In the end, the trick of it all is planning your site based on your data.

    Even after you do all that planning, you’re going to find out you missed things. You’ll overestimate things. You’re going to underestimate others. People are going to use your data in unpredictable ways. This is just how the world works. So you have to design your code to adapt.

    How to Design for Data

    This is about planning code. Designing your site for data comes down to how you store it. At its base level, everything on our site is a post. There are two types, shows and characters, and all posts have a bevy of ‘meta’ data for the various bits of information.

    What information?

    Shows: tropes, airdates, thumb score, why that score, tv stations, nations, genres, formats, gold star, trigger warnings, quality rating, screentime rating, realness rating, timeline, episodes, & ‘ships.

    Characters: clichés, actor, sexuality, gender, date of death, tv show & role on show.

    So all that is what we record. It’s grown and shrunk. We had urls in there and removed them because it was impossible to upkeep when fansites vanish. I removed and restored ‘ships, after figuring out how to store all of it in a searchable way. But with all that data, we started to see the big picture. And then … we realized how the data was stored mattered.

    Understand What Your Data Is (And Isn’t)

    Most of the data is simple. Ratings are a 1-5 option. Trigger warnings were check boxes for a binary on or off … Were. Sexuality and gender are dropdown lists, and so are tropes and cliches. Managing those is easy. Ish. We understand taxonomies, at least, being WordPess developers.

    Most of the time, data is obvious. Again, I have items that are a binary. A yes or a no. And while I personally believe that sexuality and gender are a spectrum, TV hasn’t caught up there, so that can be stored as a one to one dropdown. You are what you are. The same goes for a character being on a TV show. It’s all one or the other.

    Having said all that, let me introduce you to Sara Lance, as played by Caity Lotz. Schrödinger’s bisexual time traveling action hero.

    The Complex Data: Sara Lance

    Schrödinger’s bisexual time traveling action hero assassin pirate captain.

    Sara Lance has two actors. She’s been on three shows in three separate capacities; guest, recurring, and regular. She’s died and came back to life. Sara Lance exists to make me, as a developer, cry. Because for her I have to store all of that data in a searchable manner that plain-text post meta doesn’t make easy. She made me rethink all our data storage.

    Nothing about Sara is simple. Nothing is straightforward. Not even the existing taxonomies and lists stayed the same. Both gender and Sexuality went from a simple dropdown to a taxonomy. We moved from gay, straight, or bi, to include pansexual and asexual and I’m just waiting for Sara to step into pansexuality, y’all.

    Use WordPress First

    As much as possible, use WordPress. Taxonomies are heavily used for ‘lists’ like cliches and tropes and tv stations, because they come with built in sortables. I can easily list all shows on NBC or all characters who are parents, because those are taxonomies. Even short lists like sexuality and gender work well for that. For the rest, it’s all post meta.

    Sara exists beyond taxonomies. Originally, we had death stored as a simple taxonomy item for character cliches. If you were dead, you got the cliche of dead. Sara came along and died. And came back. So suddenly we had to rethink if someone kept the tags if they died and came back. Pro tip? They don’t. That was a quick decision, though. Don’t worry, she made us make harder decisions.

    Use Plugins Second

    I mentioned everything that isn’t a taxonomy is post meta. Adding metadata to posts that aren’t taxonomies sucks. Yes, I said it. It sucks. Plugins like CMB2 or ACF will save your vegan bacon by making it easier to create a check box or a dropdown or a plain text field, like for actors.

    Sara had two actors. While the field for actor is only plain text, and that’s relatively simple, we had to make it repeatable so we could add multiple actors. God help me, date of death had to be repeatable too. What if Sara dies again!? CMB2 has repeatable fields built in.

    Use Third Party Add-Ons Third

    The bigger the data got, the more important admin design became. The more tropes, the worse a dropdown or multi-check section was. By using a select2 addon, and some custom save code, I was able to convert taxonomies into an auto-complete, which is a lot easier to visualize. So are groups. By clumping related data together, the brain makes the right connextions. And when it’s repeatable, your page grows with the data is uses, not with the data total.

    Sara has three TV shows. THREE!

    Sara’s page is much bigger than anyone else’s because she has three shows, and each show section has a dropdown for character role and another for the show name. And I can’t guess if she’s going to show up on another, like Supergirl maybe. CMB2 does have a limit to repeatable fields and groups, though. I hope Sara doesn’t hit it…

    Be Willing to Make Changes Fourth

    You will be wrong. I removed the list of ships, relationships, from shows. Tracy was sad. I added it back. My bad, totally, and my reasoning was that it was not easy to maintain and manage in a searchable way. It wasn’t. But it could be. And I made it. Be willing to be wrong, to make mistakes, and to recover from them.

    Because … Sara is always changing. Alive, dead, new show, new actor… Sara is always changing and always adapting and always being more awesome. She’s anything but static, and that’s a good thing. Sara Lance made me throw my preconceived notions of data storage and organization out the window. And I’m better for it.

  • Hey You Gays Filter

    Hey You Gays Filter

    Are you tired of people always saying ‘guys’ when they’re talking to a mixed gender group of people? I know I am. One weekend I got four (yes four) comments about my code saying “You guys should…” or “Ask the guys who …” and so on.

    All implied I wasn’t the human who wrote the code. Spoiler alert. I was. While I can’t fix the world out there, I do tend to reply with a handy gif:

    Eowyn from Lord of the Rings, pulling off her helm and shouting I AM NO MAN before killing a wraith and saving everyone.

    But I can fix MY site. Since I only need this for comments on my site (I’m in charge of how I write), I can use this:

    add_filter( 'comment_text' , 'hey_you_gays', 11 );
 
function hey_you_gays( $text ) {
    static $dblq = false;
      if ( false === $dblq )
        $dblq = _x('“', 'opening curly quote');
      return str_replace(
        array( ' guys', '‘guys', $dblq . 'guys', '> guys', '(guys' ),
        array( ' guys', '‘gays', $dblq . 'gays', '> gays', '(gays' ),
      $text );
}

    If you need to use it in titles and post content, steal the code from capital_P_dangit(). After all, that’s what we do.