________________________________________________________________________________
Having picked up Rails 9 years ago and having been using it literally daily ever since, it's joyful to read from someone that is just starting.
I also started with
https://www.railstutorial.org/book
, highly recommend it.
I also loved Metaprogramming Ruby (Paolo Perrotta) - it's more advanced and starts to open your mind to how Rails magic DSL's were built.
I just bought today "Rebuilding Rails" (
), heard great things about it.
Ruby and Rails are amazing, and I wouldn't trade it for any other language/framework out there.
Those are great resources. One I'd add to it, for general ruby programming, is the Well Grounded Rubyist (
https://www.manning.com/books/the-well-grounded-rubyist-thir...
) . It's been kept up to date (3rd edition was released in 2019) and I found it very readable and informative.
Also I will add Practical Object Oriented Design in Ruby, by Sandi Metz (
). It was a great help to me when I was first beginning to self teach programming years ago. A lot of it applies no matter the language; I haven't written Ruby in probably 4 years but the principles in that book guide my programming to this day.
Highly recommended! I started with the Rails Tutorial as well and read The Well-Grounded Rubyist afterwards to get more in-depth with Ruby.
After that, I bought Bob Race‘s tutorial Build a Saas App with Rails which covers more practical aspects of building a multi-user SaaS app using well-known gems (instead of building everything by myself as in the Rails tutorial):
Agreed, this is a great book. In the past I used to read and write a lot of Ruby. An earlier edition of the book was the single resource that taught me the most.
The only programming language book I've enjoyed and benefited from as much since then is Fluent Python.
That was one of the books I picked up early in my career and still keep a well-loved, dog-eared copy. It's information-dense without being overwhelming, and teaches a lot of important Ruby concepts. I'm glad to see it's being kept up to date.
Great book. I own the second edition.
I really should try Rails again. I LOVE ruby, but have been anti-rails for a while and I am not sure I am right for that.
I got into Ruby programming through Rails... but in 2005. Rails was brand new (I think I was on version like 0.12 or something?), and I slowly moved away from it to things like Sinatra and Sequel. Rails had some huge performance issues, and active record was pretty unusable at any sort of scale unless you did a lot of custom SQL.
I know it has come a long way in 15 years, I should try again
I'm sure it depends on the complexity of the app you're building. For simple crud-ish apps (ecommerce, online auctions, etc) I've found that I don't need to write even a single line of custom SQL, and performance is generally good (lots of N+1s, but these are easy to avoid with things like bullet). I also love being able to let Rails render most HTML, and the few things that need to be very dynamic you can just throw a single react component in without worrying about the usual SPA problems.
If you're just prototyping stuff, I don't think you can beat Rails for productivity. But if you're targeting something more enterprise or large scale, I don't think it's a good choice. Go/Rust are so much faster (not that that matters a lot), and even things like C#/Java pretty nice to use nowadays.
"lots of N+1s, but these are easy to avoid with things like bullet"
What is bullet?
It is a plugin/gem that helps you track N+1 queries.
https://github.com/flyerhzm/bullet
It is a gem that tells you when you are accidentally making a N+1 query and suggests the best way to fix it in AR (it also tells you when you have over used includes that are not needed and other such tweaks to make to your queries).
It's definitely a lot better -- performance-wise -- now. It has its flaws but I still feel like its one of the best frameworks out there.
I read all of those and would like to add two more:
1) _Learn to Program_, by Chris Pine. It's the best book I've read on learning to program in any language.
2) Practical Ruby Projects: Ideas for the Eclectic Programmer, by Topher Cyll. In a sense it wasn't "practical" at all. But it was a joyous eye-opener to all kinds of applications that turned me into a whirlwind of enthusiasm for months!
Aw, thanks! (3rd edition is in the works)
> Learn to Program, by Chris Pine
My first programming book, 10 years ago in a few months I think. Great read.
My favorite thing about it was how it made even trivially simple exercises fun by making the content humorous. At the beginning you really need that extra reward!
7 years for me next month
Love the Rebuilding Rails concept! I'm doing a very similar thing in Ruby, focused more on "web application development from first principles" (
https://theodorekimble.ck.page/e0bb43b156
). I know I better absorb concepts if I can trace them back to a more fundamental "truth".
Curious to hear if anyone else has found success with Rebuilding Rails, and what they found most helpful.
If you want to do the same thing (build up from 1st principles) with CSS, I ravingly endorse Axiomatic CSS as defined and implemented in
Disclaimers: no affiliation, just a very satisfied customer. IME the free content alone is illuminating, and having paid $100 to access to the full "book" incl all the layouts' implementation it was a bargain.
Starting my projects from every-layout instead of using foundation/bootstrap has been like the move away from jQuery as js developed.
I learned RoR from the wonderful Agile Web Development with Rails (2nd edition). David Black’s “Ruby for Rails” and a little later “Eloquent Ruby” helped me to better grasp the difference between Ruby the language and Rails the framework.
I was a kid, and read the first two books 14 years ago. One on a holiday in Kenya and the other in Egypt. No distractions, just travel, family and reading.
These days it seems like a lot of junior developers want to learn it more interactively. I hope books stay popular. In my opinion, they do a great job at explaining the why & the reasoning, instead of just showing you how.
The Rails tutorial is of exceptional quality. I wish more software had explanations that clear.
Just starting to learn rails myself so I am glad I found this thread. I have been going through
. It has a lot of example problems and projects which helps me learn. That is also why I like
https://www.railstutorial.org/book
(although it is more like a well done tutorial than example problems).
The thing to read to really accelerate your Ruby/Rails education is the Rails source code, particularly the Model-adjacent classes and perhaps the router/controller as well.
Then use the patterns you find! No greater joy than your own project specific functionality feeling like a native part of Rails and it tended to make me use more robust approaches.
I see that Rebuilding Rails doesn't mention a version number of the book, and sales page is actually very uninformative about the actual content. Elsewhere I see it was first published in 2012- How relevant do you find the 'latest' version to modern development? And what is the latest version, has it been updated for rails 6?
Have you got any other recommendations for intermediate to advanced rails topics?
I just downloaded the free chapter. I don't see a Rails version number, but it does mention Ruby 2.6 and the book is dated thusly:
> This Version: April 2020 (Free-Chapters Edition)
> Rebuilding Rails is copyright Noah Gibbs, 2012-2020
Metaprogramming Ruby by Paolo Perrotta has the best explanation of Ruby's object system I've seen.
It's a must-read for anyone working with Ruby, even if you have no interest in metaprogramming. Despite the title, it's a very approachable and widely-applicable book.
I was in high school when Rails came out. I wanted a Mac so bad just for TextMate. But Rails and the whole philosophy of 37Signals even going back to Getting Real were total life changers. Everything from how I act to my writing to my presentation skills have all been influenced heavily by DHH and Jason Fried.
If anyone has recommendations for soft skills books that are relatable to tech please let me know.
the other book that is great for ruby is eloquent ruby. one of the best programming books I've read and one of the few that I've read cover to cover instead of piecemeal.
Rails is in a really good place.
When I learned it back in 2015 there were so many resources for learning, it felt like every time I had a specific problem related to a feature I was implementing there was either a railscasts or gorails video on it, along with 10 blog posts and stack overflow results. I can only imagine how much better it is now.
It has been one of the only semi-modern learning experiences where I was able to go from ground zero to building a real application just by reading the docs, getting started guides and Googling.
Opinions combined with a massive community are an awesome combo.
It's definitely noticeable when you try to learn a newer framework with a much smaller community and less opinions. You could end up Googling for what you might think is a common thing to solve only to find zero answers in sight, or there might be a few scattered posts that are outdated and partially implemented because everyone has their own opinions and go off in their own directions. It's just dead end after dead end and getting stuck trying to pioneer stuff without a strong grasp on how things work.
This 10,000 times. And it’s not just Rails, the quality of the Rails documentation made an impact on the Ruby community that was generally replicated. Compare that to the JavaScript world where cornerstone, insanely popular libraries will have documentation that covers roughly 10% of a library’s API surface area and maybe one simple example that doesn’t cover production use cases. And dozens of out of date Medium blogs.
I don’t understand how people operate like this day-to-day either guessing at APIs or having to dig through large, complex open source codebases just to figure out basic library functionality.
Maybe it’s my conception of how things should work that’s off, because I’ve met developers who actually enjoyed guessing at library APIs and said they don’t like reading documentation. I hoped they were the reckless fringe minority. Maybe they are actually the majority?
I worked so much faster in Rails. The community made that possible by writing well about how their libraries were meant to be used. And if anyone’s response is “well you should read your open source dependencies’s code anyway,” many times I did have to jump into the code of Ruby libraries and it was a lot easier to read the codebase when the library APIs were well documented, providing a context for understanding. I miss Ruby and Rails.
I've been doing Javascript for a long time and have rarely run into issues with a lack of documentation. Maybe in projects with like 10 stars on Github ran by a single developer but in all of the major Node projects, you're going to have ample documentation and support for implementing said libraries. Just my take.
I've found most JS libraries are as the parent described, low coverage, garbage basic examples. Maybe this isn't the case on major huge libraries, but for your every day library, it's like there's a rule where you have to write the worst docs that still look pretty and all there at first glance, but totally useless and frustrating time and time again. The docs usually feel smug in the way they make it seems so easy and then they don't tell you how to do anything useful, like you are the one in the wrong for trying to use it for a real example or that you are an idiot because you can't just infer how everything would work without docs and examples. You have to learn from StackOverflow issues to understand how to actually do anything. That's my view. Maybe in general people just don't remember anything with good docs, and only the bad examples.
I feel like my ambitions for doing anything quickly are destroyed time and time again after finding a library to help me do it easily and fast the docs are the same old garbage. And these are the top starred libraries for their purpose. "How can this common thing to do on JS not have a huge, widely used and well document library that has existed for years?". It still blows my mind how after years and millions of people using it, so many libraries still have the worst docs.
Ever used Sequelize?
Haha! That’s the one that immediately came to mind. What a dumpster fire.
My question is why Node docs on nodejs.org don't have search
> It's definitely noticeable when you try to learn a newer framework with a much smaller community and less opinions. You could end up Googling for what you might think is a common thing to solve only to find zero answers in sight
I have felt this exact way when I'm Googling for problems running Rails in modern cloud environments. It seems like there are loads of problems that are largely unsolved in the community at large when you want to go beyond Heroku and stand your app up in containers against cloud components using best practices. As a Rails newbie it has been downright painful and there have been many cases where I wish I was still writing a language like C# or Java where containers and modern cloud architectures have been embraced instead of shunned.
For a sample of one, I've run rails in containers for years without problems. Is your problem the containerization, or trying to split a rails app into microservices?
I've also split a rails application into separate services, but if you really want the MICROservices approach, then you're going to lose most of the advantages of rails.
As someone who learned Rails for the first time last year (previously worked on C++, C#, and Python projects), I concur. I find that most of the SO posts/other discussion of Rails stuff tends to be older, usually pre-2015, and that can be painful when dealing with any technologies that have substantially changed in the past 5+ years.
Almost every modern Rails app runs containerized. Heroku is containerized! What are you having trouble with?
that seems beyond the scope of rails itself. why would you want to complicate deployment as a newbie? what problems are you facing that containerization specifically solves for you, rather than deploying to a (virtual) server directly? and why not heroku to start?
Can't speak for GP, but in my case I had to learn Rails in an environment where the previous devs were no longer available and the whole app was developed on EC2 instances by a different team. Later, the company decided that containerization was the Next Big Thing and we needed to port the app or else we'd have either no platform to run on or no job. I would have loved to do the simple "just run it on Heroku" thing but sometimes that is just not possible due to external pressures. A lot of the success of Rails is due to its "my way or the highway" methodology where you either conform to the vision of DHH or you can get lost, but the downsides of this priciple are obvious when real life won't conform to his vision.
What about rails doesn’t “just work” in a containerized platform?
I'm a Rails newbie, not a software newbie. I was brought in as an engineer with no Rails experience but deep Cloud experience to help break a large complex monolith and yes, we're running into the same "DHH's way or the highway" quagmire that infests the Rails world, as mentioned in a sister comment.
When learning something new, it's usually best not to fight against the stream. After you understand it well, then your efforts to bring it into your old way of doing things will be more fruitful.
Large complex is usually just a bad architectural choice or misunderstanding your business requirements
If anyone has any tips or documentation that might help with regards to Rails containerization, I'm interested in knowing as well.
What specifically are you running into? I may have trouble seeing any gaps in documentation because I’ve been running rails in a containzerized environment for years and it seems to just work
Exactly the same - the community around Rails is what makes it shine. The resources, the tooling (so many well maintained gems out there in the Ruby-sphere, even if a lot of them being Rails-oriented makes other frameworks second class citizens).
Railscasts and GoRails are some of the best resources out there - and without wanting to stan Chris too much, if you're looking for an easy to way to deploy Rails apps, I'm a very happy customer of Hatchbox [0] and Jumpstart Pro [1]. Should really get around to a GoRails subscription at this point...
[0]
(I feel like I sell this in every HN post about Rails, but it's a great tool and he deserves as many customers as possible)
[1]
I 100% agree that Rails is in a good place as a framework, and that that is largely because of a very active and engaging community and devs who take criticisms and opinions in consideration.
I also think that it is generally easy to find answers to things by Googling them and finding blog entries or stackoverflow answers. But honestly, the Rails documentation is absolutely terrible. Be it apidock.com/rails or api.rubyonrails.org, it's just way too sparse. It's funny because the Ruby documentation is great.
FWIW, when i toyed a bit with Rails (gotta pick it up again, seriously) i used Heroku but quickly migrated over to a Dokku instance ran on my local NAS.
Getting Dokku running on something like Digital Ocean should be easy as pie...
I hesitate to state that Ruby is making a comeback, because I don't think it ever really faded (isrubydead.com ;-) )…but it definitely feels like the momentum is picking up. 2021 is going to be _amazing_. Ruby 3. Rails 6.1+ along with new HEY-derived innovations. ViewComponent + StimulusReflex is quickly becoming a powerhouse combo. A ton of useful gems coming out all the time. I myself am furiously working on making Bridgetown one of the world's great static site generators.
Honestly, there's never been a better time to be a Rubyist than right now.
The market (job vacancies) seem to imply otherwise, I rarely see it mentioned in comparison to Python, Go, PHP.
At least in the U.S there are more Ruby jobs than PHP, so what you're saying isn't accurate. In Europe (outside UK) Ruby is weaker I agree; php/.net seem to be way more popular.
Yeh, i'm going off London job market.
Hmm what do you base that on? I'm genuinely curious. Looking at Linkedin I see a lot of Ruby jobs in London, some in really top notch companies. To me London seems like a great place to be a Rubyist.
Just for comparison's sake this is from Linkedin (London Metrpoloitan):
Ruby: 1238
Node: 1940
PHP: 1332
Rust: 157
Python: 9208
Golang: 588 (might be called Go in many jobs though)
Conclusion: Ruby on par with php, less popular than Node but not by orders of magnitute, and used way less than Python. But comparing it to web development languages like PHP/Node, it's right there with them.
If anything Ruby is in bad form in mainland Europe (France, Germany, Netherlands) where for whatever reason PHP is king for startups.
Now for frameworks:
Rails: 480
Laravel: 41
Django: 535
Symfony: 164
Conclusion: Rails is really up there with any other major framework. Could be that some job posts don't mention the framework, but I'm going with the data we have.
Some famous Ruby shops I know are from London: Deliveroo, GoCardless, Funding Circle, Babylon Health. I honestly don't see how this is bad.
Anecdotally I still see it listed a huge amount, as much as ever. Much of the time the apps are more than a couple of years old. I do think the number of startups who will create a new Rails application today as their primary application is much lower, but Rails work is hardly going to dry up anytime soon.
I think I'd rather just be a plumber that be forced to program in PHP
If they had brought in a more intuitive typing system that is inline typing, I would have considered to use it for something as I like ruby itself but guess not.
I am one of those obnoxious people who is trying all the time new web technologies, without deepening the skill for years in just one. Out all the frameworks I have used (Django,Phoenix,Node/Express in all its flavors,.NET Core, Echo) Rails is by far the one in which I feel more productive. Ruby is a lovely language, the ecosystem is mature, there is always a gem for everything and for the kind of applications I do (just 1-3 developers) Rails suits the needs perfectly. All the rest have been very solid and enjoyable frameworks (except for the Node-based ones, sorry) but I still prefer Rails.
Just curious why the (negative) callout for Node-based frameworks like express? How, technically, were they inferior to Ruby (or any of the other languages you listed)?
I like Javascript and Express, so in that sense they are OK. I hate the brittleness of the ecosystem, the "flavor of the month" character, and the explosion of options, there are people who like that setup: small programs that you can plug and play to create your whole stack, I find that tiresome, I prefer big monoliths in which the best options and practices are universally agreed upon.
Ah and I hate Typescript, nice idea, but when you spend 30% of your time looking after all those custom types and end up using an ":any" hack to make it work, this leaves a bad taste in your mouth. If I am going to use strong types I would choose an actual strongly-typed language for that, C# is great.
Somewhat ironic but not sure if you know, Typescript is made by Microsoft and the lead Typescript language architect is Anders Hejlsberg who also was heavily involved in the creation and architecture of C#.
There's no irony in finding limitations when building on a poorly planned foundation that don't exist when starting from a clean slate.
Exactly, the idea is great and you can clearly notice the intention of making JS more C#-like, but the foundation is not suitable. Could you imagine trying to "C++size" the whole Python ecosystem? Shudders!
BTW dude I like your content, after Rails, Phoenix is my preferred stack, so nice, and the community is cool, too bad the job opportunities are not there yet in sufficient quantities.
If you have to end up using "any" on something not too weird, then you probably aren't getting TypeScript right.
The typing system is way better than php, ruby or swift I feel like I'm using a language of a generation behind after using TypeScript.
good thing he didnt think of phps, ruby nor swifts typing system then.
he made a specific example and it holds true. languages like c# and java are just better at it and typescript is kinda in between. not great, but maybe good enough for a lot of people.
I took a rails job by accident- I knew rails was in use but I was interviewed in Go and talked about new things going on in Go micro services. I didn’t expect 40 hours a week of rails / ember JS work and that’s my fault.
I have 12 years with Django and I was shocked there wasn’t the equivalent of the Django tutorial. Everyone says the rails tutorial is good and I’m sure it’s worth the money but no one at work endorsed it (nor provided recommendations for any Ruby / rails tutorials).
Coming from Python, Go, JS/Typescript (react, vue, etc) in my most recent experiences it was really rough. I couldn’t understand some of the rails magic and the docs were horrible compared to Django. Ruby Mine IDE was essential.
I learned how much I love DDL management via code (Django ORM or SQL Alchemy) and how active record did just enough to fool you (which is common in other ORMs).
In the end I left the job for a full time Go position and I’ve missed Rspec every day. The rails (or Ruby in general) toolset really impressed me and I’m using Ginkgo at my current job to get my fix for BDD / specs.
It’s really surprisingly difficult to jump between Python and Ruby. And Rails and Django. They are just similar enough that you think the switch shouldn’t be so tough but all the differences really bite you. Whereas jumping into a completely different ecosystem like JS or Go you don’t have the part of your brain telling you “this isn’t that different, you’ll be fine, look for something familiar.”
Same for me between R's data-frames and Python pandas' data-frames, they kind of do the same thing but they're also _just_ different enough to make switching hard, you're constantly stuck in an uncanny valley
FWIW I require all new hires to work through the Rails Tutorial in their first week. Nobody needs the entire tutorial, but everyone needs parts of it, and it's impossible to know what parts in advance. It's a fairly fun and easy way to get an exhaustive tour of the framework, and afterwards people are pretty much fully productive.
I wish there was an equally good Ruby language tutorial, as my experience is that it's a bit harder to master Ruby than it is to master Rails, but mastering the language is far more valuable.
One thing I found is that using a basic text editor for the first year (or so) of learning Ruby, made sure I understood what the IDE was doing when I eventually switched to it.
I would recommend a chromium protocol based library for golang. Ginkgo is heavy and error prone.
I’m unfamiliar with this. Do you have a specific link with more info?
Would you say Rspec is better than the Python equivalents like behave or pytest-BDD? Curious as I've never worked with Ruby/Rails but I'm aware there are some things that are way ahead of other toolchains (and others that are way behind as you've noted).
RSpec is definitely better, but I've mimicked it this way with
pytest because I didn't like each Given/When decorator in pytest-bdd requiring a separate method to setup. It was way too verbose. I want to be able to quickly nest them, like in RSpec.
So I do:
TestSomeMethod:
TestWhenDateProvided:
def test_it_does_not_use_system_date(fixture, ...):
assert ...
TestWhenDateNotProvided:
def test_it_uses_system_date(fixture, ...):
assert ...
Ah so you’d say the nested setup is one thing that differentiates Rspec.
I’d use inherited test classes for this case, either sharing the setup in the parent and having each child define their own tests, or defining the test cases in the parent and overriding the setup in the child classes.
Seems like the latter might be hard in Rspec? But the former sounds more concise in the Rspec notation, I agree. I think Ruby’s anonymous blocks seem to be the differentiator in the toolset, I’ve not seen a Python DSL that’s as good in that regard.
Define "better". The mocking story and the rspec syntax itself is insanely better than in python. But the actual internals are pretty much comparable in my opinion.
Yes. I would use the tooling inspired by the Ruby tools like factory boy and stick with pytest over behave, personally. I’ve not used pytest-bdd.
In JS mocha or jest are both great.
> The rails (or Ruby in general) toolset really impressed me and I’m using Ginkgo at my current job to get my fix for BDD / specs.
This is, I suspect, the biggest win from the Ruby/Rails ecosystem.
Rubyland went hard-core TDD a long while back -- I suspect largely due to the influence of Pivotal Labs -- and the maturity of the toolset and automation really reflects that.
Every time I work in another language, I find myself very much missing both the Ruby toolchain and (depending on the language) the everything-is-an-object approach.
Not to say that Ruby is perfect, but the tooling really is that good, which is pretty amazing given that Ruby isn't exactly the most parseable of languages -- although on that front, I've got a lot of hope for Crystal:
is there a version manager I should be using?
I am familiar with nvm and pyenv for managing Node and Python versions, respectively, however the tutorial I was following did not mention any Ruby version manager. I took to the internet and found the highly popular, rbenv.
If you want "just" a version manager for ruby, I'd go with rbenv. But if you use, say, node and python too - I'd go with asdf:
https://github.com/asdf-vm/asdf
https://github.com/asdf-vm/asdf-ruby
Keeps the stampede of VMs out of your bashrc.
I've since moved my ruby projects over to asdf for its simplicity, and the fact that you're going to be stuck using something to manage node anyways.
That's a great share! Didn't know about `asdf`, and not having to load ~4 different language version managers is a solid win.
It also looks like `asdf` Does The Right Thing and uses shims, unlike `rvm`, which, as of the last time I checked, overrides shell builtins, which is a straight-up WTF where I come from.
I’m still on rbebv amnbs clones like nodenv.
Blocks are one of the most confusing, yet most powerful elements of Ruby. They allow you to group expressions, save them to a variable, and even pass them to a method. I’m still getting used to blocks and realizing their usefulness, but overall I feel that they condense a lot of code, and also make code more reusable and extensible.
Agreed re: confusion! I've been using Ruby (and Crystal) for years and I'm only slightly ashamed to admit that while I fully understand how to _use_ blocks, I haven't really truly grokked them. I kinda use them and use yield and it all works.
But! Something clicked recently, and I'm not sure why it took so long (maybe it was lots more experience with JavaScript lately?) and I feel kinda dumb that I just realized this:
Blocks are just anonymous functions. That's it. Yield just means "call the anonymous function that was passed in". Yield with arguments (which always confused the hell out of me) is, again, just calling that same anonymous function with arguments.
(I think?)
> Blocks are just anonymous functions. That's it.
Blocks in ruby have non-local return, unlike anonymous functions.
compare `[1,2,3].map {|e| return true if e > 1 }` in ruby to `[1,2,3].map(e => {if(e > 1) { return true}})` in javascript. The ruby version will return a single `true` value, while the javascript version will return an array.
This post walks through a example that resembles my experience writing bugs when I knew way more ruby than javascript:
https://github.com/raganwald-deprecated/homoiconic/blob/mast...
Interesting! I recall reading about this before but I’d forgotten it.
And I suppose one of the things that trips people up a lot about ruby is that the implicit return gives a different result — eg your example but without the “return true if” part DOES return an array, like JavaScript.
yes, exactly! Anonymous functions weren't as common in other languages when Ruby first got popular, so the older Ruby devs had to learn about blocks without talking about anonymous functions, and I think they mostly haven't realized that the world has changed and there's a common terminology that people coming in from other languages will know.
The one big quirk is that Ruby syntax doesn't let you assign a block to a variable like you can assign a function to a variable in javascript. But you can work around that by using the lambda keyword or Proc.new with a block, which will wrap it into an object. Then you can use the & sigil to pass that object into a method that's expecting a block
What ruby blocks have in common with js anonymous functions is that they are closures, so that might be what made them click when you learned about those.
The only confusing and brittle thing is not being able to remember what the behavior of return is inside a block, price, or lambda
Anyone doing/thinking about Rails in 2020 should give matestack a try :) reactive user interfaces in pure Ruby (and Vue.js under the hood!)
https://github.com/matestack/matestack-ui-core
You can roll this yourself with Cells (
https://github.com/trailblazer/cells
) and Stimulus Reflex (
https://docs.stimulusreflex.com/
). I've been watching view_component too but the simplicity of cells keeps me happy.
I've been working full time using both and love the flexibility. My process is mostly using state machines on cells which take in a struct and output the html for that state with Stimulus Reflex.
Trailblazer Cells and Stimulus Reflex are great tools, but one big advantage of matestack (
) is to write UI components in pure Ruby, giving you the possibility to use Ruby's language features creating a really dry and clean UI implementation while having a lot of fun doing so! Adding the reactive core components on top saving you a lot of time and effort creating reactive UIs in pure Ruby. Compared to Stimulus Reflex, you have to write less code and manage less added complexity. That's at least my experience. But as said: Cells and Stimulus Reflex are great projects, don't get me wrong. I just love the pure Ruby thing ;)
@pdoub - can you elaborate on the Vue under the hood? I love ruby, and like Vue a lot. Does Matestack do a translation layer from Ruby -> Vue in JS? Eg: transpile, etc.
Matestack's reactive core components are built on pure Vue.js components. When a reactive component is rendered, Matestack renders a HTML component tag, passing in configuration via props and ships that to the browser. Vue.js on the browser then detects these component tags and mounts the appropriate Vue.js component, which reads the configuration coming from the props and perform the desired (configured) functionality. The HTML within the component tag is used as the inline template for the Vue.js component. It's rendering HTML tags out of pure Ruby on the one hand, and mounting pure Vue.js component on top of that in the browser on the other hand.
Years ago I put together a Rails app to store iPhone/iPad apps for curation. There was a backend that connected to the iTunes API and then I parsed the data elements I needed and entered them into the DB.
The most infuriating thing was realizing that I needed to update the model with a new data element, or that some API responses didn't include the needed data. There was all this controller and model code and then the migrations every time I needed to make a change.
Is this normal when coding any web application at all? I think if I had to do it again I'd just store the entire API response in a single "document" column and query it dynamically as needed. Did I stumble upon why many developers have moved to "noSQL" models of document storage?
You're just describing any software problem where things aren't static or you haven't yet mapped the domain. Storing the whole response in the database so that you aren't losing data is a good solution while you make your logic robust against the domain of values.
You run into this talking to an undocumented API for example. But notice that to "query it later", you still have to write/polish the rest of your logic to handle the actual data which is how you end up with a system that doesn't need to store every API response to disk. This isn't a web thing, it's any time you don't have a 100% handle on the interface between two systems.
Nothing to do with Rails, though. You were trying to create harder to change solutions based on a premature understanding of the values you were working with which caused churn in solutions (like DB columns) that are annoying to change frequently.
But in that situation, you as an engineer have to be able to step back and go "okay, what can I do to handle this at a more dynamic layer until I understand what I'm working with?"
> I think if I had to do it again I'd just store the entire API response in a single "document" column and query it dynamically as needed.
You'd quickly find that it is a lot of code to parse that column and read and write data to it, compared to a normalized database wrapped in ActiveRecord. I've done just that, and it's just a lot more work in the long run. A relational database really is a good thing when you want to slice and dice that data and keep it consistent.
You could have cached the entire API response in a field for a given record (or their own table) from the beginning. Then you could reprocess it if you had to change the schema, assuming Apple didn't change the response on their end in the interim.
Schema changes are normal in web applications, yes.
Kinda, but there's a subsequent phase of maturity where you realise that you are knee-deep in technical debt as a result of spurning the framework and infrastructure and find yourself reinventing relational behaviours such as joins and foreign keys, but badly and expensively and in application memory, because your attributes are a freeform uncontrolled grab-bag of poorly typed whatever, and you'll wish you'd just had the discipline to trust that the framework folks really did know their stuff after all.
What other languages/platforms do you have experience with, if any? Yeah, it sounds pretty normal to me.
Yes, storing the entire API response in a single column is an option, and yes I think you stumbled on some of what drew some people to "noSQL", which has it's own downsides, and the pendulum swings to people talking about how terrible "noSQL" is, but it can work.
Not sure exactly what you’re describing. If the iTunes api was constantly changing that’s sort of an issue in and of itself, beyond whatever database you’re using.
NoSQL's initial purpose was scale/speed. But yes, the flexibility it provides for things like trivially adding fields is another factor that leads to NoSQL adoption.
Try jsonb fields (postgres only maybe?) and the jsonb accessor gem:
https://github.com/madeintandem/jsonb_accessor
I use this for prototyping new apps a lot, where I'm not sure on the best design. Then I migrate to proper database columns when I'm sure of something. Feels like the best of both worlds to me.
Yeah I think I learned this the hard way: even making DB columns can be a premature optimization.
No, the problem was more you were dancing to the tune of someone else's fiddle. It's always boring having to slice, dice and store someone else's JSON data from an API.
As others have noted, maybe you should have just stored that data in a JSON column, but it depends on the app. Making it relational can be useful if you're going to be running reports, etc. on it.
I recently started learning Ruby on Rails about 3 months ago. I had zero knowledge about any web programming. HTML, CSS, Bootstrap, JavaScript is all new to me. Using Ubuntu was also foreign to me, but I tried.
I started watching videos on YouTube, especially from Traversy Media. Then I joined a few courses on Udemy. Reading books was painful, so I started actual working on code. I am building app to create a portal, giving information about non-profits. (planning to release my rookie code in AGPL license). Having a project in mind really helps. I really liked the simplicity of Rails' structured way, but there is a lot to learn and it gets overwhelming, but it is fun and I like it. It was also motivating to know that I could learn programming at age 53. Heartfelt Thanks to all those unknown faces on the internet who are selflessly helping others like me learn new things. Now I realized, that you are never too old to learn something new.
Yes, Ruby on Rails is fun.
Now that Rails has StimuluseReflex / ActionCable (which is kind of an additional learning curve), it's got some incredible potential. I was skeptical of WebPacker at first, too, but also have grown to love it.
Love it, just don’t touch it ;)
I love rails. I want to build products and not muck with tech stacks. Rails and the ecosystem make it easy.
This is my view. I'm a CompSci person who hates mucking in the toolsets and language peculiarities of stacks, but loves product ;)
I have never been able to be more 'meta' in product than I have felt with Ruby/Rails.
Is it just me or is Rails really complex? Its abstractions are so far removed from anything familiar (HTTP, SQL) that its difficult to understand what is happening unless you deeply understand the framework.
The whole thing centers on ActiveRecord. Understand that, and you're basically done. Be warned, though. Once you do, you'll never want to go back to any other ORM's.
Rails is somewhat complex, but it's a weird kind of complexity. In some ways it is like React: it's almost easier if you learn it first, before you know what it's doing under the hood, so you're not asking yourself "how" all the time.
The good thing about Rails is it's very well-documented, and if you just work your way through the entire Rails guide or the Rails Tutorial, by the end it all clicks together and makes a lot of sense, and from there on it becomes really easy.
The point is to rely on the abstractions. :) I get similar feelings, especially having been burned by software in the past that purported to abstract things properly. But perhaps unlike other frameworks/libraries, I think Rails has solid abstractions. Of course they're not perfect, but much like abstractions provided by an OS, they _are_ complex, and you mostly don't have to worry about implementation details. (And when you do, that's okay, because the documentation is solid too and the code is available.)
I've been working with Django lately and I definitely had to learn to let go and trust stuff like the ORM. But after watching migrations get handled automatically and easily adding foreign key relationships to tables, I was hooked. I used to be firmly in the "almost never ORM" camp, but that's changed.
For example, take the idea of inheritance. Low level thinking might sound like, “All the other classes are adding < ApplicationController if they want to use this method, so I need to do that too. Otherwise it throws an error.’’
But high level thinking might be more like, “I need to access the ApplicationController class’ methods. Ruby supports inheritance, so I’ll add < ApplicationController to the class definition to let the compiler know that I’m inheriting it.”
I don't think this is "high level" vs "low level" thinking. Both are just different approaches to discovering the same thing. It's akin to learning guitar through tabulature vs standard notation.
The difference is in the “it throws an error” bit- if you’re including lines of code because it makes your program work but you don’t know why, you’re also potentially introducing side effects and other behaviours that you don’t understand, which will bite you later.
I won't add any value to this thread, just wanted to say thanks to the folks that piled on with additional learning resources. I've always _meant_ to pick up Ruby at some point, and it feels like there's a lot of great information out there to get started.
Asking someone to learn a brand new framework/language in a week as part of a job interview is pretty harsh.
When interviewing juniors, I make them install a new-to-them-language and the job interview exercise is "do this one thing". Since they're juniors, I give them a bulleted list of things to do (so there's no trick). I'm testing to see if they can
1. read and follow directions
2. read other people's documentation
3. ask for help
4. poke around and try things
Most companies will hire a smart person and give them the time to ramp up on the job... I had to learn 3 languages at my very first backend job. They hired me because I was smart. It took me over a month to get fully onboarded and that was their expectation.
I once learned Vue on the go as I reimplemented the company's admin dashboard from static rails-generated templates to a SPA. In a week. As a paid project assignment. It was wild, but super fun. They took too long to make an offer, though, and I ended up somewhere else.
I also completely forgot all about Vue in the mean time.
It really depends on the experience. If you're a beginner and it's your first web job, sure, that's harsh/unreasonable. If you're coming from years of python/JS like the author and soon for a senior-ish position? I don't see anything wrong with it. (As a task itself. As part of an interview... that's complicated)
That's actually exactly the kind of skill I'd look for in a new hire. I don't care which crunchy items you list on your resume so much as your ability to learn and integrate new technical information quickly (as well as a host of other skills, of course).
That said, learning a new thing does take a lot of time, so if I were asking a person to do that I would either commit to hiring them if they complete the learning challenge, or pay them for their time spent that week.
> That's actually exactly the kind of skill I'd look for in a new hire. I don't care which crunchy items you list on your resume so much as your ability to learn and integrate new technical information quickly (as well as a host of other skills, of course).
Of course, but asking someone to spend a lot of hours on this in a week, with no guarantee of a job at the end of it is not a direction this industry needs to go. People have full time jobs, and parenting/carer/community responsibilities.
I was hired for a job a couple of years ago which required a lot of work on a new framework I had never touched before, and rather than the interview being around the framework, they gave me a month of full time employment to get up to speed - on the understanding that if it just wasn't clicking then we would both walk away with no hard feelings.
> Of course, but asking someone to spend a lot of hours on this in a week, with no guarantee of a job at the end of it is not a direction this industry needs to go
I have never seen this from any serious employers. If someone is asking you to do this, then go work somewhere else. Employers are expecting that you learn on the job.
I was going to say "Fine as long as you pay me for the effort", no way I would do this for free. I've had friends get scammed by having them "work out this problem" that takes a few days to complete. Usually it's a scam to get free work. Especially in the web and phone app world
Pivotal expects this as a matter of course.
The interview involves full-time pairing for a day, and you (probably) won't know one of the programming languages.
Pivotal does full-time pairing, and an experienced pairs should expected to pick up languages from new teams on-the-fly. After all, the rest of the team knows the language, and you'll get constant real-time mentorship as part of daily rotations.
This is perhaps the thing that sold me on full-time pairing: you can join a team, _not even know the programming language_, and contribute value to your team from day one.
As an introvert working alone and remote for 13 years, full-time pairing sounds like a nightmare.
On an "attitude" level, it's very useful to understand the doctrine of Ruby on Rails (RoR), as written by DHH [1]. Especially if you're coming from some other paradigms / languages etc., RoR can feel quite different. Understanding the philosophy is a nice window to kickstart the "way" of RoR.
On a more practical level, I've found the official Ruby on Rails guides [2] to be super helpful. I started a RoR job almost a year ago without having done any Ruby at all (I had a Python background). I probably should have gone through the tutorials in the OP and in other comments (rails tutorial book comes to mind). But since I didn't, I used the RoR guides A LOT. And they were super useful. Everything from routes, to controllers, to ActiveModel and migrations. They give you a good starting point to get most of the job done. Highly recommend looking at the relevant guides if you are working on specific RoR things!
1:
https://rubyonrails.org/doctrine/
2:
https://guides.rubyonrails.org/
This seems like an incredibly presumptive and onerous process to expect an interviewee to go through.
I'm a back end C++/rust type and I script with Python.
If I wanted to build a front end, is there any reason I'd use Ruby/Rails over Django? I'm not familiar with Rails but I'm curious if it's worthwhile to pick up.
I wouldn't recommend Rails as front-end only. It's fine as a full-stack framework, and rather nice for quickly building out a back-end API, but not really compelling if you're only using the front-end side of things IMO.
That said, I would argue that Ruby is a very similar but nicer scripting language than Python (particularly for general utility / glue scripts), so if you enjoy scripting in Python you would probably find Ruby easy to pick up and potentially a nice compliment to what you already know.
Rails is a bit more productive. Being a slightly more-expressive language, Ruby has a considerable edge when it comes to DSLs.
Whether it's worth it for you to learn or not depends on how quickly you can pick it up and how important the web app part is to you.
Edit: Why is yazmeya's sibling comment flagged? It's not a glib one-liner and it's clearly an attempt to be helpful.
Unless you are interested in learning ruby or have some specific gripes with how django does things (it is very opinionated) I would say no.
All web frameworks are equivalent.
The neat thing about Rails is that going from zero to a running database-backed app is done in a ridiculously few number of keystrokes that invoke quite a bit of under-the-hood magic in terms of routing, form and view scaffolding, etc. Django is kind of similar, in that you don't need to write a ton of code to get a basic app in the browser, but it exposes a bit more of itself as you get going right away, and you need to work a bit connecting things together. As far as mature, large Django and Rails apps – the similarities outweigh the differences, in my opinion. I would recommend doing the basic Rails tutorial, it really doesn't take that much time.
I wish I'd had this post a couple years ago. I got into my current job by starting as a contractor, helping a friend out in an emergency situation. I've done PHP for over a decade, but had never written Ruby beyond some basic CLI scripts! I spent a few days learning how Rails works, and then how Heroku works (ephemeral filesystems were a new idea to me at the time), and finally got it all together. I also wish I'd put something like this together based on what I went through, but I'm glad this exists for others.
laravel is so similar to rails, it's scary. tbh... all mvc frameworks are similar. once you know one, it's extremely easy to pick up another one even if you don't know the language.
“Rails generates a lot of functions and methods for you that aren’t defined in the code—I bet that will be hard to debug.”
This was definitely the biggest obstacle for me learning Rails (and also Ruby at the same time). And also figuring out what part of the language was Ruby, and what part was Rails. Thankfully Rails' docs have come a long way from just OK to being some of the best in the business.
this is where rubymine really shines, you can right click and select "goto definition" which takes you right to the class that defines the method.
In other editors either Solargraph (via LSP) or even just exuberant ctags will give you the same facility.
Rubymine really is a fanatastic IDE.
Lack of a lot negative comments on this post is surprising
The "current hotness" always gets praise, while the penultimate hotness gets piles of scorn.
I think the JS ecosystem is fading in hotness - not sure exactly where everyone is going, but Go, Rust, and Python all seem pretty hot these days, so we'll see.
Regardless, that means Ruby/Rails is no longer the penultimate hotness, it's merely a boring old technology that does what it does.
And it turns out, Ruby is a lovely language (with its flaws), and Rails is a useful and impressively productive framework (which has cast a long shadow on the entire web development world).
So I think the narrative is warming back up.
I have found the rails community to be fairly positive.
ruby coders always seem so happy
closest i can think of is clojure coders, they also seem quite pleased
Ruby on Rails: learn in a week, spend 4 years dealing with the mess you've created.
Then jump to Clojure and start again...
I love rails, but despite its presense for over a decade, it doesn't feel mature.
Something as basic as a native left join in ActiveRecord wasn't added until Rails 5.0, on June 30, 2016.
Something as basic as native multiple database support wasn't released until Rails 6.0, on August 16, 2019, 15 years after its initial release...
These are just two examples.
Rails _did_ support multiple databases up until then, it just wasn't _as easy_ as everything else in rails. You just defined another database in database.yml (say "second_database") and then ran something like
class Foo < ActiveRecord::Base
establish_connection :second_database
end
Still pretty straight forward and simple - just opaque.
A lot was available in the Rails ecosystem or using Rails code without being explicitly supported by Rails itself. Much of the last few years has been including support for stuff like this that was already being used. To me, that's what a mature framework does.
That's just per-model database annotation. It's not enough for use cases like: data sharding, switching reader/writer endpoints at runtime, and a few others. I wouldn't count the basic case as "multi-db support"
I built a Rails app with exactly that set up: sharding, dynamic switching of read/write queries across multiple slaves 10 years ago. It wasn't hard at all. Ruby's full dynamic nature makes many things easy.
Yes, I mentioned it too
https://news.ycombinator.com/item?id=24937220
- it's relatively easy to add this if needed. But I would not describe it as supported natively.
Multi-database support is not "basic". At what point do you need that? What percentage of users do?
Regardless, it was fully supported in gems for years before it went into Rails. It's nice to have it in core. But to say that Rails doesn't feel mature without it?
Come on.
Of six rails shops I've worked on, half used connection to a secondary sql database in one way or another. Exact use cases has differed but I wouldn't be surprised if it is actually a rather high percentage of medium sized to big apps that use multiples.
> At what point do you need that? What percentage of users do?
In my experience, rather a lot.
If you need to connect to multiple databases at a time for your business logic then you're doing it wrong.
Do you mean it didn't feel mature before June 2016 or August 2019? Cause... those things are there now, so how can they be examples of it not feeling mature now? What's it missing for you now to feel mature?
(And also, lots of people and code definitely did left joins and multiple databases in Rails before those dates, without needing to add any sort of plugin/additional dependency. I did myself, plenty of times! Rails just added features to make them smoother and more complete. Which is actually examples of how mature it is, that it went back and made smoother things people were already doing in less smooth ways, isn't that what maturity looks like?)
Well, business don't jump on the latest version right away for many reasons (stability, bugs, upgrade woes...) Maturity is closely correlated to how long things have been around. Just because multiple database support was officially added on August 2019 it doesn't make it mature after that date. It takes a long time to achieve maturity - people to adopt and improve on that functionality without breaking things. We have been using multiple databases for years as well, done our own way, which will now have to be re-done in the upgrade to Rails 6. It's obviously not a plug-and-play replacement.
It's never clear how long gems will be maintaned for, and when a new gem (like multiverse, which is the multi-database gem I suppose others are referring to) comes out, it doesn't mean that businesses are going to jump on it right away. It needs to be around for some time so that support and its reputation start to build up a case to use it in production.
That's why having it in core is important.
> native multiple database support wasn't released until Rails 6.0
While it wasn't in rails natively, you could do it in rails 5 in ~10 extra lines and before with... considerably more hacking. But there were external projects which gave you the possibility.
I've worked with Rails for since 2005, I've never needed those features yet.
Do you have any examples of features that haven't been added yet, which prevent Rails from being considered mature?
Nah. In a week, some component will need a security update, and your "hello, world" will break.
Rails has been relatively consistent over the past 10 years with few breaking changes, especially compared to most other frameworks.
Yep, most people get burned by other gems that aren't as thoughtful.