Here’s a quick tutorial on how to implement counter metrics from codahale that resets after being reported.

Step 1

Register a gauge that increments a Counter and returns the current value while decrementing that value from the existing counter. This operation is thread safe.

1
2
3
4
5
6
7
8
9

metricsRegistry.register("my_resettable_gauge", new Gauge() {
    @Override
    public Long getValue() {
        Counter c = metrics.counter("my_counter_not_reported");
        long count = c.getCount();
        c.dec(count);
        return count;
    }
});

Note: You will have to make sure this is only registered once in your application lifecycle as repeated calls for the same gauge name will result in an Exception being thrown.

Step 2 (Optional)

You can also prevent the actual Counter metric from being reported as well, so as to not clutter up your metrics view by adding a filter.

1
2
3
4
5
6

GraphiteReporter.forRegistry(registry).filter(new MetricFilter() {
    @Override
    public boolean matches(String name, Metric metric) {
        return !name.contains("not_reported");
    }
}).build(client);

In the past few months I’ve gone from coding in primarily PHP and learning Ruby on the side, to focusing on Ruby-only projects here at EverTrue. From day 1 I’ve been amazed at how much faster it is to develop with Ruby and/or Rails. I’ve attended many hackathons in the last few years where I’ve used PHP as my language of choice and one thing was starting to become very clear — I was rewriting a lot of the same basic things over and over again at each of these events. Since converting to Ruby, I’ve blasted through these phases of my new projects with, usually, just a few lines of code. I’m loving how the Ruby community has embraced modularity as a primary value; something I never really felt with PHP.

As a testament to the rapid development speed of Ruby, the following project is an example of how I was able to solve a problem in an elegant way in just a couple hours with Ruby.

The problem

I want to be notified when an out-of-stock product on an e-commerce website was back in stock, but the website didn’t offer this feature.

The solution

Introducing Sentry; a snazzy little daemon, written in Ruby, that will notify you when a web request meets your desired criteria.

Using the existing open sourced Ruby project Daemon Kit, I was able to generate the skeleton of a functioning Ruby daemon (a script that runs as a background process) with a single command. From there, I handpicked a few open sourced gems that I knew I would need in order to save time and not re-invent the wheel. Some gems I included were Faraday for HTTP requests, Mail for sending emails over smtp, and IMGKit for attaching a screenshot of the web page as an added bonus (something I would have probably never been able to implement from scratch).

With these gems available to me, I was able to write a solution to my problem in fewer than 100 lines of code! The final product is essentially a super basic self-hosted version of Pingdom and could even serve as an API health check service in a pinch. Sentry allows you to define as many custom “wards” as you want and supports a few different types of conditions. For my use, Sentry sends me an email when the given webpage no longer contains the text “out of stock”. I’ve included a sample in the source that will check the MBTA’s Red Line Service Alerts web page and can alert me when the Red Line is having trouble.

There is a lot of room for improvement so feedback and contributions are welcome!

We’ve been working pretty closely with Startup Institute. One of the students from the development program in NYC recently posted some of the lessons that he learned while Bob was down there.

Last Monday and Wednesday Bob Breznak, lead developer at Everture, visited Startup Institute and taught the students in the web development track about…

Today we contributed back to Ning’s NIO Http Client. The client already possessed the ability to throttle requests based on the number of concurrent connections to a host. This becomes immediately apparent when making requests willy nilly asynchronously to a host. It doesn’t take a lot of computing power to bring an API to its knee’s with this approach.

Today we contributed back to Ning’s NIO Http Client. The client already possesed the ability to throttle requests based on the number of concurrent connections to a host. This becomes immediately apparent when making requests willy nilly asynchronously to a host. It doesn’t take a lot of computing power to bring an API to its knee’s with this approach.

We found ourselves needing a finer tuned approach to handle these asynchronous requests. We wanted to not only limit the amount of concurrent requests but also the total requests per second.

To handle this we contributed back a patch and I have to say, I was pleasantly surprised with how active the project is. It was reviewed and merged within hours. A very good sign of a well maintained project and reaffirms our selection in using it as one of our core libraries within our Java ecosystem.

Bob dug into an issue with BetterErrors, a Ruby gem that we use, and wrote up about the patch that he submitted.

… a major issue though; BetterErrors would return 500 responses for every error raised. If you were working on something that used relied on proper error responses (i.e. an API) then this would make development impossible. Instead of abandoning the gem, I decided to fix the issue and improve the project.