How to structure and share code examples

Writing for technical audiences often means sharing code in one form or another. If the code is only for illustration purposes, then it can be included in the article for observation. But if the code is useful or reusable by your readers, then you need a way to make it available to them. I’ve seen a few questions on this recently (shout out to the DevRel Collective slack for a brilliant discussion AND nagging me to write it up as a post!), so I’m sharing my experiences on how to publish and maintain code in sane ways! Continue reading

Reviewdog filter settings with GitHub Actions

Reviewdog is a tool to use with GitHub actions for applying review tools in your CI. I use it with Vale, and it’s really good. One thing that has tripped me up multiple times is that by default, it only applies the checks to the changes in the pull request, not to the whole project. So when you add something like Vale, which is a prose linter, it only checks … the workflow file you just added! I always forget that it works this way, and how to change it, so I’m pasting some examples for future reference. Continue reading

Visualise OpenAPI with Blockly

Giving talks about OpenAPI often means lots and lots of slides of YAML. In fact, one of my talks even contains a “warning, contains yaml” slide! If you aren’t a professional yaml developer, it can be difficult to digest and learn from, and so I wanted to do better. The various elements are nested inside one another, and so I had this idea to build a representation of OpenAPI using Blockly (the tooling also used for Scratch, if you’ve seen that).

Showing tags with descriptions
Continue reading

Measuring Repo Community Health with GitHub’s API

I’m on record saying that GitHub is your Landing Page and when I think about companies having open source profiles, I think about how many developers will have the first contact with them on GitHub. If it’s a code example you’re looking for then like it or not, GitHub is considered a search engine by many developers.

With that in mind, I wanted to look at GitHub’s Community Health measure of the repositories I’m responsible for. You can view each repo’s community page separately through the web interface (look under “Insights”) but that’s not especially scalable if you have a lot of projects to track.

screeshot of the project's /community page, showing low completion Continue reading

Bystanders Guide to Repository Maintenance

Today’s post is about bystanders and open source. We sometimes have anxiety about doing things on “other people’s” projects but the thing about open source is that those are not “their” projects, those are “our” projects, and they only exist because people other than their nominated gatekeepers chip in now and then. Continue reading

Where was that GitHub Discussion?

Did GitHub change their activity feed? Or am I getting more confused now I contribute to so many different projects that I’m not a maintainer of? Either way, I struggle sometimes to find the pull request or issue that I had a discussion on to revisit or continue that discussion (yes, I get email notifications – and no, I don’t take good enough care of them to find things that way).

GitHub has brilliant advanced search functionality, and what I wanted was:

is:pr commenter:lornajane sort:updated-desc

Which gives me a list of all the pull requests I’ve commented on, with the most recent first. I couldn’t remember the exact repo name and I also often switch is:pr for is:issue as appropriate, but this search string has been very helpful for finding those odd things you want to follow up on.

Do you have a favourite GitHub search string combination? Would you care to share it in the comments? Thanks :)

Code Reviews: Before You Even Run The Code

I do a lot of code reviewing, both in my day job as principal developer and also as an open source maintainer. Sometimes it seems like I read more code than I write! Is that a problem? I’m tempted to say that it isn’t. To be a good writer, you must be well-read; I believe that to be a good developer, you need to be code-omnivorous and read as much of other people’s code as possible. Code reviews are like little chapters of someone else’s code to dip into.

Over time I’ve developed some particular processes that I find helpful when reviewing code. In particular, I often surprise people at how much review I do before I run the code. Sometimes I grab the branch so that I can use my local diff tools, but I don’t actually execute code until I’ve established some basic facts. This post is a little insight into what’s happening in this not-running-the-code-yet zone. Continue reading

Gollum the Git-Enabled Wiki

In trying to get company documentation off google docs and people’s laptops and into a more useful format, I have been researching developer-friendly tools for business documentation. Requirements went something like:
– must handle words and documents
– should be available locally, bonus points for revision history
– must publish to the web, and ideally be editable there
– should accept content in markdown
– must have access control (which wiped out my original plan of using a static site generator)

While I worked on this, we were using the wiki feature in GitLab … which pretty much hit the nail on the head. Further investigation showed that the wiki feature in GitLab (and indeed in GitHub) is a ruby gem called Gollum. Continue reading