HNHacker News
TopNewBestAskShowJobs

JONBRWN

227 karma · joined October 15, 2013

submissionscomments
JONBRWN··on JavaScript Pattern Matching Proposal
I should note, this isn't my proposal. Just found it interesting enough to share
JONBRWN··on Choosing Elixir's Phoenix to Power a Real-Time Web UI
Not really a question that can be answered.

I'd suggest looking at Elixir/Phoenix if you have a problem with Rails that you think Elixir/Phoenix might be able to solve. Could be scale problems, reliability, real-time communication, etc.

I wouldn't suggest replacing your entire Rails app with Phoenix right away. If possible start with a service that may be having issues and migrate that over if possible.

JONBRWN··on Choosing Elixir's Phoenix to Power a Real-Time Web UI
Most likely, yes.

As with everything though, there are trade-offs. If going strictly AWS fits your use case, you're fine working with GraphQL, etc., go for it.

JONBRWN··on Choosing Elixir's Phoenix to Power a Real-Time Web UI
Truthfully I don’t have many thoughts on that combination.

The channels abstraction was the driving force behind our choice and at the time there wasn’t anything that stood out in the Java world.

JONBRWN··on Tech Startup Slice Helps Local Pizzerias Get Online
Sometimes I get upset that my favorite pizza spots in NYC are cash only and non-delivery but after reading this I’m sure the quality wouldn’t be the same if they switched.
JONBRWN··on Choosing Elixir's Phoenix to Power a Real-Time Web UI
the Elixir community was very helpful in making this possible. Happy to give back in some fashion
JONBRWN··on Choosing Elixir's Phoenix to Power a Real-Time Web UI
Hi, I'm the author of this post. Would be happy to answer any questions if folks have some.
JONBRWN··on Building low-overhead metrics collection for high-performance systems
We didn't set out to replace Prometheus, our Metrics UI was designed to give Wallaroo users insight into several parts of the system to spot bottlenecks while developing applications.

What we did do from scratch was write the instrumenting of Wallaroo in order to collect the metrics that could be used by our Metrics UI or Prometheus.

We thought it'd create a better user experience to provide a tool that provides the metrics information in a meaningful way as opposed to letting our users pick from Prometheus, Grafana, etc off the bat and having them set it up themselves.

In the end, if a user wants to use a tool like Prometheus they can write an adapter to convert our Metrics Protocol into a format suitable for Prometheus.

JONBRWN··on Building low-overhead metrics collection for high-performance systems
Thanks for the encouraging comment, we've spent a lot of time on Wallaroo's design so we're happy to see people appreciate it.

We have a few clients who will be running Wallaroo in production in the upcoming months. We're still a fairly new product, hoping to have one of those stories out in the not so distant future.

Is there anything you'd like to gain from one of those stories? Would be helpful to us to have a target audience in mind.

JONBRWN··on Building low-overhead metrics collection for high-performance systems
Hi, I'm the author of this post and I'll be happy to answer any questions here.
JONBRWN··on Simplify Stream Processing in Python and Wallaroo Using Docker
Hi, I’m the author of this blog post. If anyone has any questions I’ll be happy to answer.