738 karma · joined May 11, 2009
Honeycomb is built to help engineering teams deeply explore and understand their own production systems — in real time. It's a service for the near and present future, where distributed systems are the new default, every service is a platform, and empowered generalist software engineers are the new ops. We are passionate about consumer-quality developer tools and excited to build a product that raises our industry's expectations of what our tools can do for us.
Job links (and threads by the hiring managers!) can be found here:
* Product Manager https://twitter.com/fishmegs/status/1290347660319154177
* Customer Success Engineer https://twitter.com/irvingpop/status/1280982010937241600
* Product Engineer https://jobs.lever.co/honeycomb/2605efc2-2f69-4193-bc21-4524...
* Engineering Manager https://jobs.lever.co/honeycomb/db0b0b03-930a-439a-a4ee-dea3...
Oof. Honeycomb is for fast, realtime analytics: starting with a high-level question in your mind ("why did our throughput drop by 50%?") and rapidly iterating on a hypothesis (examples in [0]). ELK can... be used for that, but is optimized for another (as you said, full-text search and generating static reports).
Being able to flip from a funny-looking graph directly into "raw data" mode is intended to be a bonus in Honeycomb, not the primary way you interact with your data.
While we believe that fulltext search has its place, beyond a certain point (most production systems, these days), sifting through log lines is a brute-force method of answering questions about your systems — especially if you're not sure what the proverbial needle you're searching for looks like. [1]
(But mherdeg's answer is great, go back and read theirs while you're here :))
0: https://www.honeycomb.io/blog/troubleshooting-in-honeycomb-c... 1: https://www.honeycomb.io/blog/the-true-cost-of-search-first-...
If all you care about is overall latency, awesome! Use a TSDB. Once you care about latency per endpoint/user agent/customer ID/client platform (or combination thereof), you need the flexibility associated with structured log data, stored in something meant for fast analytical querying.
0: https://www.honeycomb.io/blog/the-problem-with-pre-aggregate...
(We also don't currently support joins, while TimescaleDB's joins sound pretty dope :))
Is this because there's nothing to say ("Of course they're IPO'ing, everyone doing telephony uses Twilio, this makes total sense")? Or because the haters have all taken vacation and aren't around to draw comparisons to other recent IPOs?
... or are IPOs no longer news to the HN community anymore?
1: http://www.forbes.com/forbes/2009/0316/072_terminated_women.... 2: http://folk.uio.no/olegmo/Men%20in%20Nursing/Evans%20J%20199...
1: http://mobiledevelopertips.com/cocoa/launching-your-own-appl... 2: http://handleopenurl.com/scheme
Looking for a generalist engineer (intern or full-time) to be our first employee. Standard Rails stack, but candidates with experience in equivalent technologies are wholeheartedly welcome as well.
Venuetastic (YC W11, http://venuetastic.com/jobs) is looking for generalist engineers to join the team and be part of a very early-stage, funded startup.
Some of my recently created tasks and the holes they plug:
* RSS feeds that aren't fine-grained enough for my needs (if there's a new item in The Atlantic's Entertainment RSS feed that matches "Game of Thrones," then email it to me)
* RSS feeds that I want to be updated about ASAP, but don't want to have to sign up for (if there's a new item for an eBay search I care about, then send me a message via GTalk)
* Lightweight Twitter alerts (if there's a new tweet that mentions X, then send me a message via GTalk)
Other cool examples of ifttt flows:
http://craigt.co.uk/blog/?p=146
http://web-mastered.de/post/4748705681/iffft-dropbox-update
http://blog.christineyen.com/2011/05/how-i-use-ifttt/
tl;dr - really lightweight, well-designed version of yahoo pipes that is genuinely fun to use.
And FTR, part of the advantage of native apps is that they'll never be relegated to "just another browser tab" or lost in a sea of favicons. When I'm going to invest time in a workflow / application / product, I almost always prefer the native app to web app for this particular reason.
They're brightly colored, often aren't stuck on at right angles, and frankly refuse to be ignored. They're just the right amount of annoying, and I'll be interested to see how digital GTD applications manage to toe that line.
Then you take a look at some of the additional goodies - fadeout(), desaturate(), etc - that have been included in the most recent release, and you wonder how you ever kept your color palette organized before.
Less has prevented me from wanting to claw my eyes out during a recent round of frontend work - just for that, I'm incredibly grateful.