Ruby type conversion
kddnewton.com
kddnewton.com
> raise an error implicitly - effectively analogous to praying you get the right types
That's...not the case. Not explicitly testing or raising an error is neither “praying you get the right types” nor (as the piece later claims) the worst option, or leaving things to the next developer.
Its deferring type checking and error reporting (or type conversion) to some other method that the argument is passed to, and its absolutely what you should do 100% of the time instead of adding additional layers of redundancy if (1) you are passing the argument to a method that’s interface commits to the right type verification or conversion for the use case, and (2) you don't (in the case of error reporting) have a need to report errors differently than it will.
You may be tempted to use a lot of meta programming, because Ruby makes it easy. Resist the urge and only use it if you have no other option (which is rarely the case).
Byebug (or whatever debugger you have available) is your best friend. Also using your repl (irb/rails console) will let you “play” with your application and use your application like a shell with a domain specific language.
If you have access to Ruby 3.0, absolutely learn how to incorporate static types into your application it will save you so many headaches in the long run.
If you’re working on a web app, learn how to use your database without the ORM. ActiveRecord, for example, is really nice but if you don’t understand the underlying SQL it generates you’re going to be in for a word of pain. Learn the different ways to inject custom SQL into your active record queries. Use the .merge function to easily create complex queries using scopes from multiple activerecord classes.
Checkout Trailblazer to learn modern paradigms for building web apps with Ruby.
If your employer will pay for it, or you can afford it: Rubymine is absolutely worth every single penny. Use the 30 day trial and you’ll be hooked, I can almost guarantee it.
Take a few minutes and understand how the Ruby Ghost Class works, it’s seldom useful but you’ll impress any senior developer with his salt if you know what it is and how it works.
Why would I have different debuggers available? Can't I just choose the one I want locally?
You can use whichever you want but usually one will be specified in your project Gemfile because someone on the team likes that particular debugger and added it long ago.
Also Russ Olsen’s books.
I apologize for the digression, but Shopify today reminds me of some Delphi/object pascal shops I’d engaged with earlier in my career. Where the tooling became the primary focus and identity of the staff rather than the solutions (a sort of cargo culting off of that initial business success), and that focus meant the firm ended up being staffed with what could best be described as big fish in little ponds (e.g. the “Delphi expert” who was the guy who stuck with Delphi after everyone else had moved on to other technologies), in a recursive loop.
[1] - other successful companies started with Ruby / RoR (though in many cases it could be called legacy), but right now it seems that 100% of Ruby advocacy comes out of the halls of Shopify. The firm has turned to evangelism.
While we're sharing anecdotes: I like to advocate for Ruby but have never been a Shopify employee or even customer :)
e: where 'customer' == seller
I mean, materials coming out of Ruby and Rails are so rare and few I could hardly call them evangelism. And for the first time ever in history RoR has some decent resources backing it. Compared to Python, JS, Go.
And if people dont like the word dying, then RoR is definitely in decline. So doing a little bit of push and PR or evangelism isn't so bad.
https://charliereese.ca/article/top-50-y-combinator-tech-sta...
No one should cargo cult off of that. Ultimately the product is magnitudes more important than the technology (at least in most cases).