davidcelis

I didn't know that massive amounts of death and/or rape threats didn't count as hate crime. Thanks for the enlightenment.

At least it's responsive.

> Optimization is a rabbithole I’ve not had to go down very often. I am hardly an expert.

But really, the answer to this is because it's easy to copy a database in Redis and then just do a mass RENAME. It took all of two minutes with a Ruby script and Redis' RENAME command. I could have done a theoretical back-of-a-napkin attempt, but I wanted some real numbers. And if it's easy to get them, why not?

To be honest, when I first wrote my site (and, later, recommendable) it was for my senior project in school. I had only been programming in school so far (which was fairly different from programming in the real world) and this site was really my first real-world application. Back then I was using MySQL (!) as my main data store. I was storing Likes/Dislikes as polymorphic Rails models, but then I read about Redis and it sounded like the perfect fit for all the set math I would have to do. So when refreshing recommendations, I would pull the ratings out of MySQL and feed them into Redis to do some fast set math. Then I'd tear down the Redis sets. I only had friends on the site testing it out for me, so I didn't notice much of a problem.

Later, I switched my database to PostgreSQL but wasn't having Redis issues at that point, so I let it be. Then when goodbre.ws found itself with a lot of new faces, I found myself with the I/O bottleneck I mentioned in the article. I decided to try to solve that by moving the ratings to permanently reside in Redis. That way I'd only have to hit Redis a couple times to regenerate someone's recommendations. Then I started storing too much in my ZSETS, but here I am now.

Now that I've reduced that memory footprint again, I feel as though attempting to move the ratings back into Postgres would be a premature optimization in itself. I was, however, looking into some combination of Postgres' array types (to replace the sets) and hstore (to replace the ZSETS, but sort in the query). I think it's worth looking into, but I have some other things to focus on first!

This was one of the frustrating parts of trying to fix my issue. Every search I did for Redis optimization tips said to use hashes to reduce redundant keys (and, in doing so, use a memory efficient data structure). But every key my library uses is a SET or ZSET so, of course, hashes were off the table for me.

> enjoy crystal clear display with Retina support.

I'd enjoy it a lot more if it were true. Still no Retina support for any of their icons or images. Sure, the text finally looks right, but doesn't Cocoa handle that for you?

"If the counter isn’t going up when you check all those boxes, give the page a refresh. It’s finicky."

Mere words cannot express the emotions that reading this made me feel.

This site doesn't work at all in mobile Safari

Your SSL cert comes up as unverifiable on mobile Safari

I had been monitoring that my background workers were, indeed, working... But it seems as there's something else going on here. For some reason people aren't getting recommendations. I'll try to see what's going on.

EDIT: looks like the process had actually silently died at some point, but was still reporting as running. I think I've fixed the issue now.

Looks like my DNS account ran out of funds in the middle of the night. Whoops. Sorry about that guys. It should be good to go now.

That's under `lib/recommendable/acts_as_recommended_to.rb` towards the bottom. It's a combination of the `similarity_with(rater)` and `predict(object)` methods. Additionally, I detail the algorithm here: http://davidcelis.com/blog/2012/02/07/collaborative-filterin...

PJAX, man. Loving it.

I actually thought long and hard about Brewery DB. Their API is just fantastic, IMO. Really clean. Unfortunately, I wrote Recommendable (the Ruby gem that I wrote to power the recommendations) in a way that it really relies on ActiveRecord currently. My database also has considerably more beers than BreweryDB does right now, but yeah. Managing it by myself slowly gets more difficult as more and more suggestions on beers I need to add come my way. I'm working on an admin section for me to manage that more easily.

Yeah if I knew Objective-C I'd code up an iOS app for the site. Once I know for sure the desktop version is stable, I'll at the least be looking into making a more mobile-friendly site.

That last idea is definitely something on my TODO. I give a brief rundown on the /about page, but the tooltips would be useful. The first idea is a good one as well, I'll be looking into how to cleanly implement that. Thank you!

Recommendations start getting generated immediately after you rate a beer. The site is in its infancy, of course, so recommendations may start out rocky but they'll get better as more people (and you) rate more beers. The sad state of the cold start!

How long it takes for the recommendations to refresh is tougher to say, but it shouldn't be more than a few minutes. I can see that the workers that process them are active, so I'm fairly sure it's working.

Yeah, I'll be adding an additional and more obvious link back to the dashboard soon. As far as submitting beers, that's also coming soon. I need to also make it more easily to accept said beers into the database, as I'm the only person working on the site. Managing this database (which has some 60,000 beers currently) is really tough to do alone. Thank you for looking!

Thanks, this is exactly the kind of thing I need to hear. As the person who made the site, I already know how to use it. I'll look into ways to make this all more obvious.

Thanks for looking guys. This site has been a side-project/hobby of mine for a while now. The past few days for me have been spent rewriting it from the ground up to be a much better site. I know that there are other beer sites out there, but I think that there is something special about making a service like this freely available and open source, and I'm really proud of what I've created.

You can check out the code here: https://github.com/davidcelis/goodbre.ws/

The code that powers the recommendations themselves is here: https://github.com/davidcelis/recommendable/

Any feedback would be nice. This new design is in its infancy but, as far as I can tell, it's been very stable. If you find a bug, please, please let me know here or post on the issues tracker.

"I do feel this goes to show why Netflix is taking a continued hit on their stock price and subscriber base, simply put they lack innovation and are not catering to major niches such as Linux Users."

Funny, I thought the stock price taking a dive was because of the Qwikster fiasco. And I thought the falling subscriber base was because of the separation of streaming and DVD plans paired with a lack of good content that is available to be streamed.

It's not hard, though. Anybody can go online and search for an email validating regex, but as some have pointed out, many are too strict and don't allow for, say, tagged email addresses (email+tag@example.com). There's email validation, and there's overkill. That's what I was trying to get at.

Due to a huge failure on my part, I edited the title to more accurately reflect my opinion on this. I did not mean to say that the regex validations themselves are a waste; my point was that the complex regular expressions are often too strict and almost always overkill.

I think saying that I don't "get" UI is being somewhat presumptuous. Good UI on the registration form can go a long way in alleviating the "switching the email address and username fields" problem, but anything more than a check for /@/ (or, if you're feeling ambitious, /.+@.+\..+/) is just overkill. If I enter a valid email address that's just typo'd, the result is the same: the activation email bounces.

Whoops, you're right. That was an article left over that I meant to just replace with a bang. I've fixed that. Thank you!

Yep, this is definitely most often the case. Perhaps I should have reworded that to reflect that I believe anything more than a simple /@/ check to be largely superfluous. I still use the /@/ regex often, which I mention at the end of the article.

Yes, agreed (and I mention this at the end of the article as well) and I still use the /@/ regex often. But a good UI on the registration form can go a long way in alleviating the "switching the email address and username fields" problem.

I did that for a time (which I mention in the article), but it's still a superfluous check on top of an activation email. If your users are typing the wrong values into your registration form, perhaps you need better labeling or placeholder text? Display an error that the activation email couldn't be sent. But why add superfluous checks?

I released this gem late last night and am just excited to share it with people. It's my first own open source project and I'm proud with how the first release has turned out. The logic is based on a website (http://goodbre.ws/) I wrote last year for my thesis project at school, which was to alter existing collaborative filtering algorithms to work using set math. For a while, I have wanted to strip the logic out into a gem for others to use, but I finally buckled down a few days ago and got to work.

Sent an email about this a couple weeks ago, actually, but never heard back. Just followed up, but I was super excited to see this listing.