Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
matlock
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
11 ms
·
61.
▲
by
matlock
13y ago
Thanks, going immutable with all of our infrastructure made our system way more stable and productive
62.
▲
by
matlock
13y ago
at Codeship ( https://codeship.io , I am one of the founders) we support Bitbucket and have been for a while. We use LXC as well and are currently looking into Docker for our next infrastructure steps.
63.
▲
How to make your testing awesome with PhantomJS
(blog.codeship.io)
5 points
by
matlock
14y ago
|
0 comments
64.
▲
by
matlock
14y ago
Vine seems to be getting really slow currently
65.
▲
Which hosted and simple acceptance testing tools are out there?
5 points
by
matlock
14y ago
|
2 comments
66.
▲
by
matlock
14y ago
The editor is pretty fancy, dragging stuff around when you create a new document works really well. Will give it a try
67.
▲
by
matlock
14y ago
Of course, but it happened with a regularity that just didn't work out for us any more. Although it was definitely not the main issue to change. So far though we haven't seen any of those problems on EC2 (or at least only very very very few
68.
▲
by
matlock
14y ago
Reserved Instances are the next thing we are looking into as well to get our costs down dramatically
69.
▲
by
matlock
14y ago
As I was asked about the implementation details I'll write a second blogpost at the end of the week that goes into the details of our implementation.
70.
▲
by
matlock
14y ago
We actually went that route with historical data and it wasn't any good to be honest. Work patterns change daily, so we really need the auto scaling. Working with Historical data means you either totally oversubscribe certain days, or total
71.
▲
by
matlock
14y ago
Exactly. Price itself is not the main issue, but flexibility is. For example on Weekends we typically see 20%-30% the traffic that we see during the week, simply because people are not at work. Scaling up and down is an absolute necessity t
72.
▲
by
matlock
14y ago
Which is exactly the case in our environment. As soon as all libraries are loaded from EBS IO is not that much of an issue any more
73.
▲
by
matlock
14y ago
We store all the code and everything that changes in a Ram disk, so really fast. The virtual machine lies on EBS, but it is really fast to start and performance is not limited by EBS at all in our case.
74.
▲
by
matlock
14y ago
Builds failed from time to time because the network was simply gone. We worked around the issues by running commands again when they timed out, but it was one of the reasons (the main reason being that having your own servers is simply not
75.
▲
by
matlock
14y ago
Digital Ocean looks pretty sweet, but the advantages by going with EC2 for us are a large number of different Instance Types we can use for every task we have. It provides us with a lot of flexibility on how to build our service.
76.
▲
by
matlock
14y ago
Linode is very competitively priced, but we need to scale up/down on an hourly basis. when there are less builds to run we simply want less servers to run. Linode is much cheaper than Amazon when you go over the whole year, but it just does
77.
▲
by
matlock
14y ago
I haven't looked into Cloudflare a lot, but it looks like it would solve that as well.
78.
▲
by
matlock
14y ago
You are absolutely right. Will add this to the Header
79.
▲
by
matlock
14y ago
Rails provides great performance and when coupled with Apache/Nginx delivering Assets is not that big of a deal. But as Heroku doesn't provide any proxying it is upon every developer to implement something like this. Though doing it takes p
80.
▲
by
matlock
14y ago
NewRelic considers every Unicorn Worker to be a separate dyno
81.
▲
by
matlock
14y ago
Hi Ryan, you could deploy to your staging environment upon every build and only deploy to production when triggered manually. Railsonfire (full disclosure: I am one of the founders) makes this very easy. Just give it a look here: http://he
82.
▲
by
matlock
14y ago
We (Railsonfire, a continuous deployment service actually) deploy regularly to Heroku (up to several times a day) and the timeout is a few seconds max. We are on cedar stack though, which might make a difference there. Working on startup ti
83.
▲
by
matlock
15y ago
This looks amazing. Will take a good look
84.
▲
by
matlock
15y ago
Google Docs is really a great starting point to see what exactly you need and where to go from there if you need. It's easy, free and just works.