chucknibbleston's comments

#1 - Nginx #2 - Redis #3 - Postgres

This is interesting but the fact they list "adchoices" as a site's monetization makes me wonder how much they know about adtech...

Is this a joke?

I find "VSRE" unnecessary: if you write efficiently, anyone capable of a VSR will follow suit.

If they know what you pirated, why don't the content providers just get your ISP to shut off your internet until you watch enough ads to make up for the cost (they could do a little rev-share to incentivize comcast). Piracy will exist as long as content providers insist on selling something that can no longer be sold.

this is why I love the 3 finger drag in osx.

or this: http://www.google.com/trends/explore#q=javascript%2C%20jquer...

I bet that setting an interval to check for the specific node is actually more performant than using the mutation event (which as @Vekz pointed out, slows down the whole DOM)...

we are living in the future

Just to put this out there -- since nobody has really mentioned it -- ruby (as a language) doesn't have the greatest performance. You can do some tricks with GC to speed it up (Ruby EE might be a faster option), but you're still looking at 50x slower than C (python is 40x, Java 7 is around 2x, Javascript on V8 -- Node-- is 4x). So if you're planning on doing a lot on the backend, you might want to consider breaking off your logic/processing into java or lisp or something and using a rpc/mq system to send it tasks from your RoR/Django app....but then again...you might not want to start with too many moving parts :)

I agree; the whole node socket/handshake is a ton of overhead if you're not interested in using the socket to make calls over the API you just authenticated.

Unless you're providing an API/external access for your users, you can just use authentication internal to your app. It's pretty easy to roll your own (here's a tutorial for doing it in RoR: http://www.aidanf.net/rails_user_authentication_tutorial), but I would recommend using a popular plugin/middleware if you can find it for your language/framework so you don't have to worry as much about security.

For node/Express, passport.js is a good option (but doesn't help you out with the database at all) -- http://passportjs.org/guide/username-password.html

Django has basic user authentication built-in, Ruby on Rails has Devise - https://github.com/plataformatec/devise and AuthLogic - https://github.com/binarylogic/authlogic.

I'd recommend reading the Ruby on Rails security guide about user management to get an idea of some of the challenges in building an authentication system: http://guides.rubyonrails.org/security.html#user-management

If you want to write an OAuth provider here's a great PHP tutorial: http://djpate.com/2011/01/13/how-to-write-a-complete-oauth-p...

my 2 cents:

These are interesting ideas, but besides being difficult to monetize (@mchannon), I'm not sure there's a huge demand for them either.

The first one is going against a couple of big trends:

1. Mobile (even with low latency, streaming a FLAC is going to eat up bandwidth and memory) 2. Music discovery/personalization + consolidation of content -- users have to know what they want to listen to, or have to be willing to put up with songs they don't want to hear. Your main demo is going to be audiophiles...who already have their music collections on disk or only want specific recordings.

I'm also unsure how you're going to source content. So I guess, what I'm getting at is that it seems like you don't have much of a market (besides having few potential revenue streams).

The second one is really interesting, but I'm just not sure there's demand for that--are there a lot of touring/performing groups that are decentralized? Even if you removed the need for them to perform together, there would still be plenty of pressure for them to colocate that I'm not sure you would be able to create a market.

Are you interested in making technology demos or building a business? Because if it's all about the tech, then these are definitely interesting ideas and may lead to some innovation that can be turned into a product later.

1. I think you should consider dropping your first product. If it isn't bringing in good revenue and it's eating up your development time, you might be better off with just your mobile options. This would also handle #3.

You should pick a stable mobile framework to use (since I assume you don't want to go native). Make your backend code as modular as possible (for accommodating changes to their API).

If you're able to do a significant rewrite, I would decouple your data from your logic as much as possible. Write it with the option of offering it to your competitors as a mobile platform.

2. No, if you can reach profitability.

3. Focus your marketing on your mobile product. Devote your time to marketing and sales. Set a profit goal for the near future (well before your cash runs out). If you don't make it, write an API for your app's backend and offer it to your old competitors.

4. If you aren't 100% committed, then you should quit.

5. How much money do you need right now to stay afloat?