EverTrue Dev

[evertruedev]

Hacking at the speed of Rails

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 improvment so feedback and contributions are welcome!

[evertruedev]

Our Dev Manifesto: Testing

At EverTrue we’re big believers in testing our code, but it wasn’t always that way.

EverTrue is still a very young company and one of the the engineering exercises that often gets forgotten is testing. Name your excuse as to why but the storyline is all too familiar. You have a small amount of resources and time and some things have to get cut.

Going forward, we’re taking a different attitude towards testing. When we create a new API, we’re diligent about test coverage. Our goal is to achieve >= 90% coverage.

We’re not adhering to TDD across the board, the approach is left up to the individual developer. If a developer wants to write tests after he or she is code complete we’re fine with that. Ultimately, as a team, we want test coverage to not drop before shipping to production, and ideally before going into master.

Developers are measured against the test coverage of individual projects so as to create another incentive besides the many that already exist with testing.

One of the best things that our team has come to like about writing tests is that it serves the purpose of providing documentation. There’s nothing worse than a source file rife with outdated code comments and no test to explicitly define its behavior.

While our engineering culture is a work in progress, this aspect of it seems to well embraced by the team and we’re looking forward to iterating on it to make even better. Come help us define our culture: [email protected].

[evertruedev]

Brent speaking at an EverTrue networking event for upcoming SIB grads!

[evertruedev]

Some might say we're pretty fond of craft beer....

[startupinstitute-blog]

[evertruedev]

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.

By Jonathon Castillo

What Makes An Effective Developer?

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

[evertruedev]

Some coworkers go out for drinks after work, we go sailing.

[evertruedev]

Improved rate limiting with Ning's Async Http Client

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.

[evertruedev]

Bob dug into an issue with BetteErrors, 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.