Tag: Ruby on Rails

Caring about Costs is Cool

But costs aren’t just about the bottomline, they’re also a measure of efficiency. I have a distinct distaste for waste. Money spent on the frivolous or the ill-considered is money that can’t be spent elsewhere. Like an engine drinking too much oil just to run. Tight tolerances (but not too tight!) are a joy in themselves.

Source: Caring about costs is cool

I’ve been a fanboy of DHH for many, many years. Yes, he created Ruby on Rails, which I’m still enamored with, 14 years later, so we have that in common, and as someone who’s made a living using it for the past 10 years, that’s a big deal. However, he’s one of only a couple of people “on the internet” with which I agree with on almost everything, and I’ve never really understood why until this post.

Of course I’ve known that he was an F1 driver, but you can probably drive those cars without understanding the engineering concept of correct tolerances in an engine. That he intuits this premise deeply enough to draw this analogy is the key I was missing to understand my fascination with him.

I may be a programmer (and system administrator, and network engineer, and database architect), but I’m a mechanical engineer at heart. It’s how my mind works. I see how things are related and interconnected. I tell everyone I work with the same thing: I’m awesome at seeing the trees, but pretty bad at seeing the forrest. I’ll give you options; you make the decisions.

Being a physical engineer, whether mechanical or civil or electrical or aeronautical or nuclear, isn’t just a vocation; it’s a way of thinking about the world and how it works. In this way, I think our thinking lines up really well, and I think that leads to thinking basically the same way about most everything else.

It’s a theory, anyway.

37signals Dev — Vanilla Rails is plenty

In our example, there are no fat models in charge of doing too many things. Recording::Incineration or Recording::Copier are cohesive classes that do one thing. Recording::Copyable adds a high-level #copy_to method to Recording’s public API and keeps the related code and data definitions separated from other Recording responsibilities. Also, notice how this is just good old object orientation with Ruby: inheritance, object composition, and a simple design pattern.

Source: 37signals Dev — Vanilla Rails is plenty

This is an “implementation” of my guiding philosophy of programming:

If you truly understand the process you’re trying to implement, the code will “fall out.”

This article is discussing adding a Rails concern for making ActiveRecord objects copyable and “incineratable,” and then implementing these operations in PORO models. That’s great, but this sort of redirection is only needed to commonize the human-to-machine naming that might be used for different classes in the application. (There’s probably a term for this, but conceptualizing the terminology used in classes and methods is an art unto itself.)

I don’t think I’ve ever written a concern, but, then, I’ve never written a Rails application (out of at least a dozen and a half now), with 500 classes, which would inevitably have some overlap in their “business” functionality. My current app is the most complex thus far, and it only has 52.

If you don’t have that situation, you don’t need this level of abstraction, and, and — and here’s the important part — if you do have that situation, you will find yourself starting to write duplicated code. When this happens, as a programmer, your “spidey sense” should start tingling, and telling you there’s another level of abstraction to implement.

And that’s what I mean about the code “falling out” of implementing the actual process of what you’re trying to program.

I suppose there’s a case to be made here that you might wind up with duplicated code on a large codebase, simply because one programmer didn’t know what another programmer had done, but these kinds of things will happen. Refactoring the duplication, once discovered, is just part of the job.

The Case for C# and .NET. It has been interesting as I’ve shifted… | by Charles Chen | ITNEXT

It has been interesting as I’ve shifted out of .NET ecosystem which I’ve worked with on the server side (and some stints of desktop…

Source: The Case for C# and .NET. It has been interesting as I’ve shifted… | by Charles Chen | ITNEXT

There are a couple of takeaways from this article. He talks about it from the perspective of a fan of .NET. I see strong points in favor of Rails as well.

First and foremost, I want to talk about speed. As a fan of Rails, I hate it when critics bring up the speed of Ruby, because I have to acknowledge that there is a definite, unavoidable penalty there. And why shouldn’t there be? It’s the interpreted nature of Ruby that makes ActiveRecord in Rails so dang flexible and easy to use. But I came to using Rails after about 10 years of using PHP, and it was painful to compare page load speeds in apps I rewrote from PHP to Rails. However, the relative productivity of the Rails stack made it a no-brainer over PHP for me.

In this article, the author compares some particular benchmark amongst various languages typically used for web application development. Here, he’s pointing out how slow Javascript is compared to .NET. But what I want to point out is that Ruby’s performance is often discussed in the context of using Java, and there’s basically no difference.

Further speed point here: https://benhoyt.com/writings/count-words/

Another thing to point out is the package mess. From the top graph, above, you can see the explosion of dependencies in the Javascript stack. Comparatively, it dwarfs everything else. Combine that with this graph, below, and the situation gets even worse. Sure, by this, you can see that .NET stack wins this race, but it’s also interesting to me that Rails clearly comes in second, especially when you also consider that it has zero critical vulnerabilities.

Over and over, Ruby and Rails gets dissed, these days, as somehow being unuseful, for a variety of reasons. I find those reasons specious. Over and over, when you dig into the rationale behind those reasons, you find out the situation is better than people give it credit for being. Rails continues to be a strong contender in the web application development world. Lots of big players continue to use it, despite how critical the HN crowd is about it. Even if it weren’t suited for those big, commercial web platforms, it would still continue to dominate in writing small, focused, line-of-business CRUD apps, and I continue to find it amazingly powerful to work with.

If I were to criticize the Rails stack, my first point of contention would be the Turbolinks thing. I’ve been sort of forced into using Ag-Grid as a drop-in Javascript data table widget, and, despite a lot of effort, I can’t find a way to make it play nice with Turbolinks.