REPLs for testing, or exploring, or something...
I like REPLs (read execute print loops).
In my first Java QA job, we were testing a Java API for cash registers, a world that didn't have a whole lot of tooling at the time. I had written a bunch of tests as classes implementing an interface with some kind of "doTest" method. And I discovered that with just a few extra lines of code, I could read a line from stdin, parse the name of one of the test classes followed by optional args, make an instance of the test class, call its doTest(...), and print. And this was a great way to play with the library we were testing.
And it was scriptable. :-)
This was definitely my favorite thing from that job. I even gave it something like global variables, using a hash table in which values could be linked to names using a SetValue "test". And then the names could be used as arguments on subsequent lines.
Later we started using JACL (A Java implementation of the Tcl scripting language). JACL code could reach into Java and call static methods, create new instances, and generally hack around with anything you put in your classpath. And it had an interactive mode!
This was great for quickly trying stuff with the API were were testing, like when someone had a question, or I wanted to explore around a bug we had found.
Anyway..... today I'm trying to learn front end web development. I'm working on a for-fun single page application using React. I've written node REST services to sit behind it. (Node has an interactive mode too!) And I want to play with the REST services before I start to write real code to use them on the browser side.
So, since I will have to write some Javascript functions to call the REST service from the browser anyway, why not make a temporary hack to tack those functions onto the window object, and now I can just call them interactively from the console. :-)
I think there's a general pattern here. When building something in layers and working on layer N, you can hack together some utility functions to access it from layer N+1, add a REPL, and then you can play with the "real" layer-N code while you're writing it.
And using the layer N services while you're writing them gives you a sense of how usable they are, plus generating some code that might be reused in layer N+1.
And it's fun.
In my first Java QA job, we were testing a Java API for cash registers, a world that didn't have a whole lot of tooling at the time. I had written a bunch of tests as classes implementing an interface with some kind of "doTest" method. And I discovered that with just a few extra lines of code, I could read a line from stdin, parse the name of one of the test classes followed by optional args, make an instance of the test class, call its doTest(...), and print. And this was a great way to play with the library we were testing.
And it was scriptable. :-)
This was definitely my favorite thing from that job. I even gave it something like global variables, using a hash table in which values could be linked to names using a SetValue "test". And then the names could be used as arguments on subsequent lines.
Later we started using JACL (A Java implementation of the Tcl scripting language). JACL code could reach into Java and call static methods, create new instances, and generally hack around with anything you put in your classpath. And it had an interactive mode!
This was great for quickly trying stuff with the API were were testing, like when someone had a question, or I wanted to explore around a bug we had found.
Anyway..... today I'm trying to learn front end web development. I'm working on a for-fun single page application using React. I've written node REST services to sit behind it. (Node has an interactive mode too!) And I want to play with the REST services before I start to write real code to use them on the browser side.
So, since I will have to write some Javascript functions to call the REST service from the browser anyway, why not make a temporary hack to tack those functions onto the window object, and now I can just call them interactively from the console. :-)
I think there's a general pattern here. When building something in layers and working on layer N, you can hack together some utility functions to access it from layer N+1, add a REPL, and then you can play with the "real" layer-N code while you're writing it.
And using the layer N services while you're writing them gives you a sense of how usable they are, plus generating some code that might be reused in layer N+1.
And it's fun.
Comments
Post a Comment