indiecast-common

JSData model definitions and other components shared among apps.

---

Directory structure

``bash
component/ # Component definitions
├── datastore/
├── rethinkdb-adapter/
├── spec-config.js
└── spec.js
model/ # Model definitions
├── core/
└── spec.js
CHANGELOG.md
.gitignore
.jscsrc
.jshintrc
package.json
README.md
spec.js

`
---

Libraries used

$3

Robust framework-agnostic in-memory data store.

https://github.com/js-data/js-data
http://www.js-data.io

$3

A light, fast, flexible Javascript IOC container.

https://github.com/cujojs/wire
http://cujojs.com/

$3

The streaming build system.

https://github.com/gulpjs/gulp
http://gulpjs.com/

$3

The open-source database for the realtime web.

https://github.com/rethinkdb/rethinkdb
http://rethinkdb.com/

---

Recommended tools

$3

Windows is not recommended for development. Try elementary OS.

$3

http://www.sublimetext.com/3

$3

First install Package Control then use it to install the following packages:

* AdvancedNewFile
* DocBlockr
* JavaScript & NodeJS Snippets
* JSCS-Formatter
* NodeRequirer
* SideBarEnhancements
* SublimeLinter
* SublimeLinter-jscs
* SublimeLinter-jshint
* SublimeLinter-json
* Terminal

$3

#### Ubuntu

`
sudo apt-get install guake
`

#### Mac

Quake?

$3

#### Ubuntu: Git Cola

`bash


Download git cola

wget -qO /tmp/git-cola_2.2.1-1_all.deb https://launchpad.net/ubuntu/+archive/primary/+files/git-cola_2.2.1-1_all.deb

Install it with dpkg

sudo dpkg -i /tmp/git-cola_2.2.1-1_all.deb

Fix broken dependencies

sudo apt-get -y install -f
`

#### Mac: SourceTree

---

Git etiquette

$3

The _master_ branch is for production-ready code only. Code should be merged from release branches. Each merge defines a new release.

The _develop_ branch is for code under development. Changes should not be committed directly to _develop_. They should only be merged in from feature branches.

Feature branches should branch off of _develop_ or another feature branch, for sub-features. When ready, they should be merged back into _develop_ with the --no-ff flag.

Release branches branch off of _develop_ when _develop_ is nearly ready for release. This frees _develop_ for the next version while final touches can be made on the release branch. When ready, it should be merged into _master_ and back into _develop_ with the --no-ff flag.

Hotfix branches branch off of _master_ and are for fixing bugs after major releases. When ready, they should merge into back into _master_ and into _develop_ with the --no-ff` flag.

See http://nvie.com/posts/a-successful-git-branching-model/ for in-depth explanation of this branching model.

$3

If you have a lot of changes to commit, you should generally split them up into multiple commits. While a single commit can contain changes to many files, each commit should only serve a single purpose.

This can be easily done with most git GUIs such as SourceTree or Git Cola.