• Easy Arduino Bluetooth Communication with JY-MCU Bluetooth module

    Last time we looked at measuring temperature using a digital temperature sensor. So we have several modules generating data, would be great to be able to access that data remotely. Let’s take a look at communication via Bluetooth with Arduino, as it turns out this is very easy!

    The Bluetooth module we’ll be using is called JY-MCU Bluetooth Board Module (4-pin). It’s pretty cheap, at this time costing only $5.97. Considering how ubiquitous Bluetooth is (most smartphones and laptops have it), it will turn out to be extremely useful in our future projects.

    Here is the datasheet for the main module: HC-06 serial wireless module.

    • The main module operates at 3.3V, but requires 3.6-6V to power the full package;
    • Sleeping current is <1mA, working current is 40mA;
    • Has a working range of about 10 meters
    • Defaults:
      • Baud rate: 9600
      • Device name: linvor
      • Passkey: 1234

    It also provides some information on how to change the baud rate, device name and passkey, so make sure to check the data sheet.

    Wiring

    The wiring is really straightforward, no extra components are needed. Simply connect the 4 pins to your Arduino board.

    Check the other side of the module, there you should find screenprinted markings of pins.

    • Connect VCC pin of the module to Arduino’s 5V pin
    • Connect GND pin of the module to Arduino’s Gnd pin
    • Connect TXD pin of the module to Arduino’s digital pin 10
    • Connect RXD pin of the module to Arduino’s digital pin 9

    And that’s it. Let’s take a look at the code.

    Code

    Libraries

    For transmitting information through the module we will use the default SoftwareSerial library. It is already bundled with Arduino, so no further downloads are necessary. Reading through the docs is, again, encouraged, as we will use very similar code to drive our JY-MCU module.

    If you open up SoftwareSerial constructor docs, SoftwareSerial constructor is defined as such:

    SoftwareSerial(rxPin, txPin, inverse_logic)

    Only two pins to drive the module, other than that the interface is exactly the same as serial communication to PC via USB. We don’t need to worry about inverse_logic parameter.

    Program code

    temperature_sensor.ino
    /**
    * JY-MCU Bluetooth module communication example for Arduino.
    *
    * Connect RX_PIN to TX pin of the module,
    * Connect TX_PIN to RX pin of the module.
    *
    * Based on SoftwareSerial example by Tom Igoe and Mikal Hart.
    * Adapted for JY-MCU module by Tautvidas Sipavicius.
    *
    * This example code is in the public domain.
    */
    #include <SoftwareSerial.h>
    const int RX_PIN = 10;
    const int TX_PIN = 9;
    const int BLUETOOTH_BAUD_RATE = 9600;
    SoftwareSerial bluetooth(RX_PIN, TX_PIN);
    void setup() {
    Serial.begin(9600);
    bluetooth.begin(BLUETOOTH_BAUD_RATE);
    }
    void loop() {
    if (bluetooth.available()) {
    Serial.write(bluetooth.read());
    }
    if (Serial.available()) {
    bluetooth.write(Serial.read());
    }
    }

    First we include the library and set our RX and TX pins. We’re setting communication pins to 10 and 9, but you can choose other ones if needed. Let’s leave the default baud rate of 9600 for this example.

    Bluetooth Serial initialization works exactly the same way regular Serial communication works, we call begin method with the baud rate.

    loop() logic is simple. If there is any data received by the bluetooth module, send it over the regular Serial connection to our PC. If PC sends information via Serial, then we send that information over via Bluetooth.

    Testing

    Now that we have wired up the module and have the program loaded on our Arduino, we’d like to test it out.

    If you have an Android device, there is this Blue Serial app for testing serial communication over Bluetooth. For Apple devices there should be something similar on the App store as well.

    Once we turn on Arduino, a red light on Bluetooth module should be flashing continuously. Once connection is established, that red light will stay on constantly.

    If you open up your Bluetooth testing application of choice (I used “Blue Serial”) and search for devices, you should be able to find a device (by default) named “linvor”. Pair with it and use the (default) pairing key “1234”. Once paired with the device, click “Connect”.

    If it connected properly, the red light on the Bluetooth module should stop flashing.

    Now you can send information from the device over bluetooth to Arduino, and, if you used the example program above, Arduino will send it over to computer’s Serial window. Arduino Serial Monitor can be opened up on your Arduino IDE by clicking “Tools > Serial Monitor (Ctrl + Shift + M)”

    Here I sent some information from my PC to the phone and vice versa:

    Further reading

    If you’re interested to learn more about this, here are some extra resources:

    And if you want to buy the JY-MCU bluetooth module, here’s the link: Buy JY-MCU Bluetooth module


  • Measuring temperature with DS18B20 temperature sensor

    Last time we looked at measuring distance using an ultrasonic sensor. This time we continue looking at using different sensors with Arduino. This time let’s take a look at measuring temperature.

    I’ve purchased the Keyes DS18B20 digital temperature sensor module for $2.74. Pretty cheap, considering we can use it as a plug and play module, without the need for extra components. Of course, we could buy the sensor, a 4.7 kOhm resistor and connect it all ourselves.

    If you take a look at DS18B20 datasheet, you’ll find it’s a pretty interesting and complex device.

    • The sensor can be powered with a 3.0V-5.5V power supply, so a 5V rail from a standard Arduino board will work just fine for that.
    • It can measure temperatures from -55C (-67F) to +125C (257F), which is perfect for general usage at home.
    • +- 0.5C accuracy, temperatures can be measured in 0.5C, 0.25C, 0.125C or 0.0625C increments.
    • Multiple such sensors can be connected do a single (!) data line, meaning we could control more than one sensor with just a single wire.
    • Supports upper and lower temperature alerts

    I suggest to browse through the data sheet for more details. It’s very detailed and it’s impressive how much is crammed into that small package.

    Wiring

    The wiring is really straightforward. Since we are using the module, it already has a pull-up resistor on the board, thus we do not need any additional parts.

    The DS18B20 temperature sensor supports receiving power via the data pin (search for “parasite power” in the data sheet if you want to learn more), but we’re going to power the sensor with Arduino’s 5V rail, as it’s simpler that way.

    The module I’ve received has been labeled differently compared to the one in the first picture (G R Y instead of - s), but pins are exactly the same no matter the printed labels:

    • Left pin is GROUND pin
    • Middle pin is VCC pin
    • Right pin is SIGNAL pin

    And so we connect pins accordingly:

    • Left pin (GROUND) -> GND pin on Arduino board
    • Middle pin (VCC) -> 5V pin on Arduino board
    • Right pin (SIGNAL) -> Digital pin 3 on Arduino board (could be any other digital pin).

    Note that we’re using a digital pin for input, that’s because the sensor returns digital values.

    Code

    If you’ve read the datasheet, you’ll quickly learn that using the sensor is not as simple as writing a few lines of code. But we’re in luck, because there are two libraries that are going to help us and make it easier.

    Libraries

    The first library is called OneWire (download directly from author or from Github). What it does is allows us to communicate with 1-wire devices, such as the DS18B20 temperature sensor we’re using.

    The second library we’ll use is called “Dallas Temperature Control Library” (download directly from author or from Github). It provides convenient calls to control the sensor and is intended to use with the exact DS18B20 sensor.

    Download both libraries and extract them into your sketchbook/libraries folder. That will allow us to directly include them in our Arduino program.

    Program code

    Our goal with this program is to simply measure the temperature synchronously using one temperature sensor (though the library provides tools for asynchronous measurements as well as measurements using multiple sensors, should you be interested in that).

    Here’s the complete program code, let’s take a look at it piece by piece.

    temperature_sensor.ino
    #include <OneWire.h>
    #include <DallasTemperature.h>
    // Sensor input pin
    #define DATA_PIN 3
    // How many bits to use for temperature values: 9, 10, 11 or 12
    #define SENSOR_RESOLUTION 9
    // Index of sensors connected to data pin, default: 0
    #define SENSOR_INDEX 0
    OneWire oneWire(DATA_PIN);
    DallasTemperature sensors(&oneWire);
    DeviceAddress sensorDeviceAddress;
    void setup() {
    Serial.begin(9600);
    sensors.begin();
    sensors.getAddress(sensorDeviceAddress, 0);
    sensors.setResolution(sensorDeviceAddress, SENSOR_RESOLUTION);
    }
    void loop() {
    sensors.requestTemperatures();
    // Measurement may take up to 750ms
    float temperatureInCelsius = sensors.getTempCByIndex(SENSOR_INDEX);
    float temperatureInFahrenheit = sensors.getTempFByIndex(SENSOR_INDEX);
    Serial.print("Temperature: ");
    Serial.print(temperatureInCelsius, 4);
    Serial.print(" Celsius, ");
    Serial.print(temperatureInFahrenheit, 4);
    Serial.println(" Fahrenheit");
    }

    We begin by setting up OneWire and DallasTemperature. DeviceAddress will be needed to directly address a specific sensor in our sensor array. But we have only one sensor, so that won’t matter too much.

    Setup function is pretty simple as well. sensors.begin() initializes the sensor. With sensors.setResolution(address, resolution) we can change the resolution of a sensor. The sensor can output values in 9, 10, 11 or 12 bits. Lower resolution means faster measurements:

    • 9 bits: increments of 0.5C, 93.75ms to measure temperature;
    • 10 bits: increments of 0.25C, 187.5ms to measure temperature;
    • 11 bits: increments of 0.125C, 375ms to measure temperature;
    • 12 bits: increments of 0.0625C, 750ms to measure temperature.

    sensors.requestTemperatures() will request the sensor to start the measurement. The measurement does not happen instantly, it may take up to 750ms to get the result. Since we are doing synchronous measurements, the processor will simply wait for the result before continuing.

    sensors.getTempCByIndex(index) and sensors.getTempFByIndex(index) calculate temperatures in Celsius and Fahrenheit respectively. The sensor actually is calibrated to work in Celsius, so Fahrenheit values are coverted from Celsius by the library. Both return float values, which may be readily used in other program logic. In this case we simply print them out in the Serial Monitor.

    Here’s the result in high resolution (SENSOR_RESOLUTION = 12):

    And here’s the result in high resolution (SENSOR_RESOLUTION = 9):

    Further reading

    If you’re interested to learn more about this, here are some extra resources:

    And if you want to buy the DS19B20, here’s the link: Buy DS18B20 temperature sensor module


  • The Strategy Pattern: Design Patterns

    Strategy Pattern UML

    Strategy is a design pattern that allows to change algorithm’s behaviour at runtime. This feature generally gives this pattern more flexibility. It can be usually recognized from algorithm classes implementing a strategy interface and a context class, which dynamically accepts algorithm objects via a strategy interface. E.g. we have our Database class, which may use a MySQLServer or PostgreSQLServer algorithm object to work with different database servers.

    Examples usually make it easier to understand a concept, so let’s try and make one. Suppose we want to have a logging class that would be able to log to the database or to StdOut and we should be able to change the desired algorithm as we want (thus the choice cannot be hardcoded).

    If we follow the UML diagram, first let’s create an algorithm interface:

    iLogger.php
    <?php
    interface iLogger {
    public function log($message);
    public function error($message);
    public function info($message);
    }

    Supposedly our log algorithm classes will support log, error and info log types (hence the same operations). Secondly, from the UML diagram we see that algorithm classes should implement our iLogger interface. Let’s create separate classes for logging to the database and logging to stdOut:

    DatabaseLogger.php
    <?php
    class DatabaseLogger implements iLogger {
    public function __construct($server) {
    printf("Opening connection to the database server %s...\n", $server);
    $this->server = $server;
    // openConnectionToServer($server)
    }
    public function log($message) {
    // log to a general log table
    printf("[%s %s] %s\n", $this->server, date("Y-m-d H:i:s"), $message);
    }
    public function error($message) {
    // log to a general log table as well as error table
    $this->log(sprintf('ERROR: %s', $message));
    }
    public function info($message) {
    $this->log(sprintf('INFO: %s', $message));
    }
    }

    For this example I’m simply outputting log information to the screen for the sake of simplicity, but in a real application we would connect to the database and send queries to insert data into log tables.

    STDOutLogger.php
    <?php
    class STDOutLogger implements iLogger {
    public function log($message) {
    printf("[%s] %s\n", date("Y-m-d H:i:s"), $message);
    }
    public function error($message) {
    $this->log(sprintf('ERROR: %s', $message));
    }
    public function info($message) {
    $this->log(sprintf('INFO: %s', $message));
    }
    }

    Logging to stdOut is simple as well. It simply adds some additional information (e.g. log time) and outputs it.

    Then let’s create our Context class (in this case - Log class). It should dynamically accept a logger and delegate it all logging operations:

    Log.php
    <?php
    class Log {
    public function __construct(iLogger $logger) {
    $this->logger = $logger;
    }
    public function log($message) {
    $this->logger->log($message);
    }
    public function error($message) {
    $this->logger->error($message);
    }
    public function info($message) {
    $this->logger->info($message);
    }
    public function setLogger(iLogger $logger) {
    $this->logger = $logger;
    }
    }

    As you can see we simply store the supplied logger instance and delegate all logging operations to it. If at any point we decide to switch to a different logger - we can simply call setLogger with an instance of another logger and dynamically swap to it.

    And lastly, the example usage code:

    main.php
    <?php
    require('iLogger.php');
    require('Log.php');
    require('STDOutLogger.php');
    require('DatabaseLogger.php');
    // Create a new Log instance and configure it to use logging to stdOut strategy
    $log = new Log(new STDOutLogger());
    // Log some example information
    $log->info('Logging to STDOut may be useful for testing');
    $log->error('This is an error');
    $log->log('Let\'s try swapping to a DatabaseLogger');
    // During runtime we decide to start logging information to the database.
    // We can simply set the new logger and continue logging
    $log->setLogger(new DatabaseLogger('tmpserver'));
    $log->log('Now our logger should be logging to the database');
    $log->error('Logging error to the database');

    Now if we run our example code with php5 main.php, we should see the output:

    output
    % php5 main.php
    [2014-03-16 21:56:28] INFO: Logging to STDOut may be useful for testing
    [2014-03-16 21:56:28] ERROR: This is an error
    [2014-03-16 21:56:28] Let's try swapping to a DatabaseLogger
    Opening connection to the database server tmpserver...
    [tmpserver 2014-03-16 21:56:28] Now our logger should be logging to the database
    [tmpserver 2014-03-16 21:56:28] ERROR: Logging error to the database

    As you can see it started by logging information to stdOut. At some point we decided to swap to a DatabaseLogger. We’ve instantiated it, dynamically passed it to our Log instance and it continued logging information without any problems.

    Last thoughts

    Strategy is a good design pattern to know. It provides a great deal of flexibility by allowing to dynamically change the behaviour while keeping algorithms separate making the code clearer. However, it sometimes requires more effort to implement and use.

    You can find the code above as well as other design patterns I’ve talked about on my GitHub repository here: Strategy Design Pattern

    These series on design patterns is something I’ll write on more in the future as I explore more. I hope you find these as useful as I do. If you have any questions or comments - let me know.


  • Expanding Your Toolset #2: Grunt - The Javascript Task Runner

    This is the second post in “Expanding Your Toolset” series (previous post was Expanding Your Toolset: Bower - Package Management For The Web). Last time we’ve looked at Bower - a package manager for the web. Bower is useful for quickly resolving dependencies for your project (e.g. if you need a specific version of jQuery, AngularJS, UnderscoreJS and etc.).

    GruntJS

    GruntJS is a task runner. It’s primary purpose is to automate the tedious stuff we as developers have to do. For example, when developing for the web it’s usually a good idea to minify and combine CSS and Javascript. Do you do this by hand? Or maybe you have a custom shell script to do that for you? Been there, done that. In any case using GruntJS will make it easier and quicker to accomplish such tasks. The community has written many plugins for it (e.g. JSHint, Sass, Less, CoffeeScript, RequireJS and etc.), thus it may be really beneficial for your current (or future) projects.

    Installing Grunt

    GruntJS is a Javascript library and it runs on NodeJS. It’s distributed via Npm, so to install it globally simply run:

    npm install -g grunt-cli

    As usual, on Linux you may have to prepend sudo command if you’re getting EACCESS errors.

    Setting up Grunt

    For a new project we will need to create two files: package.json and Gruntfile.js (or Gruntfile.coffee if you use CoffeeScript).

    For our example we will automate concatenation of a bunch of files.

    First let’s set up our package.json. grunt is needed to be defined as a dependency and we’ll use grunt-contrib-concat and grunt-contrib-watch plugins for this example. We don’t provide the version so that Npm would install the latest ones.

    package.json
    {
    "name": "testproj",
    "version": "0.1.0",
    "dependencies": {
    "grunt": "",
    "grunt-contrib-concat": "",
    "grunt-contrib-watch": "",
    }
    }

    Now run npm install to install all dependencies for our little example. Next let’s set up our Gruntfile.js.

    module.exports = function(grunt) {
    grunt.initConfig({
    pkg: grunt.file.readJSON('package.json'),
    concat: {
    options: {
    banner: "/* <%= pkg.name %> v<%= pkg.version %>*/\n"
    },
    dist: {
    src: ['app/dev/aaa.js', 'app/dev/bbb.js', 'app/dev/ccc.js'],
    dest: 'app/app.js'
    },
    dev: {
    src: ['app/dev/*.js'],
    dest: 'app/dev.js'
    }
    }
    });
    grunt.loadNpmTasks('grunt-contrib-concat');
    grunt.registerTask('default', ['concat']);
    };

    module.exports = function(grunt) { ... is the wrapping function that will be executed once you run grunt command. This is the basic format, that’s where all of your Grunt code should go to.

    Configuration is passed into grunt.initConfig(configuration). Configuration should describe what tasks are available and configuration of those tasks. You can store any arbitrary data in this configuration object as well. In our example we load configuration information from package.json and will use it to construct the banner. <% %> are template tags (yes, Grunt supports templates).

    concat defines configurations for the concatenation task. We can add more tasks and will do so in later examples. We can specify an options object to override the default configuration for that particular task. dist and dev are targets. Unless specified otherwise, if we run grunt concat it will run concat task on both targets. But if we run grunt concat:dist, then concat will only be run for dist target. dist object has to have a src attribute which takes an array of file paths (e.g. in target dist). Grunt supports globbing (e.g. target dev), which means any javascript file in app/dev/ will be concatenated into app/dev.js.

    grunt.loadNpmTasks('grunt-contrib-concat'); enables you to use grunt-contrib-concat task. Though it must be noted, that grunt-contrib-concat must be specified as a dependency in your package.json file and installed.

    grunt.registerTask('default', ['concat']); tells Grunt which tasks it should run if you don’t specify which task should be run. So if you’d run grunt - it would run the task concat. If default task is not specified and grunt command is run - it will only return Warning: Task "default" not found. Use --force to continue. and exit.

    Next let’s create three files: app/dev/aaa.js, app/dev/bbb.js and app/dev/ccc.js with their contents respectively:

    app/dev/aaa.js
    (function() { console.log('File aaa.js'); })();
    app/dev/bbb.js
    (function() { console.log('File bbb.js'); })();
    app/dev/ccc.js
    (function() { console.log('File ccc.js'); })();

    Now if we run grunt we should see this:

    % grunt
    Running "concat:dist" (concat) task
    File "app/app.js" created.
    Running "concat:dev" (concat) task
    File "app/dev.js" created.
    Done, without errors.

    And if we check app/app.js:

    app/app.js
    /* testproj v0.1.0*/
    (function() { console.log('File aaa.js'); })();
    (function() { console.log('File bbb.js'); })();
    (function() { console.log('File ccc.js'); })();

    Wonderful, so it is indeed working. Sure, you may not want to use this exact method to combine your javascript (using grunt-contrib-uglify is much better). But let’s take it one step further. Let’s use grunt-contrib-watch to watch for changes in any of our app/dev/*.js files and reconcatenate them as needed.

    Watching for changes

    We’ll need to do a few alterations. We’ve already added grunt-contrib-watch dependency to package.json. So let’s add grunt.loadNpmTasks('grunt-contrib-watch'); to the Gruntfile.js.

    Then we’ll set up the watching. Add this to the configuration object:

    Gruntfile.js
    watch: {
    scripts: {
    files: ['app/dev/*.js'],
    tasks: ['concat']
    }
    }

    So we’re adding a new task watch with target scripts (the target name is arbitrary - you can pick one yourself if you wish). Then we define which files it should watch and which tasks should be executed if any of the watched files change. The end file should look like this:

    Gruntfile.js
    module.exports = function(grunt) {
    grunt.initConfig({
    pkg: grunt.file.readJSON('package.json'),
    concat: {
    options: {
    banner: "/* <%= pkg.name %> v<%= pkg.version %>*/\n"
    },
    dist: {
    src: ['app/dev/aaa.js', 'app/dev/bbb.js', 'app/dev/ccc.js'],
    dest: 'app/app.js'
    },
    dev: {
    src: ['app/dev/*.js'],
    dest: 'app/dev.js'
    }
    },
    watch: {
    scripts: {
    files: ['app/dev/*.js'],
    tasks: ['concat']
    }
    }
    });
    grunt.loadNpmTasks('grunt-contrib-concat');
    grunt.loadNpmTasks('grunt-contrib-watch');
    grunt.registerTask('default', ['concat']);
    };

    Now if we run grunt watch and change app/dev/ccc.js, then we should see this:

    % grunt watch
    Running "watch" task
    Waiting...OK
    >> File "app/dev/ccc.js" changed.
    Running "concat:dist" (concat) task
    File "app/app.js" created.
    Running "concat:dev" (concat) task
    File "app/dev.js" created.
    Done, without errors.
    Completed in 0.382s at Fri Mar 07 2014 22:58:49 GMT+0200 (EET) - Waiting...

    As you can see it reruns concat task on each change as expected.

    You can really leverage watch task in certain situations. For example it was used for grunt-contrib-livereload (and apparently it’s now baked in directly into grunt-contrib-watch!) to detect code changes and refresh your browser automatically. And since Grunt can play with other languages well, I’ve used it with grunt-shell to do some rapid prototyping with Python (nothing fancy, it detects any changes and reruns the application, yet it sped up the working process).

    Usage ideas

    The example above should give you the basic picture of how Grunt works. I’ve realized that there are many use cases for this tool and it probably be pointless to describe each one step by step, so I’ll just provide you with some ideas how Grunt could help your workflow and point to some plugins. You can read their wiki pages for integration details.

    Last thoughts

    I haven’t provided as many examples as I wanted to, but I hope that this one example gave you an idea of how this works and whether it would fit into your workflow. Personally, I really like Grunt so far and I’ve already started to integrate it into my projects. Currently it’s limited to minifying code and running shell commands, but I hope to expand the usage as I explore.

    Grunt can help a lot if you allow it to do so. Community has already created 2443 plugins (at the time of writing), so I bet there’s a lot that can be automated simply by installing a plugin. And if there’s no plugin for your use case - you can simply create one and publish it yourself.


  • Expanding Your Toolset: Bower - Package Management For The Web

    I’ve been doing web development for quite a while and certainly the whole development process has a few pains. E.g. making sure the libraries were all up to date, managing dependencies, combining and minifying scripts (or often forgetting to do so). It’s simply a chore that has to be done.

    Over the past month a few tools came to my attention that help with chores mentioned above. Those tools are Yeoman, GruntJS and Bower. I’ll go over all three in next few posts, but let’s start with Bower.

    What is Bower?

    Bower

    Bower is a “Package manager for the web”. It was created and opensourced by Twitter.

    Installing Bower

    Before the installation make sure that you have Git installed, as some packages may require it.

    Bower is written in Javascript for NodeJS, so you can install it easily via NPM:

    npm install -g bower

    -g means that we want Bower to be installed globally. If you don’t want to do that - just remove -g and it will be installed in your current directory.

    If you get EACCES errors - prepend sudo to the command:

    sudo npm install -g bower

    For any other errors consult StackOverflow.

    Once that’s done, we’re ready to take a closer look at it.

    Using Bower

    The great thing about Bower is that it allows you to install packages not only from Bower’s own package registry, but also via other means. As of the day I’m writing this post the list of supported endpoints is:

    • public remote Git repositories
    • private remote Git repositories (supports authentication via https and ssh)
    • local Git repositories
    • public remote Subversion repositories
    • private remote Subversion repositories
    • local Subversion repositories
    • Github repositories (supports shorthand syntax, <owner>/<repo>)
    • URLs to zip or tar archives (contents will be extracted automatically)

    Installing the latest version of a package is as simple as running:

    bower install <package name>

    or if you want a specific version:

    bower install <package name>#<version>

    If you’re not sure what to install and want to search for packages:

    bower search <keyword>

    Example

    Say we want to install EmberJS. We don’t know how the package is named precisely and do a search run bower search ember. It yields:

    $ bower search ember
    Search results:
    ember git://github.com/components/ember
    ember-data-shim git://github.com/components/ember-data.git
    ember-data git://github.com/components/ember-data.git
    ember-mocha-adapter git://github.com/teddyzeenny/ember-mocha-adapter.git
    ember-testing-httpRespond git://github.com/trek/ember-testing-httpRespond.git
    ember-addons.bs_for_ember git://github.com/ember-addons/bootstrap-for-ember.git
    ember-model git://github.com/ebryn/ember-model.git

    Now we install the ember package with bower install ember. It will go and install ember along with it’s dependencies. You should get something similar to

    bower ember#* cached git://github.com/components/ember.git#1.3.1
    bower ember#* validate 1.3.1 against git://github.com/components/ember.git#*
    bower ember#* new version for git://github.com/components/ember.git#*
    bower ember#* resolve git://github.com/components/ember.git#*
    bower ember#* download https://github.com/components/ember/archive/1.4.0.tar.gz
    bower ember#* extract archive.tar.gz
    bower ember#* resolved git://github.com/components/ember.git#1.4.0
    bower jquery#>= 1.7 <= 2.1 cached git://github.com/jquery/jquery.git#1.10.2
    bower jquery#>= 1.7 <= 2.1 validate 1.10.2 against git://github.com/jquery/jquery.git#>= 1.7 <= 2.1
    bower handlebars#>= 1.0.0 < 2.0.0 cached git://github.com/components/handlebars.js.git#1.3.0
    bower handlebars#>= 1.0.0 < 2.0.0 validate 1.3.0 against git://github.com/components/handlebars.js.git#>= 1.0.0 < 2.0.0
    bower jquery#>= 1.7 <= 2.1 new version for git://github.com/jquery/jquery.git#>= 1.7 <= 2.1
    bower jquery#>= 1.7 <= 2.1 resolve git://github.com/jquery/jquery.git#>= 1.7 <= 2.1
    bower jquery#>= 1.7 <= 2.1 download https://github.com/jquery/jquery/archive/2.0.3.tar.gz
    bower jquery#>= 1.7 <= 2.1 extract archive.tar.gz
    bower jquery#>= 1.7 <= 2.1 resolved git://github.com/jquery/jquery.git#2.0.3
    bower ember#~1.4.0 install ember#1.4.0
    bower handlebars#>= 1.0.0 < 2.0.0 install handlebars#1.3.0
    bower jquery#>= 1.7 <= 2.1 install jquery#2.0.3
    ember#1.4.0 app/bower_components/ember
    ├── handlebars#1.3.0
    └── jquery#2.0.3
    handlebars#1.3.0 app/bower_components/handlebars
    jquery#2.0.3 app/bower_components/jquery

    Our new directory structure is:

    % tree -d app
    app
    └── bower_components
    ├── ember
    ├── handlebars
    │   └── lib
    │   └── handlebars
    └── jquery
    ... SNIP ...
    23 directories

    As you can see, by default it places all packages in app/bower_components.

    Customizing install directory

    Say our project has a different directory structure and we want to install packages to js/ instead of app/bower_components. To do that we create a .bowerrc file with a JSON object:

    {
    "directory": "js"
    }

    Now if we install ember again with bower install ember, you should see, that Bower installed it to js directory, just as we told it to:

    % tree -d .
    .
    └── js
    ├── ember
    ├── handlebars
    │   └── lib
    │   └── handlebars
    └── jquery
    ...Snipped...
    23 directories

    Automating installation of all dependencies

    Say we’re not the only ones working on a project. Let’s assume that we don’t want to commit dependencies to version control. Will other people need to run the exact same commands to install all dependencies our project has? Well, that’s where we’ll create our own package.

    A bower package project is defined in file bower.json. (it’s similar to Ruby’s Gemfile or PHP Composer’s composer.json)

    You can create the file with bower init and the guide will walk you through all the options, but let’s create this one by hand. Create a new file bower.json with contents:

    {
    "name": "test",
    "version": "1.0",
    "dependencies": {
    "ember": "",
    "bootstrap": "~3.1.1",
    "underscore": ""
    }
    }

    I’ve added a few more packages just to make this example more visual. As you can see the version of the package can be specified as a value of dependencies object. If you omit the version Bower will install the latest one.

    Now if we run bower install Bower will install all packages to our install directory (app/bower_components by default, js/ if you’ve left our custom install directory):

    % bower install
    bower bootstrap#~3.1.1 not-cached git://github.com/twbs/bootstrap.git#~3.1.1
    bower bootstrap#~3.1.1 resolve git://github.com/twbs/bootstrap.git#~3.1.1
    bower ember#* cached git://github.com/components/ember.git#1.4.0
    bower ember#* validate 1.4.0 against git://github.com/components/ember.git#*
    bower underscore#* cached git://github.com/jashkenas/underscore.git#1.6.0
    bower underscore#* validate 1.6.0 against git://github.com/jashkenas/underscore.git#*
    bower jquery#>= 1.7 <= 2.1 cached git://github.com/jquery/jquery.git#2.0.3
    bower jquery#>= 1.7 <= 2.1 validate 2.0.3 against git://github.com/jquery/jquery.git#>= 1.7 <= 2.1
    bower handlebars#>= 1.0.0 < 2.0.0 cached git://github.com/components/handlebars.js.git#1.3.0
    bower handlebars#>= 1.0.0 < 2.0.0 validate 1.3.0 against git://github.com/components/handlebars.js.git#>= 1.0.0 < 2.0.0
    bower bootstrap#~3.1.1 download https://github.com/twbs/bootstrap/archive/v3.1.1.tar.gz
    bower bootstrap#~3.1.1 extract archive.tar.gz
    bower bootstrap#~3.1.1 resolved git://github.com/twbs/bootstrap.git#3.1.1
    bower jquery#>= 1.9.0 cached git://github.com/jquery/jquery.git#2.1.0
    bower jquery#>= 1.9.0 validate 2.1.0 against git://github.com/jquery/jquery.git#>= 1.9.0
    bower ember#* install ember#1.4.0
    bower underscore#* install underscore#1.6.0
    bower jquery#>= 1.7 <= 2.1 install jquery#2.0.3
    bower handlebars#>= 1.0.0 < 2.0.0 install handlebars#1.3.0
    bower bootstrap#~3.1.1 install bootstrap#3.1.1
    ember#1.4.0 js/ember
    ├── handlebars#1.3.0
    └── jquery#2.0.3
    underscore#1.6.0 js/underscore
    jquery#2.0.3 js/jquery
    handlebars#1.3.0 js/handlebars
    bootstrap#3.1.1 js/bootstrap
    └── jquery#2.0.3

    bower install will also install any missing dependencies, so if we “accidentally” remove a package and then run bower install, we should see the missing dependency installed again:

    % rm -rf js/underscore
    % bower install
    bower underscore#* cached git://github.com/jashkenas/underscore.git#1.6.0
    bower underscore#* validate 1.6.0 against git://github.com/jashkenas/underscore.git#*
    bower underscore#* install underscore#1.6.0
    underscore#1.6.0 js/underscore

    And lastly, if you want to update packages, use bower update.

    Last thoughts

    So far I really enjoy using Bower. I’m excited that it makes one more web development pain go away, but I suspect it will have a larger impact once we start using Bower in combination with GruntJS and Yeoman. I will cover those in next few posts, so that’s it for today.