Ruby 2.1.1 is released

Today, Feb. 24th, is the 21st anniversary of Ruby,
so we happily announce a new patch release of Ruby 2.1, Ruby 2.1.1.

Ruby 2.1 has many improvements including speedup without
severe incompatibilities. You can use this on Rails and other applications,
and get a more comfortable experience.

This release includes many bugfixes.
See tickets
and ChangeLog for details.

Following the previously announced changed versioning policy of Ruby 2.1,
this version is simply called “2.1.1”.

Update: We’ve noticed a regression in Hash#reject. For more details, see:
Regression of Hash#reject in Ruby 2.1.1.

Download

http://cache.ruby-lang.org/pub/ruby/2.1/ruby-2.1.1.tar.bz2
- SIZE: 11990697 bytes
- MD5: 53edc33b2f590ecdd9f6a344b9d92d0d
- SHA256: 96aabab4dd4a2e57dd0d28052650e6fcdc8f133fa8980d9b936814b1e93f6cfc
http://cache.ruby-lang.org/pub/ruby/2.1/ruby-2.1.1.tar.gz
- SIZE: 15092388 bytes
- MD5: e57fdbb8ed56e70c43f39c79da1654b2
- SHA256: c843df31ae88ed49f5393142b02b9a9f5a6557453805fd489a76fbafeae88941
http://cache.ruby-lang.org/pub/ruby/2.1/ruby-2.1.1.zip
- SIZE: 16618363 bytes
- MD5: 02c1dbff9c550d2d808444c8fef483bc
- SHA256: 6c226d3f3a4bd1a9356077473d1915968f45af6775660bb8ec5e245a337e3b14

Posted by naruse on 24 Feb 2014

Read more at the source

When Is It Time to Refactor?

January 9, 2014

One struggle for software development teams is determining when it is appropriate to refactor. It is quite a quandary.

Refactor too early and you could over-abstract your design and slow down your team. YAGNI! You’ll also make sub-optimal design decisions because of the limited information you have.

On the other hand, if you wait too long to refactor, you can end up with a big ball of mud. The refactoring may have grown to be a Herculean effort, and all the while your team has been suffering from decreased productivity as they tiptoe around challenging code.

So what’s a pragmatic programmer to do? Let’s take a look at a concrete set of guidelines that can try to answer this question. Generally, take the time to refactor now if any of the following are true:

Refactoring will speed up the task at hand. This is a no brainer, because you’ll get your current work done more quickly, and the refactoring you performed will benefit your team over time. Of course, this is a judgement call, but experienced developers will hone their sense for these cases.
The refactoring is quick and contained. Many refactorings consist of making small changes, generally within a single class. Because you’re altering an encapsulated unit of structure, often these types of changes require no modifications to collaborators or unit tests. The most common example is applying the Extract Method refactoring in order to implement the Composed Method pattern, but other refactorings like Replace Temp with query fall into this category.

Katrina Owen once said:

Small refactorings are like making a low cost investment that always pays dividends. Take advantage of that every time.

Remember, source code is generally “Write once, read hundreds (or thousands) of times”. Spending a little extra time now cleaning up the internal structure of your classes makes them more approachable to every developer who opens that source code file in the future.
The un-factored code has three strikes. Keep track (either in the back of your head or documented somewhere) of each time you run into a problem or friction that would have been avoided if your code had been better factored. When a given problem spot causes your team trouble three times, it’s time to clean it up. This allows you to focus on the issues that are actually slowing your team down, not just the areas that seem messy.
You’re at risk of digging a hole that will take more than a day to fix. The worst code in every app is usually stuck in god objects that feel almost impossible to refactor, but it wasn’t always this way.

A key practice to employ when considering a larger refactoring is asking yourself this question:

“If I pass on doing the refactoring now, how long would it take to do later?”

If it would take less than a day to perform later, there is less urgency to do it now. It means that if a change needs to be made later, you can be confident you won’t be stuck in the weeds for days on end to whip the code into a workable state in order to implement the feature or bug fix.

Conversely, if passing on the refactoring creates a risk of digging technical debt that would take more than a day to resolve, it should probably be dealt with immediately. If you wait, that day could become two, or three or four days. The longer the time a refactoring takes, the less likely it is to ever be performed.

So it’s important to limit the technical debt you carry to issues that can be resolved in short order if they need to be. Violate this guideline, and you increase the risk of having developers feel the need to spend days cleaning things up, a practice that is sure to (rightly) make your whole organization uneasy.