be_erik

For sure it may, but I wonder how many of those decisions will be regretted? Java is a fast portable language with a decent type system and a bevy of time tested libraries. It certainly isn't perfect, but modern Java is a decent development environment (and this comes from a Rubyist). I suspect only Go can match its speed, productivity, and safety.

HTTP 1.1 support would help those of us working in AWS with ELBs

I recently built something like this: https://github.com/reverbdotcom/protopkg

Funny, I live in Chicago, so maybe things are different here, but I view cabs as nearly a luxury now. The rates are similar to uber/lyft, still slightly higher, but not much.

The service is very different though:

1. The driver often knows the best way to get to my place and all I have to do is give my address.

2. The driver knows how to drive in the city.

3. I'm rarely if ever forced into a conversation I don't want to have.

I find the whole thing so much more pleasant.

Agreed, I think most people miss the point that most protobuf implementations support JSON and/or binary across the wire. We flip an accept flag for the frontend and we get well structured JSON.

We use both, gRPC for backend services and a GraphQL server that aggregates and communicates with those services for the frontend. Because the backend is all described with .proto files its trivial to autogenerate most of the GraphQL server that serves the fronted. Tends to be the best of both worlds, IMO.

Vim support would certainly get me to purchase this. Are you planning on using nvim as a backend or are you going to roll your own emulation?

tmate is fantastic for exactly this. You can share a session on your local machine, the pair doesn't need tmux, and obviously you don't need a remote machine setup for development.

https://tmate.io/

I want to head to your farmer's market then. I live in a high density city and proteins at my farmer's market are at least 2x supermarket prices.

NSQ does nothing like this out of the box. You could create a channel for each topic that accumulates messages, but those messages would not be distributed across the cluster and after consuming them once they would be effectively gone. If that feature is a hard requirement NSQ wouldn't fit your use case.

We use it to sync data stores for denormalization purposes (think syncing postgres tables into ElasticSearch) and event based communication between small services.

We debated the same question and went with NSQ for now. We might need some of the guarantees that Kafka makes in the longterm or for some specific use cases, but for a no thrills distributed messaging platform that is incredibly simple to operate at scale, NSQ is pretty fantastic.

Building client libraries is also a joy. I blogged about it a bit here: https://product.reverb.com/how-to-write-an-nsq-consumer-in-g...

Absolutely, but you can't rely on it to be persistent like Kafka. We use it extensively and are incredibly happy with it, but we follow best practices around not putting state in messages, making changes idempotent, and ensuring that we can always replay a message if needed.

We've yet to lose any messages in production, but it could happen and we're okay with the tradeoffs between that and the operational complexity of kafka.

Use http://gofccyourself.com to quickly leave a public comment regarding net neutrality.

Thank you so much for seatest! I've used it before on a couple of small projects and really liked it. Yes, it is a bit of a pain to specify the tests, but if you're red/greening it works out great.

I'd love to see the scripts you used to manage your suite if you wouldn't mind sharing.

With all of these note editing applications I wish I could bring my own editor. Vim has ruined me and it can be hard to adopt any of these applications without being able to use vim keybindings.

https://github.com/xolox/vim-notes mostly fits my needs, but if apps like these came with a pluggable editor interface than I imagine adoption would be a lot smoother for a certain subset of users.

Go isn't a perfect language, but it strikes the right balance for me between productivity and safety. There are few other languages right now with the same ease of deployment, good tooling, excellent standard lib, and raw performance. Here's to another seven years.

Ember still has by far the best out of box experience and guides like this make that point painfully well. With Ember CLI you start at step 1, skip all the build steps (babel, webpack, etc...), and move on to learning the framework and getting some work done.

In the end you'll end up with a framework that already has a story for state management, api interaction, client side routing, and a complete testing story.

I've setup the described React stack many times. I like React as a view management library, but it requires a large amount of duct tape to get working and even once it is I still have to dedicate a lot of time to tweaking and maintaining all of these interconnected build steps. There are still tradeoffs that have made React a great choice some cases (namely its reliance on build duct tape allows it to be retrofitted into larger mature apps), but for apps I want to just work out of the box Ember/Ember CLI is an easy choice.

I think you're thinking of The Point: https://web.archive.org/web/20110204114416/http://www.thepoi...

Their concept of the "campaign" became the cornerstone modeling concept for the Groupon platform.

React provides the kind of portable isolated and testable components we wanted for our views. Turbolinks provides some of the UX we were looking for, but certainly doesn't provide isolated components that are simple to test. In addition it would mean we'd still need to decorate client side behavior with something like jQuery.

We're currently exploring lambda for certain applications as well. My coworker wrote up a nice little post about it:

https://product.reverb.com/2016/07/16/deploying-lambdas-with...

It works against elasticsearch and is somewhat agnostic as to how those documents got there in the first place. I've been playing with it as part of an EFK (fluentd instead of logstash) install.

That sounds fantastic. Do you have an example of how you extracted the trace? Was it simple to extend ElastAlert or did you have to fork it to add that kind of option?

Is anyone running this in production and care to share their experiences? This seems to be a pretty good replacement for Splunk's alerting mechanisms in the ELK stack, which has always been one of the parts I miss the most.

Just tried this on a new setup and it works fantastically. It did all the cert mucking for me.

"We also assigned each server a static unique identifier in the form of a woman’s name – a shrinking namespace with thousands of servers."

Let me fix that for you; stop gendering your servers.

Always nice to see Chicago's tech scene get this kind of coverage.

Always nice to see a Chicago startup garnering this kind of attention.