All content licensed under Creative Commons Attribution 3.0 Unported License
This document contains guidelines for web applications built by the Front-end development practice of Roundarch Isobar (previously Isobar & Molecular). It is to be readily available to anyone who wishes to check or contribute to the iterative progress of our discipline's best practices.
This document's primary motivation is two- fold:
- code consistency and
- best practices.
By maintaining consistency in coding styles and conventions, we can ease the burden of legacy code maintenance, and mitigate risk of breakage in the future. By adhering to best practices, we ensure optimized page loading, performance and maintainable code.
We hope to encourage other developers to think about how to best standardize their approaches to development, to propose their own ideas for debate and for inclusion in our version of the document, and to adapt our standards for their own unique development practices. What better way of achieving consensus on how best to develop in our discipline than through feedback from members of that discipline themselves?
We hope to seperate the structure of the document from the content contained in the standards themselves. Effectively, our goal is to be able to easily update the content without having to worry about the structure.
This also enables pull requests to focus on content and forks to the content to be easily re-branded.
To view the latest, you can just clone locally:
git clone git://github.com/isobar-idev/code-standards.git
To make changes using the process in place, please use the build process. The next few sections describe this build process.
First, install Node.js from their Web site.
Note: Assemble is an exceptionally active and flexible framework for building static HTML pages. It allows the usage of Handlebars, Markdown, and HTML files so we can gradually migrate to Markdown content files over time.
We suggest you check out Assemble as well.
The Gruntfile (
grunt.js) includes the build for the multi-lingual copies of the document. There is a variable for
standards.defaultLanguage which will determine what language the default
index.html is rendered in.
To start with a clean slate, the Gruntfile has a
cleanup task which will remove the previously generated
index.html and associated language files.
There is also a
watch task if you like to work that way.
'npm install' from the command line of the project directory to install all the node dependencies. You may need to occasionally re-run this command as new dependencies are added.
Windows: You may need to manually run
npm install -g gruntand
npm install -g grunt-clito correctly set the path variables required to run grunt from the command line.
'grunt' from the command line of the project directory to run the build process.
*.html files in the root are generated via
grunt and should not be edited directly. There is one file per language, by language code.
./en.html ./es.html ./ru.html ...
standards.defaultLanguage setting determines which
*.html file will be copied to the
Note: In the near future the layout and templates will be updated to include the i18l language menus.
Each of the
.html files (and soon
.md - Markdown) contained within these directories is a portion of the final output file. We have separated the different sections that make up the page into individual files so that it is easier to edit.
The content files are included as partials and the data and order is defined in the following folder and files:
data.json file has special significance to Assemble, do not rename this file.
The main layout is a Handlebars file that the content is injected into and language specific attributes are updated.
The file is
The CSS files are generated via Compass from the SCSS files located in the SCSS folder, which is run as part of the Grunt task.
Because github pages only serve static content, you must push your generated files to the gh-pages branch for updates to appear online.