I had some issues using respond_to in Sinatra using Sinatra-Contrib. The respond_to method didn't handle url format extensions in the way I expected, instead requiring explicit accepts headers. Sharing my work around for sinatra url format extensions. Is there a better way?
I have been interested in code metrics, for a long time. To get a bit more involved with the community and better study metrics across many Ruby projects, I am introducing churn code metrics as a free app. It helps OSS projects track code churn over time.
I did a writeup explaining how to use the Ruby resume project to create a resume and publish to Heroku, Github pages, and a Gem. It currently supports a few formats, and soon should add PDF as well as others.
I haven't used Selenium for awhile, so I took some time to dig into the options to get some mainline tests running against Caliper in multiple browsers. The result ends with 12 browsers running selenium tests concurrently against local or staging servers with example code.
As time goes on, many Rails teams find that the rate at which they can add or improve features (known as the team's velocity) is significantly reduced. To address this problem, teams should adopt practices that allow them to identify risky and high-maintenance code and refactor the code to improve it.
If you are used to benchmark your Ruby scripts or if you ever had to improve the performance of some strategic tasks, then this post won’t tell you nothing new because you should already know that Ruby Exceptions are slow. And this is not really a Ruby problem: .NET Exceptions are slow, JAVA Exceptions are slow just because the begin/raise/rescue (or try/throw/catch) architecture is slow by nature.
A post introducing a Churn gem, which will give detailed churn metrics for Ruby projects. High churn sections of code have been correlated with high defect rates. This tool will help identify potentially problematic code so it can be refactored.
We just launched Ruby community statistics, which gives access to various metrics across the community. We generated some graphs based on the current data, a code metrics scatter plot tool for making comparisons, and made all of the data available via our API so you can dig into it. Now you can get answers on question like, does code with more duplications have higher complexity?
Many people tell me that they find metrics interesting but don't know exactly what to do with them. I try to explain how to use metrics to improve your code, by using it on a real world showing some of the refactorings.
Devver just launched Caliper, which makes getting metrics for your Ruby project simple. Give us a public git url and Caliper generates Metric_fu for your project. Add a Github post commit hook to have them generated on every commit.