Half-Elf on Tech

Thoughts From a Professional Lesbian

Category: How It Is

Making philosophy about the why behind technical things.

  • SEO Doesn’t Auto Post Anymore

    SEO Doesn’t Auto Post Anymore

    I don’t auto post to Twitter, Tumblr, Facebook, Google Plus or LiveJournal. I stopped about a year ago, and since then, I’ve stopped crossposting to everywhere except the places I actually frequent. That’s not to say I don’t skim Tumblfeeds (the spam monsters than they are) or check in on my LJ communities. It means that I no longer have any code that automatically posts to those places when I make a new blog post. Any time you see a link to my posts on another site, made by me, that means I took the time to log in and fill in the data by hand.

    Why? Well, I’ll jump around chronologically and tell you that a pair of articles hit my feed recently. First, one about how “3rd party APIs […] are punished in Facebook’s EdgeRank algorithm” (Source: Edgerank Checker — Does Using a 3rd Party API Decrease Your Engagement Per Post?) and the second, which linked back, said that pages that auto publish lose 70% of ‘likes’ and comments. (Source: Insider Facebook — Study: Auto-Posting to Facebook Decreases Likes and Comments by 70%)

    AutobotBoth of those back up what I’ve always said about SEO and HEO. If you want people to come to your site, you have to engage with them. That means you need to interact, not spam, and converse. Find out what they like and how they like it. They hammer home a point that was obvious to many of us old hats know, but many young bucks ignore. You have to be in touch with your readers, and no automated system in the world can do that for you.

    Now, certainly, I use tools like Google Analytics’ Campaign feature, and Crowdrise, to help me determine what posts of mine are popular, when and where, and attempt to comprehend the why of it all. It’s a very fuzzy science. I know I hit paydirt when my @-replies on Twitter are coming so fast I can’t keep up, and my comment-feed is burning a hole in my screen. But until we perfect an AI that knows, before I do, what I want, we’ll never have one that can predict accurately what we need to do to make our sites popular. And we all know that popularity is the end game.

    Popularity has a strange converse, though. For example, you may think that auto-tweeting your blog posts is a great idea to get the content out there and read. This is true, but I found that the more I auto-tweeted, the more splogs came to my site! That’s right, I was increasing the attack of content scrapers, and tweet bots that spam, which in turn decreased any SEO benefit I might have acquired. Sucks, doesn’t it? Thankfully, manually crafting a quick tweet, and taking the time to phrase it right, got me more traction than anything else.

    The other massive downside to auto-posting on social networks is that you rarely get to make the post look the way you want to. I want to pick which image I’ve attached to be the thumbnail, and I want to make sure my custom excerpt (which I always write) is picked up, and I want to maybe put in an extra explanation on G+, but not on Tumblr or Facebook, and … you know, I want people to know I’m thinking about them.

    There is a huge desire to share everything with everyone. To tell your friends in one social network the same things you tell them in others. And for self-promotion, this is big as well. But as the media is learning, a blanket advertisement like you see on TV doesn’t work so well anymore. How many commercials can you remember well? I can remember the Old Spice guy and the Most Interesting Man in the World (also a couple weird phone commercials), but we don’t always remember the products, nor do we actually always buy the product being advertised. I don’t use Old Spice or Dos Equis. Still, blanket ads are hard to land, since you don’t know who’s going to read your site. Similarly, blanket ‘Hey look at me!’ is hard to make efficient, because you’re not reaching out to your audience and making them a part of your process. You’re shouting at them, not talking with them.

    DecepticonWhat about those of us who aren’t advertising. If you’re crosslinking just to share with friends, an automated system seems fine, except these are your friends and don’t you want to be personal with your friends? Don’t you think they deserve the time and effort of a real ‘Hey, this is what I’m up to!’ instead of a blanket letter? Wouldn’t it be nice to say “Bob, I thought of you when I wrote this because of that conversation we had about …” Or if you send it to a group of your friends and Bob’s, then Bob feels great because you’ve brought him into the conversation and your friends know you think about them.

    The funny thing about this is I also stopped scheduling posts. I used to set posts up to run once a week, minimum, even if I was going to be off line. Now, because I want to interact with people, I post them only when I know I’ll be around.

    The next time you see a social media post of mine, linking back to a blog post, know that I took the time and effort to link it. If it’s styled pretty, I did that on purpose. I try to make it personal and not just slap a link up, and I think that effort shows, and comes back to me in pageviews, comments and likes.

  • GPL Freedoms – Yep, Porn’s Good!

    Did you know you can use WordPress for a porn site?

    Did you know you can use Drupal to show autopsy pictures?

    The freedoms of GPL don’t just extend to the software itself, but to how you use it. See, most of the time when we talk about GPL freedom, we’re talking about how you’re free to take the code and turn it into a monkey if you want to. But lately, there’s been an effort to remind people that part of GPL also means we don’t restrict your usage either.

    WordPress has a link to ‘Freedoms’ at the footer of all admin pages, and that duplicates the Bill of Rights found at WordPress’s Philosophy:

    WordPress is licensed under the General Public License (GPLv2 or later) which provides four core freedoms, consider this as the WordPress “bill of rights”:

    • The freedom to run the program, for any purpose.
    • The freedom to study how the program works, and change it to make it do what you wish.
    • The freedom to redistribute.
    • The freedom to distribute copies of your modified versions to others.

    Drupal doesn’t spell it out as clearly, but given that they have fetchgals, which can pull in thumbnails of porno pics (if I read that right), I feel confident to say that Drupal doesn’t care what you use Drupal for. Joolma! puts a lot of stock in people using their product for their communities and nowhere did I find note of a limitation of what you cannot do.

    The point is valid, however. You can use WordPress, Drupal, Joomla! and pretty much any GPL software for whatever purpose you want, moral or immoral, legal or illegal. This is interesting when you compare it to most EULAs, like Microsoft Office:

    7. SCOPE OF LICENSE. The software is licensed, not sold. This agreement only gives you some rights to use the features included in the software edition you licensed. Microsoft reserve reserves all other rights. Unless applicable law gives you more rights despite this limitation, you may use the software only as expressly permitted in this agreement. In doing so, you must comply with any technical limitations in the software that only allow you to use it in certain ways. You may not
    […]
    • use the software in any way that is against the law;

    GPL doesn’t tell you that you can’t use it in a way that’s illegal, and perhaps Microsoft only does to escape a potential lawsuit for someone saying “Aha! You used Office to draft your Mainifesto!” We live in over litigious times. Open Source, by telling us ‘Do what you want, it’s not our beef.’ removes themselves from those issues cleanly and without ass hattery.

    One of the tenets of American Law is our freedom to speak our mind. Part of being an American Citizen is that you have the right to defend your beliefs, no matter how much I oppose them, and so long as no one breaks the law, that’s fine. I can ask you to leave my house if you do it on my private property, and you can ask me to leave yours. But if we meet on the street I cannot have you arrested for that. I will defend your freedoms just as you must defend mine, regardless of any agreement or lack there of.

    This applies to Open Source because I have the right to use WordPress, Drupal or Joomla! in ways you may find distasteful. As long as I’m not violating the agreement of my ISP, the laws of where my server is located, and the laws of my nation, I’m allowed to call you names, insult your heritage, and show nudie pics of pretty girls. On the other hand, I cannot publish your personal information (it’s a violation of invasion of privacy) and I cannot post naked pictures of you without your consent. Actually, my webhost won’t permit and naked pictures at all, so there’s that.

    So when you see a site run by WordPress, Drupal or Joomla! that’s doing something you hate, there’s very little you can do about it. Report it to their webhost if you think it’s breaking the law, but otherwise celebrate people in their freedom.

  • Risk Theater and Open Source Testing

    Risk Theater and Open Source Testing

    Audits Are Fun!We make multiple test environments and platforms, testing with hundreds of users.  We perform stress tests (how much traffic can my site take?), and have an obscene amount of checks and balances to ensure that only code that is good makes it into the file product.  We have teams who question every change asking “Do you need this?” or “What’s this function for?”  We audit every update process and ensure that our work is as good as we can make it.  This is all done, we say, to reduce our risk.  Our software, we insist, will be better if we do all these things.

    But the failure rate has not dropped.

    Initially, when a product is released, there’s a spike of failures.  We didn’t anticipate that, or this didn’t work like we expected it to.  Those are not classified as ‘failures’ but as kinks to be ironed out.  Six or seven months down the line, we’ve released another set of itterations to fix the worst offenders and our failure rate drops to a comfortable rate where, most of the time, everything’s fine.

    What if I told you that one in five IT projects was a success?(Source: Statistics over IT Failure Rate)

    What if I told you that all your myriad checks, balances, testing, forms and CYA dances didn’t make anything less risky?

    What if I told you it was all Risk Theater.

    Of course you can do things in a less risky way.  If given the choice between dismantling a bomb in a nice quiet room, where you have all the time in the world and a blast shield, or doing it on the back of a van while being shot at and you only have 30 seconds, everyone would point at that room and say ‘Less risky!’  And they’d be right.  The problem with risk is that there are often, if not always, external forces that perpetuate risk.

    We have to ask ourselves “What is risk?”  We can look at it mathematically.  Risk = {si, λi, xi} – and most of us have no idea what that means.  Risk is not a magical number that says “Defusing a bomb is this risky.”  Determining risk is how we discern how likely something is to happen, and from that, what is the likelihood of an unwelcome outcome.

    Too often risk is defined as risk = likelihood * consequence and safety = 1-risk

    This can misinform: acceptable risk is a consideration of likelihood ANDconsequence, not a simple multiplication with safety as the additive inverse of risk. Acceptable risk and safety are normative notions, changing with situations and expectations, and must be assessed accordingly. (Source: Woody’s Perspective – by Steven A. “Woody” Epstein)

    Risk analysis, for all it’s a mathematical discipline, is just that.  A discipline.  That means the numbers matter far less than you think they do, and if all you do is look at the numbers and say “But we’ve predicted a five point uptime!” then you’re ignorant of the truth.(A five point uptime refers to the claim people make of providing 99.99999% uptime.  The five 9s after the decimal point are feel-good numbers/)  The trick to it all is that variation is something computers are phenomenally bad at handling.  Look at your computer.  It’s what can be best described as a ‘brittle’ system.  If you throw something a computer’s never seen before, it tends to react poorly, because unlike the human brain, it can’t adapt or improvise.  It can’t know “Oh, you meant ‘yes’ when you typed ‘yea’” unless some programmer has put in a catch for that.  On some systems, it may not even know the difference between an uppercase Y and a lowercase y.

    Variation in LeavesVariation is nature.  It’s reality.  It’ll never go away, either.  The point of risk analysis is not to come up with that number to say ‘By doing foo, we are x% less risky.’  The point is to look at the system and understand it better.  The point is to learn.  The act of explaining and defining the process, whatever it is from changing a tire to pushing software to a few hundred servers, is what makes a process less risky.  You understand what it is you’re doing, and you can explain it to someone so they too can understand it, and now you know what you’re doing.  The numbers will come, but they’ll also change over time due to variation.

    We mitigate our risk by understanding, testing and documenting.  But just as you can never have 100% uptime on a system (you have to upgrade it at some point), you cannot excise risk entirely.  On the other hand, we cannot ignore the need for testing.

    A woman named Lisa Norris died due to a software error, caused by a lack of testing.  All the safety checks, the manual monitoring and brainpower failed because the automated system wasn’t tested.  Prior to the automated system going online, the old way was for people to manually transcribe medical dosage.  This was felt to be ‘high risk’ because there was a risk of transcription error.  However nowhere in the incident report were any ‘manual errors’ noted, prior to the automated system being used. We can assume, then, that any manual errors (i.e. transcription errors, the risk the system was meant to abrogate) were caught in-flight and corrected.  The automated system does not appear to have ever been tested with ‘real world’ scenarios (there’s no documentation to that affect that anyone investigating the situation had found).  If they had run simulations, testing with data from the previous, manual system, they may have found the errors that lead to a woman’s death. (Source: Lisa Norris’ Death by Software Changes – by Steven A. “Woody” Epstein)

    There remains a possibility, however, that even with all the testing in the world, that the error that led to Miss Norris’ death would have been missed.  So how do we make testing better?  As long as we’re only testing for the sake of testing (i.e. it’s expected, so we do it), or we follow the standard test plan, we miss the point of dry testing.  Even people who stick by their ridgid test scripts are missing the point.

    Open Source software, however, gets the point.

    Monkeys sans keyboardsYou see, we know we can’t test everything, and we know that we’re going to miss that one variation on a server where code that works a hundred times on a ninety-nine servers will fail on that one where it has a tiny difference.  And yet, if a million monkeys banging on a million keyboards could write Hamlet, then why can’t they fix software?  They can help cure AIDS, we know.  Crowd sourcing knowledge means that you let the monkeys bang on your data and test it in ways you never imagined it being used.  No longer driven by a salary (and that really does lock your brain in weird ways), the monkeys (and I’m one of them), cheerfully set up rigs where we can roll back quickly if things break, and start just using the iterations of software, coming up with weird errors in peculiar situations.

    We always talk about how we want to lower the bar and make products more accessible to more people.  Make it easier for them to use.  In order to sustain that model, we need to embrace the inherent risk of software and teach the users how to correctly perform basic troubleshooting and report real errors.  To often we write our code in a vacuum, test it in a limited fashion, and release into the wild knowing there will be a second release to fix things.  As development matures, we push out more changes more often, small changes, so people are eased into that new thing.  We step out of isolation and embrace the varations of how our product will be used.

    Now we need to get our users to step out of their isolation and join the monkeys.  We can’t make things better for everyone unless everyone is a part of the improvement process.  We must ease these users into understanding that every software product is ‘in progress’, just like we taught them to accept that all webpages are perpetually ‘under construction.’  Our dry tests will never be complete until we can determine how to safely bring them in.  Maybe we make smaller changes every day, like Google does with Chrome, such that they never notice.  Or maybe we ask them to ‘check the box to join our test group and get cool features before everyone else!’  But we must do it, or we will fall behind in giving the users what they want, and giving them a solid, safe, secure product.

    Until then, we’re not analyzing or assessing actual risk, we’re merely players in risk theater.

  • How 17 Famous Website Looked In The Past: In The ’90s. You’ll Be Amazed | ImmatureBusiness

    Remember those times in the ’90s when you had to type WWW. and websites looked dull, boring, and full of moving and annoying flash banners. I’m sure nobody wish to go back to those times. Now, websites are focusing more and more on the user experience, loading speed, and subtle ways to locate ads without distracting the content or function.

    via How 17 Famous Website Looked In The Past: In The ’90s. You’ll Be Amazed | ImmatureBusiness.

  • Don’t Use WordPress MultiSite

    Don’t Use WordPress MultiSite

    Edit: It’s May 2015 and this post is still relevant.

    I talked about this at WordCamp SF 2013. Check out my slides or watch the video.

    I love MultiSite. I think it’s awesome and very helpful when you want to make a network of sites. But more and more I see people doing things where I just tilt my head and wonder why they’re using MultiSite for that particular use-case.  People seem to think that simply because they can use MultiSite that they should use it, and this simply is not the case!

    MultiSite, either by intention or effect, works best when you think of it as running your very own version of WordPress.com.  You have a network of sites that are disconnected from each other, data wise, but share the same available user base.  That means the only ‘information’ that is shared between two sites is your user ID, and even then, unless you’re explicitly granted access to the site, you’re nothing more than a subscriber.  Which is to say you can read the site, and comment.(You could get nitpicky here and point out that there are a lot more things one can do as a subscriber on a site, but you understand the gist.)  That means that while there are many perfectly valid reasons for having a MultiSite, it will never be a perfect solution for all people.

    One of the best alternatives to MultiSite is Custom Post Types.  They let you make ‘subfolder’ additions to your site and format them as you want.  There is a drawback, though, in that you cannot use YYYY/MM/DD in your permalinks for them (Otto on Custom Post Types – wp-testers email list) however I would wonder why people use that anyway these days?  The only reason I use YYYY in my URLs is that I believe there’s a date on the usefulness of these posts, and if you come back in five years, you should know how old the information is.

    Another alternative is good planning.  If you sit down and define your needs for your site before you build it out, and plan for the growth you desire, a lot of things become clear.  Think about how many different places you’d want to go to maintain your site.

    Here are some examples of sites that should not be built out as MultiSites:

    To Categorize Posts

    File CabinetThis one comes from my girl, Andrea, who reminded me of a fellow we ran into who wanted to have one site to post from, and each post would go to a special site based on the category.  WordPress already has that built in!  It’s called, get this, ‘categories.’  Now the user in question said he didn’t want categories because your URL shows up as /category/pemalink, and that wasn’t his desire.  So I suggested Custom Post Types.  /posttype/name was much better, and he could add in tags as he wanted.

    When Your Site is Homogenous

    Do you want your whole network to look and feel 100% the same?  Don’t use MultiSite.  If every single subsite is going to be exactly the same, except for content, but the content is all written the same way, you don’t need MultiSite.  Replicating the theme and settings on every subsite is a pain, and you can achieve the same result with categories, tags and CPTs.  You can even use a membership plugin to control who sees, and has access to, each CPT!(Role Scoper claims to do this, in fact.)

    Now someone will point out that this site fails that check!  If you notice, three (four, kind of) of the sites look very similar. Same general layout, same links and sidebars, but different headers.  This site could have all been done as categories and CPTs, and not needed the multisite until I hit on the children sites like the one for my grandmother.  But.  When I built it out, I decided to put my tech posts on their own page to separate the writing.  They are separate sites.  What I write here is vastly different from my blog, and that’s important to me.  The site has the same ‘feel’ in look alone: the context is what separates us.(And I have a plan for the photo blog.)

    For One Special ‘Thing’

    I’m guilty of this one.  I had a site that was a blog, and I wanted to make a ‘video’ section.  So I made a MultiSite!  Boy was that dumb.  Two admin areas, two sections for layout, and I wanted the site to still look like ‘itself.’  I caught a clue later on and converted the whole thing to Custom Post Types!  Much easier to maintain!  Now I have a smaller, faster, site.

    Users Shouldn’t Know About Each Other (AKA Separate User Databases)

    Andrew Norcross pointed this out.  If you need users to be on different sites, but not aware that they’re on a network, don’t use MultiSite!  Now, yes, there are ways around this, however it’s an auditing nightmare for any large company, and a security risk that you should be aware of before you start.

    Hidden UserCurtiss Grymala points out that if you need totally separate user databases, this is a strong case against MultiSite.  Be it for security or just obscurity, if the users need to be separated  don’t do it.  There are workarounds, but you’ll spend more time on that then updating your sites.

    Hosting Small Client Sites

    I don’t host my Dad’s site, Woody.com, even though I maintain it.  Why?  Because, as

    Cristian Antohe said, he just needs a standalone WP install.  Would it be easier for me to have one place to go to upgrade him?  Yes and no.  He’s small, he doesn’t need a lot, and he now owns his domain, his site and his email, all in one place.  It costs him $7 a month, plus the number of meals he buys me when we’re in town together, and he’s master of his own domain.  This is great for him, because if he fires me, he still has everything.  Also, if he does something weird that spikes his traffic 500% (like last month), it doesn’t affect the rest of my sites.  Factor that into your budget.  Make your client own their own data.

    Users Need To Embed JS Into Posts

    This is not a bug, people.  Only the Super Admin on a MultiSite install has the access to include iframes, javascript, and other non-oEmbed’d data into posts! You don’t want them to!  If you’re running a MultiSite, you’re the big dog, and you’re responsible for limiting their actions to things that won’t take down everyone because they don’t understand what an insecure iframe hack is.  Yes, there’s a plugin that will let you allow this.  No, I won’t tell you what it us, because unless you’re using a 100% locked down, you approve users you know and trust with your car, site, you do not want to open this door.

    If you can’t give them they access they need via shortcodes, then they need to host themselves, or you host them separately.  Protect everyone on your network, and don’t give them unregulated access.

    Users Need To Install Themes/Plugins

    Curtiss again reminded me that MultiSite doesn’t let you let your users install themes and plugins as they want.  You can, via the use of clever themes that save settings per site (like TwentyEleven) and plugins that allow you to tweak CSS (like WordPress.com Custom CSS) give them more customization, but you cannot give them access to install plugins and themes.  Why?  Because those things will be available to everyone on the whole Network.(There are plugins to manage plugins more granularly, and only permit some sites to use certain plugins, but again, this isn’t something everyone on your network should have access to do.)  Remember, we’re sharing here!

    Same Post, Every Site

    I keep running into this one.  “I want to have the same post pushed to every single site on my network!”  I understand why people do this, I just think they’re doing it wrong.  It’s not just that MultiSite is meant to be separate (aka individual) sites, it’s that you’re diluting your content.  The more different places someone can go to in order to get the information you’re providing, they less impact you have because you’ve given them too many options.  Decisions.  Make one. Also, as Andrea reminded me, identical content in multiple places is something spammers do. Google will downgrade your site ranking if you do this.(This doesn’t impact categories, tags and archives because of the use of canonical links.)

    Mimeograph (copy)Now, one user said he needed to do this as a business decision, because each of his (mapped) domains was a separate brand.  But the separate brands had shared data.  So … they’re not actually separate, but children.  Me?  I’d have everything link the shared data back to the master brand.  McDonalds may sub-brand out happymeal.com (they did!) and make a whole separate site, but if you click on their ‘Privacy’ link, you go back to macdonalds.com!  Why?  Because the parent brand is where that stuff belongs.

    BuddyPress Separation

    This comes from Andrea again.  If you need to have totally separate BuddyPress installs, use separate installs entirely.  Just … y’know, you can do it other ways, but it’s not worth it.

    What else?

    This list could go on and on, so jump in and tell me your reasons why you’d never use MultiSite!

  • New Plugin – WP Grins SSL

    WP Grins SSL is in development. So there’s that.