What workflow tips do you have that everybody should know?

[Kah0ona]

So after watching Sean Corfield’s excellent bug-fix screencast recently, where Sean uses REBL and tap>, reminding me I should maybe try it if it fits my workflow as well, I got to think:

What workflow tips do you frequently use, that are invaluable for you? Doesn’t have to be eccentric, clever, spectacular,… just darn useful Simple is good

I’ll start:
When fixing a bug with re-frame on the front-end, I often create a comment section where I @(rf/subscribe [:my-sub]) and, if needed, use (def db @re-frame.db/app-db) to inspect or navigate the database state. I tend to prefer this over various GUI based tools, as it’s right there in my buffer.

[bartuka]

While building some functions I tend to enable cider-auto-test-mode in Emacs and use the package toggle-test bind to s-t to go back and forth {core,test} namespaces. The workflow is something like:

(ns my-namespace)

(defn smaller-fn [args])

And the test:

(deftest testing-smaller-fn
  (testing "requirements and expected behavior of smaller fn"
    (let [data {:something 10}
          ret (my-namespace/smaller-fn data)]
      (is (= 1 ret)))))

Now he is the thing, 1) I use a map as input because I often don’t know the function signature before hand so I can put anything in the map as I wish. 2) I test against 1 because this will fail and I often don’t know for sure before hand the output signature either. lol.

However, as I save the buffer, the test runs and the output is updated to me instantly in the test report buffer. So I can only save and look what I am producing as output. I got used to it and find better than sending to repl and looking there. Because as I move forward with the understanding of the smaller-fn I can add more tests around some parts I find good and not losing track of it.

Idk if I explained well enough, but I just got used to do this way for a while. Maybe weird rsrsrs. Side effect, the test is almost done in the end, I don’t think this follows TDD that much because I usually experiment with input/output signatures along the way, or it is .

I never used REBL, but seems a great addition to this workflow, if the output data is too large (like a spec error), it is more difficult to see in the test report buffer. I tend to comment some parts of smaller-fn only to see the data at that specific point being printed in the test report buffer. I have to practice the debugger feature more often

[crispinb]

I have no tips to offer, but I would really encourage any other Clojure neophytes reading this to watch Sean Corfield’s screen cast (thanks for highlighting it @Kah0ona). It’s a pleasingly lucid presentation of the live and interactive nature of REPL based development. No wonder experienced Clojure devs appear to enjoy using the language so much.

[Kah0ona]

Agree, he has a few more. I also love this one where he explains in more detail his dot-file for the clj command line tool.

[seancorfield]

I promise I will post more screencasts but I haven’t found a good piece of technology that makes them easy and isn’t horribly time-consuming **. As with the core.memoize bug fix, what so often happens is that I work on something and then, after I’m done, think “Oh, that would make a great little screencast!”. With the core.memoize bug, I figured it was actually worth my time and effort to reproduce it, knowing what aspects of the debugging I wanted to highlight. Sometimes I think I should just live stream when I’m working on my open source projects but I’m often working in an environment that’s not conducive to that (I do a lot of my “small” open source maintenance in the evenings, while watching TV with my wife).

I did the original three screencasts on weekends when my wife was traveling but, with the lockdown, she hasn’t gone anywhere for four months (and was home for three months before that, going through knee surgery and recovery)

** I’m looking at StreamYard next as a way to live stream to YouTube or Facebook but I suspect the resolution won’t be as good as the earlier screencasts (which were QuickTime recordings, followed by slow 1080p exports, and then long, slow uploads to YouTube!).

[Richard_Heller]

I use VSCode and make copious use of the tasks feature. Here’s my workflow for working on a bug or new feature.

1. Create a test that recreates the problem or should work with the new feature.
2. Create a VSCode Task that runs that one test.
3. I have Run Task mapped to Alt-Shift-R, so do that and select the task from the list.
4. VSCode moves the task to the top of the list, so rerunning it is Alt-Shift-R + Enter.

I don’t use the REPL. I only connect to it with Calva because it won’t do completion without it. I use print statements to see what parameters, variables, etc are set to.

For me, I find the advantages with this are

1. My focus and cursor never leave the function I’m working on.
2. Even with Clojure’s 2-5 second start time, it’s still faster than flipping between files and jumping the cursor around to whatever forms need evaluated.
3. Far fewer key strokes means I can work longer without my wrists hurting.
4. Same workflow regardless of language.

[taf]

seeing ( and hearing - idk if i have already pointed this out before… but your voice is very easy on the ears! ) more of your videos would be brilliant! really looking forward to that!