Eden Li wrote:
Yes The cool thing about this is you can get an irb shell right
into the ruby process running rails, which means you can do all sorts
of useful stuff like twiddling class variables and inspecting your
controller states directly.
Probably a bad idea to do this in production, but could be useful
Precisely. It’s not intended to be exposed remotely. I’ve no idea what
DRb’s ACL stuff offers etc, but that could be looked at.
The idea was to be able to execute code inside a running ruby
application. Initially this was because I had rails running as a windows
service, and wanted to debug the different environment.
One of the things my (internal) rails app does though, is being a job
process monitor, for scripts largely written in ruby. I can set some
flag, that allows me to not just hook into and monkey patch rails live
:), but also to capture exceptions in a running job, and rescue it
providing this sort of simplistic remote debugging.
At any rate, while it was easy to write, it seems a few things didn’t
work with DRb as I thought they should.
I would’ve imagined that I could simply pass a local
ReadlineInputMethod, and StdioOutputMethod to the remote IRB::Irb#new,
but in fact that still did both input and output remotely - hence the
kind of cumbersome proxies.
Remote output still didn’t work, but that seems to be an IRB issue.