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.
HN user
manume
Ruby on Rails developer, founder of Uplink (uplink.tech), a network for IT freelancers. Based in Berlin, Germany
More options: https://agentmgmt.dev (disclaimer: built by me)
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...
Sure, but we gotta start somewhere, right? :) What would you find most useful to add next?
I added a comment to Cursor in the list. ;)
Thanks for the feedback!
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. :)
Really cool to see superpowers adjusted for Rails development!
One question: looking at the Rails conventions stills you added, wouldn't rules with paths be a better match for that: https://code.claude.com/docs/en/memory#organize-rules-with-c...
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.
For 99% of use cases (especially when writing shell scripts) it doesn't matter, just pick the one you know better. Both are nicer than Bash though. :)
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).
What do you mean by "broken gems"?
Sadly, 9 out of 10 environments lack a Ruby interpreter out of the box.
Please name those 10 environments you are talking about. In my experience, a reasonably recent Ruby version is present almost everywhere.
add 5 minutes to your docker build
Why on earth would it take 5 minutes to install anything? If you install Ruby through a package manager (it's present in pretty much all of them: https://www.ruby-lang.org/en/documentation/installation/#pac...) it takes only seconds.
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.
Bundler inline works great for that: https://bundler.io/guides/bundler_in_a_single_file_ruby_scri...
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.
Oh really? I never bothered to check the exchange rate. Good to know, I'll let my German bank do the conversion from now on!
Good idea! If both the money and the card could be taken in the same movement, that would make it very convenient.
In Sweden (and possible in other countries) the ATMs let you choose whether you want to let the ATM (or bank that the ATM belongs to) do the conversion from Euro to Swedish Kronor or your own bank. If you pick the latter option, your bank might charge you for the conversion, I never had the case that the Swedish bank charged for it.
I guess a machine like an ATM has be usable by 100% of the population, including people who get easily confused by more than two options/buttons, so usability has to be sacrificed for simplicity to a certain degree.
My girlfriend (the author) is out hiking right now. :) She uses Illustrator and Sketch AFAIK. You can see more of her work on her profile: https://www.jennylettow.com/ Feel free to contact her via email to ask for details!
I'm sure there are people who arrived at work one day and only then noticed they had forgotten to put on pants, but I guess quite a lot more forget their wallet or cell phone. ;)
Yes, multiple (trans)actions in one session are a use case where it would make sense to keep the card until the end. I'd say it would still make sense to return the card before the cash and have the user insert it again - a small inconvenience for the few users that want to do multiple actions but probably a big decline in forgotten cards.
I had to take down the server for a minute to install a WP caching plugin, it should be back up soon!
I had to take the server down for a minute to install a caching plugin... check back soon!
"Insert card, remove card, ..." makes even more sense than returning the card right before the money!