Creating dummy data for blueprints

Blueprints must always include data/autotune.json. You need this file to be able to develop locally, and Autotune needs this file to be able to ingest the blueprint as valid. This file must be readable (i.e. it needs to exist) as per development settings, and both readable and writeable as per production settings. There are multiple reasons for this, but one of the most basic is that the confib.rb file in all blueprints maps certain keys (title, slug, etc.) from autotune.json to symbols referenced throughout the blueprint.

####What goes inside data/autotune.json?

When the project builds in production, the data in data/autotune.json is generated from the form submitted by the user. In development, this interaction doesn’t exist, so we need to create an autotune.json file containing data that mimic’s the output in production.

####Creation of data in production versus in development

####Example dummy data Here’s an example autotune.json for an image slider:

{
  "title": "N++ 2",
  "slug": "n-2",
  "theme": "theverge",
  "image_left": {
    "image_url": "https://cdn3.vox-cdn.com/uploads/chorus_asset/file/3913386/N___20150727155226.0.jpg"
  },
  "image_right": {
    "image_url": "https://cdn0.vox-cdn.com/uploads/chorus_asset/file/3913384/N___20150727155252.0.jpg"
  },
  "slider_theme": "light-bar"
}

####Relationship between autotune-config.json and autotune.json Keep in mind that each one of the alpaca form fields in you autotune-config.json maps to a key in your autotune.json. It’s best to update these files in tandem so that they always reflect each other and neither get stale.