spimmy

8 ms·

31.
by spimmy 9y ago
It's actually a lot cheaper. Honeycomb is a lot more efficient in the way it collects and stores data than any other option available. But yeah, side by side it looks worse. At this stage we are mostly talking to good engineers thou
32.
Honeycomb: Full Stack Observability, No *Really*(thenewstack.io)
34 points by spimmy 10y ago|0 comments
33.
Instrumenting high volume services with sampling(honeycomb.io)
20 points by spimmy 10y ago|0 comments
34.
by spimmy 10y ago
yea that's not good advice, but "don't rely on overstuffed dashboards" is good advice. you should only have simple dashboards (and alerting) for KPIs and end to end checks. Everything else should be instrumented and deb
35.
Adventures in GELF(jpetazzo.github.io)
4 points by spimmy 10y ago|0 comments
36.
by spimmy 10y ago
Yay!! So happy to see Scuba get more visibility. I can't even count the number of times I said, and heard other engineers say, that the thing they would miss most about Facebook was Scuba. That's the whole reason why we built ho
37.
by spimmy 10y ago
Oh, I just realized that by "company's engineering" you meant CleverTap, not MongoDB. Got it.
38.
by spimmy 10y ago
I'm agreeing with your comment, not arguing with it. The problems we had moving from mmapv1 to rocksdb were almost entirely based on the rewrite of the query planner in 2.6, not the storage engine itself. The WT storage engine is far l
39.
by spimmy 10y ago
The article was written by people who don't understand very basic things about databases. To be fair, this is part of Mongo's pitch: come use a database, you don't need DBAs or people who know things about databases. Which i
40.
by spimmy 10y ago
I have plenty of rants about the company's engineering, priorities, etc. I just hate people saying dumb shit. :) Workload QPS is a meaningless number unless you know what the workload is. At Parse, we used RocksDB (a LSM tree write
41.
by spimmy 10y ago
No, you're being dumb. :) Was mysql "ready for production" when google used it? facebook? Lol. Storage engines are hard. I'm boggled that they recommend that you keep the old replica around for ten days. When we did
42.
AWS, VPCs and you(charity.wtf)
1 points by spimmy 11y ago|0 comments
43.
by spimmy 11y ago
I think you're right, and I completely intended it in a practical, non-incendiary way. People would constantly say they weren't there to pursue personal, political agendas, they wanted to have maximum impact and do what was best
44.
by spimmy 11y ago
"Try me."
45.
by spimmy 11y ago
Yeah, or just completely oblivious. Most of the technical "advice" they insisted on giving us was just completely wrong. Also, gotta say, I was never as self-conscious about being a woman in tech until we got acquired by Facebook
46.
by spimmy 11y ago
This completely describes our experience. Thank you.
47.
by spimmy 11y ago
I am absolutely venting emotionally, I thought that much was clear. :) But I heard a variant of this in dozens or hundreds of meetings, generally when a project was getting shut down or canned or reorg'd, so it's not true to say
48.
by spimmy 11y ago
OP here. Engineer/tech lead.
49.
by spimmy 11y ago
Nice. These guys are legit. (RIP, Parse :( )
50.
by spimmy 11y ago
You are totally right, most of the stuff that really hurt us was Rails middleware magic, not Ruby itself. I should have been more precise -- grumpy rails bashing, not grumpy ruby bashing! FWIW we still use Ruby on Rails for our website an
51.
by spimmy 11y ago
Hard to say. Ruby really did let us move and ship products insanely fast, without having to sink precious engineering time into boilerplate and standard libraries. Most startups fail, and it's often because they couldn't move fa
52.
by spimmy 11y ago
Gustavo is the best. ^_^
53.
by spimmy 11y ago
(we can, and do, do a lot of things to limit the impact any one app can have ... but there are limits. Async is much better for our API model.)
54.
by spimmy 11y ago
Keep in mind that we're a platform, not a website, and we have very little control over things like schemas, slow queries, inefficient looping requests that our developers send us. We can't optimize 500 thousand apps' querie
55.
by spimmy 11y ago
Good points. Technically we still use rails for our website, and have no plans to move off of it. Rails is great for websites! It's just our API that we rewrote in Go.
56.
by spimmy 11y ago
optimizing won't help you here, unfortunately. the process-per-request model is fundamentally flawed past a certain scaling point.
57.
by spimmy 11y ago
ahh, thanks for the clarification. :) (edited the post to be more accurate)
58.
by spimmy 11y ago
it's more like, getting paged in the middle of the night over and over and over is a known mental health problem :)
59.
by spimmy 11y ago
we had to way overprovision to handle even momentary spikes in availability from any backing store. we aimed to run at around 20% unicorn worker utilization under normal conditions.
60.
How We Moved Our API From Ruby to Go(blog.parse.com)
151 points by spimmy 11y ago|60 comments

More ›