treeder

10 ms·

61.
by treeder 14y ago
The static website part is nice, unfortunately working with Jekyll isn't. Such a painful process to update docs.
62.
by treeder 14y ago
This is awesome, nice work. Although I'd prefer one that transferred them to Picasa/Google+.
63.
by treeder 14y ago
What is meant by elasticity is that you can handle varying load on demand. You don't need to provision/scale for spiky/unexpected loads in advance, your infrastructure will expand and contract on demand. This is a very difficult problem to
64.
by treeder 14y ago
I've been reading Fooled by Randomness by Taleb, great book, same topic.
65.
by treeder 14y ago
Not yet, but very soon we'll add the upload function to the API so you don't need the cli.
66.
Sharable, Open Source Workers for Scalable Processing(blog.iron.io)
26 points by treeder 14y ago|4 comments
67.
by treeder 14y ago
It's really not that complicated. The example on github works and you can try it out pretty easily to see for yourself. And if you need any help or have any questions, you can get some real-time help in our public chat: http://get.iron.io/
68.
How to Schedule SMS's and Calls on Twilio(blog.iron.io)
21 points by treeder 14y ago|7 comments
69.
Auto Retry for IronWorker(blog.iron.io)
1 points by treeder 14y ago|0 comments
70.
How to Quickly Migrate from GoDaddy to Amazon Route 53(plus.google.com)
1 points by treeder 14y ago|0 comments
71.
by treeder 14y ago
Are you referring to polling vs web sockets or something? A lot of chat systems use polling at scale, Campfire being one of them.
72.
Using IronCache as a Persistent Key Value Store for Real-time Chat(blog.iron.io)
19 points by treeder 14y ago|5 comments
73.
by treeder 14y ago
You could start by reaching out to companies you have relationships with. We could probably use someone like you.
74.
1988 - 2012 RIP Nintendo Power(ign.com)
8 points by treeder 14y ago|1 comments
75.
Elastic, Highly Available Backend for Delayed Job: IronMQ(blog.iron.io)
2 points by treeder 14y ago|0 comments
76.
by treeder 14y ago
This is pretty much spot on as to IronWorker's sweet spot. Discrete jobs, no servers, never worry about scaling.
77.
IronWorker's Most Requested Feature is Here: Max Concurrency(blog.iron.io)
10 points by treeder 14y ago|1 comments
78.
by treeder 14y ago
@amix, you clearly didn't read the post.
79.
.NET Just Got Some Iron Behind It(blog.iron.io)
13 points by treeder 14y ago|0 comments
80.
GoSF Meetup on June 21st with Rob "Commander" Pike and other Top Go Developers(blog.iron.io)
2 points by treeder 14y ago|0 comments
81.
by treeder 14y ago
The pattern is to put the work in a queue, respond to the user immediately, then process in the background, outside the request cycle. Regarding auto scaling, it is scaling your worker servers to work down the queues, but it is not as urgen
82.
by treeder 14y ago
IronWorker is billed by the second so if an image takes 5 seconds to process, you only get billed for 5 seconds of the hour. No need to deal with auto-scaling heroku workers to keep your costs down. And priority on IronWorker has a much dif
83.
by treeder 14y ago
No resque setup/management, no auto-scaling setup, scale huge with zero effort (go from processing one image to millions without lifting a finger), redundancy and reliability (how are you going to ensure that with your Resque?), full visibi
84.
by treeder 14y ago
In some ways yes: - they are both hosted services - they both are key/value stores In other ways no: - IronCache has a REST API and supports memcached protocol - IronCache only supports the basic functions of Redis, redistogo supports all o
85.
IronWorker Goes Hyperpolyglot - Adds Java, Node and Go Support(blog.iron.io)
5 points by treeder 14y ago|0 comments
86.
One Webhook to Rule Them All - One URL, Millions of Possibilities(blog.iron.io)
5 points by treeder 15y ago|0 comments
87.
by treeder 15y ago
Cloud has a lot of different meanings these days so it's nearly impossible to really define it, but it is possible to think of them in various different contexts: - Consumer cloud or SaaS for consumers (gmail, rdio, facebook, etc) - SaaS fo
88.
by treeder 15y ago
I agree with this, it's generally a good idea to use services that don't lock you in and provide common interfaces so you can move your data or take in house at any time. Like http://www.mongolab.com for instance uses standard MongoDB and
89.
by treeder 15y ago
> Because I am not stupid to pay monthly fees instead of single upfront licenses. You also have to think about the cost of hosting, maintaining, monitoring, etc. Usually a service fee by a provider is much smaller than the cost of doing
90.
Why Aren't You Developing in the Cloud?(blog.iron.io)
14 points by treeder 15y ago|23 comments

More ›