Writing code is a very creative endeavour. However, if you're not careful, you may well end up wasting a lot of time writing code that you don't have to.
Do you want to check if a file is available on a remote server before attempting to download it - in a short and effective way? If so, and you're not sure how you'll learn how in this post.
Writing technical documentation has a lot of similarities to writing software; an important one being content reuse, instead of content duplication. In this post, you’ll learn why and how to use attributes in AsciiDoc and Antora to reuse content as and when needed.
Whenever you create online documentation, eventually, the structure needs to change; such as a name change, content restructure, or old content is removed. When these times come, it's important to create redirects to avoid breaking user expectations. In this post, I'm going to step you through how to do so with Antora.
Git, despite still being a bit terse, is extremely powerful version control software. However, because it's so powerful, it takes time to learn. In this post, I'm going to show you four small techniques to help you use it more effectively.
If you need to migrate Markdown content to AsciiDoc, there's a tool designed specifically to do it — it's called kramdoc. In this post, I'm going to show you how to use it and relate my experience with it.
Markdown is one of the most ubiquitous file formats around at the moment for writing technical documentation — and it's easy to see why! However, it may not be the choice long-term. When it's time to change, you need to be able to migrate to a more feature-rich format. Come learn about the best tool for the job and how to use it.
If you've ever attempted to bind a process on a port on Linux, BSD, or macOS, only to find that something else is using the port, yet you don't know what that process is, here's a quick way to find the process and remove it.
Do you want a no-fuss command-line tool to lint the quality of the prose in your technical documentation project, or in your technical writing projects? Do you want something that has an uncomplicated interface, yet provides rich feedback? Then come learn about proselint.
Are the words in your technical documentation strong, sharp, direct, and powerful? Or are they passive, weasely, and replete with clichés and adverbs? If you want to make them stronger than they are now, then come learn about write-good.
When you're reviewing generated HTML content, broken link's are the last thing you want. However, given the massive amount of documentation in modern projects, manually hunting for broken links isn't practical. So how do you deal with this problem?
Markdown is far-and-away the most popular technical documentation format used by developers (in my experience). If you and your team write in Markdown too, how do you know that your Markdown files are valid? You use MarkdownLint. Come learn all about it!