stevegrossi / stevegrossi

The [former] bits and bolts behind stevegrossi.com, a personal zoo for books and ideas.

What is this?

This is the source code for the Ruby on Rails app which powers stevegrossi.com. Its duties include managing the books I've read, posts I've written, which can be optionally be about a book or an external link, plus a handful of informational pages and redirects.

stevegrossi's Issues

Store image assets on S3

With Paperclip (or maybe try out Carrierwave) for uploads. And fronted by CloudFront if you feel like splurging...

Ensure required fields are marked NOT NULL in the database

Nice best-practice, Viget: http://viget.com/extend/adding-a-not-null-column-to-an-existing-table

Though this really applies only to fields that are inherently—not just temporarily or under certain circumstances—required.

Set up some indieweb goodies

Adactio has a nice list. Things like rel="me" links to enable IndieAuth look handy, and I should probably be using the hentry microformat.

Should pagination be reversed?

Chris Coyier makes a good case, the main argument being that if "page 2" corresponds to "the 11th through 20th most recent articles", then what's on page 2 today will be different from what's on page 2 in a month, effectively breaking the URL.

To fix this, "page 1" should correspond to "the first 10 articles ever written" and "page 2" to "the 11th through 20th least recent articles". These never change. But it also means that this month, the homepage (or whichever page doesn't have /page/# in the URL) may be showing effectively page 38 today, and page 39 next month. You won't see that in the URL, but when you click "previous posts" from stevegrossi.com it should take you to stevegrossi.com/page/37 or whichever the previous page is, going back to page 1.

Here's a proposed solution using Kaminari, though it requires—and I don't see any way around this—a floating limit on the number of posts on the most recent page. While this makes sense in theory, it may be a case where the wrong thing (paginated URLs pointing to different content) is such an established convention that the right thing will confuse people.

A compromise would be date-based pagination. You show articles 1-25, and the "previous" button links to the most recent 25 articles with a published_at value of less than article 25's. The content on a given "page" will be stable, at the cost of defined page numbers. Basically, it seems like 3 constraints are in conflict:

1. a given URL should have the same content over time
2. paginated pages should all have the same number of items on them
3. pages have defined numbers

One of these has to give. I'm currently sacrificing number 1, which seems like the most important. Djo's kaminari solution sacrifices number 2, but it seems like if something has to go, number 3 is the one to throw out. Who ever said websites need to behave like books with defined page numbers?

Use `srcset` for responsive images

Or <picture> if they're art-directed. With a JS polyfill for picture. More info: http://blog.cloudfour.com/dont-use-picture-most-of-the-time/