ruby
The search plugin that I’m writing for Jekyll with bloom filters is coming along swimmingly. I still haven’t thought of a convenient way of using it with Github pages since Github runs all Jekyll-powered sites with the safe: true configuration option, but I’ll cross that bridge when I come to it. In the meantime, I’m generating one bloom filter per blog post and putting all the filters into a /search.json page that will be filled up by my plugin.
I spent a few days working on this site, moving a few items around and changing the content of the index page and the sidebar. It’s still not quite where I’d like it to be, but I’m happy with it for now. Next up will be add a few more of my github repos to the sidebar, and hosting those repos on heroku instances. My dedicated EC2 instance which used to host this site and several node.
A heredoc (short for “here document”) is defined as follows on Wikipedia:
In computer science, a here document (here-document, heredoc, hereis, here-string or here-script) is a file literal or input stream literal: it is a section of a source code file that is treated as if it were a separate file. The term is also used for a form of multiline string literals that use similar syntax, preserving line breaks and other whitespace (including indentation) in the text.
As promised in my previous post, I spent some time today understanding Bloom filters. While [the wiki page]((http://en.wikipedia.org/wiki/Bloom_filter) intimidated me a bit when I first looked at it, it’s actually pretty simple once you sit down and patiently read through the whole thing.
Bloom filters are a lot like hash maps, except that they save a lot on the space occupied for maintaining an index of your data at the cost of a minor chance of false positives.