Half-Elf on Tech

Thoughts From a Professional Lesbian

Category: How It Works

  • The Curious Case of a Comatose Cloud

    The Curious Case of a Comatose Cloud

    The summary here is that remotely hosting SVGs caused a massive slowdown.

    Isn’t the Cloud Magic?

    Nope. Well. No. It is totally magic, in that they’re great for large files and are an inexpensive storage alternative. But the cloud is, at the end of the day, just another server out there in the world, holding your data. Unless that cloud server is behind a CDN, you may not see a great deal of speed improvements on your site.

    And in my case, it didn’t.

    Diagnosing the Problem

    In building out a dev site with Tracy (LilJimmi), we noticed certain pages were really slow to load. 35 seconds slow. That’s unacceptable. I compared it to the live site, and it was faster, but some specific pages were still incredibly slow. What pages? The L Word for the most part. And as we inched closer to being done, I said “I’m going to fix this speed stuff before the weekend!” because you can’t go-live on a slow site. You just can’t.

    Once I was home, I fired up a local site, installed Query Monitor, and had a serious sit down with everything.

    It Wasn’t What I Thought

    My initial thought, the one I ruminated on during my bike ride home, was that it was the database queries. Most shows have one or two queer characters, but The L Word has 60 right now. While I may joke about wanting nine more, it’s a weird situation where I need to get the number of characters on the show without knowing the number of characters on the show. My assumption was that it was my calculation loop that caused the issue. That I was querying the queers too many times.

    Turned out it wasn’t (just) the number of characters, it was the number of tags.

    How It Got So Slow

    Most of the issue is my fault. Every single tag has a custom image associated with it. These images are stored remotely, in the cloud, and called as part of the design. The issue was that when calling the images I ran a check “Is the service available?” and if not, it would stop. When you make one or two calls, it’s no big deal. When you make a couple hundred, it adds up.

    The L Word had 2 icons per 60 characters, and then 15 tags, and then 30 more icons.

    Remote Get Is Slow

    I used wp_remote_get to process my images, and it was taking between .1 and .4 seconds per image. That adds up. At first I simplified my check-if-exists routine and more than halved the time to load from 35 to 15 seconds. But in order to drop the page back to 1 second-ish load times, I had to put the images local again. No matter what I did, if I loaded them remotely the best I could get was a 13 second page page load.

    Sometimes, local is better.

    What’s the moral?

    Obviously the moral is test before you rollout. Which we certainly did! By using Query Monitor, I was able to narrow down the speed for the database queries as well as the speed for all the HTTP requests. In doing so, I lost a CDN but gained speed. I’m trying to figure out how to speed up the CDN, maybe by finding a different front-end proxy, but right now I’ll keep using it for the large files like videos rather than the hundred small ones.

    I think it it’s worth it.

  • Git: Combining Your Messy Commits

    Git: Combining Your Messy Commits

    Sometimes I end up making a lot of commits while I’m working on a branch in order to get the code right. It mostly happens when I’m going back and forth between my new branch and the old (live) one to double check some code that I think got lost. It happens when changing theme structures.

    However. This left me with a conundrum. I had about 100 commits and really it was going to be the messiest pull request ever. Which I didn’t want.

    One Branch to Rule Them All

    In order to fix this, finished up all my errant commits, as messy as they were, and then I went back and checked out the clean development branch (named development). Since everything was up to date, I went and made a new branch.

    That gave me three branches:

    1. development – The actual dev branch
    2. messy-dev – My super messy branch
    3. clean-dev – My clean branch

    Of course, nothing of mine was actually in that clean branch.

    One Branch to Find Them

    Once I switched to my new branch ( git checkout clean-dev ) I imported my old branch with this: git merge --squash messy-dev

    Yep, that was it. I then went though all my regular checks, made sure the code was working, did a few more fiddly changes, and then I ran a git commit to run the last pull.

    This gave me a commit message filled with … well … this:

        Merge branch 'development' into messy-dev
    
    commit 6c7534b9f7eabb5db59a85880bbf42ff2b982d84
    Author: Mika Ipstenu Epstein <ipstenu@ipstenu.org>
    Date:   Sat Sep 23 19:47:27 2017 -0700
    
        Cards again
    
    commit 9fe21f380a1befcbbe34a79937399b679c31c06f
    Merge: 0362bb5 14b4fab
    Author: Mika Ipstenu Epstein <ipstenu@ipstenu.org>
    Date:   Sun Sep 24 18:08:18 2017 -0700
    
        I hate Sara Lance so much!
    
    commit 0362bb5a289e2694bd4872137ad470091529021d
    Author: Mika Ipstenu Epstein <ipstenu@ipstenu.org>
    Date:   Sun Sep 24 17:57:33 2017 -0700
    

    One Branch to Bring Them All

    Don’t worry. I didn’t keep that. In fact, I’d been writing a log of the entire work, listing out what was changed, fixed, added, deleted, etc. So I deleted that entire commit message and pasted mine in it’s stead.

    Well written inline documentation is one thing, but a good commit message saves lives. Since I planned to submit this as a pull request, I knew I had to have a good, simple, commit that listed things that had changed.

    But there also had to be more…

    And In The Pull Request Bind Them

    I’m rather pedantic about all that and wrote about 500 words to explain what all the code was in that Pull Request. Since I’m working with other people, and I’m not the lead developer on this project, I know not to commit my changes to the dev server right away.

    Instead, I made a pull request with a repeat of data in my commit, but also a different and more detailed explanation. A pull request has to explain why the work was done and why the pull is needed.

  • How Mobile is AMP?

    How Mobile is AMP?

    There are pros and cons of using AMP, the biggest being Alex Kras’ discovery that Google is kinda stealing your mobile traffic with AMP. But since WPBeginner lays out the pros and cons really well, I’m going to skip over that and discuss something else.

    Responsive Themes

    The concept of a ‘mobile only’ theme is one I generally deride. After all, if you’re on a website in 2017, it should have been written with the concept of mobile first. Most people design a site for their computer/browser of choice, and then add in resizes for mobile. Contrasting this is the idea that you build out your website for mobile browsers first, and then go back in and add in the larger views. That is Mobile First.

    It’s an ideal, I agree, and while I love it (and Carrie Dils who made the beautiful Utility Pro Theme as a mobile first them), it can’t always be achieved. Some websites are written to be ‘apps’ and they’re intended to be used as a browser app.

    In general, I support the use of a responsive theme, be it mobile first or not. This kind of theme will react based on browser size, or operating system type. But a mobile ‘only’ theme? I dislike them a great deal. They create headaches with caching (ask anyone who’s had their cache catch the mobile page for everyone!) and they can be difficult to jump back from, if someone is perhaps on a tablet that can handle the ‘full’ site. They also double your work.

    AMP

    AMP is a project by Google. The concept is a super light, ultra-fast mobile page for your sites. AMP is fast, it’s simple, and it’s a stripped down version of your normal site. How it works is that When Google searches your site and adds it to their big giant database, they can can see “Aha, this site has AMP! I will use it for mobile!” And then, when someone surfs to your site via a Google search, Google would notice “This user is on mobile! I will show it AMP displays!”

    The downside you might have noticed is that the AMP pages only get called when you’re doing a Google search. That means if you go to a website on your phone, you get the mobile responsive site anyway. Which is what Paul (and I) think you should be doing. And right away, you might think “Hey, I should make all my mobile visitors go to AMP!” and you may come up with code like this:

    function amp_redirect() {
    	if ( wp_is_mobile() ) {
    		$url = trim(  $_SERVER['REQUEST_URI'], '/' );
    		if ( substr( $url, -3) != 'amp' ) {
    			$url = $_SERVER['REQUEST_URI'] . '/?amp';
    			wp_redirect( $url );
    			exit;
    		}
    	}
    }
    

    That looks great, doesn’t it? It’s smart enough to check if the URL ends in ‘amp’ and, if so, not redirect. Plus it uses ?amp which means if the page doesn’t have an AMP URL, it won’t fail an ugly 404 death.

    There is, however, a big problem with AMP. You end up having two sites. Paul Bakaus talks about the pitfalls of a separate mobile site, and how you should keep a responsive theme for your site, and not use AMP for Mobile. This is not a good thing in the long run.

    A RESTful Alternative

    So let’s think about this differently and not in the simple “Mobile vs Non-Mobile” way. Let’s ask ourselves the real questions. “What is this site doing?” and “How will people be using this site?” Because the crux of the matter is really how is the data from the site being consumed!

    Recently, with the advent of the REST API, WordPress has as new way for people to eat your data. Much like I’ve talked about before, using the REST API to power an Alexa app or a plugin, the REST API can be used to power mobile apps! Yes, people are running iOS apps with the REST API. This lets you display the content however you want, even audio only, and yet power it fully with WordPress.

    In a way, you’re still making two sites, the app and the theme, but… You’re not making a generic theme that fits all users. You’re making a real application that fits the specific use case.

    What’s The Answer?

    Let’s break this down.

    1) Your theme should be responsive for mobile. Period.
    2) AMP is great for Google searches.
    3) The REST API can, and should power your apps.

    That’s it. Three steps to amplifying your site.

    Oh, and please don’t use that code I showed you. It’s sad.

  • Review: Do The Twist

    Review: Do The Twist

    When I got ready to go to WordCamp Europe this year, I realized I needed a new adapter. I had one, and it worked, but it also was highly imperfect as it required me to charge everything through my laptop. You know that drill, right?

    Like a lot of road warriors, I travel with about four USB plugs and it’s a mess. It’s always looking for good plugs in a hotel room, and hoping I can charge everything. I used to have a cheap USB hub, but it shorted out. Cheap. I knew what I needed, and it was a charging ‘station.’ But I wanted one that would work ‘universally.’

    The Drama Of Plugs

    I don’t actually remember how I found this. It may have actually been an ad that popped up when I was searching for chargers. I’d been thinking about getting a multi-outlet travel power strip with a couple USB ports. My constant worry with those is the 3-prong US outlet isn’t actually universal here. I’ve been in a lot of nice hotels that don’t have them. Worse, converting from 3-prong to European outlets has, in summer at least, caused a power short.

    Seriously, I blew out the power on my floor in Spain once. Sorry.

    OneAdaptr to Bind Them

    And then I ran into OneAdaptr. At first I was skeptical of the idea. While I had a universal adapter, the sort you can plugin anything into and get anything back out of, this was slightly different.

    If you’ve got a Mac laptop, you’re familiar with the odd way you can change your power adapter to use the 2-prong or grab an extension and use a 3-prong. Backpacking off that concept, the Twist+ adapter lets you plugin your laptop right into the base, while leaving you four USB outlets.

    Example of the twist adapter

    This is the TWIST+ World Charging Station. And I’m a super fan.

    How I Use It

    First, yes, I use it entirely as intended, plugging my laptop and all my devices in. But I actually use it more as a USB hub. Shoving it into my purse, I was able to whip it out at a dinner with friends and plug all our devices in to charge. One of them had a 3-in-1 USB charging cable, and we ended up with 6 devices all plugged in and charging.

    This works well with my ‘style’ as I tend to plugin laptops to charge while I shower and clean up at the end of the day. By the time I’m done, the laptop is charged and goes away, and the hub gets plugged in at my nightstand to charge a Watch, a phone, and an iPad. It could even do another phone without breaking a sweat. And in the absolute worst case? I could plug in my laptop and get two more ports.

    If you just want a USB hub, they (will soon) have a World Charging Station which looks about perfect for a lot of things.

  • Secure Mindsets in Plugins

    Secure Mindsets in Plugins

    At WordCamp Europe last week, I talked about the basics of plugin development. Since I had a mixed bag of experiences, I decided not to actually write a plugin in the class, but instead I took Hello Dolly and edited it. I discussed how the plugin worked, that an action called a function, which returned a value, and showed the interconnectivity. In this way, the attendees could understand the big picture of how code comes together.

    But at the end, with five minutes, I touched on an important aspect of plugins that Hello Dolly doesn’t do much with, because it doesn’t have to.

    I talked about security.

    Past You

    In the past, you probably done insecure things. Have you ever left your car unlocked in the driveway while you ran the groceries inside? We all do things that are insecure or unsafe. This is normal. Similarly, we have done insecure code. In the past, all of us, when we begin, we write code to perform actions without thinking about how it will be used globally. We don’t worry about safe, we worry about functions.

    There’s nothing wrong with this. We are often focus driven designers, fueled by passion and desire, so we want to do and not worry about the details.

    This Morning’s You

    That said, when we do work in that way, we get ourselves into trouble when we ignore security. We assume people will only use the code in the right way, because it’s obvious what is right and what is wrong. I try not to say ‘obvious’ or ‘simple’ when talking about code or interfaces, because they are absolutely never, not once, obvious or simple. When I got my Apple Watch, the UX of Force Touch wasn’t obvious to me. It’s not simple now, since it can be a bit touchy, but it’s not difficult.

    In the same vein, we all know that users do weird shit. Really weird shit. They put text in fields that should only gen numbers. They put numbers in for email. They copy paste without thinking. And you know that. You’ve seen it.

    The Right Now You

    Having read that, you’re hopefully thinking “how can I make my code secure?”

    When we talk about basic security, we mean four things:

    1. Validate your data
    2. Sanitize what you save
    3. Escape what you output
    4. Verify a human meant to do it

    That’s it. Make sure a date is a date and an email is an email. Make sure you save the data in a way that doesn’t put other data at risk. Remove any possibly dangerous characters from what you show to users. Always make sure someone meant to do the action. WordPress has over a dozen Sanitize and Escape functions to help make sure you save the right data and it has nonces to help make sure you save when you should.

    They’re very complex, but at their heart, they do those four things.

    Future You

    The you of tomorrow will appreciate the you of today, if you remember to never trust your data. People typo. People make mistakes. People do bad things on purpose. All of that just happens. And if today, you learn how stop those bad things, tomorrow’s you will look back on you with love and thanks. Your users will thank you. Your next future will love you even more.

    Security isn’t just https and good passwords. It’s a mindset to remember that anything passed to your code might be attacked. It’s a mindset that good users do bad and dumb things. It’s a mindset that mistakes happen. And it’s a mindset that being aware of the whole of your code, how it all comes together, must always include validation, sanitization, escaping, and nonces.

  • POST Isn’t Just For Posting

    POST Isn’t Just For Posting

    I’m taking a moment here to explain something that confused the hell out of me when I was getting into the JSON API. In short, I was confused about what POST meant in the JSON API.

    POST vs GET

    The official documentation mentions this:

    Want to get your site’s posts? Simply send a GET request to /wp-json/wp/v2/posts. Update user with ID 4? Send a POST request to /wp-json/wp/v2/users/4. Get all posts with the search term “awesome”? GET /wp-json/wp/v2/posts?search=awesome. It’s that easy.

    From that I inferred that if I was updated content on my site, I would use a POST call. Otherwise, I’m always going to be using GET to get data. Makes sense. If you want to get the data on a specific post, you do a get for /wp-json/wp/v2/posts/1234 and get that post’s data. Store the JSON output as a parameter in your plugin, let’s say, and Bob’s your father’s brother’s husband.

    I was wrong.

    Alexa Posts

    When I started working with Alexa I was confounded. It told me it sent a POST request to my site. I stared at that for a while. I’d been assuming that when I asked Alexa something, I’d be able to tell it to do a GET request from /wp-json/MYAPP/v1/MYSKILL/parameter. After all, I’m not posting data.

    But then I thought about it a little bit more. A straightforward GET request gets data from a URL without interaction. A POST posts data to a site, and you decide what to do with it. Most of the time when we think of a POST action happening, we think of updating data.

    POST doesn’t have to mean update

    A POST is just sending data to your JSON API. It posts to your site.

    That’s why passing the WP_REST_Request $request data to your function gives you magical access to the request data. And from that we can grab all the data Alexa requests send to your site, which lets us parse the data and make decisions on our replies.

    Now like I said before, what you do with the POST is up to you. But that explains a lot about why Amazon is so picky about making sure a request came legit from them. Especially since you can order stuff from Amazon…

    “Hey Alexa, can you tell TV shows to stop killing off queer characters?”