<commit_before># Ember Rocks ( a.k.a em-cli ) 

[![NPM][npm-badge-image]][npm-badge-url]

[![NPM version][npm-image]][npm-url]   [![Build Status][travis-image]][travis-url]   [![Dependency Status][dependency-image]][dependency-url]


> An Em(ber) command line utility to help developer(s) build an ambitious web application. It is highly inspired by some awesome open source projects, [ember-cli](https://github.com/stefanpenner/ember-cli), [ember-tools](https://github.com/rpflorence/ember-tools), [Web Starter Kit](https://github.com/google/web-starter-kit), [Gulp](https://github.com/gulpjs/gulp/).


## Getting Started

```bash
    npm install -g ember-rocks
```

After the installation, you should have a global command `em` available. 
Try `em --help`, you should see a list of helper information. 
Try `em generate --help` to see a specific command helper information.


## Features

- well align with Ember-Cli project
- gulp ( build tool of choice ) build insanely fast via node stream api
- lighting fast development rebuild system
- live reload on all resources
- super powerful generator system
- Sass language support with CSS sourcemap, trace back to original Sass defination
- ES6 ( Next Version of javascript ) with JS sourcemap, trace back to origional ES6 defination
- hackable express server as back end
- simple command to build a production ready application and ready to be deployed
- tablet and touch device support out of box. Responsive Web Design supported.
- hybird web app on native phone and tablet via Cordova package. For iOS, Andriod, Blackberry, and more

## A sample ember app in the Ember Rocks

**Ember Rocks** comes with a sample application, and user could even have their own set of templates. See [Ember Rocks Template Basic](https://github.com/mattma/Ember-Rocks-Template-Basic) for details.

An express (Node.js) server will handle all requests. A fake user api route will read the RESTful json api on the disk, return the data over the wire when Ember app request the data via latest **Ember Data** library. In real world application, it should be replaced with MongoDB (recommended), CouchDB, etc. It is very easy to integrate with any NoSQL database.  

The fully stylish application works on touch and tablet devices out of box. Try to resize your browser into a smaller screen resolution, you should see an animated effect from the left edge which is the most popular choice of mobile application navigation menu. You could tweak the styles and markup to fit your use cases. 


## Ember-cli is the official **Ember** app CLI tool (Ember#2.0 and forward). Why am I building another em(ber)-cli?

**Ember-Cli** is awesome and it is supported by [Ember core team](https://github.com/emberjs/rfcs/pull/15). If **Ember-Cli** is working for you, stick with it; otherwise, you can try **Ember-Rocks** and continue reading below,

`TL;DR`

There are a few reasons why I started with this project:

1. There was no official build tool for Ember project when I started in the middle of 2014. But now, Ember core team has announced that [**Ember-cli**](https://github.com/emberjs/rfcs/pull/15) is the official build tool to move forward. 

2. **Ember-cli** has chosen [broccoli](https://github.com/broccolijs/broccoli) as its build tool. Do not get me wrong, **Broccoli** is an awesome build tool. I have even chatted with its creator, [<NAME>](https://github.com/joliss). She is an awesome engineer. But to me, after I switched from **Grunt** to **Gulp** at the end of 2013, I have learned in and out about **Gulp** and its EcoSystem. I do not want to follow the same path again from **Gulp** to **Broccoli**. Essentially, they are the same thing with different approach but solving the same set of problems. 

3. **Ember-cli** has chosen [Qunit](https://github.com/jquery/qunit) as its testing tool. I was never a fan of TDD and Qunit. BDD and Mocha framework are always there to cheer me up. This is almost No-Brainer question for me since there is no addon for using Mocha testing framework. But now, [Ember-Mocha](https://github.com/switchfly/ember-mocha/) has released to change the game. In fact, **Ember-Mocha** also powers **Ember-Rocks** testing use cases.

4. **Ember-cli** project is trying to be an universal toolset to fit most of use cases for majority of **Ember** developers. It is truly amazing to see Ember core team is there for wide range of audience. But I have a set of tools that works well. I will stick with it and also want to have full control over it if I could. Note: If **Ember-cli** works for you, great, you should stick with it since it supports by Ember core team. 

5. **Ember-cli** has hided lots of complex system scripts and build logics into CLI core. For example, express server is built in so that it is hard to roll in any homebrew middlewares. Exposing Express server is becoming a necessary problem that need to be addressed.  

Those are the major reasons why I started **Ember-Rocks** project. I have built several build systems throughout my professional career and some plugins/libraries for developers. In details below,

After built a large Backbone application (>15000 LOC), I developed a set of developer toolings which fit my customized workflow very well. **Ember Rocks** approach is my opinionated toolset on building a large scaled Node.js modern web application with Ember.js framework on the client side.

**Ember Rocks** can be globally installed on your local machine ( tested on Linux based operating system ) via `npm install -g ember-rocks`. After you have done that, magic happens :). You would have an `em` command available. Try `em --help`, `em generate --help` for a comprehensive guide. 

**Ember Rocks** is chosen [gulp](https://github.com/gulpjs/gulp) as a build tool. In fact, it is powered by [gulp](https://github.com/gulpjs/gulp) under the hook. **Ember-cli** choose [broccoli](https://github.com/broccolijs/broccoli). The main difference between two awesome build tools is, *broccoli* use "directory in, directory out" pattern, and *gulp* use "file in, file out" pattern. *gulp* takes advantage of *Node Stream* to pipe files to destination folder. This is the one I perfer for now until [broccoli](https://github.com/broccolijs/broccoli) is out of beta. Sorry, [<NAME>](https://twitter.com/jo_liss), you are awesome.

In addition, technology stack besides Ember.js, I have picked [sass](http://sass-lang.com/) as css pre-compiler, [autoprefixer](https://github.com/ai/autoprefixer) as css post-compiler, [express](http://expressjs.com/) as node web application server, and [mocha](http://visionmedia.github.io/mocha/) as javascript testing framework. [6to5](https://github.com/6to5/6to5) used to turn ES6+ code into readable vanilla ES5.

Just like [lodash](lodash.com) is a project which solve the same problem that [underscore](http://underscorejs.com/) does, [Ember Rocks](https://github.com/mattma/ember-rocks) is trying to solve similar problem that [ember-cli](https://github.com/stefanpenner/ember-cli) does. I will try to sync the features from [ember-cli](https://github.com/stefanpenner/ember-cli) to [Ember Rocks](https://github.com/mattma/ember-rocks). 

What is on my road map? Ember Add-ons, custom components, frequent updates along with Ember releases and more. PRs, Issues, Suggestion are highly welcomed and appreciated. 


## Quick Start

```bash
    em new my-app          # generate a brand new ember app in *my-app* folder
    cd my-app              # switch to application folder
    em serve               # start a server, open the new app in browser, livereload all resources
```

## Usage

```bash
    em [command] [options]

    Commands:

        new [options]      # Creates a new ember application at [dirName]
           
        g|generate         # Generate a new file with ES6 support in the ember app
               
        s|serve            # Builds and serves your app, rebuilding on file changes

        m|mobile           # Builds an Cordova application, and ready to deploy to phone or tablet
           
        b|build            # Release your app and places it into the output path '~/build'

        t|test            # Run client side integration and unit tests, rerun tests on file changes
       
    Options:

        -h, --help     output usage information
        -V, --version  output the version number

    Command-Specific Help:

        em [command] --help
```

## Guide

Since the project is highly inspired by [Ember-Cli](http://www.ember-cli.com/), ( both projects even share the same commands but completely different implementation under the hook, i.e. `em(ber) new`, `em(ber) generate`, `em(ber) g`, `em(ber) serve`, `em(ber) build`, `em(ber) test`, etc ), **Ember Rocks** uses the same modules -- [ember resolver](https://github.com/stefanpenner/ember-jj-abrams-resolver), and [ember load initializers](https://github.com/stefanpenner/ember-load-initializers). Ember Modules system ( *client/app/* ) and the resolver guide will apply to **Ember Rocks** modules and the resolver as well.

* Modules and the Resolver [Documentation](http://www.ember-cli.com/#using-modules)

_( More Coming Soon )_


## Testing your app

Integration tests are located in the folder `client/tests/integration`, and Unit tests are located in the folder `client/test/unit`. You do not have to manually create any new test files since you could simplly use `em generate` to generate any new tests with pre-defined boilerplate. If you do not know how, use `em g --help` for more details. 

If you have to manually create a test file, name test file anything you want, suffix `-test` or `_test` with file extension `.js`.

You could use future **ES6** syntax in tests, and they would be pre-compiled into vanilla javascript before serving in the browsers or phantomjs headless browsers.

- #### Easiest way, the recommended way to run your test

By simply running `em test` or `em t`, it would compile your testing files, build the project, launch an express server to take any requests, watch any test file changes and rerun the test again, show the result of the tests.

```bash
  em test
```

- #### Easy way, but requires two different processes and `testem` installed globally in your system. ( `npm install testem -g` )<commit_msg>setup the title case<commit_after># Ember Rocks ( a.k.a em-cli ) 

[![NPM][npm-badge-image]][npm-badge-url]

[![NPM version][npm-image]][npm-url]   [![Build Status][travis-image]][travis-url]   [![Dependency Status][dependency-image]][dependency-url]


> An Em(ber) command line utility to help developer(s) build an ambitious web application. It is highly inspired by some awesome open source projects, [ember-cli](https://github.com/stefanpenner/ember-cli), [ember-tools](https://github.com/rpflorence/ember-tools), [Web Starter Kit](https://github.com/google/web-starter-kit), [Gulp](https://github.com/gulpjs/gulp/).


## Getting Started

```bash
    npm install -g ember-rocks
```

After the installation, you should have a global command `em` available. 
Try `em --help`, you should see a list of helper information. 
Try `em generate --help` to see a specific command helper information.


## Features

- well align with Ember-Cli project
- gulp ( build tool of choice ) build insanely fast via node stream api
- lighting fast development rebuild system
- live reload on all resources
- super powerful generator system
- Sass language support with CSS sourcemap, trace back to original Sass defination
- ES6 ( Next Version of javascript ) with JS sourcemap, trace back to origional ES6 defination
- hackable express server as back end
- simple command to build a production ready application and ready to be deployed
- tablet and touch device support out of box. Responsive Web Design supported.
- hybird web app on native phone and tablet via Cordova package. For iOS, Andriod, Blackberry, and more

## A sample ember app in the Ember Rocks

**Ember Rocks** comes with a sample application, and user could even have their own set of templates. See [Ember Rocks Template Basic](https://github.com/mattma/Ember-Rocks-Template-Basic) for details.

An express (Node.js) server will handle all requests. A fake user api route will read the RESTful json api on the disk, return the data over the wire when Ember app request the data via latest **Ember Data** library. In real world application, it should be replaced with MongoDB (recommended), CouchDB, etc. It is very easy to integrate with any NoSQL database.  

The fully stylish application works on touch and tablet devices out of box. Try to resize your browser into a smaller screen resolution, you should see an animated effect from the left edge which is the most popular choice of mobile application navigation menu. You could tweak the styles and markup to fit your use cases. 


## Ember-cli is the official **Ember** app CLI tool (Ember#2.0 and forward). Why am I building another em(ber)-cli?

**Ember-Cli** is awesome and it is supported by [Ember core team](https://github.com/emberjs/rfcs/pull/15). If **Ember-Cli** is working for you, stick with it; otherwise, you can try **Ember-Rocks** and continue reading below,

`TL;DR`

There are a few reasons why I started with this project:

1. There was no official build tool for Ember project when I started in the middle of 2014. But now, Ember core team has announced that [**Ember-cli**](https://github.com/emberjs/rfcs/pull/15) is the official build tool to move forward. 

2. **Ember-cli** has chosen [broccoli](https://github.com/broccolijs/broccoli) as its build tool. Do not get me wrong, **Broccoli** is an awesome build tool. I have even chatted with its creator, [<NAME>](https://github.com/joliss). She is an awesome engineer. But to me, after I switched from **Grunt** to **Gulp** at the end of 2013, I have learned in and out about **Gulp** and its EcoSystem. I do not want to follow the same path again from **Gulp** to **Broccoli**. Essentially, they are the same thing with different approach but solving the same set of problems. 

3. **Ember-cli** has chosen [Qunit](https://github.com/jquery/qunit) as its testing tool. I was never a fan of TDD and Qunit. BDD and Mocha framework are always there to cheer me up. This is almost No-Brainer question for me since there is no addon for using Mocha testing framework. But now, [Ember-Mocha](https://github.com/switchfly/ember-mocha/) has released to change the game. In fact, **Ember-Mocha** also powers **Ember-Rocks** testing use cases.

4. **Ember-cli** project is trying to be an universal toolset to fit most of use cases for majority of **Ember** developers. It is truly amazing to see Ember core team is there for wide range of audience. But I have a set of tools that works well. I will stick with it and also want to have full control over it if I could. Note: If **Ember-cli** works for you, great, you should stick with it since it supports by Ember core team. 

5. **Ember-cli** has hided lots of complex system scripts and build logics into CLI core. For example, express server is built in so that it is hard to roll in any homebrew middlewares. Exposing Express server is becoming a necessary problem that need to be addressed.  

Those are the major reasons why I started **Ember-Rocks** project. I have built several build systems throughout my professional career and some plugins/libraries for developers. In details below,

After built a large Backbone application (>15000 LOC), I developed a set of developer toolings which fit my customized workflow very well. **Ember Rocks** approach is my opinionated toolset on building a large scaled Node.js modern web application with Ember.js framework on the client side.

**Ember Rocks** can be globally installed on your local machine ( tested on Linux based operating system ) via `npm install -g ember-rocks`. After you have done that, magic happens :). You would have an `em` command available. Try `em --help`, `em generate --help` for a comprehensive guide. 

**Ember Rocks** is chosen [gulp](https://github.com/gulpjs/gulp) as a build tool. In fact, it is powered by [gulp](https://github.com/gulpjs/gulp) under the hook. **Ember-cli** choose [broccoli](https://github.com/broccolijs/broccoli). The main difference between two awesome build tools is, *broccoli* use "directory in, directory out" pattern, and *gulp* use "file in, file out" pattern. *gulp* takes advantage of *Node Stream* to pipe files to destination folder. This is the one I perfer for now until [broccoli](https://github.com/broccolijs/broccoli) is out of beta. Sorry, [<NAME>](https://twitter.com/jo_liss), you are awesome.

In addition, technology stack besides Ember.js, I have picked [sass](http://sass-lang.com/) as css pre-compiler, [autoprefixer](https://github.com/ai/autoprefixer) as css post-compiler, [express](http://expressjs.com/) as node web application server, and [mocha](http://visionmedia.github.io/mocha/) as javascript testing framework. [6to5](https://github.com/6to5/6to5) used to turn ES6+ code into readable vanilla ES5.

Just like [lodash](lodash.com) is a project which solve the same problem that [underscore](http://underscorejs.com/) does, [Ember Rocks](https://github.com/mattma/ember-rocks) is trying to solve similar problem that [ember-cli](https://github.com/stefanpenner/ember-cli) does. I will try to sync the features from [ember-cli](https://github.com/stefanpenner/ember-cli) to [Ember Rocks](https://github.com/mattma/ember-rocks). 

What is on my road map? Ember Add-ons, custom components, frequent updates along with Ember releases and more. PRs, Issues, Suggestion are highly welcomed and appreciated. 


## Quick Start

```bash
    em new my-app          # generate a brand new ember app in *my-app* folder
    cd my-app              # switch to application folder
    em serve               # start a server, open the new app in browser, livereload all resources
```

## Usage

```bash
    em [command] [options]

    Commands:

        new [options]      # Creates a new ember application at [dirName]
           
        g|generate         # Generate a new file with ES6 support in the ember app
               
        s|serve            # Builds and serves your app, rebuilding on file changes

        m|mobile           # Builds an Cordova application, and ready to deploy to phone or tablet
           
        b|build            # Release your app and places it into the output path '~/build'

        t|test            # Run client side integration and unit tests, rerun tests on file changes
       
    Options:

        -h, --help     output usage information
        -V, --version  output the version number

    Command-Specific Help:

        em [command] --help
```

## Guide

Since the project is highly inspired by [Ember-Cli](http://www.ember-cli.com/), ( both projects even share the same commands but completely different implementation under the hook, i.e. `em(ber) new`, `em(ber) generate`, `em(ber) g`, `em(ber) serve`, `em(ber) build`, `em(ber) test`, etc ), **Ember Rocks** uses the same modules -- [ember resolver](https://github.com/stefanpenner/ember-jj-abrams-resolver), and [ember load initializers](https://github.com/stefanpenner/ember-load-initializers). Ember Modules system ( *client/app/* ) and the resolver guide will apply to **Ember Rocks** modules and the resolver as well.

* Modules and the Resolver [Documentation](http://www.ember-cli.com/#using-modules)

_( More Coming Soon )_


## Testing your app

Integration tests are located in the folder `client/tests/integration`, and Unit tests are located in the folder `client/test/unit`. You do not have to manually create any new test files since you could simplly use `em generate` to generate any new tests with pre-defined boilerplate. If you do not know how, use `em g --help` for more details. 

If you have to manually create a test file, name test file anything you want, suffix `-test` or `_test` with file extension `.js`.

You could use future **ES6** syntax in tests, and they would be pre-compiled into vanilla javascript before serving in the browsers or phantomjs headless browsers.

#### Easiest way, the recommended way to run your test

By simply running `em test` or `em t`, it would compile your testing files, build the project, launch an express server to take any requests, watch any test file changes and rerun the test again, show the result of the tests.

```bash
  em test
```

#### Easy way, but requires two different processes and `testem` installed globally in your system. ( `npm install testem -g` )
{'fraction_non_alphanumeric': 0.09179659041235612, 'fraction_numerical': 0.0034970129680897567, 'mean_word_length': 3.8492699010833724, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 11, 'https://': 48, 'lorem ipsum': 0, 'www.': 4, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '585833', 'n_tokens_mistral': 5832, 'n_tokens_neox': 5571, 'n_words': 2783}