REPL is a pretty old idea. If you take nothing else away from this survey of my bag of tricks, please take these two ideas: first, pay close attention when you find old ideas that are still going strong; second, use REPL as a regular part of your programming practice.
The REPL you will have already encountered is the traditional shell command-line. You type cryptic commands and the computer responds with cryptic replies. It lets you have a text chat with your computer. At the terminal command-line the language you are speaking with the computer is some dialect of shell.
The core mechanic of this game is typing and reading until you can make sense of the cryptic messages you are sending and receiving. Interacting in this way lets you build up a mental model of this part of the system you are using.
But everyone hates shell.
What we actually hate is the direct feedback that we don't know how this stuff works. And the shell is the most common place where we encounter that feedback. It always takes much longer than anyone wants or believes to really understand what we're doing and what these machines are doing.
One python project included a flask web application. The previous developers had already included flask-shell-ipython in the project. If you work in python I strongly recommend getting to know IPython. (If you're in Ruby, get to know Pry. A long time ago I used jython as a REPL for java projects—some chance there are other options now.) The flask shell lets us chat with our code at a command-line using the python language.
We were trying to understand a complex bit of code that imported data from a foreign API. We opened the code in question in our editor on one half of the screen and opened a terminal on the other half. In the terminal we fired up the flask shell. We proceeded to gradually build up our mental model of the code and the API by picking commands out of the script and pasting them into the flash shell.
For the sake of this story, we're skipping a lot of discovery. These were the lines we were exploring.
from the_engine.lib.apis import TheForeignAPI ... self.api = TheForeignAPI(self.config) ... while not done: try: data = self.api.get( f'/scanresults/scans/{target_scan_id}/vulnerabilities/', params=params) if data['next']: params = { 'page': data['next'].split('=')[-1] } else: done = True
TheForeignAPI module was a wrapper around the python standard library for http: request. In our shell we imported the library, created a local object with necessary credentials provided in the config, and manually tried a couple .get() commands to see what data the API returned.
This let us understand exactly what was inside data['next']. It turns out this loop was managing the pagination in the API. We were also able to inspect the rest of the payload from the API and understand other parts of the code. Buy moving slowly through this code we could build a mental model that let us reason about the code.