home

(draft) Holiday Coding Topic List

This is a list of topics I consider for the Holiday Coding sessions. Let me know if you’re particularly (dis)interested in a topic.

Some topics are big. Some topics are small. All of them are ideas.

Do Repeat Yourself

  • Make things look the same to keep them easy.
    • Order of functions in a file
    • Name of files and directories easily predictable by a quick file search.
    • handleXYZ or XYZhandle.
    • snake_case or CamelCase
    • writeOutVariablesInFull or x,i,z?

Toolmaking

  • Makefile / Rakefile
  • Making your own CLI
  • The art of “one-off” scripts.
  • Helper functions in testing setups. (createEvent)
  • CLI basics - creating shell scripts.
  • Making your own (mini) DSL
    • This includes e.g. defining custom layouts and components in front-end.
    • Things like custom chaining functions in the backend.

Know your Tools

  • Package.json
  • ts/jsconfig
  • Loggers and Log Levels
  • eslint / prettier
  • GIT
  • Basic CLI - find, grep, head, tail, sort, uniq, xargs
  • Test Tooling:
    • Playwright -> pages / storageState / loggedInState
    • JEST -> how to use variables in each test case?

Use your tools

  • Github
  • Sentry
  • Amplitude
  • Slack (notifications)

AWS Specific (Power) Tooling

  • Cloudwatch (and structured logging)
    • Queries
    • Tailing
    • Custom Metrics & Alarms
  • SQS
  • DynamoDB
  • Lambda
  • Step Function

The spectrum from code to infra (AWS)

  • Step Functions
  • DynamoDB
    • Streams
    • TTL
  • SQS + Dead Letter Queue
  • SES

Don’t break the Internet

aka: Know your standards

  • HTTP
    • HTTP Response codes.
    • HTTP (custom) Headers
    • HTTP Tags and their attributes
  • CSS & data selectors
    • For prototyping & testing
    • For analytics & tracking (icw e.g. Google Tag Manager)
  • Template Languages
    • HBS
    • ERB
  • DNS and (local) subdomain control.
  • DMARC / SPF

Software Architecture Patterns

  • Startegies for Mapper(s)
  • IF statements
    • Treating If statements as a code smell, especially when nested.
      • Not because they are inherently bad. But because the smell leads us to areas we can likely improve.
      • The deeper the if structure, the bigger the smell.
      • The more if statements in a single function, or object for that matter, the bigger the smell.
    • Various Strategies of dealing with if statements.
      • Push if’s to the outside
        • Can you return early?
        • Can you skip the if, if you make it somebody else’s problem?
        • Swallowing functionality with Objects.
        • default values as arguments vs ifs
        • value objects vs ifs
        • single vs multiple return paths.
        • using functions in your statements instead of just statements.
      • Switch / Case statements to clarify the process.
        • Especially when implementing external protocols (e.g. authorization flows)
      • Duck typed objects / Value Objects
      • Placing conditions outside or inside a function.
        • Is it your problem or not?

System Architecture Patterns

  • SQS vs Direct handling of Lambdas
  • API Gateway with Lambda
  • Benefits of Idempotent design
  • Don’t wake me up at night & defensive coding.

Observability & Cleanliness

It’s easier to hold the 0 line than to judge the mess.

  • CloudWatch
  • Local Logs
  • Keeping Console.log open