Draft notes for our November meeting

docs/community/meetings/2024-11-14.md

@@ -0,0 +1,115 @@
+# 10 October 2024
+
+## Eamon Conway: coding tools and workflow
+
+In this meeting [Eamon](https://github.com/EamonConway) gave a presentation about a range of coding tools and how he makes use of them in his workflow.
+
+Attendance: 3 in person, 5 online
+
+<!--
+Here: Eamon, me, TK
+Online: Michael L, Nick T, Rahmat Sahara, Samik Datta, Tanaphum Wichaita
+-->
+
+!!! info
+
+    We welcome presentations about research projects and experiences that relate in any way to reproducibility and good computational research practices.
+    Presentations can be short, informal, and free-form.
+
+    Please contact us if you have anything you might like to present!
+
+## Linters
+
+!!! tip "Key message"
+
+    Linters enforce a consistent coding style, which makes it easier to read your own code and also other people's code.
+
+Eamon began using linters to format his code in order to avoid creating commits that contained "noise" such as trailing space characters at the end of a line and other unanticipated minor effects.
+One source of motivation was working on [Git is my lab book](https://git-is-my-lab-book.net/), which is written in Markdown.
+
+You can adjust your editor settings so that it will automatically format your code whenever you save, whenever you paste text, or even whenever you type (which some people suggested might be annoying!).
+
+Michael mentioned that when working on shared R code with Eamon, who isn't an R coder, he used [`lintr`](https://lintr.r-lib.org/) and [`styler`](https://styler.r-lib.org/) to clean up Eamon's code and make it easier for him (Michael) to understand.
+
+Michael also asked if anyone had good experiences when edited nested code blocks in R Markdown documents.
+Rob replied that he uses Emacs, and that [polymode](https://polymode.github.io/) handle nested R code blocks very smoothly, but he has no experience with other editors — and doesn't suggest anyone switch to using Emacs!
+
+## Language servers
+
+!!! tip "Key message"
+
+    Language servers are tools that understand your code and can make your editor more powerful.
+
+An immediate question from the audience was: "what is a language server?"
+
+A language server is a program that **understands your code** and provides your editor with features such as:
+
+- **Automatic completion** of variable and function names;
+
+- **Displaying documentation** when you place your cursor on a variable or function; and
+
+- **Renaming** variables and functions **in every file** that uses them.
+
+Nick mentioned that [`ark`](https://github.com/posit-dev/ark) is a language server for R.
+It's created by Posit and (at the time of writing) is only available in [Positron](https://positron.posit.co/).
+
+Rob said that he uses [`python-lsp-server`](https://github.com/python-lsp/python-lsp-server) for Python, and [`basedpyright`](https://docs.basedpyright.com/) is another language server for Python.
+
+Nick asked how Eamon (and others) have set up language servers.
+Some editors support language servers through separate packages or extensions (e.g., for VS Code), while other editors have a single "LSP" package that will automatically use any installed language server when you open a code file.
+
+Eamon then walked through some examples of using language server features in VS Code, for both C++ and Python files.
+
+## Debugging
+
+!!! tip "Key message"
+
+    Stepping through your code is a great way to investigate when it doesn't appear to be working as intended
+
+The discussion then moved on to using debuggers to step through your code, so that you can understand what it's doing when you think there's a problem.
+
+In the examples that Eamon presented, he uses Python code as a "wrapper" to call his C++ code, and the debugger allows him to step from Python code into the C++ code and back to Python again.
+
+Nick mentioned that he has used [Positron](https://positron.posit.co/) to debug C code that was being called from R, using the [LLDB](https://lldb.llvm.org/) debugger, and that it is also possible to step into Python code from R.
+
+In fact, as Eamon explained, if your code is compiled with an [LLVM](https://llvm.org/) toolchain, you can used LLDB to step through code that is written in multiple languages (e.g., C, C++, Julia, Rust).
+
+This was followed by a broader discussion about VS Code, Posit, and R Studio, which features these editors provide, and which additional features can be enabled by installing additional packages.
+
+## Testing
+
+!!! tip "Key message"
+
+    Pick a testing framework and give it a go!
+
+Eamon finished by talking about writing and running test cases, using Python as an example.
+He showed how to use [`unittest`](https://docs.python.org/3/library/unittest.html), which is part of Python's standard library.
+One feature that Eamon has found particularly useful is the ability to only run tests that are relevant to the current file or code that he's working on.
+
+Eamon emphasised that testing your code is something you need to **learn by doing**, and told everyone:
+
+> Just pick a testing framework and give it a go!
+> Most, if not all, of the concepts and practices will be directly applicable to other frameworks, if you end up finding a better tool.
+
+For example, Rob mentioned that he uses [`pytest`](https://docs.pytest.org/en/stable/) instead of `unittest`, because it is fully compatible with `unittest` but adds a lot of useful features, such as running tests that failed last time, and allowing you to select specific tests to run.
+
+For R, [`testthat`](https://testthat.r-lib.org/) is the most popular unit testing package.
+Nick mentioned that [`lazytest`](https://lazytest.cynkra.com/) lets you rerun only the tests that have failed during the last run, and that [`usethis`](https://usethis.r-lib.org/) can create GitHub actions for automatically running your tests.
+
+## Automation
+
+!!! tip "Key message"
+
+    Using an automation tool to perform repetitive tasks can prevent human errors.
+
+Eamon explained that he uses [GNU Make](https://www.gnu.org/software/make/) to ensure that his C++ code is recompiled when necessary, so that the executables are always up to date.
+The [`targets`](https://docs.ropensci.org/targets/) package provides similar functionality for R.
+
+Importantly, both of these tools **understand the dependencies** between running commands/code and the files/outputs that will be created.
+This means that they know which files and outputs are up to date, and can **avoid unnecessary computation**.
+
+Eamon asked if there is an equivalent or similar package for Python.
+
+- [`doit`](https://pydoit.org/) is a build tool similar to Make and targets;
+
+- [`tox`](https://tox.wiki/) and [`nox`](https://nox.thea.codes/en/stable/) are commonly-used Python automation tools, but do not avoid unnecessary computation.

docs/community/meetings/README.md

@@ -2,6 +2,8 @@
 
 This section contains summaries of each Community of Practice meeting.
 
+- [14 November 2024](2024-11-14.md): presentation from Eamon Conway about coding tools and workflow.
+
 - [10 October 2024](2024-10-10.md): workshop retrospective, identify future workshops.
 
 - [12 September 2024](2024-09-12.md): test run of our Introduction to Debugging workshop.

mkdocs.yml

@@ -88,6 +88,7 @@ nav:
     - community/README.md
     - "Meetings":
       - community/meetings/README.md
+      - "14 November 2024": community/meetings/2024-11-14.md
       - "10 October 2024": community/meetings/2024-10-10.md
       - "12 September 2024": community/meetings/2024-09-12.md
       - "8 August 2024": community/meetings/2024-08-08.md