Welcome to the next issue of the Tidy Cloud AWS bulletin! In this issue, I cover some freeCodeCamp courses, a productivity tool recommendation and a few AWS blog posts, as well as AWS CDK experimental stuff.
freeCodeCamp infrastructure-as-code courses
One great website to learn some coding and development skills for free is freeCodeCamp. There are literally thousands of tutorials available, plus several more well-defined learning paths and curriculums - all for free.
Although originally focused more on web development, freeCodeCamp is nowadays broader than that, with contributions in many areas. A few tutorials there also include infrastructure-as-code topics, covering tools such as AWS CDK, Terraform and Pulumi.
A few tutorials in that space that you can find there are:
What is infrastructure as code? (Pulumi)
How to deploy AWS infrastructure with Terraform and GitHub Actions - a practical multi-environment CI/CD guide
How to use Terraform to automate your AWS cloud infrastructure
If you are thinking of using AWS CDK, CDKTF, Pulumi, but have learned none of the supported programming languages - you can probably find a tutorial for that as well here.
Productivity recommendation - Obsidian
I write a fair amount of text, which can include a bulletin like this one, articles and blog posts, documentation, book material, code, etc.
I have tried several tools over the years to handle writing and keeping track of information and stuff, including Notion, Evernote, Scrivener, Drafts, and a few more. Given that I write a lot of technical texts and documentation, markdown has in practice been the target format most times, even though I thought Asciidoc was a more powerful markup language and better suited.
Obsidian is a knowledge management tool that uses Markdown for storing text. It is simple, yet brilliant. Part of its power is its wiki-style linking capability to create links and references on-the-fly as you are writing. it lets you organize content in multiple ways, though file structures, tags and keep track of these links and references for you, even if you move things around.
You can create templates for documents which you can auto-generate new documents with pre-filled (dynamic) data.
It also has an extensive plugin system, and here is perhaps another of its superpowers. There are hundreds of plugins to extend Obsidian with features in various ways.
Personally I am using a handful of these plugins, which include integration with Todoist (my task manager tool of choice), multi-column extension to markdown, Obsidian Git to allow synchronisation between multiple devices via Git repository, integration with Excalidraw (a neat diagramming tool for “hand-drawn” pictures), etc.
The editor experience is semi-visual. You write markdown, but it will be visually changed to a suitable formatting as you write - unless you switch to source mode. It automatically creates backlinks between documents and you can navigate visually across your different references. You can also create block links to specific blocks in other documents. It also has neat search and autocomplete features, so it works out well to find information you are looking for.
Obsidian recently had its 1.0 release, but has been around for years. There are lots of material around using Obsidian, a few links from YouTube include these:
Use Obsidian (BEST Markdown editor) for note taking and tech docs!
How I use Obsidian for work as a software developer advocate
AWS Blog stuff
A few blog posts from AWS that I found interesting:
Use IAM Access Analyzer policy generation to grant fine-grained permissions for your AWS CloudFormation service roles
This article covers the use of IAM Access Analyzer to identify IAM least privilege permissions to use for a specific CloudFormation stack. This includes creating the stack and then deleting it, and let IAM Access Analyzer record what AWS service operations were needed. I think the idea behind this is good, but I wish AWS would package this in a simpler and more automated user experience.
Deciding between large accounts or micro accounts for distributed operations at AWS digs into the area of what to consider when structuring your AWS setup into different accounts. Nowadays, best practices include having multiple AWS accounts, but how large or small should they be in terms of what is deployed and managed in each account? This article outlines some considerations for deciding if a workload belongs in an existing account or a new account.
AWS SAM CLI Pipelines now supports Open Id Connect protocol is a news item that was news to me that AWS SAM actually has pipeline support nowadays (!). I must admit I have not used AWS SAM for quite a while, and it has not been on my radar. It turns out that it can generate CI/CD pipelines not only for AWS own Code-services but also for other tools like GitHub Actions, Bitbucket Pipelines, Jenkins, etc. I think that is a neat feature, and I wish more of the AWS developer tooling should adopt a broader pipeline support.
If you are an AWS CDK user, check out CDKLabs at GitHub. This is a GitHub organisation which contains mostly experimental features that the AWS CDK people are working on, or tools that do not strictly belong to the AWS CDK distribution itself.
There are a few interesting things to check out there, but remember that many of the items are at an experimental stage and may have breaking changes.
You can find older bulletins and more at Tidy Cloud AWS. You will also find other useful articles around AWS automation and infrastructure-as-software.
Until next time,
Top comments (4)
Obsidian always looks like a great tool, and your recommendation is weighty, @eriklz!
Do you find the free plan to suffice for your needs, or have you sprung for add-ons or upgrades?
Yes, I just use the free stuff at the moment. Obsidian Git is a good enough alternative to Obsidian Sync for me. Obsidian Publish is interesting, but have not tried that, and I use others tools at the moment.
Downloaded and exploring! It will take me a while to find the time to do this, but I'll get there. Thanks for the review!
The main issue I have found when using Obsidian Git is that you need to gitignore the workspace settings in the .obsidian directory, otherwise you will end up with merge conflicts. The changed the filename for that from 0.x to 1.y, which caused a bit of problem.
You can also gitignore the whole .obsidian directory, but then need to do hotkey mapping and other settings on each device separately.