Ruby on Rails in a week
simplethread.com
simplethread.com
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" (https://rebuilding-rails.com/), heard great things about it.
Ruby and Rails are amazing, and I wouldn't trade it for any other language/framework out there.
The only programming language book I've enjoyed and benefited from as much since then is Fluent Python.
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): https://leanpub.com/basair6
Curious to hear if anyone else has found success with Rebuilding Rails, and what they found most helpful.
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.
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.
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.
If anyone has recommendations for soft skills books that are relatable to tech please let me know.
Have you got any other recommendations for intermediate to advanced rails topics?
> This Version: April 2020 (Free-Chapters Edition)
> Rebuilding Rails is copyright Noah Gibbs, 2012-2020
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
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.
What is bullet?
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!
My first programming book, 10 years ago in a few months I think. Great read.
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.
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.
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.
I asked because parent comment said he/she was running into problems. But if your experience is smooth sailing so far then that's great.
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.
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 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.
Getting Dokku running on something like Digital Ocean should be easy as pie...
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] https://www.hatchbox.io/ (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)
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.
Honestly, there's never been a better time to be a Rubyist than right now.
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.
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.
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: https://crystal-lang.org
In JS mocha or jest are both great.
So I do:
TestSomeMethod:
TestWhenDateProvided:
def test_it_does_not_use_system_date(fixture, ...):
assert ...
TestWhenDateNotProvided:
def test_it_uses_system_date(fixture, ...):
assert ...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.
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.
> 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.
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'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.
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?)
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
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...
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.
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?
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.
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 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?"
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.
Schema changes are normal in web applications, yes.
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.
I have never been able to be more 'meta' in product than I have felt with Ruby/Rails.
> 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 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.
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.
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.
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.
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.
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.
1. read and follow directions
2. read other people's documentation
3. ask for help
4. poke around and try things
I also completely forgot all about Vue in the mean time.
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!
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.
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.
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.
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.
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.
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.
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.
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.
closest i can think of is clojure coders, they also seem quite pleased
Then jump to Clojure and start again...
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.
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.
In my experience, rather a lot.
Virtually every software shop I've worked at has had most backend code communicating with multiple databases to get the job done. Sometimes those databases were behind [micro]service abstractions and the communication was indirected by RPC/one-way async dispatch. Sometimes it wasn't. But multiple backend datastores' contents were required for most business operations. The only places I've worked with that didn't need that were very, very small (single digits of thousands or fewer users).
class Foo < ActiveRecord::Base
establish_connection :second_database
end
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.
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.
(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?)
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.
The things that were difficult before (that I didn't do), that are now supported/smoother, include: migrations (schema-history-as-code) for multiple databases; and the really new exciting feature, different database connections used for read and for write. (i'm sure there are other platforms that support that, but I know it's not universal).
To me these seem like fairly advanced features, I am not sure how many/which other "competing" frameworks support these features; it's a matter of opinion whether these features are required for 'maturity' or not, I'm not going to argue about that.
But to be clear that basic ability to connect to multiple databases has existed since long before August 2019.
For the other feature mentioned as being introduced four years ago in 2016, trying to make the argument that it indicates a lack of maturity because it should have existed for even more than 4 years in order to call it 'mature'? I think it's clear there is just some axe-grinding going on there.
In general, whatever Rails faults are (and of course it has plenty) I don't think a lack of "maturity" is one of them. There are few frameworks/platforms more mature (and I would actually be interested in what examples you are thinking of). If I wanted to talk about the places where Rails isn't as mature as would be liked, it's not features that don't exist or features that were introduced "only" four years ago -- it's in some new features that IMO were introduced with insufficient stability and polish, like webpack integration. That, or ActionCable, are much better examples if you want places where Rails isn't mature. The examples in this thread are... silly.
Finally, rails upgrades are always painful, unless your codebase is written by engineers that know how to avoid those pains. In which case, you probably will end up without rails (a lot of the features are useless to highly experienced engineers)