DEV Community

Cover image for My First 12 hours with Ruby

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 ...
Collapse
 
phallstrom profile image
Philip Hallstrom

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...

Collapse
 
david_j_eddy profile image
David J Eddy

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?

Collapse
 
phallstrom profile image
Philip Hallstrom

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

Thread Thread
 
david_j_eddy profile image
David J Eddy

All info. is welcome info Philip.

Collapse
 
dangolant profile image
Daniel Golant

"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

Collapse
 
tadman profile image
Scott Tadman • 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.

Collapse
 
tomekbuszewski profile image
Tomasz Buszewski

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.

Collapse
 
david_j_eddy profile image
David J Eddy

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

Collapse
 
tomekbuszewski profile image
Tomasz Buszewski

This is a great approach! :)

Collapse
 
chenge profile image
chenge • 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
Collapse
 
tadman profile image
Scott Tadman • Edited

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

[0 => 'value']
# => [{0=>"value"}]
Collapse
 
dangolant profile image
Daniel Golant

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.

Collapse
 
pancy profile image
Pan Chasinga

Having known Ruby made me a better functional programmer.

Collapse
 
david_j_eddy profile image
David J Eddy
  • 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 profile image
David J Eddy

"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.

Collapse
 
botandrose profile image
Micah Geisel

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

Collapse
 
david_j_eddy profile image
David J Eddy

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

Collapse
 
botandrose profile image
Micah Geisel

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. :/

Thread Thread
 
david_j_eddy profile image
David J Eddy

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

Collapse
 
david_j_eddy profile image
David J Eddy

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

Collapse
 
david_j_eddy profile image
David J Eddy

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

Collapse
 
dangolant profile image
Daniel Golant

Thanks for the info, will look into.

 
dangolant profile image
Daniel Golant

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.

Collapse
 
david_j_eddy profile image
David J Eddy

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

Collapse
 
david_j_eddy profile image
David J Eddy

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

Collapse
 
dangolant profile image
Daniel Golant

What about those three languages did you enjoy?