avand

If you subscribe to the philosophy that every line of code is a liability, which I do, this really hits home.

#awesomesauce

You're blowing my mind here. Really good stuff.

What I think is really cool is that all this stuff is coming. There are a lot of stakeholders deeply invested in seeing these ideas come to fruition.

To the future! Cheers.

Thanks for the kind thoughts!

I agree, the whole concept of a cloud-based music library is very new. Forget music, the concept of the cloud is new! I'm looking forward to a holiday filled with questions like, "where is it, who owns it, is it secure?"

Once people are comfortable with the paradigm shift, will really be cooking with gas.

Selecting music to play at any given moment is entirely human. Play Strength was not intended to make music selection automatic.

I think humans can make better decisions with data. Play Strength attempts to expose insights already locked inside your music library.

For example, one of the big changes in driving some hybrid vehicles is a real-time monitor of how power is flowing in and out of the battery. I think just seeing that data changes your driving habits.

That's what I was going for with Play Strength. Thanks for sharing your thoughts.

All told, I think rating songs in your library is a really personal thing.

@JimEngland, you use stars purely as an organizational tool, which is slick. It's cool that the iTunes interface extends it self to different uses.

@tkahnoski and @zeedog, how would you elegantly expose controls for those different feelings?

I need something more binary. Deciding between three and four stars seems totally arbitrary.

Well thanks for the insights. I'll keep triggers in mind when I come across a problem like this in the future.

Thanks for sharing. I agree with @bunkat here (though I didn't read the whole page). I find the language around analytics apps (including big boys like Mixpanel) to be generally vague. If you're catering to a primarily developer audience, you may consider just showing me how easy it is. StatHat does a good job of this.

That's slick.

I pinged the guys over at RedisToGo to get you some more clarity on the pricing.

Speaking for ourselves, we've historically preferred to have someone else manage our infrastructure. Setting up Redis is fairly trivial, I agree. However, setting up a secure machine out on the internet and making sure it's always there is less trivial. Rather than juggle an ops/engineer role, we just double down on engineering. I'm sure at some point this may need to change. Hopefully, when that day comes we can afford a sysadmin!

To be fair, we may have over-engineered this solution. I've been doing some work with compound indexes with Mongo and they seem to be performing really well. Maybe I'll have to write a guest post for MongoHQ too ;)

Appreciate the time and thoughtful response.

We definitely could have done this in Postgres.

Our API is a Rails project and though we do a lot of work that's "off the rails," so to speak, we do try to follow a convention where possible. A convention that's worked well for us is to use Postgres only for database-backed models in the app. So when it came time to solve this problem, Redis seemed like a good choice.

Map/reduce isn't an option here. First, it's too slow. Second, it's asynchronous by nature, which doesn't work well when trying to load a webpage. We did consider using it in the background, however, to generate the counter-caches.

Thanks for reading!

I've never used SQL triggers. We host our Postgres database with Heroku. As a result, I think I've ruled out database level solutions.

On a related note, it feels good to know that everything our app needs to run is in the code base. Back in my C# days, I remember relying on stored procedures that were configured manually at the database level. Rails fights that with migrations and the callback chain too, so I guess that thinking has sunk in for me.

Thanks for the comment.

Good god. I can't believe I missed that. Thanks. I'll make sure that gets fixed.

Hey, I'm one of the co-founders of Sqoot. We're a small startup trying to do big things. Sometimes we trip and fall. This is one of those times. In hindsight, our language was reckless & immature. Please accept our apology:

http://blog.sqoot.com/we-can-do-better-an-apology-from-sqoot

Hey, I'm one of the co-founders of Sqoot. We're a small startup trying to do big things. Sometimes we trip and fall. This is one of those times. In hindsight, our language was reckless & immature. Please accept our apology & help us turn this negative into a positive.

http://blog.sqoot.com/we-can-do-better-an-apology-from-sqoot

Part of what we think makes this feature great is that you can generate leads with it. Instead of bouncing a user to a deal page, you can send them to this landing page first. If they subscribe, they're a customer for life!