Overview
In most Rails applications, there is a substantial amount of interaction with the application inside of the Rails console.
However, while rails c is quite a powerful tool, the REPL with the application context depends on interactions in IRB or PRY, which emphasize the last (or recent) commands executed. Scrolling through history or searching through history is a frequent need, and to execute a flow, you may need to do this many times (e.g. (1) x = SomeModel.find_by(**some_criteria); (2) x.do_something; (3) ap x could be repeated for different models or different candidate implementations of #do_something — each time would require three searches through history, or the foresight to keep redefining a method that tied the steps together).
Since we often want to define such multi-stage flows in the console, it would be powerful to use a notebook approach such as Jupyter that loads the Rails application similar to in the console.
Benefits:
- Much easier to tinker in multi-step flows - just define them in a block in the notebook and rerun it
- Easier debugging
- Encourages saving and source controlling notebooks for common console playbooks as notebook files. While
raketasks also cover this playbook use case, the interactivity and usability of notebooks would often be preferable. E.g. you can run half a notebook, inspect the result, and use human judgement about whether to proceed with the rest of the task. - Easier integration with visualization tools (e.g. show a histogram of
SomeModel#some_numerical_propertyattributes instead of just looking at a tally hash in the CLI)
Implementation ideas
- Could use an approach similar to this existing but infrequently maintained project as a starting point for iruby + Jupyter
- Take inspiration from how Django achieves this