Half-Elf on Tech

Thoughts From a Professional Lesbian

Category: How It Is

Making philosophy about the why behind technical things.

  • Be Nice to Future You

    Be Nice to Future You

    Sometimes the brunt of my education of developers is a constant reminder to be nice to the future them. Future you, or Drunk You if you’re Otto, loves you most when you take the time to prepare things for them. A little bit go foresight and planning will make life so much better for future you, and I’m going to break down six tips to make you love yourself in the future.

    Document, Document, Document

    Yes. Document everything. Did you make an API for your system? Document it somewhere everyone can get to. For my LezWatch TV project, I painstakingly documented out all of that, plus how the git repositories worked, how they deploy code, and how to get access. This is for something that two people work on. But by documenting it, we all know what to do! The better my documentation, the less likely I get a panicked message from my cohorts in crime.

    Make Good Commit Messages

    I’m terrible at this when it’s for personal use (the number of commits that are ‘I am stupid’ cannot be counted), but at work I’m pathological about a good subject and a descriptive summary. I want someone down the road to know what the patch does, but also why I did it.

    icons: Add new icon set

    Add 17 new icons from LIBRARY. This adds support for iconography with job descriptions, as well as better defaults for taxonomies and categories.

    It’s not complicated, but it’s helpful when someone wonders “When did we add those new icons?”

    Inline Document Weird Stuff

    One of my coworkers is great at this. Ben litters his code commits with them, and I’m sure some people find them annoying but I see them as helpful and amusing. Sometimes he puts in “I hate that we do this, but I needed to pass X.” That tells me two things: First, this code could be better. But second, I know what he’s trying to do and generally why. He’s given context to the situation, and future us will hopefully be able to make this better.

    Make Note of To-Do Items

    Another great habit is to put in notes, as inline comments sure, but also in the documentation. I’ve been using Trello in addition to inline comments (usually things like “To Do: Add in a check for foobar”) to make sure that my future plan is known. You want to make sure future you knows where you were going, and those to-dos are your sticky notes.

    Follow Existing Project Standards

    Okay. I hate this one. But. If your project has a standard, keep using it. The other day I ran into a problem where a new version feature wasn’t behaving the same way as the old one, but only in very specific situations. I walked backwards through the code until I determined a parameter didn’t exist on the new version. I had two options. One was to edit the code to check “If this new version, also…” and the other was to add the parameter to the 500 or so impacted items and then fix my code so it was always fixed going forward.

    The project had been using the parameter method for years, so that was my solution. It followed the standards.

    If You Have A Plan, Use It

    This sounds weird, doesn’t it? It came up when I was reviewing a plugin and noticed that some code looked very ‘generic’ while still being specific. I thought that it had to be a library the company had made for themselves, and asked if that was the case. I explained, if it was an original library they planned to reuse, they should use an if-exists check.

    What Are Your Tips?

    What tips do you have to make life better for future you?

  • Query Strings vs Static Resources

    Query Strings vs Static Resources

    If you ever do a page speed check on your site, you may have seen the notice to “Remove query strings from static resources.”

    What Are They And Why Do I Care?

    At their most basic, a query string is any URL that has a ? in it. For example, if you go to a url of https://example.com/?lang=en then that last bit is the query string. It’s job is to tell the browser to pass on specific information to the website. It’s essentially a variable that will be read by the website or the browser.

    A static resource is a file used by a website that doesn’t change much (if at all). These are usually images but also CSS (style sheets) and javascript files. These resources can be stored on web servers, proxy/CDN servers (like Cloudflare or MaxCDN), or even a web browser, which makes your sites run faster.

    However. The explanation is that browsers don’t cache anything with a query string. Which means, yes, if your static resources have one, they won’t get cached.

    Or will they? (It’s complicated.)

    Why Do My Resources Have Query Strings?

    If query strings break caching, why would anyone have them? Because we don’t always put version numbers in our paths for common files. For example, in WordPress if you call jQuery (a common javascript library), you’re calling a path like https://example.com/wp-includes/js/jquery/jquery.js and that has no version number. But WordPress has certainly updated that a number of times.

    In order to make sure that jQuery gets properly cached when you upgrade, WordPress adds a query variable like this: https://example.com/wp-includes/js/jquery/jquery.js?ver=1.12.4

    This is important because otherwise when you upgraded WordPress, you’d see a page formatted weirdly and misbehaving, all because the wrong (cached) jQuery was loaded.

    Should I Remove The Query Vars?

    Maybe.

    Yes, allowing your resources to be cached will make your site faster, and it will get you a higher score in those page speed checks. At the same time the speed benefit is pretty low compared to the dangers of those files not being properly updated. Features on your site will, literally, cease to function.

    So you’ll need to decide for yourself which is more important.

  • Is This A Good Idea?

    Is This A Good Idea?

    I’ve joked about this a few times, that I should go into business telling people if their web idea is a good one or not. The prices would be simple.

    • $25 – A quick yes or no.
    • $100 – I’ll tell you if it’s dangerous or possibly illegal.
    • $500 – Details of everything.

    While I doubt anyone would ever actually pay for that, let me tell you some things I think are bad ideas for the web, and why.

    Obvious Bad Ideas

    Excluding the whole “Facebook but for pets!” and “Uber but for Pizza!” ideas, and dismissing every single ‘disruptive’ concept out there (seriously, no they’re not), some ideas are really easy to point at and say ‘this is a bad idea.’

    If you’re thinking about making something new for WordPress, before you start coding, please use google. Because the first kind of bad idea is the idea that’s been done before, ad nasueum. For example, sliders, snowfalls, BMI calculations (actually ANY sort of calculators including loans), ‘simple’ contact forms, and Google Analytics.

    These are bad ideas because they are overdone.

    If it’s been done more than 10 times, and you’re not introducing something totally new (this includes the fellow who made a ‘login logo slider’ – no, it wasn’t new), then file it away as a good experiment. Write the code, but don’t publish it.

    Illegal/Dangerous Ideas

    Depending on how often you hear me rant, you may or may not be surprised to find out how often people write code that’s illegal.

    Now hold on. Before a single one of you says “But the GPL!” let me remind you. The GPL doesn’t make things magically legal just because it’s open source. You can use GPL code to break laws (like, say, make a child porn website), and while that’s fine for the GPL, it’s still illegal.

    On a less creepy but still illegal note, the Yahoo! finance APIs aren’t actually legal for you to use in your code. Yes, I am well aware of the number of people who make packages for it. I’ve actually spoken to Yahoo about this and the way they explained it was this. Their Finance API is for your personal use. You’re not meant to use it to retrieve data for apps (and yes, plugins are apps) or any third-party usage (again, plugins). Also they do make it pretty clear with this comment:

    By accessing the Yahoo! site, you agree not to redistribute the information found therein.

    A lot of public APIs have these restrictions, including Airbnb and even some Google APIs (finance again). And using them without checking the terms of use and verifying they’re allowed to be used in your situation puts you at risk for breaking the law and that is dangerous because, in the case of a plugin, it’s not just you who pays the price.

    Ignorant Code

    Really the magic of everything, the answer to all ‘is this a good idea’ questions can be found in this. Did you bother to do the research first? And no, I don’t mean did you do market research (though that’s a good idea too).

    Did you check if the idea existed already? Did you check if the tools you want to use permit that kind of use? Did you read the terms of use of any service? Did you listen to your gut or not?

    Think first. Look before you leap. And above all, please don’t make yet another snowflake tool. No one actually likes them.

  • Dogfooding DreamPress

    Dogfooding DreamPress

    While I work for DreamHost, and I’ve used DreamPress since day one, I haven’t have the opportunity to put a serious, stress site up on it. The reason for that is simple. The two sites I have that I might do that for are ineligible for pretty much all managed WordPress hosts … because they’re not 100% WordPress.

    But. There is one domain that is, and I’ve moved it over. And this gives me an opportunity to determine what needs to be done to this site to make it fly on a different host.

    All Hosts Require Site Tuning

    This is possibly an unpopular opinion, but no matter which host you pick, there will never be a ‘drop it in and forget it’ option for any web host. The reason is that no two sites are the same. No two sites use the same code, have the same data, and have the same traffic patterns. And all those things come together to determine how well your site will run.

    No matter who your web host is, you will have to adjust. It may be something as simple as editing an .htaccess file or removing a plugin you no longer need. Maybe it’s as complex as PHP settings or having someone write you custom code.

    I don’t mean to say that no two hosts are equal, or that one is better than another. What I mean is that no two situations are identical. Of course a site will work, out of the box, better on one site than another. But when we have the capacity to understand what it is that makes our site work, what it does and how it does it, we can make any site work on nearly any host.

    For DreamPress, I Made Four Changes

    After I moved the site over to a test setup, I quickly debugged the ‘big’ issues. I had a white screen of death. Thankfully I knew right away what it was, because I was clearly aware of what went into my site and how it worked.

    First, a lot of sanity checks I’d put in to my .htaccess didn’t work. Primarily it was a case of how I’d handled redirects, since I was using an Apache4 format that didn’t work universally.

    Second, I wanted to use a phar file, so I had to add custom lines to my PHP settings to let it know how to run properly.

    Third, I replaced the old caching system with the new one. DreamPress has Memcached and Varnish, so I removed some of the object caching I didn’t need anymore.

    Fourth, I wrote some customized code to teach my site how to talk to Varnish, since I do weird things.

    That’s it. Four things. And I was able to debug this in about an hour because I took stock of the moving parts of my website. Not everyone can do this, I understand that, but when you build out a website, even if you can’t code, it’s incumbent on you to document what you did.

    When you add a plugin or a theme, you need to make a note somewhere of what it is and why you did it. I recommend someplace not on WordPress, since if your site is down, it won’t do you any good at all.

    The Immediate Impact

    With those four changes, the result was immediately obvious.

    A change in page timings - basically everything went balls faster.

    In the chart above, there are two major drops in speed (in this case, a drop is good). At the end of July, I reoptimized how images were processed by using Photon via Jetpack, I applied caching for FacetWP, and I removed all Google Ads. In doing so, I halved my time to load. This is a great thing.

    But then, just by moving to DreamPress and doing no changes to code, I halved it again.

    The average site load is now .8 seconds. It ‘spikes’ to 1.2 seconds if you hit a non-cached page. The time to first byte, which is shown on the graph as the yellow/orange line, went from 1.6 second to .1 second.

    Was Everything Perfect?

    No. But as it turned out, everything that wasn’t perfect had nothing to do with my new hosting setup. I reproduced the site locally and found I had some seriously slow database queries on a couple pages, which resulted in poor load times. Once I fixed that, a few of my archive pages began to fly.

    Also as I mentioned in the four things I changed, I did have to write new code. The bonus for the new code is that I was also able to back port some of that into the Varnish plugin itself, which means fewer people will have to write that code. You’re welcome. But that really was more for convenience as the site ran fine, it was just a bit overly aggressive in caching.

    Is DreamPress Right For Everyone?

    No host is right for everyone. Period. End of conversation.

    Is it right for you? Maybe. It certainly can be, and not just for generic ‘blog’ type sites. But you have to know what your site does, who uses it, and what they do to really know the right questions to be asking.

    The question isn’t “Is this good for me?” but “What does this do to a site that does what I do?”

  • I Hate Migrating Sites, And That’s Okay

    I Hate Migrating Sites, And That’s Okay

    Friday I tweeted coming up for air after migrating a 1 gig website. And I had hated doing it.

    Apparently that was a signal for men with whom I’m acquainted with but am not friends to drop unsolicited advice on me, most of which I’ve already written about on this blog.

    I found this incredibly condescending from most people. When someone says “I hate X…” and your reply is “Have you tried…” then you aren’t listening to them. You’re addressing them from a place of superiority and arrogance. “I know better than you. Let me tell you what to do.” Or worse, you’re listening for keywords and then pitching your wares.

    Let me put this clearly:

    1. I did not ask for help (I didn’t need it)
    2. None of the men asked if I needed help (they assumed I did)
    3. None of them were friends.

    That last one is important. If my good friends, the people whom I play CAH with or share drinks, offer unsolicited advice, they know me well enough to do so intelligently. They do it respectfully and sometimes sarcastically. But they are friends. When non-friends, Internet people with whom I’ve exchanged words or reviewed code, do it, it’s not at all the same.

    Here’s a selection of how my weekend went:

    “But I love it!”

    That one wasn’t advice, and as it happened, he didn’t like moving sites, he liked writing the code to do it. Me too! But watching a site move is as fun as watching paint dry. And testing everything to make sure the code works on the new server is similarly dull. And yet you have to do it.

    “That’s not a large site.”

    Didn’t say it was. Again, not advice, and this was from someone I know fairly well, so I was more inclined to chat about it. Turns out he has to move a 5 G site multiple times a year. Which … something’s wrong there, first of all. But also his users need to sit down and talk about image sizes, because daaaaayyyyyyymmmmmnnn.

    “You should use wp-cli.”

    Funny thing, I did. I love using wp-cli for updating the database, and since I happened to be unraveling a multisite, it was perfect. But you know… I’ve written tutorial on it, added documentation, written extensions, and talked about that tool multiple times. Including on this site. Know your audience, folks.

    “You should use zip [instead of rsync].”

    When you’re looking at large files, like gigs, sometimes zip is stupid and won’t unpack. PHP has limitations of 2G you see. I did zip up the plugins and themes and then the uploads, but I had to move them from server A to server B. And I did that with rsync. My other option was to download and then re-upload. Maybe if you’d suggested SCP you would have been helpfull. Rsync made sure I didn’t re-copy anything.

    “You should use [my service].”

    No. Absolutely not. No. JM Dodd is the only human I would trust with that kind of a migration. Why? Because it was WordPress Multisite. None of your tools, not even VaultPress, is capable of handling that well. Plus, the added wrinkle was moving one multisite into it’s three separate sites.

    Also … I am very very very skeptical of using anyone’s tools. I review their code and their websites and their communication skills. And honestly, I’m not impressed by that company. They just don’t give me the feel-goods I’d want when going into business. To be fair, I’m not sure how I feel about VaultPress either, but they’re my experiment.

    To be fair, one of the services apologized after.

    “Why not move things manually?”

    I … did? This one takes the cake because when I pointed out that I did know that stuff, and perhaps one should think about to whom they are offering unsolicited advice, I got told that I should use a specific host and service. After I blocked him, he subtweeted about women/lesbians and their egos. Not a great way to win your case, buddy.

    “You should use host X.”

    Stop. I didn’t ask for hosting advice, nor was it mentioned. People move sites on the same host sometimes, you know. And once I had the site up on site.dream.press, moving it live was ten seconds of work.

    I Never Asked For Help

    This is the big deal. The word ‘help’ never came out of my mouth. I didn’t even break DNS or forget TTL this time. I didn’t need help. All this was, was me saying I hate moving sites when they’re a gig (or more) of data.

    Not single man asked me “Do you need help?”

    They all assumed I did.

    That, friends, is why I called it Mansplaining, and blocked over ten men on twitter.

    Comments on this post are disabled. Don’t reply, just think about it.

  • Review: Twitter vs Twitter

    Review: Twitter vs Twitter

    Like most people, I use Twitter. I don’t always use the official Twitter tools for that, though. For example, I rarely use the website itself as it’s slow and annoys me. I’ve almost always used Twitter apps on my computers, too.

    In July I decided to try using the official Twitter app again. I’d stopped when, at some point, they stopped working on it. Since they’ve picked it back up, I felt I should try it out. As a whole, I like it 90% but … well let me explain.

    Tweetbot

    This is my normal, go-to Twitter app. I’ve used it for a couple years, and it meets nearly all my needs for a Twitter app. I can have multiple accounts, which is a must-have for me, and it separates my @-replies from my likes/retweets. I really like that. It also makes those @-replies a different color in my timeline so they stand out.

    But… It only tracks likes/retweets for while the app is open. So if I log off, get a million retweets, and log back in, I’ll never know. Also it lacks some of the basic Twitter features like being able to report users and seeing if my other accounts have messages etc I need to pay attention to. I have to click to expand the other accounts to see what’s going on.

    Interestingly, all third party apps, be it iOS or MacOS, seem to have this issue with the notifications. They just can’t keep track if you’re not logged in. I’m guessing it’s a matter of the API and limiting calls. Most annoyingly, recently Twitterific has just stopped showing me @-mentions from people I don’t follow.

    Twitter

    Currently it has a brain and does everything you can do on the web. Multiple accounts, which I can see at a glance who has an alert or message, and it’s easy to switch between them. One click. I can see

    Downside? Sometimes when I log back in, the Live Stream is messed up. Also the notifications and mentions and replies are all jumbled up, in the worst ways. I can’t just see replies or likes or mentions. There’s no indication that a message IS a mention in my main-timeline. And the alerts that tell me I have an unread are for notifications and mentions combined.

    That I can’t easily find my mentions, which I want to reply to, sucks.

    So Which Wins?

    Right now, Twitter’s app is winning for the simple reason of easy user status, easy user switching, and actually being able to see all my likes/retweets. Which is important in some cases. It certainly sucks that I can’t easily identify my replies, and I can’t separate mentions from notifications like I can in the web-app, but the reliability of the API is (currently) worth it.