Package: sirtuin
AWS CLI RoutinesReport BugTable of ContentsAbout SirtuinBuilt WithGet StartedIDE RecommendationsCode qualityGit ConventionsAbout SirtuinSirtuin 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 WithPythonBashTyperPydanticAWS CLIAWS EB CLIGet Started# install dev experiencemakesetup# install dependenciesmakeinstallInstallingawscli:A fully documented tutorial is availablehere, 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.7.27Python/3.9.11Linux/5.15.0-56-genericexe/x86_64.ubuntu.22prompt/offInstallingawsebcli:A fully documented tutorial is availablehere, and is recommended to follow depending on your distribution.Verify whether your installation worked by opening a new terminal:meryll@xps:~/Venvs$eb--version
EBCLI3.20.3(Python3.10.)IDE RecommendationsI 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 QualityHusky:Many of our internal toolings are enforced viahusky, a wrapper for Git hooks. I currently enforce two hooks:commit-msgrelying oncommitlintto make sure that our commit conventions are respectedpre-pushrelying on ayarncommand to run locally a majority of our CI scriptsMake sure you correctly initialized your hooks prior to starting:yarnhusky:setupReturn 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:Return statements should be isolated from any code blocksDo not use spacing betIen a function name and the first line of codeAn application of those guidelines is illustrated below:# dodeffunction():returnobject# don'tdeffunction():returnobject# dodeffunction():object=get_object()returnobject# don'tdeffunction():object=get_object()returnobjectAssert Statements:The guidelines are the same forassertstatements than they are forreturnstatements.Prettier:To maintain some minimal standards within our codebase, I rely onprettierthat is configured through.prettierrc. I use.prettierignoreto avoid conflicts with some configuration files that would otherwise be broken by using prettier. Make sure prettier is correctly used in VSCode by installing theVSCode extension.Helpers:I use Python 3.10 so make sure to install a clean venv environment depending on a 3.10.* version. I rely onpoetryfor environment management.I use some pieces of software to help with code development, those are:blackconfigured inpyproject.tomlisortconfigured inpyproject.tomlruffconfigured inpyproject.tomlNaming Conventions:"There are only two hard things in Computer Science: cache invalidation and naming things." - Phil KarltonThat 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:Do not use abbreviationsUse at least 2 words for function namesBoolean variables should be infered from their name (e.g. start withis_orhas_)Usesnake_casefor folder names, function namesUsePascalCasefor class namesUseSCREAMING_SNAKE_CASEfor constantsUse_prefix for private functionsTyping: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 viaPydanticand use static typing via VSCode for now. To enable static typing, ensure that you are using the VSCode extensionPylance.I will most likely move towards the introduction ofmypyin the future to manage our static typing.Git ConventionsBranches: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 bejd/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 morehere.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 theREADME.md;Do not merge a PR until all comments are resolved;Remove your branch after merging;