Skip to content

Instantly share code, notes, and snippets.

@ZapDos7

ZapDos7/00_intro_practices.md

Last active January 28, 2025 15:23
Show Gist options
  • Save ZapDos7/9bb45b1ac293844f87aba5ba4707228a to your computer and use it in GitHub Desktop.
Save ZapDos7/9bb45b1ac293844f87aba5ba4707228a to your computer and use it in GitHub Desktop.
Download ZIP
Raw
00_intro_practices.md

Programming Practices & Tips

Raw
12_factor.md

12 Factor App

Source

1. Codebase

One codebase tracked in revision control, many deploys

If there are multiple codebases, it’s not an app – it’s a distributed system. Each component in a distributed system is an app, and each can individually comply with twelve-factor.

There is only one codebase per app, but there will be many deploys of the app. A deploy is a running instance of the app.

2. Dependencies

Explicitly declare and isolate dependencies

A twelve-factor app never relies on implicit existence of system-wide packages. It declares all dependencies, completely and exactly, via a dependency declaration manifest. Furthermore, it uses a dependency isolation tool during execution to ensure that no implicit dependencies “leak in” from the surrounding system. The full and explicit dependency specification is applied uniformly to both production and development.

3. Config

Store config in the environment

Apps sometimes store config as constants in the code. This is a violation of twelve-factor, which requires strict separation of config from code. Config varies substantially across deploys, code does not.

4. Backing services

Treat backing services as attached resources

A backing service is any service the app consumes over the network as part of its normal operation. Examples include datastores, messaging/queueing systems, SMTP services for outbound email, and caching systems.

The code for a twelve-factor app makes no distinction between local and third party services.

5. Build, release, run

Strictly separate build and run stages

The twelve-factor app uses strict separation between the build (converts a code repo into an executable bundle), release (takes the build produced by the build stage and combines it with the deploy’s current config), and run (The run stage (also known as “runtime”) runs the app in the execution environment, by launching some set of the app’s processes against a selected release) stages.

6. Processes

Execute the app as one or more stateless processes

The app is executed in the execution environment as one or more processes.

7. Port binding

Export services via port binding

The twelve-factor app is completely self-contained and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service. The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port.

8. Concurrency

Scale out via the process model

In the twelve-factor app, processes are a first class citizen. Processes in the twelve-factor app take strong cues from the unix process model for running service daemons. Using this model, the developer can architect their app to handle diverse workloads by assigning each type of work to a process type. For example, HTTP requests may be handled by a web process, and long-running background tasks handled by a worker process.

9. Disposability

Maximize robustness with fast startup and graceful shutdown

The twelve-factor app’s processes are disposable, meaning they can be started or stopped at a moment’s notice. This facilitates fast elastic scaling, rapid deployment of code or config changes, and robustness of production deploys.

10. Dev/prod parity

Keep development, staging, and production as similar as possible

The twelve-factor app is designed for continuous deployment by keeping the gap between development and production small.

11. Logs

Treat logs as event streams

A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles. Instead, each running process writes its event stream, unbuffered, to stdout. During local development, the developer will view this stream in the foreground of their terminal to observe the app’s behavior.

12. Admin processes

Run admin/management tasks as one-off processes

The process formation is the array of processes that are used to do the app’s regular business (such as handling web requests) as it runs. Separately, developers will often wish to do one-off administrative or maintenance tasks for the app. One-off admin processes should be run in an identical environment as the regular long-running processes of the app. They run against a release, using the same codebase and config as any process run against that release. Admin code must ship with application code to avoid synchronization issues.

Raw
13_clean_code.md

How to Write Clean Code

Clean code is a term used to describe computer code that is easy to read, understand, and maintain. Clean code is free from complexity, redundancy, and other code smells and anti-patterns that can make it difficult to maintain, debug, and modify. Good documentation, consistent formatting, and a well-organized codebase are all indicators of clean code.

How do we do it?

  1. When adding new features, prioritise: Effectiveness, Efficiency and Simplicity
  2. Using consistent formatting and syntax throughout a codebase is an important aspect of writing clean code.
  3. Clearly and descriptively name variables and functions.
  4. Strike a balance between conciseness and clarity; while it's important to keep code concise to improve its readability and maintainability, it's equally important to ensure that the code is clear and easy to understand
  5. Code reusability
  6. Have a clear flow of execution
  7. Single Responsibility Principle (SRP): each class or module should have only one reason to change, or in other words, each entity in our codebase should have a single responsibility.
  8. Having a "single source of truth": there is only one place where a particular piece of data or configuration is stored in the codebase, and any other references to it in the code refer back to that one source.
  9. Only Expose and Consume Data You Need
  10. Modularization: breaking down large, complex code into smaller, more manageable modules or functions, which makes the code easier to understand, test, and maintain.
  11. Choosing a good folder structure
  12. Write proper documentation
Source
Raw
25_conventions.md

Naming Conventions

  • camelCase
  • kebab-case
  • snake_case
  • PascalCase
Raw
26_tests.md

It's a good practice to create a test case that replicates the issue and then fix it: that way, it is proven the fix is working & the code is protected from future mishaps.

Raw
48_dynamic.md

Dynamic Programming

  • optimization over plain recursion
  • store the results of subproblems so there is no need for recomputing (O(en) -> O(nx))
  • 2 ways to store data:
    • tabulation (↑)
    • memorizzation (↓)
Raw
99_useful_tools.md

Personal Websites of CS Pros

For Programmers

AI Sites

Open Source Sites for Beginners

QA Resources

Security

Font Websites

File manipulation

Music/Background noises sites

For 💩 & Giggles

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment