werkshy
Joined 18 years ago
Karma
60
Submissions
28
Member since
Jan 25
Engineer at Harry's.
andy at potatoriot.com
View on Hacker NewsRecent submissions
Comment · 11 years ago
From the chrome extension github:
"This is pre-alpha quality software, the result of a three
day project. It will crash your browser, leak your
passwords and destroy your home. This is actually my first
Chrome extension and I am no expert javascript programmer."
Comment · 11 years ago
We (Harry's) have released a tool called Kontrast: https://github.com/harrystech/kontrast, http://engineering.harrys.com/2014/09/24/kontrast.html
It's written in Ruby but is not really dependent on Rails or anything to run. We use it to compare a list of URLs between the version we are currently testing in CircleCI and our production site. Any differences are highlighted in a nice gallery and we get a message in our Hipchat room.
Comment · 11 years ago
I run mine as a NAS, and the performance is pretty terrible. The portability is great though! I'm somewhat nomadic at the moment so it's great to have a 1TB NAS that I can pack in my laptop bag (1TB external 2.5" drive + rpi: minimal weight too)
Comment · 12 years ago
ubuntu@c1-10-1-18-157:~$ sysbench --test=cpu --cpu-max-prime=2000 --num-threads=4 run
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 4
Doing CPU performance benchmark
Threads started!
Done.
Maximum prime number checked in CPU test: 2000
Test execution summary:
total time: 6.7674s
total number of events: 10000
total time taken by event execution: 27.0485
per-request statistics:
min: 2.69ms
avg: 2.70ms
max: 7.00ms
approx. 95 percentile: 2.70ms
Threads fairness:
events (avg/stddev): 2500.0000/17.36
execution time (avg/stddev): 6.7621/0.00Comment · 12 years ago
Because everything written in Ruby is junk? This project can be used by any system that uses a cron-like syntax for scheduling jobs, regardless of the languages and frameworks that system is built with.
Comment · 12 years ago
I don't understand why web professionals are publishing their work in .docx format, whatever the standard of the writing.
Comment · 12 years ago
We certainly don't use Heroku for the price. I've got a fair amount of experience running distributed apps on AWS and I have found that Heroku do provide a lot of value-added services on top (from deployment to database provisioning). For us, the best reason to use Heroku is that when AWS has a problem, Heroku can actually do something about it. Try calling AWS support when a whole availability zone just went down!
Of course, we are a Rails shop who have been on Heroku since we launched, so Heroku is really tailor made for us. If you're happy on raw AWS, good for you. Every hour I'm not thinking about AWS is an hour I can be writing a feature for our 10-month-old startup. The extra cost of Heroku is negligible when viewed in that light.
Comment · 12 years ago
We find that neither New Relic nor Analytics gives the full picture: some of our pages are heavily cached, others (e.g checkout processing) are computationally expensive, database heavy and communicate with other systems (e.g payment processors) that can be a big bottleneck. Both New Relic and GA tend to just average those together (although with GA you can create new views that focus on specific pages). You are right that 'number of visitors on site' does not reflect our site performance in every respect.
We first conceived of Dynosaur as a plugin-based autoscaler (with GA and New Relic plugins to start with), but we've found the times we really need to scale fast are the times we have a lot of traffic generated from press stories etc (like this from today, if you will excuse the shameless plug: http://dealbook.nytimes.com/2014/01/21/a-start-up-run-by-fri...) and using the analytics live API allows us to react a little quicker than if we waited for New Relic to tell us our response times are getting slow. So far, we're happy enough with just a Google Analytics plugin.
One possible improvement would be to scale differently based on different traffic / performance metrics across the site. I think New Relic or other performance instrumentation would be very useful for that.
Comment · 12 years ago
That really depends on your app and your caching strategy. If you are doing something complex or memory intensive (or your app is poorly optimized), or if your users are highly engaged, it could be in the low tens of users! If you are doing a lot of caching you should be able to serve static pages on the order of several hundred or more per dyno.
Comment · 12 years ago
Woah! So sorry to be treading on your namespace! I did a google search for the 'Dynosaur' and didn't get any hits if I recall. We will put our heads together and come up for a new name for our project later today.
No offense intended: you picked a cool name!
Comment · 12 years ago
We haven't benchmarked against other autoscalers or done any direct comparisons.
Our main motivation was to write something that scaled as we scale manually (i.e. when we get a lot of traffic due to press hits etc, we scale up based on GA realtime data as well as New Relic response times). When we were given access to the GA live API it just seemed like a natural fit.
Comment · 12 years ago
Dynosaur author here, if anyone has questions.
Comment · 13 years ago
Good point. I am on GSM in the US but also prefer an international phone.
Comment · 13 years ago
Yes, but it's a 3 row keyboard. I upgraded from the G1 (5 row qwerty) to the G2 (4 row, numbers-on-the-qwerty-row) and it's next to useless.
As a phone, I need to use the number line a lot. As a computer /terminal, I need to use letters, numbers & symbols a lot. 3 and 4 row keyboards are bad for both of these use cases.
If someone makes a decent, interesting 5-row qwerty phone, I will buy it tomorrow.