That's great, but from my experience, 90% of Rubyists I met are working with Rails.
"Divorcing" from Rails is therefore absurd, just stuff people say who don't like DHH for one reason or another.
Hmm, I don’t think sharing my personal experience would be that useful. For one, I’ve only used a handful of these tools long enough to give a meaningful assessment. More importantly, though, these tools evolve so quickly that anything I wrote would likely be outdated almost immediately.
I'd rather give folks an overview over which tools exist and some info about their popularity, price point etc.
Maybe it would be cool to add links to the founder's accounts on X, Youtube etc. where they share new releases and what they're working on...
> Good list, but gosh the term "agent orchestrator" is really being diluted endlessly these days.
Yeah, there's a lot happening in this space... but I think those 13 tools which are one the list right now all try to do the same thing - make it easier to run multiple agents (mostly over multiple apps) at the same time.
Are there any tools you would add or remove?
> Also, putting Zed and Cursor in the same "freemium" bucket is really unfair...
Sure, the "free" plans of some of the tools are not really comparable, but I think that's out of scope for this list. :)
In my experience, Bundler has improved a lot with regard to resolving dependency issues over the years.
And OS libs are only really depended on by a few gems, no? 99% of them don't use FFI or call OS libs.
Moreover, how often do you really move a script to a completely different OS, where you don't know which OS libs are installed?
And wouldn't those missing OS libs also be a problem when writing the script in Bash or any other language?
Hearing people still mention "monkey patching" always makes me chuckle...
I haven't "monkey patched" anything in Ruby in > 5 years, and I don't see it in any of the popular libraries/gems anymore either.
You can pin a gem to a specific version, of course.
`gem "mygem"` installs the latest version.
`gem "mygem", "~> 4.0.0"` installs >= 4.0.0 but < 4.1.0, which is what you probably want when using Semantic Versioning, which most gems adhere to, to get the latest patch version.
`gem "mygem", "4.0.10"` installs exactly that version.
Can you give an example?
I can't think of a single situation where whitespace matters in Ruby (unless of course you forget to put a space between two commands or something silly).
Similar case for me, but I think the author says it well:
> That is, most of the cases Bash for me is enough, but if the script starts to become complex, I switch to Ruby.
Even if ChatGPT lets you bang out more complex shell scripts easily, if you have to come back to it later on to fix an error or add a new feature, it's really hard to understand it (if you don't deal with such scripts on a daily basis).
If you start with Ruby (or Python or similar) from the beginning, it's much easier to understand and extend later on.
> but it's temperamental and I have trouble getting it working.
> I was trying to set up editor support
Not sure what problems you had exactly, but saying that editor tooling is bad, simply because you can't get it to work, is not fair.
I've been using the LSP from Shopify since it came out, it works great, is very stable and updates come in on a regular basis.
> ... the new LSP one from Shopify doesn't want to work for whatever reason.
Sorry, but calling it "a mess" simply because you can't get it to work is quite unfair.
I've been using the LSP from Shopify since it came out, it works great, is very stable and updates come in on a regular basis.
Hi, author here. Indeed I try really hard to see it from the recruiter's point of view, which is what the article is about. And I don't think other devs have any problems to see it from the recruiter's point of view either.
Of course it's a sales job. Of course it involves calling/mailing a lot of people and getting a lot of "no"s. Of course the developers are not the customers in this relationship.
What does that have to do with the IT competency of the recruiter though?
I don't buy the "it's a sales job so it's ok if they do it quick and dirty and don't take the time to educate themselves". In my opinion, the opposite is true - recruiters would be much better salespeople with a higher success rate if they showed more competency in the field they work in, both to their customers/clients and to the candidates.
Seriously great conference! The concept is really appealing - step out of the echo chamber of your own programming language / framework community and learn a bit about many other languages.