Seven.new

Back in January, David Heinemeier Hansson answered the question What makes Rails a framework worth learning in 2017? on the Q&A website Quora.

After a few years when JavaScript frameworks have been monopolizing the limelight, it seems like there's enough new framework fatigue for Rails to become an exciting proposition once again. And it's interesting to see that DHH answers this question by saying that the same thing that made Rails exciting in 2004, still make it so in 2017. It's a full-stack web framework that does it all.

While acknowledging JavaScript frameworks like React and Angular, DHH underlines the fact that despite all the front-end progress and excitement, there's always a need for the back-end for databases, computing, job queueing, mailers, push notifications, and much more.

It's an interesting post that sets the tone for the upcoming Rails 5.1 release later this year.

You probably know about Ruby Toolbox and other similar tools to find popular Ruby libraries and tools.

While popularity is always somewhat relevant when picking an off-the-shelf solution, because if more people use something the more likely someone is to keep maintaining it, it's definitely not a panacea to determine the maturity and quality of an open source project.

Sergey Dolganov from Evil Martians created OSSERT, an open source project classification system that takes a lot more than popularity into account.

It breaks projects down into three main components:

• Maintenance
• Popularity
• Maturity

Each of these components includes a metric ton of signals in order to deliver a grade from A to E (for experimental).

For Maintenance, OSSERT looks at issue and pull request processing times, active issues and pull requests, number of releases, commits, commits since last release, etc.

Popularity looks at users, issue reporters, watchers and contributors, questions on StackOverflow and the ranks of people who ask and answer them.

Finally Maturity looks at the number of users creating issues, commenting, submitting Pull Requests, existing forks, dependent libraries, and so much more.

I don't think I've ever come across a more refined tool to find sustainable open source projects before. It does have some flaws (notably established projects which require low maintenance) but for the majority of dependencies, it's a great idea to look at OSSERT.

There's nothing quite like a good blog post looking at core Ruby classes you often take for granted.

Marc Gauthier wrote about the subtle differences between Ruby's to_s and to_str methods. While they look very similar, to_s is defined on Object, which means virtually every Ruby object responds to it.

to_str however isn't defined on Object and usually means that the object CAN behave like a String even if isn't necessarily an instance of the String class itself.

Therefore calling to_str on objects that define it may not actually return a String instance, but merely a String-like object.

One more example of something that quacks but isn't necessarily a duck.

Piotr Solnica announced in late January the release of ROM 0.3.0 which includes the first stable versions of rom-sql and rom-repository.

From now on, all relations will have schemas, which means the schema API is now available from all adapters.

Speaking of adapters, the Postgres one now supports more types like enum, point, and inet.

You can now pass relation objects to join, left_join, and right_join methods; and there's a new assoc method on Relation instances to easily prepare a joined relation.

If you want to coerce data from a column that uses a special type like JSONB, you can easily have it cast as a special type automatically when it's being read from the database.

If you've only ever been exposed to ActiveRecord, I recommend looking at ROM, which alongside Sequel makes for a very interesting ORM alternative.

Speaking of coercion. Luca Guidi — author of the Hanami web framework — wrote a two part series on Ruby Coercion Protocols.

In the post, Luca laments the over-reliance on type checking with the is_a? method in gems since it makes it difficult to define Ruby classes that act like core classes but don't necessarily inherit from them.

This also leads to cruft from what Luca describes as unneeded inheritance when people do inherit from core classes like Float without thinking about the invisible public API they suddenly expose on their objects, which now implement all of Float's public methods.

Instead of relying on type checking, his simple solution is to attempt to coerce inputs by simply calling explicit coercion methods like to_f on them.

By doing this we allow any all object that implement to_f to become compatible with our interface instead of denying them entry solely based on their identity.

Similarities with the real world are probably not coincidences.

A common struggle for Rubyists is dealing with nil values.

We can wrap things in conditional to blanket ourselves against them, litter our code with ampersands, ... or we can use the Object-oriented power of Ruby to embrace them.

In a Ruby Tapas joint venture with Upcase, you can discover two ways to eradicate nil values by using the Special Case and Null Object patterns.

The basic idea of the Special Case pattern is simple, if you're afraid of the special case, extract an object for this special case. So the next time you check that current_user, think about making a GuestUser class that responds to the same methods your current_user would.

The Null Object pattern merely expands on that idea to push it a bit further.

Remember that all Ruby Facets listeners can get a 10% off discount on a Ruby Tapas subscription which in turn helps to fund the production of the show. I can't think of a better way to make something out of nil.

To get that discount simply use the coupon code "rubyfacets" spelled as one word on the subscription page.