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
"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.
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
If you're writing BackboneJS apps, you need to buy this book. There's so much great information in there. It's the book I wanted to write, but they beat me too it. :)
Thanks for the feedback on that first episode! I heard similar statements from other buyers as well, and I've taken it to heart for this episode.
I took the time to script out the code and the talking points this time around. I also recorded the audio separately so that I could really focus on the code and on the audio, independently.
I hope this episode shows the level improvement I think it has! If not, I'm always looking for feedback on what I can do better.
I thought about that when I first wrote it but decided not to, because it's not a ruby app. The backbone-rails gem provides some convenience generators and other things... but I'm not sure I see the value in packaging the modelbinding plugin as a gem. Is there a specific reason you would like to see that?
disheartened? we've basically said the same thing.
as for the wizardry - it's jquery (or zepto or something else), not backbone that does this. while backbone integrates with and uses jquery heavily in the views, i don't think it's a fair claim to say backbone creates facilitates those user experiences. it helps us organize our code effectively so that we can create those user experiences in a well structured manner.
and come on, Jeremy... you know how much I love backbone! it's 80% of what I blog about these days! :)
that's one of the benefits and drawbacks of them, really. it's great to have flexibility, but it makes learning them more difficult because there's no hand-holding. it may require someone that has already formed opinions, to guide you through the learning process.
backbone and knockout focus on two different problem spaces: app architecture (backbone) and UI wizardry (knockout).
there are several plugins for backbone that bring model binding and other user experience enhancements to it, though. plus, backbone integrates directly with jQuery, so you have access to all of jQuery's libraries and plugins, still.
http://lostechies.com/derickbailey/2014/01/03/semantics-modu...