merylldindin / sirtuin

AWS CLI Routines

AWS CLI Routines

Report Bug

Table of Contents

1. About Sirtuin
2. Built With
3. Get Started
4. IDE Recommendations
5. Code quality
6. Git Conventions

About Sirtuin

Sirtuin is a collection of AWS CLI routines that can be used to automate some of the most common tasks. It is a work in progress and will be updated regularly.

Built With

• Python
• Bash
• Typer
• Pydantic
• AWS CLI

Get Started

# install dev experience
make setup
# install dependencies
make install

Installing awscli:

A fully documented tutorial is available here, and is recommended to follow depending on your distribution.

Verify whether your installation worked by opening a new terminal:

meryll@xps:~/Venvs$ aws --version
aws-cli/2.15.23 Python/3.11.6 Darwin/23.3.0 exe/x86_64 prompt/off

IDE Recommendations

I recommend working with VSCode, an IDE that does not need to be presented. Internally, I use a set of code extensions enabling a minimum of code standardization, making the life of many developers more enjoyable. Those extensions are given in .vscode/extensions.json, and can be downloaded directly via the VSCode extension store. This goes hand and hand with properly configured VSCode workspace settings, available in .vscode/settings.json.

Code Quality

Husky:

Many of our internal toolings are enforced via husky, a wrapper for Git hooks. I currently enforce two hooks:

• commit-msg relying on commitlint to make sure that our commit conventions are respected
• pre-push relying on a yarn command to run locally a majority of our CI scripts

Make sure you correctly initialized your hooks prior to starting:

yarn husky:setup

Return Statements:

A comment that will come back often in PR reviews is the spacing in your code. The overall strategy is to split your code by functional blocks, aka adding empty lines to differentiate loops, if-statements or clusters of similar actions. There are also a few more guidelines:

1. Return statements should be isolated from any code blocks
2. Do not use spacing betIen a function name and the first line of code

An application of those guidelines is illustrated below:

# do
def function():
  return object

# don't
def function():

  return object

# do
def function():
  object = get_object()

  return object

# don't
def function():
  object = get_object()
  return object

Assert Statements:

The guidelines are the same for assert statements than they are for return statements.

Prettier:

To maintain some minimal standards within our codebase, I rely on prettier that is configured through .prettierrc. I use .prettierignore to avoid conflicts with some configuration files that would otherwise be broken by using prettier. Make sure prettier is correctly used in VSCode by installing the VSCode extension.

Helpers:

I use Python 3.10 so make sure to install a clean venv environment depending on a 3.10.* version. I rely on poetry for environment management.

I use some pieces of software to help with code development, those are:

• black configured in pyproject.toml
• ruff configured in pyproject.toml

Naming Conventions:

"There are only two hard things in Computer Science: cache invalidation and naming things." - Phil Karlton

That is exactly why it is important everyone follow guidelines regarding naming conventions, especially when moving quickly as a team. Here are a set of rules that will most likely guide you through any problem you would face:

1. Do not use abbreviations
2. Use at least 2 words for function names
3. Boolean variables should be infered from their name (e.g. start with is_ or has_)
4. Use snake_case for folder names, function names
5. Use PascalCase for class names
6. Use SCREAMING_SNAKE_CASE for constants
7. Use _ prefix for private functions

Typing:

Typing is key to maintainability. It will increase the readability of the code, but will also passively document your code. Finally, type checking will help to find some obvious bugs.

I rely on dynamic typing via Pydantic and use static typing via VSCode for now. To enable static typing, ensure that you are using the VSCode extension Pylance.

I will most likely move towards the introduction of mypy in the future to manage our static typing.

Git Conventions

Branches:

I have a simple convention for branch naming: {initials}/{descriptive-kebab-case}. Keep them all loIrcase. For John Doe working on a feature A, that would be jd/feature-a.

Commits:

The Conventional Commits specification is a lightIight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages. Learn more here.

Pull Requests:

There are simple rules in regards to our PR management:

• Link your PRs to their related Notion tickets;
• Use prefixes for your PR titles among [FIX], [FEAT], [REFACTOR], [RELEASE], [HOTFIX], [TEST];
• If your code affects the application build, be sure to update the README.md;
• Do not merge a PR until all comments are resolved;
• Remove your branch after merging;