DEV Community

My First 12 hours with Ruby

David J Eddy on December 13, 2018

Cross posted from my blog. Background For the last 10 years or so I have been squarely a PHP developer. From version PHP 4 around 2000 up to and ...

Read full post

Philip Hallstrom • Dec 14 '18

If you’re just getting started a couple suggestions:

Replace rvm for rbenv. Much less intrusive to your shell.
Pay close attention to the distinct between what is Rails and what is Ruby. Rails adds a lot of nice methods that aren’t ruby. It also adds a lot of magic that isn’t specific to ruby. A good grounding in Ruby will go a long way in clearing up said magic.
The Well Grounded Rubyist is one of the best books there is on ruby. manning.com/books/the-well-grounde...

David J Eddy • Dec 14 '18

Thank you Philip! I will try out rbenv. I was not a fan of rvm changing my system Ruby version every time I wanted to change versions. I have been very aware of the Ruby VS Rails delimiter. I want to learn the language before jumping into any frameworks. Any other books you would recommend?

Philip Hallstrom • Dec 14 '18

Probably not the best one to ask as I've been doing Ruby long enough all the books I read are years and years old. On the Rails side I hear very good things about railstutorial.org

David J Eddy • Dec 14 '18

All info. is welcome info Philip.

Daniel Golant • Dec 14 '18

"The optional paren's was confusing at first, but quickly mentally internalized."

Same. I've gotten used to it now, but I still mostly only use it in tests, where RSpec matchers read more fluidly without parens.

I will say, since starting with Rails around 8 months ago, every time I think about starting a new side project I find myself sad that nothing else seems to give you as much as RoR does out of the box

Scott Tadman • Dec 13 '18 • Edited

It often takes tens or hundreds of hours to produce code. Ruby's big advantage is that you can write less code and get more done, it's very programmer friendly. Even if the resulting code wasn't as "fast" as alternatives, you get it working sooner and can start optimizing as necessary.

The power of Ruby's data manipulation methods like Enumerable is considerable and you can often solve difficult problems by chaining together a few of those methods with a tiny bit of glue.

Since computers are stupid fast today it's rarely necessary to get too aggressive with optimization. You can throw hardware at the problem until hardware itself becomes expensive. It's not worth spending a month shaving 5% off your runtime if you're running it on a $5/mo. server. You gain nothing. It might make sense if you can run on 25 servers instead of 40.

Tomek Buszewski • Dec 13 '18

I tried Ruby (with Rails) for some time. I was in love with how easily and quickly I can create working applications. But I decided to go with Python in a long run, because it felt more natural, as I come from the JavaScript world.

David J Eddy • Dec 14 '18

No problem with that. Right tool for the right job. As long as the work gets done.

Tomek Buszewski • Dec 14 '18

This is a great approach! :)

chenge • Dec 13 '18 • Edited

You can add "ruby" after 3 symbols to color.

[0 => 'value'] #array
{'key' => 'value'} #hash
1+2=3 # int + int = int
1.2 + 2.3 = 3.3 # dec + dec = dec
self.validate data #object.method parameter_date

Scott Tadman • Dec 13 '18 • Edited

Shows that the "array" there isn't really an array, but an array with a hash in it:

[0 => 'value']
# => [{0=>"value"}]

Daniel Golant • Dec 14 '18

Point 2, performance of the core app, is actually interesting given the current shift back to server-side rendering paired with smarter CDNs/Edge. How much perf (roughly translating to "cloud provider cost") can you take on before it outweighs the gains in dev productivity? I am going to guess no one's hit that point, at least not purely because of stack choice.

Pan Chasinga • Dec 14 '18

Having known Ruby made me a better functional programmer.

David J Eddy • Dec 14 '18

Very valid point in regards to frameworks. However I would argue that medium to large apps performance is more of a concern than for small / meds. Larger the applicaiton the slower they tend to operate. At lteat in my experience. LArger the app, the more people and effort hours have done into to the logic the more 'quick fixes' and cluges to 'get it to work'. Not to mention to geographic distance between processing, database, etc. These leading to more and more slowness.
Of course benchmarks are not the only measuring stick. Simply one of many. CDN's, caching, right-sized hardware; many solutions exist. Benchmarking is simply one of many parts of the stick.
At you point out, the comparisons are based on familiarity. One of the reasons I want to learn Ruby is to expand the scope of experience.

You also make an interesting point Daniel. The industery is definatly in the grips of a 'big server, little client' trand.

David J Eddy • Dec 18 '18

"Larger the application the slower they tend to operate" was a response to "When you're working with a small- to medium-sized app, speed is often a greater concern than freedom". I think there was a miscommunication between development speed and execution speed. That's my bad.

No language overcomes I/O latency due to network. I did not mean to insinuate one could.

"o, if we're to analyze something objectively, we should consider all of the major yardsticks, right?..." 100% yes. Benchmarks are but one tool. I did not mean to sounds like I was deriding one over the other. Simply reiterating what the tool of benchmarking stated.

Micah Geisel • Dec 13 '18

Can you talk a bit more about modified SemVer? How does Ruby's SemVer differ from others'?

David J Eddy • Dec 13 '18

Sure thing Micah.

Ruby's Versioning (+2.1 onward):
MAJOR: increased when incompatible change which can’t be released in MINOR
Reserved for special events
MINOR: increased every christmas, may be API incompatible
TEENY: security or bug fix which maintains API compatibility
May be increased more than 10 (such as 2.1.11), and will be released every 2-3 months.
PATCH: number of commits since last MINOR release (will be reset at 0 when releasing MINOR)

SemVer:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

So Ruby is using a version number based on time schema, whereas SemVer is change set based. As a developer, I don't care when a change happened; I can how bad a change is going to wreck my weekend. #my_opinion

Micah Geisel • Dec 13 '18

Ah, yes, I see what you mean now! I thought you meant the Ruby ecosystem in general, but I understand now that you meant the Ruby language itself. I agree with you; this irks me too! Rails is also guilty of this, but getting better about it. At least almost all of the other gems in the Ruby ecosystem are good about following SemVer. :/

David J Eddy • Dec 14 '18

Exactly. I was handed a Rails project. Updated from Ruby 2.7 to 2.9 and it broke the app due to a class inheritance change. Very not expected behavior. :( . I had to roll the language version back to get the app to work again. I'm sure we will get to update the app dependencies eventually; I just did not expect a minor version update to wreck things to badly.

1st world problems right? :S

David J Eddy • Dec 14 '18

Thank you for the perspective Aleksei, I will give Hanami a look.

David J Eddy • Dec 14 '18

Thank you for the resource Aleksei, I'll check out Phoenix.

Daniel Golant • Dec 14 '18

Thanks for the info, will look into.

Daniel Golant • Dec 14 '18

Elixir, Erlang, and Ruby. I assumed based on your comment that you enjoyed some aspect of each one. If that’s the case, I’m just curious what those aspects might be.

David J Eddy • Dec 14 '18

Phoenix has microsecond (!) response times o_0. Wow.

David J Eddy • Dec 14 '18

Python is harder for functional programming? Interesting. I am curious, do you have any person experience examples you would be willing to share.

Daniel Golant • Dec 14 '18

What about those three languages did you enjoy?