Half-Elf on Tech

Thoughts From a Professional Lesbian

Category: How It Is

Making philosophy about the why behind technical things.

  • 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…’

  • Jekyll Layouts vs Wiki Templates

    Jekyll Layouts vs Wiki Templates

    One of the things I was doing in Mediawiki was using a lot of templates. A lot. The way a template works in Mediawiki, you have a special page called Template:NAME and you can embed it with {{NAME}} in any post. You can even embed a template in a template. They’re basically static ‘blurbs.’ You can make them dynamic, but I have found that even after ten years of using Mediawiki, it’s still a bit of a mystery.

    With Jekyll, that gets thrown out the window.

    Let’s take, for example, my list of interviews. I have 14 or so years of interviews, broken up into a separate page by year and internally sorted by date. Manually. I also have a template {{Interviews}} which outputs a pretty formatted link to each year. Also made manually. For every new interview, I edited at least two pages (the interview itself and the year). And for every year I had to update the main interviews page and the template.

    My end goal was to do the following:

    1. Each year index would dynamically list the posts for that year
    2. The interview main page would list links to all the available years
    3. The interview ‘template’ would be output on every page
    4. The interview year page would list everything from that year
    5. All those things would dynamically update when I added a new item

    Oh and I also wanted a layout to be intelligent enough to show a special header with specific information on the individual interview pages.

    Love Collections

    To convert this, I first made use of collections, making one for _interviews and within that I have a folder for each year with the interview as a flat file and an index.md to make the main index. I don’t have to do this. I could have the index anywhere I wanted, but this was easier for me.

    There is a big gotcha here, though. Subfolders and collections and sorting by date doesn’t work the way you’d think it would. I could make it easily sort by title, and I could reverse it, but sorting by date proved to be a killer. Eventually I figured this out:

    1. All the pages have to have a date, even if you’re not going to sort that page (see my index)
    2. You can’t sort in a for loop

    The final code looks like this:

    {% assign posts = site.interviews | sort: 'date' %}
    <ul>
    	{% for post in posts %}
    		{% if post.topic != 'index' and post.tags contains page.year %}
    			<li><a href="{{ site.baseurl }}{{ post.url }}">{{ post.title }} ({{ post.date | date: "%d %B" }})</a></li>
    		{% endif %}
    	{% endfor %}
    </ul>
    

    Front Matters

    This is funnier if you know that the ‘header’ of a Jekyll file is called the Font matter. Here’s an example of mine:

    ---
    title: Interviews
    author: Mika E.
    layout: interview
    permalink: /interviews/
    date: 2001-01-01
    topic: index
    tags:
      - 2001
    ---
    

    Everything except topic: index is a default variable. I made the topic, and what that does is tell me “This page is an index page” and what year things are. There are reasons for this down the line. Now I also want to sort by year, but I can parse the date for that.

    Design the Layout

    I designated my layout as ‘interview’ in the first example, so I made a file called interview.html in layouts and made it a child of my default layout. In there, I have this code:

    <ul>
    {% for post in site.interviews %}
    	{% if post.topic == 'index' %}
    		<li><a href="{{ site.baseurl }}{{ post.url }}">{{ post.date | date: "%Y" }}</a></li>
    	{% endif %}
    {% endfor %}
    </ul>
    

    That says “if a page is an index, list it.” Now when I want a new year, I just add in a new folder with an index file.

    I’ve gone even further, taking the logic from some WordPress themes I’ve see, and the layout file has all the code for both the index view and the per-item view, allowing me to format my interviews with custom headers and footers around the content.

    Does it Work?

    Yes it does! Mostly.

    The problem with this, and yes there’s a problem, is that the interview layout page doesn’t regenerate itself. I have to go and re-save the layout for interviews in order to regenerate any lists I have on that page.

    I can get away with typing this in shell: touch _content/_jekyll/layouts/interview.html && jekyll build but it is a little annoying. Even running a manual jekyll build won’t do it because the layout doesn’t realize it has a change yet. I do understand why, though. It may be worth moving that somewhere else, though I have a feeling even if I make it a template it would have the same problem, since that template file wouldn’t know to update until it was edited.

    It took me a while to find the magic sauce is a bit of code called regenerate: true – This is not something you should use everywhere! I use it on my interviews index pages because those pages get updated when a new item is added to their folder. It actually lets my index pages be totally blank except the yaml headers which is nice and simple.

  • Mailbag: Why Jekyll?

    Mailbag: Why Jekyll?

    Why didn’t you convert your site to WordPress? You said you had to import it from Mediawiki to WordPress already.

    I had this conversation with my wife, too.

    WordPress is awesome at being a dynamic website. To be a static ‘wiki’ style website, it sucks. It’s not meant to be static like that. It’s not intended to be static. Even if you turn off comments on your site, you mean for WordPress to generate index pages and categories and the like.

    With WordPress, all that work is done on the server. When you visit a page, it’s generated for the first time. I may have a cache that lets reader number 2 see that page, but always the page, the HTML, is being dynamically built on-demand. MediaWiki works the same way. In contrast, Jekyll is dynamically built on my laptop and deployed as an in-situ static site. Each HTML page is a real HTML page on the server. No extra work has to happen. It’s small, it’s light, and it’s fast, because all that processing was done by me on my laptop before putting it on the server.

    And that actually illustrates the problem with WordPress, and why we struggle with things like Varnish and nginx and caching. We want our sites to do more and be faster. We need flexibility and posting to Twitter and dynamic page generation when we make an edit, because we’re constantly making changes.

    Except I didn’t. I don’t. Not the particular site I was working on, anyway. The site has about 1000 pages (probably closer to 600 once I decided not to import some of the things) and they’re pretty static. At most I updated them once a week for half the year. WordPress would be overkill. Hell, the Wiki was overkill and the only reason I kept using it was technological debt. I didn’t want to add to the debt. I didn’t want to make things even weirder and harder to use. I didn’t want to put a site more at risk with software I didn’t want to upkeep (MediaWiki, not WordPress).

    So it was clearly time to dig myself out with a little sweat equity and decide what I really wanted. I made a list of what I needed, what I wanted, and what I could live without. When I did that, Jekyll started looking more and more like a viable option. I would have spent as much time removing the aspects of WordPress I don’t need as I would have learning a new theme system and language.

    Also in the end I didn’t use the WordPress import. I manually copy/pasted content. The content was what I wanted, and I needed it text only, and MediaWiki made that damn hard to get at. Of course the Jekyll exporter for WordPress was pretty freaking cool. If I was pure WordPress to Jekyll, I’d be fine. I guess there just aren’t a lot of people doing MediaWiki exports.

  • Jekyll Collections

    Jekyll Collections

    Early on, Jekyll’s developers said that if someone was using posts for non-blog content, they were doing something wrong. That left one other avenue open, the first time I looked at Jekyll, which was pages. They’re nice, but they’re not what I wanted.

    Enter Jekyll collections. These are ‘arbitrary’ groups of related content which you put in their own folder. I had 15 years of interviews collected, so for me this seemed like a perfect idea. I read up on Ben Balter’s – Explain Jekyll Collections like I’m 5 and it helped me sort out what I wanted.

    Configure

    This is easy. You just add the collection code to _config.yaml

    # Collections
    collections:
      interviews:
        output: true
    

    Having the output set to true means that when I run jekyll build the pages are generated. That’s pretty simple. They don’t get auto-generated when you run a jekyll serve and you’re testing locally, however. Which sucks. I upgraded to Jekyll 3.0 beta and it started working, though, and I’m okay with running a beta.

    Create A Folder

    Also easy. Make a folder called _interviews in the main Jekyll folder. I will note, this gave me a fit. I wish I could put all my collections in a subfolder, because now I have this:

    _data
    _includes
    _interviews
    _layouts
    _pages
    _posts
    _sass
    _site
    

    It’s messy, and if I didn’t know that some of those folders are special (like _includes) I could easily be confused. The _site folder makes some sense, that’s where my site is output. But even if I use the source setting to move all my source pages into a folder (called _source in my case), I still can’t separate the code from the content. What I would like is this:

    _assets – Store all of my ‘code’ like layouts, plugins, css, etc here.
    _content – Store all my post content, collections, pages, etc here.

    Still this is a little better for me. Less insane. I will note, I was able to move my folders by defining the directories in my configuration file like this:

    # Moving Folders
    source:       _content
    plugins_dir:  _jekyll/plugins
    layouts_dir:  _jekyll/layouts
    includes_dir: _jekyll/includes
    

    So now my main folder has two folders _site and _content which is a lot easier for me to work with. I feel less muddled. Inside the content folder is a _jekyll folder which is my ‘wp-content’ folder, and a _data folder, which has some data files. More on that later.

    NB: This only works on Jekyll 3.0 and up!

    Create Files

    All I had to do was make my files in my _interviews folder and I was done. Well. Not really. I needed a way for Jekyll to link through everything, and I really didn’t think making manual pages was smart. I tossed in this code to my interviews post file and it cleverly looped through everything it found, generating the page on the fly:

    <ul>
    {% for topic in site.interviews %}
    	<li><a href="{{ site.baseurl }}{{ topic.url }}">{{ topic.title }}</a></li>
    {% endfor %}
    </ul>
    

    If you’re familiar with WordPress loops, this is the same thing as saying “For all posts in a category…”

    Customize the Hell Out of It

    Of course you know that’s what I did next. I went and made it super-complex by putting my interviews in year subfolders and then making the main interview page a list of all the years, with links to those pages, and loops back and … well. That’s another post.

  • Mailbag: Delete My Account, Please

    Mailbag: Delete My Account, Please

    Becuase I’m active in the support forums, people find me and ask all sorts of questions. Like Charlie.

    I want to totally delete my word press account. I will PAY you to do this. Why? Because I worked for 15 minutes on the original word press website but found it too difficult for me and chose to go with a super easy Wix.com website, which is now published and works well. In searches I come up under wordpress only and my deleted wordpress website is still there. I want people to be able to find my wix site. I hope there is a way to TOTALLY delete my word press account. I will PAY you to do it.

    Sorry, Charlie, no can do. I checked his email and his domain that he put in his email and it was on WordPress.com so I sent him the link on .com for How to delete your site.

    I will note, I am sorry he wants to use Wix.com, but on some levels it is far simpler than WordPress (yes, I said it). It’s drag, drop, and done, and looks great on desktops. Mobile? That’s another story. But I had a paint-by-numbers GeoCities account back in the day, so I really don’t have room to talk about ugly first websites.

    The story doesn’t end here. Charlie asked me to do it for him.

    Even if he was a customer at my company, I would tell him no. I would send him directions on how to do it but I would not delete it for him. I don’t delete customer’s sites or data (unless the data is a Terms violation). Hell, even with hacked content, I back it up elsewhere first. Deleting someone’s data is an absolute, 100%, last resort. You should never ever do it. There’s no going back.

    Then Charlie asked me again.

    I suspect his issue was that he was really frustrated and wanted everything to die in a fire. Which I totally understand, but amidst all your anger, you need to take a deep breath and follow the directions. And, when someone tells you “I don’t work for that company, but I found out how to do it. Here you go!” perhaps you can say “Thank you.”

    Just a thought.

  • An Ad Network You Can’t Use

    An Ad Network You Can’t Use

    Amidst the kerfluffle of Peace being pulled from the App Store after a couple days, there was a mention of how it also blocked the Deck Network ads.

    Most people in tech have seen Deck ads, but few outside the ‘hard core’ geeks know of it, and it’s for good reason. It’s an invite only ad system that makes ads that don’t slow your site down.

    Manually curating ads, they restrict users to show one and only one ad on the site, perhaps not on all pages of a site, but just the one ad.

    In essence, buying a month on The Deck gives you an exclusive showing on three percent of all the pages viewed for that month across all fifty-two sites and services. And there won’t be Google or other third-party ads diluting your exposure. The Deck ad is the only ad on the page.

    It’s a phenomenal amount of work. And that would be why only fifty-odd sites are in. Peace happens to be on that network. But let’s put aside the whole ethics and morality of ad-blocking for a day.

    The idea behind the Deck Network is everything I want an ad network to be. They pride themselves of relevancy to their network and only show ads relevant to the network. They only show ads they’re okay with seeing. As mentioned before, it’s an incredible amount of work, but it’s exactly what you’d want to see in an ad network. Ads that people would rather be relevant than, nessecarily, make money.

    That’s really kind of the same reason as my I like Project Wonderful so much. With Project Wonderful, though, the quality of the ads is a little crowd sourced. If enough of us report an ad, it will likely get pulled but it will always be reviewed. With The Deck, it’s the other way. Nothing gets in that isn’t vetted first.

    The amount of work that goes into that is exactly why, every time anyone says “I’ll pay you to put my ad on your site” I say “No thanks.” The whole mess of running my own ads, having them expire and rotate and change, is a hassle I don’t want to mess with. I don’t want to spend my time running ads, and I’m a one-woman-show here, folks.

    The balance between making money and having relevant ads is tricky. I think, for the tech world, The Deck gets it right. But I doubt any of us will ever be on it.