News for hackers. Stuff that matters.

JONBRWN

Re:JavaScript Pattern Matching Proposal on Wednesday April 25, 2018 @10:46AM (#16921948)
I should note, this isn't my proposal. Just found it interesting enough to share
Re:Choosing Elixir's Phoenix to Power a Real-Time Web UI on Friday April 13, 2018 @09:34AM (#16829803)
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.

Re:Choosing Elixir's Phoenix to Power a Real-Time Web UI on Friday April 13, 2018 @09:28AM (#16829747)
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.

Re:Choosing Elixir's Phoenix to Power a Real-Time Web UI on Thursday April 12, 2018 @06:53PM (#16825693)
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.

Re:Tech Startup Slice Helps Local Pizzerias Get Online on Thursday April 12, 2018 @06:22PM (#16825478)
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.
Re:Choosing Elixir's Phoenix to Power a Real-Time Web UI on Thursday April 12, 2018 @06:11PM (#16825382)
the Elixir community was very helpful in making this possible. Happy to give back in some fashion
Re:Choosing Elixir's Phoenix to Power a Real-Time Web UI on Thursday April 12, 2018 @05:15PM (#16825009)
Hi, I'm the author of this post. Would be happy to answer any questions if folks have some.
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.

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.

Hi, I'm the author of this post and I'll be happy to answer any questions here.
Re:Simplify Stream Processing in Python and Wallaroo Using Docker on Wednesday December 20, 2017 @08:13AM (#15969193)
Hi, I’m the author of this blog post. If anyone has any questions I’ll be happy to answer.