You have disabled auto-rotation for stories. Re-enable?
You want to ship it right instead of doing it again. But what could you clean while still meeting the deadline? PullReview reviews the Ruby code you just wrote and tells you what's wrong, why, and how to fix it - from style to security. Code, Spot, Fix, and Ship!
The Ruby Core Developer meeting took place in Japan and Terence Lee was kind enough to let us know what happened. Team Matz is considering accelerating the release schedule for Ruby patch releases. So that would be things like 2.1.1, and 2.1.2 as opposed to waiting for a 2.2 release. It would allow them to tackle bugs that cause dreaded segmentation faults much faster. To achieve this, Shibata Hiroshi & Koichi Sasada will work on a CI environment in order to make the release process easier. They also discussed removing commits that are not directly relevant to a patch release (or hotfix) before a the release goes out, probably in order to avoid potential regressions in those releases. By the way, since Ruby 2.1.0 was released, the core team announced that they would not release versions with patchlevels anymore. So no more obscure versions like 1.9.3p545? Finally dear listeners, remember that feature suggestions for Ruby 2.2 are still being accepted so if you’ve ever wanted to give back to your favorite language, you should head over to bugs.rubylang.org right now.
RailsConf was less than two weeks ago and the good people at Confreaks already have David Heinemeier Hansson’s keynote along with a handful of other talks available on their site. There’s another part of that talk that was a little less talked about: the part about David’s confession his inability to ever become a computer scientist. Although it was overshadowed by his knack for controversy, I think it was really interesting to hear such a prominent programmer — whatever you think of him — describe himself more as a software writer with affinities towards humanities instead of sciences.
So speaking of the TDD controversy, a number of prominent voices in the community have by now responded to his allegations that TDD for instance hinders design, is not necessary, etc. Robert Martin a.k.a Uncle Bob, was one of the first to respond with several blog posts actually. While deploring DHH’s rhetoric at first, he reiterated the benefits of TDD in a first post. As DHH continued aboard his TDD hate train, it was more like a blog ping pong than a code one. That’s about when it got interesting for me, right when Gary Bernhardt chimed in. On top of that yesterday, both Martin Fowler and Corey Haines joined in the merry battle of giants.
Continuing down the testing path, this weekend Jakub Arnold published a shortyetuseful post entitled, “Duplication in Tests is Sometimes Good.”. I presume that you’re writing tests for your application or library. And I further presume you’re using a framework with before and after test hooks, like RSpec. People often use those hooks to clean up their test code, pulling out common setup and configuration. Is it possible that you can extract too much of that setup and configuration? Perhaps to the point of making your tests hard to understand? As Jakub shows, some duplication can be good. It’s not always bad to repeat ￼yourself, especially if the repetition is easily updated with a find and replace.
I think a much more important thing than dislike of TDD happened at RailsConf. I’m sad that not enough people have talked about Aaron Patterson’s Keynote. He spent quite a bit of time explaining the hard work that was put into speeding up ActiveRecord for the upcoming 4.2 release of Rails. He showed multiple benchmarks of the AdequateRecord branch and how in many ways it’s even faster than back in the Rails 2.3 days. So while the video for Aaron’s talk wasn’t available at the time of this recording, we highly recommend you watch it on Confreaks when it comes out. By the way, AdequateRecord has already been merged into rails/master on GitHub so you can already test it out if you like your edge really really bleedy.
And finally, to wrap up a TDDHHfilled episode, yesterday, Marcin Stecki published an article on the netguru blog describing some of the background for and aftermath from creating the Code Ping Pong with DHH site. In summation, the Rails 4 app was built on a whim, the source is available on GitHub, DHH didn’t know about it before hand, yet he did agree to respond to a handful of entries, DHH’s tweets brought several thousand eyes to the site, and ultimately Marcin was confused. As he put it, people poop on Rails all the time, but when presented with an avenue for presenting “bad code” to DHH for his thoughts, almost no one had any concrete examples. I think they got about 11 submissions ... and most of them weren’t even serious. Ultimately, only three entries were presented to David. Three submissions were presented to DHH... and David’s refactorings won the popular opinion vote for all three. Anyway, it is actually quite impressive to me that David volunteered his time for this, especially since he had nothing to do with its setup or concept. I appreciate that he gave his time and attention to what could’ve easily been seen as being silly and just ignored. So, thanks, David and Marcin!
Test-induced design damage, Frocking the console, Advanced Rake and Mutation Testing
Configuring variants with Various, what to learn with What's Next, fixing Celluloid with RailsReloader, improving communication with Capistrano Team Notifications, integrating AngularJS with Rails, and getting more from Postgres with PG Power.
A web interface for letter_opener, getting right at your Mint.com data, observers in mongoid 4, an interview with DHH, parsing out social network user ids, and the Ruby Hero Awards all in this episode of the Ruby5!
This week we cover Searchlight's 3.0, dumping code in models, this week in Rails commits, Whiny Validations, Bootstrap 3 support for Simple Form, and how to be an open source gardener.
Looking to learn about Ruby? Take a look at the Ruby Path on Code School
This podcast is produced and distributed by Code School. Copyright © 2016 Code School LLC