| 0=8 | |
| 0==8 | |
| 0===8 | |
| 0====8 | |
| 0=====8 | |
| 0======8 | |
| 0=======8 | |
| 0mfg | |
| 1488 | |
| 2girls1cup |
| version: 1 | |
| disable_existing_loggers: False | |
| formatters: | |
| simple: | |
| format: "[%(levelname)s] [%(name)s :: %(funcName)s] - %(message)s" | |
| verbose: | |
| format: "%(asctime)s <PID %(process)d> [%(levelname)s] [%(name)s :: %(funcName)s] - %(message)s" |
This is a collection of the things I believe about software development. I have worked for years building backend and data processing systems, so read the below within that context.
Agree? Disagree? Feel free to let me know at @JanStette. See also my blog at www.janvsmachine.net.
Keep it simple, stupid. You ain't gonna need it.
There are already dozens of tutorials to setup an Arch and Windows dual boot - welcome to a dozen + 1. Like most others this is a step by step guide. Unlike most others the steps are ordered in a way that makes sense (starting with the download first - duh!) so you won't have to restart your computer a gazillion times.
I did this on a single SSD Dell XPS 15 with windows 10 preinstalled. It's obviously possible to follow this guide if you're installing Arch onto a different drive or if you're running older hardware. If you run into any problems please be sure to read through the Arch Installation Guide and the Arch Dual boot with Windows wiki.
To get started you will need:
This cheat sheet provides a detailed overview of the exposed lifecycle events and available commands (and entrypoints) of the Serverless framework, that can be hooked by plugins (internal and external ones). The document is structured by the commands invoked by the user.
Lifecycle events are shown as the globally available outer events (all providers) and sub lifecycle events that are provider specific in the called order. Currently only the AWS provider is shown. If you have information about the other provider,
PRs are a great way of sharing information, and can help us be aware of the changes that are occuring in our codebase. They are also an excellent way of getting peer review on the work that we do, without the cost of working in direct pairs.
Ultimately though, the primary reason we use PRs is to encourage quality in the commits that are made to our code repositories
Done well, the commits (and their attached messages) contained within tell a story to people examining the code at a later date. If we are not careful to ensure the quality of these commits, we silently lose this ability.
| # Compiled source # | |
| ################### | |
| *.com | |
| *.class | |
| *.dll | |
| *.exe | |
| *.o | |
| *.so | |
| # Packages # |
