Agile Otter Blog

This is one of those things that just doesn't stick in my head, so I'm dropping this note to remind myself.  I often have trouble recalling cryptic variable names in bash, make, and perl. For my own sake, I thought I'd make a quick list of favorites and refer some sources.   Maybe you'll find this useful too.  Variable value, but exit if no such variable: ${var:?"error message"} Use default if   variable isn't set:  ${var:="default"} Get a substring : ${var: start: length}   Length: ${#var}  Uppercase:  ${var@U} Lowercase : ${var@L}   The first one is quite helpful when you expect a particular set of parameters and don't want to write if/then logic about each of them.   #/bin/env bash directory=${1:? You must provide a directory to search} pattern=${2:? You must provide a search term for filenames} find ${directory} -name ${pattern}   See more at the gnu shell expansion page. 

  A bit of background: I was chatting with some colleagues and friends this week about AI-augmented workflows.  M was talking about having LLMs "write the epics and features" for teams. He was envisioning a flow where a PO or PM would have much less cognitive effort and could do this work alone and then hand it off to the teams for execution. Of course, the teams are using LLMs to help with testing and code generation, and to explain code that should probably be refactored to make LLM explanations unnecessary. There are also AI code reviews, though they burn a lot of tokens for what they deliver. I was more cognisant that we should never (per Agile Manifesto) use tools or processes to reduce the interactions between humans doing the work, but might want to use them to improve or enhance those conversations. M talked about the really important conversations he wants to focus on: the discussion that happens when users and sponsors can see the working product increment and gi...

You're working with some Python code, and would like to write a test, but... "I can't test that - it uses STDOUT!" Okay, well, that's really not such a big problem to handle. The solutions to this problem are actually simple enough that you can apply them to many other situations that might otherwise encourage you to skip tests just this one time (again). In our modern age, we have the advantage of ubiquitous LLMs in browsers, IDEs, and CLIs. We shouldn't be stuck on common problems anymore, nor must we remain unaware of features in our test libraries. Rather than look at print statements as a brick wall, you can get started writing useful tests right away. So, let's talk about a few options: Pytest "capsys" fixture. This is pretty trivial. You import and mention 'capsys' in your code, and you have access to the content printed to stdout and stderror.  These are what we would call "listener fakes" - they listen to, and remember,...

 Sometime back in my early days of programming, I learned to enjoy a truth table. Fizzbuzz seems to beg for a simple truth table - the values ' should_fizz ', and ' should_buzz ' form up a simple tuple of booleans, and the choices are True, False - fizz False, True - buzz True, True - fizzbuzz False, False - string of the number This expresses rather neatly in Python, is efficient and pythonic, and handles negative cases neatly also: But here's the rub:  One of the "normal" changes is to add a rule that multiples of 7 say 'woof' even if they are also divisible by 3 or 5. That's a peculiar rule, but let's consider it for a moment. If I am going to add another term to the set, I have to edit the match line and every case line. I will have to add new cases for all the possible truth values in my new 3-tuple table. That's not so much fun.  The changes to my test suite are, at least, minimal. The best expression in our codebase may not be t...

Here is a .vimrc file built from the recommendations in my Vim book, " Use Vim Like A Pro " (available on LeanPub ).

Recommended bash scripts for every project clean_start  ensures you are ready to start new work. It does: 'pull -r' (which fails if you have uncommitted work) a refresh of the local environment  'git clean -i' in case you have untracked files you've forgotten about a full test run. onboard is the script to run if you are a brand-new developer and you need to set up your development environment. It will deal with setting up the environment (installing dependencies and any virtual environment) and runs the tests. run runs the application itself. I started adding run scripts when I started changing between ruby, python, java and other projects and got tired of having to remember which incantation started the servers.  This is a shortcut. run_tests will run all of the tests -- every kind. run_integration_tests will run only the integration tests (I don't always separate these). I don't use a script to run only the unit tests, because I have IDE configured to...