A couple weeks ago, an internet friend/mutual of mine, Steve Klabnik, published a very timely blog post titled Ten Years of Ru…ewriting my website and, well, I was inspired. His post was timely for me because I was in the middle of rewriting my website too. Now that it’s live, I thought a similar post would be really fitting.
In the world of API architecture, REST has been the reigning ruler for well over a decade. Mobile devices like smartphones and tablets have made it nearly impossible to avoid REST APIs. If you use technology at all, chances are that you use software built on a REST API constantly every day. Maybe you’ve even worked on a REST API or written one yourself! Despite REST’s popularity, however, it has a few glaring flaws.
Note: you’ll never truly be done rewriting your site so, true to fashion, my website is now a Rails app. Also, it’s way easier to put your static site behind something like Cloudflare to get automatic SSL, a CDN with caching, and plenty more. Because of that, I don’t really recommend using this post as a guide; many parts are out of date and some are no longer true. Like other defunct posts, I’ll leave it in my garden, but I’m unlikely to tend to it.
So you’re a squirrel, and winter is coming. It’s time to start gathering nuts for… woah, wait! Come back! Remember last year? Sigh, of course you don’t… You squirrels have great spatial memory for their caches, but not the spots you’ve foraged in. Last year, you did a lot of searching for nuts in places you’d already cleaned out. What a waste of time! Don’t worry, though; I’m here to help! To increase your productivity, we’re going to keep a spatial database of all of your foraging spots.
Note: The Discourse team now provides Docker images that greatly simplify the process of deploying Discourse, so you should just use their official installation guide. I’ll leave this post up for posterity but, unlike my other posts, I’m unlikely to update or maintain it.
Back when I was still working on goodbre.ws (well… rewriting, really), there was one big issue I was dealing with. Really big. Big enough to have taken down the entire site semi-permanently without me having access to more expensive servers. Long story short, my Redis database grew out of control and ballooned to 1.5 GB. The day before publising this for the first time, I reduced that memory usage to a cool 50 MB.
Just stop, y’all. It’s a waste of your time and your effort. Put down your Google search for an email regular expression, take a step back, and breathe.
Here’s a peek at an enhancement for ActiveSupport::Inflector that was introduced in Rails 4.0 and which I’m proud to have contributed. The Inflector is the part of Rails responsible for a good amount of the cool stuff you can do with Strings: pluralization, singularization, titleization, humanization, tableization… The list goes on. Rails uses these methods extensively to map between, say, Model names, Controller names, database table names, and more. Let’s dive into the new stuff!
Ah, the Rails Inflector; one way or another, we all know and love it. This little part of ActiveSupport has a lot of responsibility in our Rails applications, after all! It’s used to determine table names, class names, our resourceful routes, foreign keys… It’s a small part of ActiveSupport, but it has a huge footprint. Outside of Rails’ internal use of the Inflector, it also provides a lot of useful mechanisms for string manipulation to Rails developers. But how does the Inflector actually handle things like singularization and pluralization? English isn’t a regular language, after all!
We’ve talked about some of the pitfalls of the five-star rating system and how a binary system based on likes and dislikes can be much better, but what does using this kind of rating system look like in practice? How can we take a user’s likes and dislikes and use them to generate helpful recommendations? The answer, as with the five-star system, is through collaborative filtering, but we can rely on a methodology better suited to a binary system!
When I was originally developing goodbre.ws (and, later, recommendable), the very first thing I had to decide was how users would rate items. Would I give them a standard five star system? Maybe something with more granularity, like allowing for half stars? Or perhaps the humble thumbs up or down? Truth be told, going with a binary thumbs up or down system of likes and dislikes was an easy choice. After all, I hate the five-star rating system.
