params.json

{"name":"Styleguide","tagline":"General guidelines for Chambers Judd web projects","body":"This is an overview of the tools and techniques we use project to project. It will change over time and we're not married to it so think of it as guidelines rather than gospel.\r\n\r\n---\r\n\r\n#### General\r\n\r\n- Assets should be an assets folder in the root, i.e.\r\n/assets/css\r\n/assets/js\r\n/assets/img\r\n- When editing code, use spaces not tabs\r\n- If in doubt, write a comment - assume you won't be there when someone else opens the file\r\n\r\n---\r\n\r\n#### CSS\r\n\r\n- Written using SASS in [SMACCS structure](http://smacss.com/book/categorizing).\r\n- Comments should be written using [KSS syntax](https://github.com/kneath/kss)\r\n- Comments should be ruby (i.e. // not /* )\r\n- Use [Bourbon](http:Bourbon.io) mixins\r\n- Use classes not ID's wherever possible\r\n- Give JS only classes a js- prefix\r\n\r\n---\r\n\r\n#### JS\r\n\r\n- All JS should be tested against JS Lint. There is a [Sublime Text plugin](https://github.com/fbzhong/sublime-jslint) which let's you do this as you go. \r\n- Minify JS prior to production (or on the fly with a Sublime Text Build Task) using Uglify JS\r\n- Write code in modules. [CSS Tricks module pattern](http://css-tricks.com/how-do-you-structure-javascript-the-module-pattern-edition/) is a good example.\r\n\r\n---\r\n\r\n#### Images\r\n\r\n- Use sprites where possible - [Spritecow](http://www.spritecow.com/) is a useful tool for this\r\n- Minify large images using imageoptim prior to production\r\n\r\n\r\n---\r\n\r\n#### Git\r\n\r\n__Always pull a repository before you start working to check it's up to date__\r\n\r\n- Please work on branches for a specific feature, then when it's complete merge into the 'staging' branch (as opposed to master). Name branches in the style navigation_feature. Overview of the idea at http://blog.teamtreehouse.com/our-simple-git-workflow\r\n\r\n- Create tags for releases. These should be preceded by the date and include a description e.g. 20120101-site-launch\r\n\r\n---\r\n\r\n#### Databases\r\n\r\n- Databases should be named with the tech as a prefix, then the project shortname (e.g. for an expressionengine site it would be 'ee_projectname')\r\n- Database exports should be gzipped where possible and exported to a _database folder in the root of the project\r\n- Exported DB dumps should be prefixed by the date and include the initials of the person working on it - e.g. 20120101-JC-ee_projectname.sql.gz","google":"","note":"Don't delete this file! It's used internally to help with page regeneration."}