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.
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.
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!
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.