Granted I am over a month late on this, but I had a backlog on my podcasts (I currently have almost 600 unlistened podcasts). In episode #32 of the Rails Envy podcast they gave a shout out to can_has_auth. I just thought it was pretty cool and wanted to thank them for the mention. I met Jason and Gregg at last years Lone Star Ruby Conf and they are both solid guys, even if they chose to play werewolf instead of going out to 6th street. Here’s the link to the show notes for the podcast. Rails Envy #32

There has been some confusion about the hashtags registration process. Why do we require you to follow the bot account? Why can you just parse the public feed like other sites do? I am here to answer these queries.

Why do we require you to follow the bot account?

It boils down to the fact that we want hashtags to be an opt-in service. If you don’t want the bot to look at your messages, it didn’t. We also figure this would develop a more active user base. I mean how many people are going to use hashtags unless they know about the site? Another benefit, that we didn’t realize at the time, was that this process allowed us to handle gradual growth rather than just letting open the flood gates of twitter.  So that is why we have you follow the bot.

Why can’t you just parse the public feed like other sites do?

Simple, it just doesn’t really work. Have you ever looked at the public feed page and tried refreshing? Even if you click twice in a row, the results are almost always completely different. What that means is you inevitably miss some messages. In order to do this reliably we’d have to have multiple bots hammering the public xml feed and parsing those. Parsing xml, in general, is really slow too. We made the decision to not hammer twitter’s servers and instead took the passive approach of parsing the bot’s xmpp feed.

What’s next?

Well the beta version we’re working on runs off of the public jabber feed. So we’ll be processing every single message that comes in. The only problem is that it requires a lot more computing power. We’re processing a whole lot more messages. The beta site, feature wise, is pretty complete. Right now Ben is working on optimizing our database calls and caching the hell out of everything. Our biggest problem, if you want to call it that, is that we’re getting to much client work. Since there’s no current value proposition in hashtags itself, it’s hard to dedicate too much time to it. Any suggestions or question you have post in comments and we’ll give them a look.

I’ll be honest, I’m a Merbaholic. I think about Merb, I dream about Merb, I even bought a pug and named him Merb (points to you if you get that last joke). Well…part of that is true. I do, however, use it for all my new projects. As with any project a common need is user authentication, cause you gotta have users. There’s merbful_authentication a port of Rick Olson’s restful_authentication to merb, but that didn’t seem to fit with the philosophy behind Merb. It was very railsy with the generators in options. I decided there had to be a better way. Ben and I talked about came up with a baisc idea of how it should work, but never did anything with it. Then I read Aaron Wheeler’s post about distributed mvc and decided to get off my ass and do it. The end result is two gems can_has_auth, which works with datamapper 0.3.x, and can_has_auth_core, which works with the latest trunk of dm-core.

So why distributed mvc instead of generators? First, you can’t really test generators. You can test the code they generate, but you can’t really test the templates, which makes it harder to debug. This approach has specs in the gem that test the code throughly. This isn’t meant to be the end all be all of user models and authentication, it just gives you a nice set of defaults to build on. It has default templats, which will be over written if you create a view of the same in the appropriate folder (e.g /views/user/new.html.*). If you want to extend any of the models or classes you can just re-open them by adding a file of the same name in you app directory. So in other words it works with your code rather than replacing it like restful_auth does. If you need to really customize the code create a gems directory in your app and run “gem install can_has_auth -i /path/to/gems/directory” and it will put all the code in you app. Oh and it use it in your app you only need one line of code. In init.rb add ‘dependency “can_has_auth”‘ and you’re good to go. It’s hard not to love that.

The gem also includes something neat I wrote that isn’t in restful_auth, restful password management. This allows users to reset their password if forgotten and then change it after entering a reset code. It also allows logged in users to change their current passwords. This is all tested by specs. Also the controller specs only test the controller logic. It bothered me that the controller specs were testing model logic (such as whether or not a user had a login). I have more plans for the plugin including configuration options for catpcha or email for authentication and whether to use an email or a login name to identify a user. For now check out the gems and give me feedback.

For you skimmers, here’s the gems can_has_auth and can_has_auth_core.

This will be the first in a series of posts about the pending release of our complete rewrite of Hashtags. Why did we rewrite it? Simple, it started out as an experiment and the traffic has grown. What start out as a thought experiment with two people now has a team of four behind it. Unfortunately two of the four know ruby and the person who originally wrote it developed it in python. In order for all of us to contribute we found in necessary to move it over to ruby, specifically Merb. This allows us to a better work flow to optimize the site as well as work on new features, which we have a lot planned.

So what can you expect from the new site? Well for one, it’ll be faster. We’re using memcache to cache most of the pages as fragments and also caching slow running methods, like creating the nifty graphs. So hopefully we won’t see the slow downs that have happened on the current site. What else? Well we’re now receiving the xmpp public feed, this means we’re now tracking every message. There have been some ui tweaks as well. We’ve layout out the messages on the main page a little different, we think for the better. We’ve also changed up the navigation to make it easier for us as we start adding features.

The other big news is now you can have Hashtags user accounts. Why is this good? It’ll will allow you to track certain tags and then have a custom page that will display message from those tags. We’re also looking at the ability to recommend tags or users based on which tags you are tracking, so look forward to that.

We’ll keep you updated as we get closer to releasing it, we’re shooting towards the end of may for now. Also we’re looking for some beta testers, so let us know if you’re interested.