The 9984 >> SUMMIT 2017 site

Blockchain Futures for Developers, Enterprises & Society
October 5 - 6, 2017
https://2017.9984.io

---

Live | Beta

---

Table of Contents

• Content editing
  • Pages
  • Special pages
    • Front page
  • Speakers & Talks
    • Add new speaker or talk through GitHub
  • Schedule
    • Add new slot to schedule through GitHub
• Development
  • Install dependencies
  • Development build
• Continuous deployment: always be shipping
• Manual deployment
  • Prerequisite: authentication
  • Staging build & beta deployment
  • Production build & live deployment
• Coding conventions
  • (S)CSS
• Authors
• License

Content editing

Most content on the site can be edited on GitHub without messing with HTML markup.

The site's source and structure is in the _src/ folder. Ignore everything with an underscore in its name.

When viewing a file on GitHub you will see a small pencil icon in the top right. Click that to edit the file.

Pages

All pages are simple Markdown files. Markdown is a way of telling the site how an element should be marked up, like headings & bold text:

I'm a simple paragraph. No fancy symbols needed.

# I'm a heading 1
## I'm a heading 2

You can make text **bold like so**

Have a look at Code of Conduct or the Imprint to see how Markdown is used.

Special pages

Some pages like front page & speakers page source their content dynamically during site build. This is so we have a single source of truth for content used in multiple places on the site.

Front page

Content for all sections on front page is coming from a data file:

• _src/_data/content-front.yml

Speakers & Talks

All speakers data is coming from individual files in _src/_speakers & _src/_talks. Each content item is represented as a Markdown file with YAML at the top. providing metadata. The data should look something like this:

---
property: "value"
other_property:
    - "list"
    - "of"
    - "values"
---

Add new speaker or talk through GitHub

1. Click into the appropriate directory (/_src/_speakers, /_src/_talks
2. Copy the data from an existing .md file
3. In the parent folder, click Create new file
4. Paste the data into GitHub and edit
5. Edit to your heart’s content!
6. When finished, fill in a commit description and select Create a new branch for this commit and start a pull request.
7. Wait to see if the created pull request passes the build. If it does, click merge and your changes will be live

Schedule

The schedule is being constructed automatically based on a combination of:

• _src/_data/schedule.yml (for exact time and in-between blocks)
• _src/_talks/ files (for title & type)
• _src/_speakers/ files (for speaker name & speaker page link)

Slots in the schedule file are automatically grouped by day, then ordered by start_time. The actual order of slots in the schedule file doesn't matter so no need to reorder items when times change. The time set as start_time will be output within the talk block on speakers page too. Only when a slot has a talk_id, it will be linked to respective speakers page with the talk description.

Note that all spacing and indentation in YAML files matter. So make sure to always keep the same indentation as existing items in there.

Add new slot to schedule through GitHub

1. Find the _src/_data/schedule.yml file.
2. Hit the edit pencil icon to open edit view.
3. Copy and paste an existing slot and modify its talk_id, day & start_time.
4. When finished, fill in a commit description and select Create a new branch for this commit and start a pull request.
5. Wait to see if the created pull request passes the build. If it does, click merge and your changes will be live.
6. You can also do more edits and commit to the same branch to build up your pull request.

Development

You need to have the following tools installed on your development machine before moving on:

• node.js & npm
• (optional) use Yarn instead of npm for faster dependency installations
• Ruby (for sanity, install with rvm)
• Bundler

Install dependencies

Run the following command from the repository's root folder to install all dependencies.

npm i && bundle install

or

yarn && bundle install

Development build

Spin up local dev server and livereloading watch task, reachable under https://localhost:1337:

gulp

Continuous deployment: always be shipping

The site gets built & deployed automatically via Travis. This is the preferred way of deployment, it makes sure the site is always deployed with fresh dependencies and only after a successful build.

Build & deployment happens under the following conditions on Travis:

• every push builds the site
• live deployment: every push to the master branch initiates a live deployment
• beta deployment: every new pull request and every subsequent push to it initiates a beta deployment

Manual deployment

For emergency live deployments or beta & gamma deployments, the manual method can be used. The site is hosted in an S3 bucket and gets deployed via a gulp task.

Prerequisite: authentication

To deploy the site, you must authenticate yourself against the AWS API with your AWS credentials. Get your AWS access key and secret and add them to ~/.aws/credentials:

[default]
aws_access_key_id = <YOUR_ACCESS_KEY_ID>
aws_secret_access_key = <YOUR_SECRET_ACCESS_KEY>

This is all that is needed to authenticate with AWS if you've setup your credentials as the default profile.

If you've set them up as another profile, say [9984] you can grab those credentials by using the AWS_PROFILE variable like so:

AWS_PROFILE=9984 gulp deploy --live

In case that you get authentication errors or need an alternative way to authenticate with AWS, check out the AWS documentation.

Staging build & beta deployment

The staging build is a full production build but prevents search engine indexing & Google Analytics tracking.

# make sure your local npm packages & gems are up to date
npm update && bundle update

# make staging build in /_dist
# build preventing search engine indexing & Google Analytics tracking
gulp build --staging

# deploy contents of /_dist to beta
gulp deploy --beta

Production build & live deployment

# make sure your local npm packages & gems are up to date
npm update && bundle update

# make production build in /_dist
gulp build --production

# deploy contents of /_dist to live
gulp deploy --live

Coding conventions

(S)CSS

Follows stylelint-config-bigchaindb which itself extends stylelint-config-standard.

Lint with stylelint in your editor or run:

npm test

Authors

• Matthias Kretschmann (@kremalicious) - BigchainDB

License

For all code in this repository the Apache License, Version 2.0 is applied.

Copyright 9984 SUMMIT & 9984 HACK courtesy of IPDB and BigchainDB, 2017. All rights reserved.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.