derickbailey

exposing methods for the purpose of testing is bad design, whether or not you are only doing it in a test environment. if you have a method that is sufficiently complex and warrants its own testing, put it in it's own module file and test that module file on it's own - no need to break your design and modify your runtime module exports based on runtime environment checks

http://lostechies.com/derickbailey/2014/01/03/semantics-modu...

"saying you don't need to own/run servers for things like a podcast is just pissing money into the wind." - that's probably true. i may end up doing something like your suggesting in the future. right now, the streaming side of things is not something i want to concern myself with. i have other things that need my attention.

linode's $160/mo plan would cover me for a while. i'm transfering around 4TB a month right now, and that would cover 16TB.

thanks for the feedback and suggestions! this is something i'll need to keep in mind in the near future.

I'm serving files from Amazon S3. This gives me the benefit of world class storage and streaming, without having to own / run the servers myself. Bandwidth from them is "cheap" at $0.12/GB... but with an average podcast of 30 minutes being 25meg file, an episode with 1,000 downloads is 2.5GB of bandwidth.

i have a customer that averages 20,000 downloads per episode, and a bunch of others with close to 1,000 downloads per episode. it adds up fast.

good point. maybe a shorter trial to start with, for the early version though :)

true! i tried to make that point at the very end of the post... maybe should have emphasized it more

thanks! :) i totally get the need to move things in house, too. i'm pretty happy that i can get the right experience for my users without having to do that, at this point. IaaS is definitely amazing! "oh, i need more servers? (fiddles with a knob) DONE!" :D

definitely things that need to be considered - vendor lock in being the worst, IME. i'm less worried about API call integration, as i tend to isolate 3rd party APIs from my code... but that doesn't prevent all vendor lock-in.

for me, being able to focus on features is more important than these concerns, right now. i expect that over time i will take some of these tasks in and write the code myself, but at the moment i'm more concerned with feature growth.

good points that need to be considered in building your startup! it's a balancing act, i think, and that balance will change over time. for me, with an early stage of my service, being able to focus on my system's features and functionality is more important than the performance and customization that i would get out of writing some of these services myself. i imagine that later on in the lifecycle of this system, i will remove some of the 3rd party services in favor of my own code. but right now, being able to get features done quickly is more important than the monthly subscription costs. i don't expect everyone's situation to be the same, but i think it's a good place to start when you are bootstrapping your own apps / services

I really like http://www.karmacrm.com - probably should have included that in my list