Half-Elf on Tech

Thoughts From a Professional Lesbian

Author: Ipstenu (Mika Epstein)

  • Deploying with Hugo

    Deploying with Hugo

    One of my headaches with Jeykll was the deployment. It wasn’t until I found Octopress that I had any success. Hugo wants you to use Wrecker for automated deployment. I don’t want to since I don’t host on GitHub.

    Deploying (v1)

    The first method I could use is a script like I have with Octopress, which runs an rsync, but instead I went with a git post-update hook:

    GIT_REPO=$HOME/repositories/my-repo.git
    TMP_GIT_CLONE=$HOME/tmp/my-repo
    PUBLIC_WWW=$HOME/public_html/
    
    git clone $GIT_REPO $TMP_GIT_CLONE
    rm -rf $PUBLIC_WWW/*
    cp -r $TMP_GIT_CLONE/public/* $PUBLIC_WWW
    rm -Rf $TMP_GIT_CLONE
    exit
    

    And that copies things over nice and fast. I could do this for Jekyll as well, since now I’m version controlling my site content (in public) as well as my source code. There are downsides to this. I don’t want to sync my site folder. It’s going to get very large and messy and annoying.

    The workaround for Jekyll people is to install on the server and that didn’t work for me.

    Install on the Server

    But Wait! There’s More!

    I actually like Hugo better than Jekyll,. It feels slicker and faster and more … app like. Also since it’s not Ruby, I was able to install it properly on my server. Yes, unlike Ruby which was a crime, GoLang was incredibly easy to install on CentOS 6.

    First install Go and it’s dependancies:

    $ yum install golang
    $ yum install hg
    

    Now install Hugo. No you can’t yum it up:

    $ export GOPATH=/usr/local/go
    $ go get -v github.com/spf13/hugo
    

    This puts it in /usr/local/go/bin/hugo and I can run Hugo commands natively.

    Which brings me to …

    Deployment (v2)

    Change the aforementioned script to this:

    GIT_REPO=$HOME/repositories/my-repo.git
    TMP_GIT_CLONE=$HOME/tmp/my-repo
    PUBLIC_WWW=$HOME/public_html/
    
    git clone $GIT_REPO $TMP_GIT_CLONE
    /usr/local/go/bin/hugo -s $TMP_GIT_CLONE -d $PUBLIC_WWW 
    rm -Rf $TMP_GIT_CLONE
    exit
    

    Works perfectly. Unlike Ruby which is just a brat.

    Now the Magic

    When I’m ready to write a new post, I can locally spin up my hugo site with hugo server, write my post, make sure it looks nice, and then commit my changes to git and push.

    cd ~/Development/my-repos/hugo-site/
    hugo new content/some-file.md
    vi content/some-file.md
    git add content/some-file.md
    git commit -m "revised some-file"
    git push deploy master
    

    And it all works.

    Massive hattip to Andrew Codispiti for detailing his work which made mine easier.

  • Hugo

    Hugo

    I’ve been playing with Jekyll a lot. After WordCamp US, I started toying with the idea of a JSON powered Jekyll site, where WordPress output its posts as JSON and Jekyll pulled in the posts and converted them. This ran into many snags. It wouldn’t be ‘dynamic’ for one, but the biggest issue is that Jekyll’s JSON reading ability was terrible. It didn’t like the complex JSON that WordPress put out.

    That sent me hunting down other things like Hugo. Unlike Jekyll and it’s use of Liquid, Hugo uses Go (hence the Go in the name you see).

    Installation (on a Mac) is easy.

    brew install hugo

    Done. It’s harder on my server, but still easier than Jekyll, which started to become a ‘thing’ as I worked through all this.

    Using Hugo is remarkably similar to Jekyll except that it works faster and a little more smoothly. The site builds incredibly fast and it dynamically refreshes. So if I edit a post, the page refreshes itself. This let me tweak my theme and posts and sort out the new language incredibly fast. Edit a file, boom, I see what’s wrong.

    It’s about as logical as Jekyll too, so it took me one DayQuil addled afternoon to sort out how to make things work.

    The Basics

    The basic are simple. You have a basic structure like this:

    ▸ archetypes/ 
    ▸ content/
    ▸ data/
    ▸ layouts/
    ▸ static/
    ▸ themes/
    config.toml

    The config file is what you think it is. Your posts go in content and the html-ized version shows up a public folder that gets created on the fly. The data folder is for your static data like a .json file or a .yaml.

    Independant to your theme, you can put css and js in the static folder, and layouts in the layout folder. Ditto archetypes, which are post-types. So if you know you’re always going to have a post type of ‘musician’ and you want it to have special headers, then you can have an archetype called musician.md with all that pre-filled in. Then when you want to make a new entry for Clifford:

    $ hugo new musician/clifford.md

    You can also have those in your theme if you wanted, but generally I use the same theme and separate projects. At this point, I was impressed enough to be swayed from Jekyll. I’m not going to explain how to write a post, since it’s just markdown and a header, just like Jekyll or GitHub Pages.

    Building Your Site

    The commands are basic. Running $ hugo server will build your demo server. Of course, you’ll want to post your drafts, so you need to add the param --buildDrafts … Oh and you want a theme …

    $ hugo server --theme=utility-pro --buildDrafts

    That’s silly, right? Why do I have to define all that? Thankfully I can edit my config.toml file:

    baseurl = "http://example.com/videos"
    languageCode = "en-us"
    title = "My Super cool Video Library"
    theme = "utility-pro"
    buildDrafts = "true"
    [params]
    Subtitle = "Videos about cats, collected from the internet."
    

    Now every time I run the command ‘hugo’ it will build my drafts with my theme!

    $ hugo
    45 of 45 drafts rendered
    0 future content
    45 pages created
    42 paginator pages created
    14 tags created
    3 categories created
    in 254 ms

    That’s incredible fast seeing as it built everything. Of course the other site I have is a great many more pages.

    Theming

    Since I’d already mastered Jekyll theming, this was trivial. Go and Liquid are weirdly similar and most of it was transposing. There’s not much to say here except that there’s a Twenty Fourteen Theme for Hugo and it’s pretty much what you expect. For WordPressers, it’s a good place to start.

    Shortcodes

    The neat thing is that Hugo has shortcodes! They’re not like WordPress ones, but you can see the similarity between WordPress and Hugo.

    [video mp4="video.mp4" flv="video.flv"]

    vs.

    {{< video mp4="video.mp4" flv="video.flv" >}}

    Sadly there’s no oEmbed. And I had to write the shortcode on my own, but again, if you know the basics of logic all this stuff is easy. Here’s the magic behind the shortcode:

    <video class="video-js" width="{{ if .Get "width" }}{{ .Get "width" }}{{ else }}640{{ end }}" height="{{ if .Get "height" }}{{ .Get "height" }}{{ else }}385{{ end }}" controls>
    
    	{{ if .Get "mp4"  }}<source src="{{ .Get "mp4" }}" type="video/mp4">{{ end }}
    	{{ if .Get "ogg"  }}<source src="{{ .Get "ogg" }}" type="video/ogg">{{ end }}
    	{{ if .Get "webm" }}<source src="{{ .Get "webm" }}" type="video/webm">{{ end }}
    
    Your browser does not support the video tag.
    </video>
    

    Once you look at it, it’s remarkably like WordPress. Only I don’t need a plugin. Everything in /layouts/shortcodes/ are like mu-plugins.

    And So?

    And so Hugo won enough of my attention that I’m going to keep playing with it and see what’s next.

  • Mailbag: Why did you ask that at the Town Hall?

    Mailbag: Why did you ask that at the Town Hall?

    Last weekend, at WordCamp US, I asked a question at the town hall.

    At its heart, the question was that did Matt feel the rapid release cycle of WordPress major revisions was too fast? I asked this based on the concerns I hear voiced by plugin developers, generally the smaller shops (single person or under ten teams), who not only have to test their plugins with the new versions of WordPress, but also learn these new, rapidly evolving and changing, libraries like ReactJS and the REST API.

    Matt’s answer was essentially no, and that he felt that things would only get faster. Also he said he didn’t think plugins should be one-person shops.

    What did you think of the answer?

    I was asked variants of this by many people that night and the next day.

    I disagree with Matt somewhat.

    This isn’t a shock. I’m sure he’ll read this and nod. But he and I both know that a health disagreement can be good for an ecosystem. I understand his point, and in many ways agree with it. A team project for plugins and really any development is what makes things improve faster. Two heads are better than one.

    But at the same time, we look back on things like Yoast SEO, and to think that those can only exist while supported by a team is to forget the way that all of this, even WordPress, started.

    One person has an idea. One person shares the idea. A second person makes a suggestion.

    One person.

    Of the 45,000 plugins in the repository, the majority happened because of one person. One person had an idea and a dream and built a plugin. One person learned a thing and shared it. One. And the harder we make it for that one person to grow, the harder it will be for them to become the next Yoast, or Woo, or Jetpack.

    As of this post, we released four major releases of WordPress within 355 days. I think that speed for the sake of speed is as bad as dragging out feet and having one release a year. Yes, we have improved our stability by having more frequent releases, because we don’t rush to have an unready feature added to a release. There’s going to be another soon. And that’s a good thing.

    At the same time, it’s pushed us to release faster and faster, and that causes the bar to be set too high to new people. It causes burnt out. It causes update fatigue.

    I don’t think we should revert to ‘release when it’s ready’ again. That has as many problems (if not more) as ‘release X times per year.’ I do feel we need to consider the emotional health and the supportability of what we are releasing.

    Do it well, do it fast, do it cheap. Pick two. And know that the price is from our blood and bone.

    I think we should turn it down a notch. Just one notch. And we should stop releasing just to be sure we release a number of times a year.

  • Beginning to Understand JSON

    Beginning to Understand JSON

    Themes without php …

    Dynamic content without page requests …

    What about Multisite without Multisite?

    These are all things I’ve heard when people talk about the JSON REST API and how it’s the next greatest thing in WordPress. Well great, but what is it?

    REST stands for representational state transfer. It’s actually the juice that’s been powering the web since forever. RESTful systems generally run over HTTP (hypertext transfer protocol) and use the agreed upon language to get and put data. REST gives you a way to read and write data programmatically. You’ve been using it for years without even realizing it.

    This means our question isn’t what is it, but why do we want it or care about it?

    The WordPress REST API is a nice way to get at the data from WordPress without having to load all the heavy parts of WordPress. It’s useful for things like mobile apps, which don’t need to load everything, just the data, and it’s faster.

    Now, yes, WordPress has an API, called XML-RPC, and it sucks. You’ve used it already if you use the iOS app. We also have APIs like RSS, but that’s pretty much read only. The reasons that the current implementation of XML-RPC sucks are myriad, but basically it’s due to security, abuse, sanitization, and weight. It’s powerful but expensive and risky.

    The JSON API being added to WordPress aims to simplify and secure all that.

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

    The WP API is very simply the interface to make it easier to get at your data. That’s it. How it does it is incredibly complicated. What it does is simple.

    Make it easier to get at my data without loading WordPress itself.

    What I dig the most about it is this idea.

    Take a website running backbone js that calls the JSON API from your WordPress site. Say frontend.com and backend.com are your URLs. You blog on backend.com and use WordPress normally. Your readers will visit a non WordPress site on frontend.com….

    Go on then. Hack the front end.

    It’s not WordPress, so unless you introduce an endpoint that puts you at risk, you have a way to protect your content. Plus now you can upgrade your blog all you want without having to worry really about taking your blog down.

    Obviously this isn’t perfect. By not using WordPress on the front end you won’t have access to a lot of features from plugins. Like related posts. And then again, maybe you can use related posts. Maybe you can even us Jetpack’s related posts.

    Mind? Blown.

    If everything WordPress can do the JSON API can do, then there’s nothing I can’t do. I can make any site where I run WordPress on the backend and anything I want on the front end. And now I can separate my site data, run by WordPress, and my theme and it’s options. I can dry run theme changes and layouts using my live data. I can tell the JSON API frontend.com site to ignore all posts with a special status, tell testend.com to use them, and draft posts.

    Migrations become easier. Who cares where the backend is, as long as the API frontend.com page can call what it calls.

    WordPress is becoming more and more of an application, and that is why we can all be excite about being at REST.

  • Calypso

    Calypso

    You’ve heard about it. Calypso, the WordPress desktop editor for Macs. I’ve been using it and I’m going to give you a quick rundown on what I like and what I don’t.

    A screenshot of calpyso, used to write this post.

    Like

    First of all, it’s Open Source, which is great to look at. Anyone can poke at it and play with it. It’s also a nice GUI to use. Markdown works out of the box if you have it set up in Jetpack. That’s awesome since I’ve gotten very used to using it thanks to Jekyll.

    It’s very fast as well, which is great. Fast is good. It also saves rather quickly, even when I’m on some shitty wifi. It’s much faster than using the native WordPress editor.

    There have been some bumps in the road, but the development is open to comments and suggestions and steering. Some of the decsions made make sense from every angle except the end users. Users use things in weird ways and, once explained, development seems willing and able to adjust.

    Dislike

    There’s no spell check. This makes me very sad (I’ve been told it’s a feature request). Clicking back and forth between my sites is a little annoying, and I can’t easily hide sites (or reorder them). There aren’t tabs either, which means I can’t write on three or four posts at once. Yes, I totally do that.

    You can’t do Custom Post Types. Yet. This is a deal breaker for one of my sites. Basically I can’t manage my WordPress eCommerce store with this. You also can’t change color schemes. I somewhat wish that it would pick up my user settings and use the profile color from MP6 that I selected there. That way I’d have purple for some posts, green for others, and I’d always easily know where I was.

    On the Fence

    I don’t really like that it forces me to use Jetpack, but at the same time, the REST API isn’t in core yet, so this makes sense. Similarly, I don’t like that it’s Mac only, but I understand why. Unlike ‘traditional’ software development, the people on the WordPress.com project are primarily Mac users. Of course they went to Mac first. Since it’s open source, I’m hoping someone figures out how to Windows it up soon. Making it Unixy shouldn’t be too hard, since Mac is running Unix.

    Back to Jetpack, I would love to see this forked and decoupled from Jetpack, using the REST API instead. Not because I hate Jetpack (quite the opposite) but because I’d like to set my father up with this, and he travels to China where WordPress.com (and Jetpack) are problematic thanks to the Great Firewall.

    All in All, I Like It

    So far, so good. I like Calpyso and it’s no great effort to remember to use it, unlike pretty much every other desktop app for WordPress. And yes, I’ve tried those.

  • The Details of Your Life

    The Details of Your Life

    Becuase it’s my son’s birthday this week, can you please do X faster?

    I get emails like that a lot. It has to do with the nature of my volunteer work. It doesn’t really matter what the actual, technical, request is. Pretend it’s a request to reboot a server.

    I don’t need to know that your partner left you, took your dog and your truck, and so it’s really the worst day in the universe for your site to be down.

    The truth of the matter is I really don’t care. No one in support (dev or tech or any) actually cares about the country song that is your life. This doesn’t mean we don’t emphasize with you and feel sorry that you’re having a crappy day. It means the crappiness of your day doesn’t magically make us be able to do things faster.

    That server reboot? All the sob-story in the world will just not make your server reboot faster. Got a security issue? Ranting about how life is unfair doesn’t get it fixed and reviewed faster.

    We do get it. You’re having a shitty day and this one thing, this item that appears to be at the arbitrary whim of some relative stranger, is holding up your ability to feel better. Except we’re not. We’re following process and procedure for a reason. The world is bigger than just you, and we have to consider all of it when we do a thing.

    If rebooting your server impacts more people than you, say 500 other people, then we can’t just reboot on demand. We have to ensure we won’t break them either. If the security fix isn’t complete, or worse, we find more insecure things, we can’t wave our hands at it. We know what hackers look for and we want people to be safe.

    When you’re having the worst day of your life, when your server is down or your plugin is closed or your account is locked out, stop making it worse. Take a deep breath. Remember that the world is a big place. Ask politely and trust that the people are doing things to the best of their ability and speed and safety for you and everyone else.