Ramblings of General Geekery

Blog Archives in PieCrust

The question has come up a couple times already via email or Twitter, so here’s a quick recipe to write a nice looking archive page for your PieCrust blog.

There are 2 main types of blog archives: monthly archives and yearly archives. We’ll look at them one at a time after the break.

Yearly archives

This is the simplest one. Because PieCrust exposes your posts sorted by year in the blog.years template variable, you just need to loop on that with a for loop. Each object returned in the loop contains the following attributes:

  • posts: the list of posts for that year.
  • name: the name of the year (although you can also use the object itself, which is what we’ll do).

You end up with something like this:

layout: blog
title: Blog Archives
format: none
{% for y in blog.years %}
<h2>{{ y }}</h2>
<ul class="archive-list">
    {% for p in y.posts %}
            <a href="{{ p.url }}">{{ p.title }}</a>
            <time datetime="{{ post.date|atomdate }}">{{ p.timestamp|date('M d') }}</span>
    {% endfor %}
{% endfor %}

Note how we render the date of each post with a custom format using the date filter (here using only the day and month). For more information about the date filter, check out the Twig documentation. Also, to provide a little bit of metadata, we use a time tag along with the atomdate filter, which is a handy shortcut for using the date filter specifically with an XML date format. Of course, you don’t have to keep that same markup – you can reuse the Twig logic but completely change the rest.

Monthly archives

This one is a bit more complicated. Although PieCrust also exposes your posts sorted by month in blog.months, you still need to spot changes in years so you can print a nice title or separator. To do this, we keep a variable curYear up to date with the current post’s year. If the post has a different year than the post before it, we print the new year in an h2 tag.

Each object in the blog.months has the following attributes:

  • posts: the list of posts in that month.
  • timestamp: the timestamp of the month, so you can render it to text with the |date filter.

So to get the year of each month, we use month.timestamp|date("Y"). To print the name of each month we use month.timestamp|date("F").

In the end, it goes something like this:

layout: blog
title: Blog Archives
format: none
{% set curYear = 0 %}
{% for month in blog.months %}
    {% set tempYear = month.timestamp|date("Y") %}
    {% if tempYear != curYear %}
        {% set curYear = tempYear %}
    {% endif %}
    <h3>{{ month.timestamp|date("F") }}</h3>
    {% for post in month.posts %}
            <a href="{{ post.url }}">{{ post.title }}</a>
            <time datetime="{{ post.date|atomdate }}">{{ post.date }}</time>
    {% endfor %}
{% endfor %}

Again, feel free to keep the logic and change the markup to your liking – that’s the whole point of PieCrust!

Data First

I like to think I’m being careful and responsible with my data, especially when I look at what most people do with theirs, so I thought I’d start a new series of posts on the subject.

Hard Disk

Data-first” is about choosing applications, services and devices based, first and foremost, on the data that you will get out of them, or the data they accept as input. It’s important because, at the end of the day, once you’ve quit your apps and turned off your devices, your data is the only thing that’s left, and the only thing from which you’ll start again tomorrow. It’s also the only thing you’ll have when you decide to switch to different applications, different OSes, or different devices.

Who is this for?

Some companies – Apple, Google, Amazon, or Microsoft – want you to trust them with your data. Trust that they will keep it available to you as the technological landscape around us changes. Trust that they will keep it stored for the next 50 years or so. And that they’ll always be there to unlock the files for you. And that they’ll pass it all on to your kids when you die.

If you can trust at least one of them, “data-first” is probably not for you. Instead you’ll choose the path of least resistance where all you have to do is tap a button on your iPad or Kindle Fire, watch that movie or read that book, and forget about it. Did you just rent or purchase? Do you own or merely lease? Does it have DRM? What about maybe switching to another eco-system in the future? Who cares! I applaud your ability to not worry about such things. Be on your way, you blissfully lucky person, I wish you well.

If you’re like me, however, there’s no way you can think that way. Being French means, at best, having a… let’s say: a “healthy” distrust of governments and corporations. Even if I trusted a company right now (which I don’t), I have no guarantee that the next CEO or board of directors are not going to screw their customers over. And this is important when you want to keep consuming your data for a long time. Am I ever going to stop re-watching “Who Framed Roger Rabbit” or “The Shining”? Or stop re-reading any Alan Moore comic? Probably not. And how long is “Game Of Thrones” going to last? Another 6 years, maybe? Remember how things were 6 years ago? Yeah, that was when people were eagerly waiting for the first iPhone to be released, and Netflix was still about mailing DVDs to people.

So no, I will not trust anybody but myself to manage my data for the next 50 years, let alone the next 10.

What is it for?

Keep in mind that the “data-first” approach has nothing to do with services and applications where you’re not supposed to keep any data. This includes iTunes rentals and subscription based services like Spotify or Netflix. I have absolutely no problem with those, which I use extensively.

What it’s for is any data you’ve chosen to purchase (videos, music, books, whatever), or that you have created or shared (emails, IMs, or other social media bullshit). That’s what we’ll be talking about.

Data-first” posts will be tagged with the eponymous tag, so keep an eye on it for case-by-case studies.