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.

Every year, like clockwork, you’ll find me glued to a TV set at a sports bar, friends house, or restaurant. I’ll sit there 4 quarters, watching a certain NBA team show 3 western conference teams how it’s done, then an eastern conference team in the finals. It is a wonderful experience being a Spurs fan.

Since I only watch 25-35 hours of live TV a year, it is awfully hard for me justify the $80 or $90 a month for cable. There’s a few sitcoms I watch, but they are available on great services like Hulu. So where does that leave me? Listening to the game on the radio, errr, internet radio.

I would have no problem paying $5 per game to watch them in my browser - just like Hulu. I’d even be fine with watching the two and three minute commercial breaks because it’s not like they can cut them out if I’m watching it live.

So, they would be able to get $5 from me per game, and the ability to show me 40-50 commercials. You can’t tell me that this is not a money making opportunity. I’m sure the cable companies have some pressure on the NBA and TNT/ESPN/ABC to keep them exclusive to the old RG6, but how long can that last?

I feel like the NBA, as well as myself, is missing out on a golden opportunity to, in their case, make a bunch of money and, in my case, watch Tony Parker drive the lane for an easy 2.

We all try to keep the signal to noise ration down quite a bit when communicating. Unfortunately, I think most of us are usually on the receiving end of it. I have tried to keep tabs on my communicating by asking myself the questions: Is this the right outlet? Is this the right context?

Normally I will send out a tweet with just a little bit of information rather than whip out Wordpress and goto town writing a blog post because what I have to say doesn’t need to be elaborated on.

I do not have a blog of my own. I have a tumble log, but that’s nothing more than an aggregate of what I publish. So I publish in different blogs that have to do with the topic I’m writing about - be it politics, culture, or technology (here).

So after being unsatisfied with our current Twitter/Blog/RSS scheme, I came up with an interesting idea to weave our tweets into the flow for Downtown Cartel as asides. Matt Mullenweg, creator of Wordpress, introduced asides to the blogging community a couple of years ago. I found that asides were exactly the thing that microblogging platforms like Twitter and Pownce tried to be but were handled differently - mainly by method of distribution.

I’m still trying to figure out how to pull off asides so that they work with Twitter, Wordpress and Twitter-Tool. I’m not certain that this can be done, but we’ll see.

Cody Marx Bailey, a partner in Downtown Cartel, was recently interviewed by our friend Lynn Bender of GeekAustin.org. As an integral part of the scene in Bryan/College Station, he has brought a lot of attention to what was traditionally a low-tech culture.

The Downtown Cartel crew try to make it over to Austin several times a month to attend different events, functions, and networking opportunities so keep an eye for us if you see us out and about.

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.

Somehow I missed the fact that an interview I did while at the BIL Conference in March was posted to YouTube. For those of you who don’t know what BIL is, it’s an unconference that was held outside of the TED Conference in Monterey, California. Several members from the Creative Space helped plan the event and made the trek out to California.

When we started Downtown Cartel,  I was pretty naive about how to go about building a client base. The last several months have been a crash course in that. I have a lot to learn still, but I think I have made significant progress. Here are a few things I have learned along the way.

Make use of everyone you know

The last couple weeks I have been going through my GMail, Linked In, and Facebook contacts and finding a ton of people that I forgot I knew (sorry friends!). One by one I am going through and contacting them individually, catching them up on what I am doing with the business and letting them know we are actively seeking client work. It really amazes me, but the most unlikely friends and family can bring you some of your best business.

Be willing to do what it takes to gain the client

One of the quickest ways to sell yourself to a potential client is to make it easy for them to choose you. To do that be willing to help them cut costs on the projects they bring you. Sometimes that will mean cutting your rates a bit, or sometimes helping them identify the core features that they really need. Look for innovative ways to create extra value in their project at no additional cost.

Work for repeat business

When you begin a project with a new client often you are implementing just the first version of what their ultimate product will be. Make sure you work closely with them to achieve their vision of what the end product will be like. You can achieve this by giving your clients the opportunity to provide regular feedback on the progress of your work. If you are not giving your client that opportunity at least every 2 weeks you are probably doing something wrong. Alternatively, if you see that their vision is a bit misguided but there is great value in their idea, help them see a different, better vision for the product. If you can do this, you will win clients for life.

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.