To be organized

Here we have a few documents that need to be subsumed into the rest of the documentation.

• Available Decorators
  • @tag
    • How do I query by tags?
  • @extract_columns
  • @extract_fields
  • @config.when*
    • @check_output
    • @parameterize
    • @parameterize_values (replacing @parametrized)
    • @parameterize_sources (replacing @parameterized_inputs)
    • Migrating @parameterized*
  • @does
  • @model
• Available Drivers
  • Hamilton Driver Usage
    • Instantiation
    • Execution
      • Using a DAG once
      • Using a DAG multiple times
      • Short circuiting some DAG computation
• Best Practices
  • Using within your ETL System
    • Compatibility Matrix
    • ETL Recipe
  • Migrating to Hamilton
    • Continuous Integration for Comparisons
    • Integrate into your code base via a “custom wrapper object”
  • Function Naming
    • It enables you to define your Hamilton dataflow
    • It drives collaboration and reuse
    • It serves as documentation itself
  • Code Organization
    • Team thinking
    • Helps isolate what you’re working on
    • Enables you to replace parts of your DAG easily for different contexts
  • Function Modifiers
    • Why would I use them?
  • Common Indices
    • Best practice:
  • Loading Data
    • Plugging in new Data Sources
      • Modules as Interfaces
      • Using the Config to Decide Sources
    • Caching Data Load for Rapid Iteration
  • Output Immutability
    • Best practice:
• Extensions
  • Scaling Hamilton: Parallel & Distributed Computation
    • A note on the definition of Experimental
    • Ray - Experimental!
      • Single Machine:
      • Distributed Computation:
    • Dask - Experimental!
      • Single Machine:
    • Koalas on Spark, a.k.a. Pandas API on Spark - Experimental!
      • Single Machine:
      • Distributed Computation:
  • Customizing what Hamilton Returns
    • How do you change the type of the object returned?
• Writing Drivers