Never Read The Comments

As a fun little project I started playing around with Firebase and this Jekyll blog. In a move I hope to not live to regret, I made it possible to submit comments!

Update (December 2016): Retired (aka nuked) the code shown in this tutorial from my blog. As much fun as it was to over-engineering a comments section in Jekyll, it’s time to retire the seldomn used (if ever) comments section. Incidentally, the tutorial led me to learn how to use Google’s reCAPTCHA and Liquid templating which was fun.
Lastly, due to Google’s aquisition of Firebase shortly after this post was published, I was able to painlessly transfer the database from the legacy servers to the shiny new Material Design interface at Firebase Console

Folks who have pertinent and kind comments can scroll to the bottom of a post and enter a name, message, and an optional email for a Gravatar image.

Isn’t that nice?

I used part 3 of an article from CSS-Tricks¹, so if you’re curious, go ahead and follow those directions. The only tricky part was configuring the security rules.

If I get hit with lots of spam, I will need to take corrective steps, but for now the only validation that is done is checking for the presence of a name and a message.

Firebase is really cool, fast and well documented. I am loving the realtime NoSQL cloud database which stores data as familiar JSON objects. For a simple blog it does seem to be a bit overkill, but I just love to over-engineer this lil’ blog to bits.

Got feedback? Leave a comment, bub. Or, you know, just reach out to me on Twitter or email.

Momentum Scrolling FTW!

The mobile experience for this page is responsive via relative sizing, images (such as they are) and media queries, but from Safari on iOS there was a distinct lack of snappiness in scrolling leading to a stagnant feeling. We must bring back the bounce!

‘Inertial’ or momentum scrolling is easily enabled with the CSS property -webkit-overflow-scrolling.¹

Thanks to an article from CSS Tricks², this was a simple matter of adding two lines to the body selector.

  overflow-y: scroll; /* has to be scroll, not auto */
  -webkit-overflow-scrolling: touch;

Page scrolling from mobile, that is to say, from iOS WebKit, now has the familiar bounciness. Cross-browser behavior at least from the point of view of device mode in Chrome Dev Tools seems to be looking A-OK as well.

Mongo Bongo

I really love the paradigm shift that happens when you start using new tools, and recently this happened to me with MongoDB. Here are a couple of gotchas that I wanted to document for my future self.

From the incredibly rich and highly helpful documentation pages, “MongoDB is an open-source document database that provides high performance, high availability, and automatic scaling.”¹

MongoDB is a noSQL database, which means it is schema-less. This means no need for migrations. Incredible, I know. Records in MongoDB consist of documents in a BSON object format which are functionally identical to the JSON objects that we all know and love.

I happened to use MongoDB in conjunction with a recent Rails project via the Ruby gem, Mongoid. Mongoid is “an ODM (Object-Document-Mapper) framework for MongoDB in Ruby,”² and it is also very well documented.³

Cool things that you can do with MongoDB include querying the database in JavaScript, nested attributes and whole slew of other nice things.

It is obviously not the right choice for every project, and I don’t think anyone is really claiming it to be, but what it does, it does extremely well. It is performant and scalable, did I mention it is well documented? That being said, there were a couple of subtleties that I noticed.

Gotcha #1

Anytime you drop the database and you had a document’s field indexed, then that index would have to be created again before seeding. (A document field is like a SQL table column.)

You would simply have to include this command in your workflow:

$ rake db:mongoid:create_indexes

Gotcha #2

MongoDB and by extension Mongoid uses the _id field as the analogue to the more familiar id in SQL tables. The _id field consists an ObjectId⁴ hexadecimal that increments sequentially, but not one by one as we are used to with ordinary id attribute integers.

For example, a typical newly-created object on a new database could have the _id field of:

_id: {
  $oid: "56d3320efc3868284b000000"
}

This was confusing, but after a while I started getting used to my URLs having a hexadecimal :id params.

If you really, really need the id field automatically generated alongside the existing _id field, (and this is quite conceivable since most programs expect there to be an id field or column in a database), I used a workaround to insert them.

In Rails config/initializers folder, create a file called mongoid.rb:

module Mongoid
  module Document
    def as_json(options={})
      attrs = super(options)
      attrs["id"] = attrs["_id"].to_s
      attrs
    end
  end
end

This adds an additional field called id with the same hexadecimal value of _id to each new Mongoid document.

There are plenty of other avenues to explore with regard to MongoDB, and the above barely scratches the surface. These were just a couple of the issues that were new to me when I started exploring the exciting world of noSQL databases.