fhirzall
Joined 17 years ago
Karma
46
Submissions
24
Member since
Nov 10
Recent submissions
Comment · 6 years ago
Of course they can, their whole business is designed around service.
Comment · 9 years ago
Every single product including the ones that go hockey-stick start out as prototypes that don't need to be prematurely optimized for scaling. That doesn't mean you shouldn't plan ahead with best practices for performance / etc, but the bulk majority of startups will not reach product-market-fit with the first version of their product. It takes months and years of iteration to be able to put up a hockey-stick growth curve.
Offering up a refined, live version of the product is non-negotiable and completely achievable with the tools mentioned in the post, but adopting services that simplify your infrastructure processes gives you the focus that an early stage product needs.
I'm 100% with that you should control your infrastructure if you're an established company, brand, or product, but we're coming at this from a startup's standpoint where speed of iteration & shipping features make a huge difference in the eventual outcome of the startup.
Comment · 9 years ago
Hey pmlnr, author here. I think what the post is trying to say is that the ops team will still be at the company, but the communication overhead across teams will be less of a burden. Your ops team will still be thinking about cost, scalability - but your developers can focus on shipping features. We also mention that this is a good approach for early stage startups looking for product market fit, i.e scalability and server costs still haven't become an issue at this stage.
Comment · 13 years ago
Feras from buttercloud here (author is my co-worker).
We have a complex application that heavily interacts with webhooks - that's what prompted us to create StripeTester. We can now easily spec out the interactions and set expectations when a webhook is received. A side benefit is that this can be used without connectivity and really cleans up our test suite.
Previously, we used Requestbin for manual webhook testing, and made heavy use of Mocha for stubbing. This required us to maintain fixtures and test data to simulate Stripe's.
There's also https://github.com/mindeavor/stripe-ruby-mock that provides some testing hooks (although repo says it's incomplete). We're planning on keeping the webhook data up-to-date when Stripe releases newer versions.
Comment · 14 years ago
Lenovo Thinkpad X220.
Comment · 16 years ago
You could run something like Autotest for continuous testing & quality control: http://ph7spot.com/musings/getting-started-with-autotest
You can run Capistrano for continuous deployment: https://github.com/capistrano/capistrano.
If you wanted to go the extra mile you could also setup different staging environments on your server: http://cjohansen.no/en/rails/multi_staging_environment_for_r...
Comment · 16 years ago
I think goals are valuable if you set them right. An overarching goal can be to have 1 of the ideas implemented, and then you can refer back to the goal at the end of each month and evaluate whether or not the tasks you've been setting have gotten you closer to your goals.
This approach combined with having different levels of goals will keep you on the right trajectory in finishing everything you want to accomplish. Something like "Only eat out once a week" can be a goal, it's up to you to choose your level of granularity.
IMO the most important thing is to periodically take a few steps back and reevaluate your current habits in relation to the goals you set.
Comment · 16 years ago
What about this? http://www.typetester.org/
Comment · 16 years ago
I've been using Remember the Milk for GTD:
http://blog.rememberthemilk.com/2008/05/guest-post-advanced-...
You can reach me at feras @ buttercloud dot com