Half-Elf on Tech

Thoughts From a Professional Lesbian

Author: Ipstenu (Mika Epstein)

  • Mapping the Apple Watch

    Mapping the Apple Watch

    While in Japan, I had the chance to use my Apple Watch to get around and I figured out something.

    For walking or driving, the Apple Map app is the best to use with the Apple Watch. Not only do you get turn by turn directions with the haptic taps, but you can quickly see what’s next if you’re not sure what side of the street to be on. The haptics I love:

    A steady series of 12 taps means turn right at the intersection you’re approaching; three pairs of two taps means turn left…

    I use this feature constantly. It’s brilliant to be able to walk around and enjoy the area I’m in without worrying that I’ll get too terribly lost. As I walked through Kanda, my wrist tapped “tap-tap, tap-tap, tap-tap” and I turned left like a boss. The only time I used my phone was when I was at a five-way intersection. I can even use it to walk from my father’s apartment to his mother-in-law’s house a few blocks away. Or the 7-Eleven (which are awesome in Japan).

    For public transportation, the Google Maps app is brilliant. No. It’s phenomenal. Ueno station, in Tokyo, is one of the more complicated and confusing stations I’ve ever seen. It’s crowded, it has a damn shopping mall on top of it, and it’s where seventeen major train lines meet. The Google Map can, most of the time, tell me what track to be on and when for what train.

    Ueno makes Penn Station look tiny.

    But Google Maps can’t do ‘both.’ In fact, I’ve learned the Google Maps app is getting worse at things. You see, you go through Ueno to the Keisei Skyliner (the train to the airport) when you take the train from my dad’s apartment to Narita. It’s very simple. Takasaki line from Ageo to Ueno, exit Ueno via the South (not the Park) exit. Turn right. Pass the duck. Done.

    Instead of showing you a walking route, when I asked Google Maps to get me to Narita, it drew a straight-as-the-crow-flies line from Ueno Station to Keisei Skyliner. Yeah. Not so much there, Google-San.

    It only got worse when I wanted to take the train from Ageo to Kanda for WordCamp. You’d think that Google would be able to alert me, since they have an Apple Watch App, with taps “Hey, get off the train at the next stop.” But they don’t. In fact, the Apple Watch app just lists the directions, not very well, and doesn’t give me alerts. Even worse, you can’t easily track from the iPhone to the Watch. When I put in a direction on my Apple Maps, it automatically triggers the map on my Watch. Google Maps only shows ‘recent searches’ and Work and Home.

    It’s an absolute fail to use the technology properly.

    To make Google Maps ‘right’ for the Watch is pretty simple.

    1. Direction alerts. Tell me when to turn left or right. Steal it from Apple or make your own.
    2. Change train alerts. Tell me when I should get up. This will prevent people from sleeping through their stops.
    3. Give me easy directions to anywhere. Let me set up a path on my phone and immediately transfer it to my Watch.
    4. Use Siri. “Hey Siri, use Google Maps to get me home.”

    Four things. I’d settle for the first two, though I think the first three should be a priority for user experience.

    Until then, I’ll have to use my iPhone for transportation in a strange land, and my Watch for walking around the planet.

  • Octopress

    Octopress

    A brief history lesson. In the beginning there was Jekyll, a website generator that created static sites for you to deploy to your server. And then there was Octopress, a ‘framework’ for Jekyll that actually was a fork of one guy’s Jekyll site.

    Octopress is basically some guy’s Jekyll blog you can fork and modify.

    That’s a direct quote from Brandon Mathis, the creator and curator of Octopress. But it wasn’t a framework like WordPress people think of Frameworks. It wasn’t like Underscores, which is just a theme framework. It really was more like a one-click install for Jekyll, that had someone’s theme on it.

    Wisely, Mathis is working on changing this. Starting with Octopress 3 (currently 3.0.11) it’s a Jekyll add-on. While there is no ‘migration’ explanation yet, if you’ve never used Octopress, it’s a great time to start.

    How to Install

    Add this line to your application’s Gemfile:

    gem 'octopress', '~> 3.0'

    And then execute:

    $ bundle

    You can also install with bundler if you want, but it works out about the same in the end.

    How to Use

    I was stuck using bundler on my personal computer. That meant to use Octopress I had to do this:

    $ bundle exec octopress COMMAND

    Sucks, doesn’t it? After reading Ben Hamill’s post about ‘never typing bundle exec again’, it was fixed! I used the Ruby fix since it’s just me on the project.

    Now I can use octopress as my command prefix.

    What I Dig

    The deploy is way better than my own. Just put that out there.

    Also there’s a draft command!

    $ octopress new page _legal/terms/

    That will make the file /_legal/terms/index.html and I’m happy. If I want to use custom templates, I can do that too:

    $ octopress new draft "New Article" _news/2015/articlename --slug articlename --template _template/news --date now

    Sadly I can’t move the template folder. I wanted to store it in _jekyll/templates/ but that’s not an option. Also moving things to the _drafts folder is a little techy at best, since they assume you want to make posts and I’m making collection pages.

    Most of the time I do exactly what I was doing with MediaWiki, and that is to copy the content of an existing file into a new one. Most of the time I just copy the file, rename, and edit it. It’s not perfect, but it works and I know I get the right layout that way. I plan to look into why drafts is so touchy about where things are, and how to make it behave better with collections, but Octopress 3 is still in the early stages.

  • The Security of a Lifetime License

    The Security of a Lifetime License

    A few years ago, before I started working for DreamHost but after I decided I wanted to do WordPress all the time, I bought the StudioPress All Themes Package. For $500, it gave me a lifetime access to all their themes, all their future themes, support, and more. So I tucked away all my ad and ebook income for a while and bought it the day before a 50% deal hit. Of course, right? Brian being a wonderful guy, saw my amused tweet and credited me the difference.

    Since then, I’ve pretty much been a nothing but StudioPress shop. Almost every site I run on WordPress is using StudioPress themes. I’ve gotten free upgrades for all their themes, free versions of the ‘pro’ themes (all the HTML5 friendly ones), and it’s very much been worth it to me.

    But licensing is a strange subject. Chris Lema recommends charging annually (instead of monthly). And while I have a lifetime subscription, the unlimited free support will be leaving this world soon. From what I’ve heard, this only impacts support. To be honest, I’ve filed less than ten support tickets in five years. And it’s not because I’m savvy. There’s very little that I need help with to use Genesis themes. They have pretty darn good directions on how to reproduce their demo sites, they have code snippets, and they have a friendly self-help forum.

    Basically, this code is tight. Right now I’m using the Generate Pro Theme on this site, but I also bought Utility Pro theme from Carrie Dils (worth it). The child themes rarely need updating, and all I ever have to worry about is the parent Genesis theme being updated, which is easy as pie. They have their own updater.

    My friend Amanda Rush (also a StudioPress fan) wonders if this heralds the end of days of unlimited forever support and licenses. I suspect so. Will I be annoyed if I have to start paying for updates? Maybe, but mostly because I have a serious concern about security.

    Let me paint a picture for you. I get a free parent theme or plugin, it could be Genesis (the StudioPress parent theme) or WooCommerce (a popular ecommerce plugin), and I purchase an ‘add on’ of a child theme or an extension plugin. I pay for a year, and I’m happy. The add-on does what I wanted, I get my updates, and everything’s cool. Then one day, 370 days later, there’s a major issue. A massive security hole and suddenly my site is vulnerable!

    My license has run out.

    Do I get the update or not?

    Do I get notified of the update or not?

    I’ve seen this play out over and over again with sites like CodeCanyon and ThemeForest. How do people who have purchased a product get alerted properly and given the ability to update? We’re spoiled because if Jetpack or WooCommerce itself has a critical hole, those plugins are free in the WordPress.org repository. And I know, from working on that team, that if there’s a big enough issue, then the free plugins get updated and the update is pushed out to everyone. It’s rare, but when it happens, it’s for the benefit of everyone involved.

    The sad truth is most one-off shops can’t do that. WordPress.org can update all branches of your plugin. If you’re properly using versions for your plugins and themes, then you can release version 2.3.1 to fix a bug, but also fix that bug on 2.2.4 and 2.1.9 and so on. And yes, WordPress can push those branches (2.3 and 2.2 and 2.1) so even people on older versions can get fixed.

    To the best of my knowledge, no one else does that yet.

    And, perhaps worse, some won’t even consider letting you have the security update because your license isn’t up to date.

    All that said… Should you buy it, knowing you may not get support and updates forever? Yes. Right now, the StudioPress Pro Plus All-Theme Package is on sale. $262.46 for every theme plus third party themes. The sale goes on until the 16th, so grab it this weekend.

    It’s an investment I’ve never regretted.

  • One Direction: Sanely

    One Direction: Sanely

    In my ongoing saga of moving from MediaWiki to Jekyll, I decided to be smart and rename all my URLs.

    Stop.

    I know that’s the worst thing you can do. Please put down the pitchforks. I didn’t do this without redirections and I didn’t do it without deep thought. You see, the issue with MediaWiki is that it was a pretty flat file representation of the site. This doesn’t have to be the case. You can choose to put pages as sub-pages on MediaWiki very easily, but few people do. I didn’t. That means I had around 1000 pages that, in Jekyll land, would all be in one folder. And that sucked. Like I mentioned before, I made Collections.

    This meant I was moving from example.com/PAGE to example.com/folder/PAGE/ (and yes, the backslash matters, MediaWiki doesn’t do that). Now, from a structural standpoint, this makes a lot more sense. You want to have a collection of interviews, you have example.com/interviews/year/interviewname/ and that’s ridiculously easy to understand. But. When you’re moving from no structure to some structure, you have to accept a bit of a loss.

    So here’s how to redirect sanely:

    1. Make a list of what has a direct relation to a new page
    2. Look at your page visits to see what’s hit the most and make sure that’s redirected
    3. Have a catch-all at the end

    That’s it! Three simple steps to do it. But how did I do it?

    On the Wiki, I had a whole subsection called “Encyclopedia” which had all my internal documents like the about page, the policy pages, and so on and so forth. Those were all moved to the WordPress blog. Most had a new page, but the category itself did not so I added this the .htaccess in root:

    Redirect 301 /wiki/Category:Wiki /
    Redirect 301 /wiki/Encyclopedia:About /about/
    Redirect 301 /wiki/Encyclopedia:Policy /policy/
    RewriteRule ^wiki/Encyclopedia:Copy(.*)$  /copyrights/   [L,R=301]
    RewriteRule ^wiki/Encyclopedia:Terms(.*)$ /terms-of-use/ [L,R=301]
    RewriteRule ^wiki/Encyclopedia:(.*)isclaimer /disclaimer/ [L,R=301]
    

    That’s all incredibly straightforward for .htaccess rules. The first three are one-to-one direct links and the last three are with variables to handle URL strings like “Terms_Of_Use” and “Terms_of_use”, both of which were Wiki-forwarded to the correct “Terms of Use.” Similarly, I wanted to redirect “General_Disclaimer” and “Disclaimer” to one page, simplifying things.

    This pattern of one-to-ones continued on through my .htaccess. Pages that I could link like that I did. But then I hit on a couple big sections, the Interviews and News Articles. Those I had, for years, broken apart into pages by year. So I cleverly used tricks remembered from changing my WordPress date permalinks to do this:

    Redirect 301 /wiki/Interviews /library/transcript/
    RewriteRule ^wiki/Interviews_\((.*)\)$ /library/transcript/$1 [L,R=301]
    RedirectMatch 301 /wiki/(News|News_Articles) /library/news/
    RewriteRule ^wiki/News_Articles_\((.*)\)$ /library/news/$1 [L,R=301]
    

    The main URLs were directed to the new main locations, but the per-year ones were sent, logically, to their new year locations. But that was the easy part. When I moved things over, I got rid of ‘character’ pages (which I had only sporadically updated anyway) and I wanted to combine a lot of the redundant pages:

    RedirectMatch 301 /wiki/(The_West_Wing|West_Wing|west_wing|ww|Jed_Bartlett) /library/show/west-wing/
    RewriteRule ^wiki/The_West_Wing_\((.*)\)$ /library/show/west-wing-episodes/ [L,R=301]
    

    That’s starting to look a lot better. I did a lot of those. I tried to make them as dynamic as possible, but there were limits. In the end, I had about a dozen popular links I had to do manually. I don’t like that, but that’s the world I got myself into. I wanted to be able to redirect news and interviews to at the very least their year page, but as it turned out, I used the same naming conventions.

    Redirect 301 /wiki/Yahoo_News_(01_January_2000) /library/news/2000/yahoo-1/
    Redirect 301 /wiki/EOnline_(01_January_2011) /library/transcripts/2011/eonline-1/
    

    See the problem? There’s no way to really point those around. I played with a lot of options before I ran a search my recent traffic to see what pages were popular that people were going to in the /wiki/ folder and redirected them as best I could.

    Finally I had my fall back:

    RewriteRule ^wiki/(.*)$ /where-has-the-wiki-gone/ [L,R=301]
    

    This is the last rule. If anything gets through the others and down to this one, it sends them to a new page that explains where the wiki went and links to the popular pages.

    The most important thing to remember in all this is to put things in order. Your .htaccess is a top-down file. It starts at the top, it processes rules in order, until it’s done.

  • Quick Notes on Ruby and Jekyll

    Quick Notes on Ruby and Jekyll

    I feel like I should be writing about Once Upon A Time at this point…

    Let’s take a moment to talk about our stack here.

    • Ruby is a dynamic, reflective, object-oriented, general-purpose programming language.
    • Ruby libraries are bundled into gems.
    • Jekyll is a gem that can publish static websites.
    • Bundler lets you list all your dependencies required for the project you’re working on.
    • A Gemfile is a file in which we can list gems for the aforementioned dependencies.

    Still with me?

    This matters because you can use a Gemfile to define your standard libraries for a Jekyll site. The general idea is that you install Bundler:

    $ gem install bundler

    Then you make a Gemfile in your Jekyll folder:

    source 'https://rubygems.org'
    
    gem 'jekyll', '>= 3.0.0.pre.beta9'
    gem 'jekyll-oembed', :require => 'jekyll_oembed'
    gem 'jekyll-last-modified-at', :require => 'jekyll-last-modified-at'
    

    What this does is it defines what version of Jekyll I want to use and some of the gems I want to use. For example, if I wanted to add Jekyll Compose to all the users of my Git repository, I would add this:

    group :jekyll_plugins do
      gem 'jekyll_compose'
    end
    

    Now all they have to do is run bundle after their git pull, and they get the new requirement.

  • Mailbag: But You Can’t Post Mobile!

    Mailbag: But You Can’t Post Mobile!

    This has been marked as the biggest downside to using Jekyll. Once I started telling people I was moving the Wiki to Jekyll, a great many of them were cautionary about this issue.

    How do you post from your phone or iPad?

    The answer is that I don’t.

    I won’t lie. Mobile posting is a pain. Since I don’t have Jekyll running on my server, I can’t edit a file there and regenerate. If I had that it would all be a lot easy. In my case, since I’m using it as a non-blog it’s never the place I need to post mission critical things. Besides, if you’ve ever tried to keep your pretty formatted WordPress site updated when you want a custom crafted excerpt and a featured image, from your iPad, I gotta tell you … it sucks.

    And that’s WordPress, something that has a dedicated, usable, app for iOS. WordPress is also pretty okay in mobile. People like Ryan Boren spends a great deal of time caring about mobile usage. WordPress has gotten slower on the admin side in the last decade, but it’s gotten more responsive and agile at the same time.

    MediaWiki not so much. Editing should be a lot easier, seeing as there’s no ‘admin’ back end to mess with things, but for whatever reason MediaWiki was always terrible on my iPad. It was next to unusable on my iPhone. Even with their default themes (remember, with MediaWiki you see the front end theme on page edits) it was dodgy.

    Furthermore, what did I need to post? This is a wiki-type documentation site. It is rarely, if ever, updated on the fly. It houses long form news articles. There are recaps of TV episodes, explanations of humanitarian events, and reports of events. There is no live blogging. There is no quick off the cuff journaling. It’s storytelling.

    So here’s my ‘mobile’ workflow.

    1. Write the content in something, probably Byword
    2. Email it to myself
    3. Probably rewrite the whole thing in longer form, with design and fancy things
    4. Post

    I could probably streamline that better if I saved from Byword to Dropbox and had that automatically copy over (suggestions welcome), but I don’t really write from my iPad that much. I usually send myself an email with six or seven links and a note to ‘Import these things…’