Solution Online

The bare minimum: pretty

Use JS's pretty function to prettify your JSON documents or collections within the Mongo's shell:

db.find({}).pretty()

Here's the difference with a simple example:
You can even turn it as your default in your preference file ~/.mongorc.js using this command:

echo "DBQuery.prototype._prettyShell = true" >> ~/.mongorc.js

Thanks to Lee Machin for this tip: https://coderwall.com/p/3vfw9a

The cleanest one: Mongo-Hacker

Mongo-Hacker adds much more than a simple prettification: it adds colors and some additional API. Installing it with the following commands:

npm -g install mongo-hacker

Now, here is the same example with some nice hacking:

Inside my CLI, I sometime like to see which process eats up my CPU or my RAM. top is generally a nice utility for that kind of tasks. But, there is a better and cleaner alternative: htop. A comparison picture is worth a thousand words.
Install it on OSX using:

brew install htop

Sidresorhus has just published an awesome package named trash. This little CLI command delete your files and folders by moving them into your OS's trashcan. Beside being a secure rm command, it simplifies it when you are removing a tree of files. Super nice.

It supports Windows, OSX and Linux.

Introduction

In my former article "Virtualize your servers", we created a virtualized server in few command lines. But... It's empty as the void in space (or so we think...). Still, you can log in easily with:

vagrant ssh

It is now time to fill it with some goodies: NGINX with all the bells and whistles.

Saltstack to the rescue

There are many provisionner available for Vagrant: Chef, Puppet, Docker, Saltstack, ... even simple bash scripts. A provisionner acts as framework for creating scripts that will fill your server wether they are physical or virtual. Note that as the servers may be virtual or physical, we will simply refers them as nodes. Nodes are the processing unit of your private cloud, wether it be a single to thousands machine.

Depending on the provisionner you choose, you may have more power for addressing use case scenarios such as:

• Managing a common configuration for each node with specialization for some of them.
• Configuring IP addresses and routes for each node.
• Managing states for each node: a state is an expected running configuration.
• Upgrading each node and letting the other knows about it while limiting the impacts on service unavailability.

I've chosen Saltstack as it covers these capabilities and the configuration files, the minions, that you write are simplistic and well organized.

Make Vagrant knows about Saltstack

Vagrant speaks Saltstack out-of-the-box. You only put in your little Vagrantfile where are stored your Saltstack files. Here, I put them in a directory named salt.

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  # Name of the node
  config.vm.box = "UbuntuServer"

  # Import a preinstalled Ubuntu Server 12.04 LTS
  config.vm.box_url = "https://cloud-images.ubuntu.com/vagrant/precise/current/precise-server-cloudimg-i386-vagrant-disk1.box"

  # Add port forwarding to access service deployed in the node
  config.vm.network "forwarded_port", host: 8080, guest: 80

  # Synchronized folders
  config.vm.synced_folder "salt/srv/salt/", "/srv/salt/"
  
  # Use Saltstack as provisioner
  config.vm.provision :salt do |salt|
    # Set the directory where is stored your minion
    salt.minion_config = "salt/minion"
    # Maintain states
    salt.run_highstate = true
  end
end

Note the option salt.run_highstate = true. It tells  Vagrant to ensure the node state whenever it is executing it.

Here comes the minions

There are 2 ways of using Saltstack: locally or as a server which acts as a repository of minions. In our simple example, we use the most basic way, the local incarnation: masterless. Therefore, the salt/minion file is kept as its bare minimum:

# We run in masterless mode
master: localhost
# We use the local file directory
file_client: local

We use the default Saltstack directory structure to store our minion that will install NGINX:

.
├── Vagrantfile
└── salt
    ├── minion
    └── srv
        └── salt
            ├── top.sls
            └── webserver.sls

The top.sls file is your entry file to the installation. Here, there is only one formula. Thus, it is pretty straightforward:

base:
  '*':
    - webserver

The webserver.sls is called by the top.sls. It contains the formula to install and run NGINX as a service:

nginx:
  pkg:
    - installed
  service:
    - running
    - require:
      - pkg: nginx

Get ready!

Now, it's time to fire up everything. If you have just followed my previous tutorial "Virtualize your servers", you should already have downloaded the node's OS. We will destroy it. Yes. Destroy it. This will not re-download the node's OS. It will simply destroy its current customized image. Then, we will rerun Vagrant with our new and fresh configuration. This will do the following:

• Re-configure the node.
• Bootstrapping Saltstack into it.
• Launch Saltstack so that:
• It install NGINX using the node's OS package manager, apt-get in this case.
• Launch NGINX as a service.

vagrant destroy
vagrant up

Now, fire up your browser of choice and use the following URL: http://localhost:8080. This should display the NGINX default page just as if you had install it on a regular Ubuntu server.

Next steps

Vagrant and Saltstack are an incredibly powerful combo. In this example, I've made you destroy and reinstalled the node. It was only to ensure a clean state. While creating your server, you don't need to recreate everything and restart your node. Using the states provided by Saltstack, you just modify your SLS files and reprovision the states as you develop them. Iteration are done in a matter of seconds with the command:

vagrant provision

You can install other services as easily. There are some already prepared formulas that you can directly import or take inspiration from in the Saltstack formulas repository.

Still a nice trick. When you need to get the results from a command line into your documentation, you can use Vim's ability to run Bash / Zsh commands and read their outputs.

For instance, I want to list all the files contained into a directory:

:r ! ls -l my_dir

Another nice example, I want to show the directory tree of my project into my documentation :

:r ! tree -d

Note : On OSX, you can install tree with Homebrew easily:

brew install tree

Some pretty useful reminders on Bash history manipulation from Shawn Biddle. Of course, il works perfectly with Zsh.

CoffeeScript as your Gulpfile

Though being less in the hype today, CoffeeScript shortens the need of writing boilerplate codes (as already detailed in this post A gulp of coffee: your gulpfile in coffeescript). All you need to do is to follow these simple steps:

1. Start by installing CoffeeScript globally:

   npm -g install coffee-script

2. Create a regular Gulpfile.js that bootstraps Gulp into using CoffeeScript:

   require('coffee-script/register');
   // This bootstraps your Gulp's main file
   require('./Gulpfile.coffee');

3. Now, you simply edit your Gulpfile.coffee and forget about most of the semicolon, accolades, parenthesis, ...

Load plugins, automatic loading of your plugins

Like MatchDep or grunt-load-tasks do it for NodeJS and Grunt, gulp-load-plugins leverages your package.json and automatically loads all the plugins in Gulp. Here are the steps to follow:

1. Start by creating a regular package.json for your project:

   npm init

2. Add locally all your required plugins and save their installation as a development dependency. Here is an example for gulp-clean:

   npm install --save-dev gulp-clean

3. At the very beginning of your Gulpfile.coffee, load Gulp and every plugins in two lines of code:

   gulp = require 'gulp'
   gp = do require 'gulp-load-plugins'  # Load all gulp plugins

4. Now all your plugins are loaded and accessible from the gp object. Their name matches the plugins name in camel case. Putting it more simply, for the plugin gulp-clean, you use it as gp.clean, for the plugin gulp-ruby-sass, you use is as gp.rubySass.

Plumber, avoid restarting Gulp when transpiling fails

When you start your watch and transpile tasks for the first time, it happens that syntax errors abruptly ends Gulp. It forces you to go the old way, fixing the bugs, re-launching Gulp, fixing the bugs, re-launching Gulp, ... tedious, to say the least.
gulp-plumber avoids the stream to end upon error. Thus, whenever you need a transpilation, you just add gulp-plumber to your pipes. Here is a simple example that shows up how to use it.

gulp.task 'css', ->
  gulp.src 'app/css/index.sass'
    .pipe gp.watch()
    .pipe gp.plumber()    # Add Plumber just before the transpilation
    .pipe gp.rubySass()
    .pipe gulp.dest 'www/css'

Installing is made easy thanks to the automatic loading of plugins as described in the previous paragraph:

npm install --save-dev gulp-plumber

Connect, start a livereload server, open your file and a create a static server in one plugin

This plugin gulp-connect is incredibly powerful: it combines a connect server with a tiny-lr one and it opens your transpiled files. Pure voodoo style. Here is short example of its basic usage:

path  = require 'path'
# Start a webserver for static files
gulp.task 'webserver', gp.connect.server
  root: path.join __dirname, 'www'
  port: 9000
  livereload: true
  open: browser: 'Google Chrome'

Just like before, the installation is easy as pie:

npm install --save-dev gulp-connect

Now, on each watch task requiring a livereload, just add a gp.connect.reload() call to their task.
Note : BrowserSync is also a very good alternative.

Autoprefixer, forget about vendor's prefixes

Wether you use pure CSS, Less, Stylus or Sass and its compagnon Compass, you have to take care of vendor prefixes depending on the public your website or hybrid app are targeting. Doing it manually is a pure madness. But using some libraries assistance may also ends up in a tedious work, piling up a bunch of libraries that you need to add or remove depending on public adoption of next generation of operating systems and browsers.
Autoprefixer does this automatically for you. It leverages the usage statistics Caniuse (by the way, an incredible and so useful website) and adds to your CSS just the prefix that it requires. A life time saver. Using it in Gulp is incredibly easy. Here is a simple example that takes Sass as its input and produces the CSS for 99% of browsers:

# Create CSS from SASS
gulp.task 'css', ->
  gulp.src 'app/css/index.sass'
    .pipe gp.watch()
    .pipe gp.plumber()
    .pipe gp.rubySass()
    .pipe gp.autoprefixer "> 1%"  # Set Autoprefixer for 99%
    .pipe gulp.dest 'www/css'

A complete sample

To complete this article, here is one of the Gulpfile.coffee that I've used on a production website (a very basic SPA):

gulp  = require 'gulp'
# Load all gulp plugins
gp    = do require 'gulp-load-plugins'
path  = require 'path'

# Start a webserver for static files
gulp.task 'webserver', gp.connect.server
  root: path.join __dirname, 'www'
  port: 9000
  livereload: true
  open: browser: 'Google Chrome'

# Create CSS from SASS
gulp.task 'css', ->
  gulp.src 'app/css/index.sass'
    .pipe gp.watch()
    .pipe gp.plumber()
    .pipe gp.rubySass()
    .pipe gp.autoprefixer "> 1%"
    .pipe gp.cssmin keepSpecialComments: 0
    .pipe gulp.dest 'www/css'
    .pipe gp.connect.reload()

# Create HTML from Jade
gulp.task 'html', ->
  gulp.src 'app/index.jade'
    .pipe gp.watch()
    .pipe gp.plumber()
    .pipe gp.jade()
    .pipe gulp.dest 'www'
    .pipe gp.connect.reload()

# Copy font files
gulp.task 'copy_fonts', ->
  gulp.src './bower_components/font-awesome/fonts/*'
    .pipe gulp.dest 'www/fonts'

# Copy vendor JS files, concatenate them and uglify them
gulp.task 'copy_js', ->
  gulp.src [
    'bower_components/better-dom/dist/better-dom.js'
    'bower_components/better-details-polyfill/dist/better-details-polyfill.js']
    .pipe gp.concat 'better-dom-and-plugin.js'
    .pipe gp.uglify()
    .pipe gulp.dest 'www/js'

# Copy vendor CSS files and minifies it
gulp.task 'copy_css', ->
  gulp.src [
    'bower_components/better-details-polyfill/dist/better-details-polyfill.css']
    .pipe gp.cssmin keepSpecialComments: 0
    .pipe gulp.dest 'www/css'

# Clean produced files
gulp.task 'clean', ->
  gulp.src ['www', 'tmp']
    .pipe gp.clean()

gulp.task 'default', [
  'copy_fonts', 'copy_js', 'copy_css'
  'css', 'html', 'webserver']

And here are the relevant part of its package.json:

{
  "name": "Blablabla",
  "version": "0.0.0",
  "description": "",
  "main": "Gulpfile.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Me",
  "license": "MIT",
  "devDependencies": {
    "gulp-cssmin": "~0.1.0",
    "gulp-ruby-sass": "~0.3.0",
    "gulp-util": "~2.2.14",
    "gulp-autoprefixer": "0.0.6",
    "gulp": "~3.5.2",
    "gulp-jade": "~0.4.1",
    "gulp-watch": "~0.5.0",
    "gulp-sass": "~0.6.0",
    "gulp-plumber": "~0.5.6",
    "gulp-clean": "~0.2.4",
    "gulp-load-plugins": "~0.3.0",
    "gulp-concat": "~2.1.7",
    "gulp-uglify": "~0.2.1",
    "gulp-connect": "~0.3.1"
  }
}

tig, git in reverse, is a nice CLI that allows to browse your git history with a clean ncurse interface.

Installing it on OSX:

brew install tig

I've made a simple video of its basic usage:

Pros and cons

Gulp is  a new buildsystem for the web. It contrasts with Grunt by leveraging NodeJS's streams. Therefore, it writes no temporary file on your drive when you're performing multiple operations on your assets. Of course, it speeds up the build process, but it is not the only advantage. Thanks to the streams, when you write your tasks, it feels more like you are describing the required workflow. For me, it is much more natural.

The main drawback that I've found is its inability to directly use CoffeeScript as its main file. Streams and their piping abilities produce a ton of parenthesis obfuscating the semantic of your development with unnecessary grammar and syntax requirements.

Regaining access to CoffeeScript

Like Grunt, Gulp expect a main file named Gulpfile.js. We will use this file to bootstrap CoffeeScript and, thus, regain access to a more friendly language. Of course, the same trick could be applied to other languages such as Dart or TypeScript.

Gulpfile.js

// Note the new way of requesting CoffeeScript since 1.7.x
require('coffee-script/register');
// This bootstraps your Gulp's main file
require('./Gulpfile.coffee');

That's it.

Now, just an example that demonstrates the achieved advantage, and also, the new parenthesis free chaining of CoffeeScript 1.7. The following script transpiles Jade, minifies it, compresses your SVG, transpiles your Sass, autoprefix it and minifies it, copies the fonts used in your Sass files.

Gulpfile.coffee

# Load all required libraries.
gulp       = require 'gulp'
sass       = require 'gulp-ruby-sass'
prefix     = require 'gulp-autoprefixer'
cssmin     = require 'gulp-cssmin'
jade       = require 'gulp-jade'
minifyHTML = require 'gulp-minify-html'
svgmin     = require 'gulp-svgmin'

# Create your CSS from Sass, Autoprexif it to target 99%
#  of web browsers, minifies it.
gulp.task 'css', ->
  gulp.src 'app/css/index.sass'
    .pipe sass()
    .pipe prefix "> 1%"
    .pipe cssmin keepSpecialComments: 0
    .pipe gulp.dest 'www/css'

# Create you HTML from Jade, Adds an additional step of
#  minification for filters (like markdown) that are not
#  minified by Jade.
gulp.task 'html', ->
  gulp.src 'app/index.jade'
    .pipe jade()
    .pipe minifyHTML()
    .pipe gulp.dest 'www'

# Minify your SVG.
gulp.task 'svg', ->
  gulp.src 'app/img/*.svg'
    .pipe svgmin()
    .pipe gulp.dest 'www/img'

# Copy the fonts using streams.
gulp.task 'copy', ->
  gulp.src 'app/fonts/*'
    .pipe gulp.dest 'www/fonts'

# Default task call every tasks created so far.
gulp.task 'default', ['css', 'html', 'svg', 'copy']

A simple and nice tutorial to refresh my memory when I contribute on Github.

ssh-copy-id is a simple tool that send your public SSH key to a remote server. Installing it on OSX:

brew install ssh-copy-id

And sending your public ssh keys is done like so on a local server at 192.168.1.32:

ssh-copy-id root@192.168.1.32

Note: If you have never generated your SSH key pair, simply issue the following command:

ssh-keygen -t rsa -C 

In a former post (A gulp of coffee: your gulpfile in coffeescript), I've shown how to bootstrap CoffeeScript in Gulp. There is now a far better solution than mine that does not require any additional file: Cult.

This little CLI just analyse the extension and automatically requires the right REPL. A time saver!

Each time you attempt to perform a sudo vim, you end up into the configuration of root. Therefore, you loose some of your personal plugins that requires local commands. That, and a warning message.

There are different ways of achieving a proper  sudo vim (providing a new $HOME via -H or using your /etc/sudoers), but still, there are situations when you have forgotten to use sudo and you end up stuck with a file that you can't overwrite.

My preferred move is to completely avoid using sudo vim and simply hit the following command whenever I need a proper right upgrade:

:w !sudo tee %

What? REPL? It stands for Read-Eval-Print-Loop. Basically, it is a form of a language interpreter that allows you to enter into a dedicated prompt, evals each commands that you pass in and prints out their results. Think of Bash, Zsh, SQlite, Redis, Coffee, NodeJS, iPython, ... You enter your commands, one at the time, and they prints out their results, one at the time. And then?

PHP on the CLI is only an interpreter. Thus, it is capable of evaluating commands and scripts. But, it can't let you pile up commands and spit out their results line by line. It has no REPL capabilities. And what?

REPL makes easy to check some aspect of a language. It lets you play with a language before coding your programs. Having this tool alongside prevents you from writing a ton of scriptlets just to check or enhance your development or improve your syntax.

Thankfully, here comes Boris. It is the REPL that PHP should have from its early days.

Installing it on OSX with Homebrew is easy as pie and is performed with these simple steps:

1. Start by installing some new recipes (or formulas):

   brew tap josegonzalez/homebrew-php

2. Then, install a local PHP interpreter. I prefer installing the 5.4 release as it matches the one provided with OSX but you can experiment with other if you plan on mimicking one of your servers in production:

   brew install php54

   
   Note: If you haven't done it before, Homebrew may warn you that a zlib dependencies is not met. In this case, follow his advice by running the following command and re-running the former one:

   brew tap homebrew/dupes

3. Now, you should have a local PHP available. It is time to add a decent package management for it, Composer:

   brew install josegonzalez/php/composer

4. And, now, let us invite Boris to the party:
   

   brew install boris

J'ai publié mes doftfiles sur GitHub. On y retrouve ma configuration personnelle sur OSX pour mes outils quotidiens :

• Vim
• Git
• Zsh
• Tmux

Just hop under your current Vagrant VM and launch the SLS file locally:

vagrant ssh
sudo salt-call state.highstate --log-level=debug

Log files are a pain to read. When colored a bit, you start having a better understanding of what it going on under the hood.


This is achieved via a simple tail replacement: colortail.

On OSX, hit the following command:

brew install colortail

On Ubuntu, use your favorite package system command:

sudo apt-get install colortail

Now, in your ~/.bashrc or your ~/.zshrc, add a simple aliases:

alias tail='colortail -k ~/.colortail/conf.default '

Create a ~/.colortail dir where you can put your colored theme files:

mkdir ~/. colortail

Here is my ~/.colortail/conf.default file:

COLOR brightred
{
# matches the word ERROR
^.*(ERROR|error).*$
}
COLOR yellow
{
# matches the word WARNING
^.*(WARNING|warning).*$
}
COLOR green
{
# matches the word INFO
^.*(INFO|info).*$
}
COLOR grey
{
# matches the word DEBUG
^.*(DEBUG|debug).*$
}
COLOR brightblue
{
# matches the time
^.*([0-9]{2}:[0-9]{2}:[0-9]{2}).*$
}

Sidre Sorhus has created an interesting set of QuickLook plugins for the OSX's Finder. Among them, there is a Markdown previewer. Very handy. Install these plugins with this command:

brew cask install qlcolorcode qlstephen qlmarkdown quicklook-json qlprettypatch quicklook-csv betterzipql webp-quicklook suspicious-package