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

Curious to hear if anyone else has found success with Rebuilding Rails, and what they found most helpful.

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.

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!

Have you got any other recommendations for intermediate to advanced rails topics?

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.

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.

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.

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)

[1] https://jumpstartrails.com/

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

Getting Dokku running on something like Digital Ocean should be easy as pie...

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.

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

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.

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

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

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

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.

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

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 have never been able to be more 'meta' in product than I have felt with Ruby/Rails.

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.

1. read and follow directions

2. read other people's documentation

3. ask for help

4. poke around and try things

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.

I also completely forgot all about Vue in the mean time.

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.

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.

  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.

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.

(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?)

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.