This is the Jekyll based source code and assets for the Roaring Fork Technologist's group website.
This project serves as an independent ( outside of Facebook, for example ) platform for supporting the Roaring Fork Technologist's mission, including the promotion and nurturing of the technological community and economy in the Roaring Fork Valley in Colorado.
Jekyll uses the Ruby programming language and package environment to translate templates and data files into a static set of website assets. While you will not need to write Ruby programs, you will need to install Ruby on to your local environment.
If you are on windows, the easiest way to install Ruby is probably via Rubyinstaller. Follow the instructions for installing the latest version here:
On OS X, your best bet is to use homebrew, as described here:
Ruby programs use a package manager called Bundler. This manages sets of shared functionality or libraries called gems. In order to build and run Jekyll locally, you will need to install a set of gems, including Bundler.
Gems can be installed locally within a project, or globally for all projects on your computer. The gem command, is installed alongside the version of Ruby.
Install Jekyll
$ gem install jekyllThis is not yet using Bundler, there is no Gemfile yet.
With that gem installed, you should now be able to build and serve the website locally from inside of the root of the project directory where this README.md is located.
$ jekyll serveThis will run a server at http://localhost:4000. Enter that URL into your web browser and it should present the website from the local source code.
Although you do not have to learn Ruby, you do need to learn how to maintain a Jekyll based website. This includes learning the Liquid templating language and the rest of the Jekyll workflow.
You can start here:
The github issuetracker for this project is current. Please check there for info on what issues may be open.
For now we are not going to have formal releases for the site. We will build toward a version 1 and from that point can consider whether we want to have a formal release strategy or just push changes as needed.
- Each developer must create a new branch in which they will do their changes.
- To commit your work perform a pull request against the master branch. When the pull request is reviewed and accepted it will be qued up and folded into the gh-pages branch for release.
MIT- See LICENCE file in the repository.