Posva Dev Blog

Git Flow aliases

2016-01-05T00:00:00+00:00

I recently started using git-flow which is an utility that makes it really easy nvie’s branching model

The branching model is well explained in his blog. If you’ve never heard about it, I really recommend you to read it.

About git-flow itself, there is a nicely done cheatsheet here

If you’re on a mac you can install it with brew

brew install git-flow

This also downloads the completion files. Which are in my opinion really useful when you start using a tool

However we can bring it to the next level by setting up some aliases. This takes very little time and saves you some keystrokes everyday. I couldn’t find any so I created my own:

alias gf='git-flow'
alias gfi='git-flow init'
alias gfid='git-flow init -d'

alias gff='git-flow feature'
alias gffv='git-flow feature -v'
alias gffco='git-flow feature checkout'
alias gffd='git-flow feature diff'
alias gfff='git-flow feature finish'
alias gffp='git-flow feature publish'
alias gffl='git-flow feature pull'
alias gffr='git-flow feature rebase'
alias gffs='git-flow feature start'
alias gfft='git-flow feature track'

alias gfr='git-flow release'
alias gfrv='git-flow release -v'
alias gfrf='git-flow release finish'
alias gfrp='git-flow release publish'
alias gfrs='git-flow release start'
alias gfrt='git-flow release track'

alias gfh='git-flow hotfix'
alias gfhv='git-flow hotfix -v'
alias gfhf='git-flow hotfix finish'
alias gfhp='git-flow hotfix publish'
alias gfhs='git-flow hotfix start'

Do you have any more aliases you use everyday?

Using Material Design Lite with Vue.js

2015-08-26T00:00:00+00:00

When building an application I like to use a nice framework for the design. Lately Material Design has been getting some attention. Some implementation are being worked on and are functional. One of these implementations is Material Design Lite which is library agnostic and can be used with any data-reactive library/framework like Angular, Reactjs, Aurelia or, my preferred one, Vue.js.

As MDL (Material Design Lite) is library/framework agnostic, you have to manually call some functions on elements that are dynamically created. This is clearly said on the Getting Started section of MDL. It is actually very simple as you only have to call the method componentHandler.upgradeElement on an element to make it behave as any other MDL component.

In Vue.js this is extremely easy to do by using a directive:

Vue.directive('mdl', {
  bind: function() {
    componentHandler.upgradeElement(this.el);
  }
});

This directive will call the needed method at creation on any element using it. In the case of a button, this will add the on click ripple effect.

But what about more complex components, like the progressbar?

It has a variable value that must be changed with a special method element.MaterialProgress.setProgress. It would be nice to have some markup like this:

<div v-progress="progressVariable" class="mdl-progress mdl-js-progress"></div>

If the progressVariable value changes, the progressbar should change accordingly. Well, another incredibly simple directive solves this as well:

Vue.directive('mdl-progress', function(val) {
  // The directive may be called before the element have been upgraded
  if (!this.el.MaterialProgress)
    componentHandler.upgradeElement(this.el);
  this.el.MaterialProgress.setProgress(val);
});

Easy peasy!

Using task-logger.sh

2015-02-03T00:00:00+00:00

task-logger.sh

task-logger.sh is a tiny shell lib I wrote about a week ago. It is compatible with zsh and bash and can be used with sh by just changing the echo calls (sh echo doesn’t accept -n option).

It allows to have some fancy output, summarizing what is most important: * execution time * status code

The output is all written to temporary files in /tmp, making the status of each task easily readable.

ISERT PIC HERE

In my dotfiles I use a quite simple install.sh script to install everything I need to work. The output isn’t great and I cannot read easily if something fails. This is way I’m moving to task-logger.sh.

Helpers

During my install script I want to have some critical tasks. However I just want to print messages and then exit instead of -c option behaviour for log_cmd. Therefore I implement two functions fail and crash:

fail() {
  ko
  bad "$@"
}

crash() {
  ko
  bad "$@"
  exit 1
}

They are supposed to be used as a replacement for the ko function in the log_cmd <task-name> <task> || ko call.

Approach

Most of the translation is pretty much straight forward but sometimes you want to group very tiny tasks such as cd or mkdir. You can either extend working functionality to fit your needs or create functions with || return 1 at the end of each command. I personally prefer the last one as it produces less output.

For instance backing up files looks like this:

_backup_dir() {
  mkdir -p $olddir || return 1
  for file in $files; do
    if [ -f ~/."$file" -o -d ~/."$file" ]; then
      mv -f ~/."$file" "$olddir" || return 1
    fi
  done
}
backup_dir() {
  working -n "Backing up files to $olddir"
  log_cmd $0 _backup_dir || crash "Backup failed, aborting"
}

You can even group many log_cmd inside a function if the tasks are dependants. For example when installing oh-my-zsh, I need zsh first. There is no point in installing oh-my-zsh if zsh already failed. To achieve this we create an other auxiliary function and call it from the main function adding a || ko or any other equivalent (warn, crash, failed)

_install_zsh() {
  if [[ ! -x $(which zsh) ]]; then
    working -n "Installing zsh"
    log_cmd zsh-install ${INSTALL} zsh || return 1
  fi
  if [[ ! -d ${dir}/oh-my-zsh/ ]]; then
    working -n "Cloning oh-my-zsh"
    log_cmd oh-my-zsh git clone https://github.com/robbyrussell/oh-my-zsh.git || return 1
  fi
}
install_zsh() {
  _install_zsh || ko
}

Note the || return 1 to exit the function. The || ok is actually necessary because log_cmd does print the check mark when the task succeed but doesn’t print anything if it fails. It doesn’t print a newline.

Vim plugins

I install Vim plugins with Vundle, inside Vim. This means that Vim is launched and the progress is shown inside. Therefore using log_cmd is not the right way to go as this will print dots (.) while in Vim. You should actually use timers and print some custom information. It’s this simple:

  # install plugins
  working -n "Installing plugins"
  reset_timer 5
  if vim -Nu "$dir/vim-plugins.vim" +PluginInstall! +qall; then
    echo -n "[$(get_timer 5) s]"
    ok
  else
    echo -n "[$(get_timer 5) s]"
    ko
  fi

In my dotfiles i replace the ko call with return 1

Final result

At the moment I just have this tiny screenshot with a few tasks because most of them are skipped. I will added a better one when I can

Optimizing static webpages with gulp

2014-12-22T00:00:00+00:00

Recently I decided to create my own online portfolio/CV. Having a Github profile with all of your projects is nice but seems quite slow to inspect in my opinion. I therefore want to show off myself with a simple and light webpage. This doesn’t only relate to the design, which I’m not very good with by the way, but also in the resources you use: images, scripts (JavaScript), style sheets (CSS) and HTML pages.

Grunt or Gulp

I’m not going to discuss about which one is better but I already used Grunt in dominion and it works pretty well. I find it to be sometimes slow but my computer that may be my computer’s fault too. Gulp is all about piping files into plugins and it runs faster (at least in my case). It’s a streaming build system. Finally I could also use Brunch but that won’t be this time.

Gulp configuration file gulpfile.js is actually easier than a Gruntfile.js. It starts as any node module:

var gulp = require('gulp');

And then you add modules and tasks:

var gulp = require('gulp');
var jshint = require('gulp-jshint');
var stylish = require('jshint-stylish');

var from = {
  js: 'src/js/*.js'
};

gulp.task('jshint', function() {
  gulp.src(from.js)
  .pipe(jshint())
  .pipe(jshint.reporter(stylish));
});

This is just an example to lint the js code using a better reporter. You will have to install these modules with npm install.

Directory structure

.
├── README.md
├── fonts
│   └── fontawesome and stuff
├── gulpfile.js
├── images
│   ├── 404.png
│   ├── favicon.png
│   └── plogo.png
├── lib
│   └── js libs and stuff
├── css
│   └── css from libs and stuff
├── package.json
└── src
    ├── css
    │   ├── demo.css
    │   ├── tabs.css
    │   └── custom.css
    ├── index.html
    └── js
        └── app.js

lib dir contains js lib but you could also use bower to install them.
css dir contains css from lib/frameworks but you could, again, use bower.
src contain all the files that we are writing ourselves

Image optimization

When creating some webpages, the size of the resources is always what takes longer to load. Therefore optimizing images is always a good idea. We will be using gulp-imagemin. In addition to that we will also be using gulp-changed to only pipe images that were modified and therefore diminishing deploy time.

var changed = require('gulp-changed');
var imagemin = require('gulp-imagemin');

var from = {
  img: 'images/**/*.@(png|jpg|gif)',
  js: 'src/js/*.js'
};
var to = {
  img: 'images/'
};

gulp.task('imagemin', function() {
  return gulp.src(from.img)
  .pipe(changed(to.img))
  .pipe(imagemin())
  .pipe(gulp.dest(to.img));
});

We are chaging the images in place because we don’t need to save the same image twice if we are only going to use one of them. imagemin can also optimize svg files and support some options that should be taken into account depending of the kind of pictures you’ll be using on your site. You can check the readme for more help.

`gulp-usemin`

Now, we are going to minimize the js, the css and the html files all together by using the gulp plugin usemin. This is really useful because it will rename the tags used on your dev page as well, meaning that we won’t need to manually create an html page that includes your minified css and js files. Unfortunately we need to add some lines to help it:

<!-- build:css style.css -->
  <link rel="stylesheet" type="text/css" href="css/tabs.css" />
  <link rel="stylesheet" type="text/css" href="../css/normalize.css">
  <link rel="stylesheet" type="text/css" href="../css/skeleton.css">
  <link rel="stylesheet" type="text/css" href="css/custom.css"/>
  <link rel="stylesheet" type="text/css" href="../css/font-awesome.min.css"/>
<!-- endbuild -->

It’s very similar for the js:

<!-- build:js script.js -->
  <script src="../lib/modernizr.custom.js"></script>
  <script src="../lib/director.min.js"></script>
  <script src="../lib/cbpFWTabs.js"></script>
  <script src="js/app.js"></script>
<!-- endbuild -->

Our ìndex.html being located under src we need to reference the folders properly. One downside about usemin is that it rips off any comment including those targeting IE:

<!--[if lt IE 9]>
  <script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

I might fix this myself in a pull-request. minifyHTML should not be ripping off these kind of comments because they’re not comments!

Once our html is fine, we should add the corresponding js to the gulpfile.js:

var usemin = require('gulp-usemin');
var uglify = require('gulp-uglify');
var minifyHTML = require('gulp-minify-html');
var minifyCSS = require('gulp-minify-css');

var from = {
  img: 'images/**/*.@(png|jpg|gif)',
  css: 'src/css/*.css',
  html: 'src/*.html',
  js: 'src/js/*.js'
};
var to = {
  img: 'images/',
  css: './',
  html: './',
};

gulp.task('usemin', function () {
  return gulp.src(from.html)
  .pipe(usemin({
    css: [minifyCSS(), 'concat'],
    html: [minifyHTML({empty: true})],
    js: [uglify(), 'concat']
  }))
  .pipe(gulp.dest('./'));
});

As you may have noticed we are creating the files at ., this is because having a gh-pages branch allows to Github to directly serve that index.html without further configuration.

Now we can do gulp imagemin, gulp usemin and we will be generating our site. But you can do better right. Gulp does have a built-in watch method. However we will not be using it because it doesn’t detect new or deleted files. We are therefore using gulp-watch plugin instead.

var watch = require('gulp-watch');

gulp.task('watch', ['default'], function() {
  watch(from.img, function() {
    gulp.start('imagemin');
  });
  watch([from.js, from.html, from.css], function() {
    gulp.start('usemin');
  });
});

gulp.task('default', ['jshint', 'imagemin', 'usemin']);

Please note that gulp.start will be removed in later versions. We could just copy the task code inside that function instead. It’s important to add default as a dependency so the generation will be executed at least once. Otherwise it will just wait for changes before generating anything.

Optimizing even more

If we run audits on the page with Chrome or Firefox, you may notice that most of the css is unused. What a shame! Fortunately we can fix this! We can rip off the unused css rules with gulp-uncss plugin. It also takes the html to detect what is not used. If some rules are not present in the index.html we must add an ignore array to the uncss call. This is documented on the Github page for gulp-uncss.

What we are going to do is simply strip off anything unused from the final style.css file instead of doing it with each file because it’s way faster. We are going to create a task named style depending on usemin so that the initial style.css file exists and we can modify it. We also need to update the default task to depend on style instead of usemin and, a new watch(from.css,...) and remove that from.css from the last watch(...):

var uncss = require('gulp-uncss');

gulp.task('style', ['usemin'], function() {
  return gulp.src(to.css + 'style.css')
  .pipe(uncss({
    html: [to.html + 'index.html']
  }))
  .pipe(gulp.dest(to.css));
});

gulp.task('watch', ['default'], function() {
  watch(from.img, function() {
    gulp.start('imagemin');
  });
  watch(from.css, function() {
    gulp.start('style');
  });
  watch([from.js, from.html], function() {
    gulp.start('usemin');
  });
});

gulp.task('default', ['jshint', 'imagemin', 'style']);

Finally I like to serve at the same time so I can launch gulp watch and then just keep working. This is very easy, we just need to add the gulp-connect plugin, create a task for it and add it as a dependency to the watch task:

var connect = require('gulp-connect');

gulp.task('connect', function() {
  connect.server();
});

gulp.task('watch', ['default', 'connect'], function() {

And voilà, happy coding.

The whole code source is available at Github. Thought it may change in the future.

Mocha + RequireJS boilerplate

2014-09-13T00:00:00+00:00

Yesterday I had a bit of a bad time trying to code some tests for a web application (written in js). The main problem was that using requirejs needed some further configuration within tests. It didn’t take too long to find what I was doing wrong but it may be confusing at the beginning. During this post I’ll be talking about:

Mocha for tests
should for BDD style assertions
RequireJS for JS modularity
selfish for prototypal inheritance

In order to run tasks you need to install grunt with npm install -g grunt-cli.

Context

In order to learn some modular JavaScript and how nodejs works, I decided to code a card game called Dominion. There are already multiple web versions of this game, there is even an official one. Yet this is a good way of practicing modularity, testing and server/client behaviour with nodejs.

Let’s show how the work tree is organized:

$ tree
.
├── Gruntfile.js
├── index.html
├── main.js
├── package.json
├── js
│   ├── app.js
│   └── card.js
└── test
    └── cards.js

Let’s look at the package.json file as it includes all the dependencies needed:

{
  "name": "TODO",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "test": "./node_modules/.bin/mocha"
  },
  "dependencies": {
    "domready": "^1.0.7",
    "requirejs": "^2.1.15",
    "selfish": "^0.3.2"
  },
  "devDependencies": {
    "grunt": "~0.4.5",
    "grunt-contrib-jshint": "~0.10.0",
    "grunt-contrib-requirejs": "~0.4.4",
    "grunt-http-server": "0.0.5",
    "grunt-mocha-test": "~0.11.0",
    "requirejs": "^2.1.15",
    "rjs-build-analysis": "0.0.3",
    "should": "~4.0.4"
  }
}

The Gruntfile.js file has been simplified to match the testing part:

module.exports = function(grunt) {

  // Project configuration.
  grunt.initConfig({
    pkg: grunt.file.readJSON('package.json'),
    mochaTest: {
        test: {
            options: {
                reporter: 'spec'
            },
            src: ['test/**/*.js']
        }
    },
  });

  grunt.loadNpmTasks('grunt-mocha-test');

  // Default task(s).
  grunt.registerTask('test', ['mochaTest']);

};

We are using requirejs to load modules. Therefore we can share some the configuration with a file: require-config.js

requirejs.config({
    baseUrl: 'js',
    nodeRequire: require,
    paths: {
        ready: '../node_modules/domready/ready.min',
        selfish: '../node_modules/selfish/selfish',
    },
});

In this project I load this file only once, in the main.js. However when having more complex configuration you should load it every time you need it.

We first start by using requirejs and selfish to create some classes that will be used in the application:

define(["selfish"], function(selfish) {
    var Base = selfish.Base;
    var Card = Base.extend({
        initialize: function(cost) {
            this.cost = cost || 0;
            this.img = "";
            this.text = "Empty text";
            this.type = [];
        },
    });

    return Card;
});

We can ignore src/app.js and main.js as they are used for the requirejs entry point and have nothing to deal with testing.

Here comes the important part which is accessing modules from the test and being able to use them. First let’s take a look at the test file:

var requirejs = require("requirejs");
var assert = require("assert");
var should = require("should");
requirejs.config({
    baseUrl: 'js',
    nodeRequire: require
});

describe('Card Testing', function() {
    // Load modules with requirejs before tests
    var Card, Victory;
    before(function(done) {
        requirejs(['card'], function(card) {
            Card = card;
            done(); // We can launch the tests!
        });
    });

    describe('#instanciation', function(){
        it('should work without problems', function(){
            Card.should.have.property('new');
            var c1 = Card.new(1);
            var c2 = Card.new();
            c1.should.have.property('img', "");
            c1.should.have.property('cost', 1);
            c2.should.have.property('img', "");
            c2.should.have.property('cost', 0);
        });
    });
});

First we require the different modules needed by node

var requirejs = require("requirejs");
var assert = require("assert");
var should = require("should");
    requirejs.config({
    baseUrl: '.',
    nodeRequire: require
});

We are going to use requirejs to load modules. This is actually different from the nodejs method require(). Then we add the configuration. The baseUrl specifies from which point modules must be found. This path is relative to the runtime, thus when running grunt at project root (cf tree) we must specify files as card or subdir/file.

When loading modules within tests there’s one important thing: creating a test before calling requirejs(). This is because Mocha need to know tests exists. After that we can load any modules needed by the tests:

describe('Card Testing', function() {
    // Load modules with requirejs before tests
    var Card, Victory;
    before(function(done) {
        requirejs(['src/card'], function(card) {
            Card = card;
            done(); // We can launch the tests!
        });
    });

We declare a variable Card to store the Card class and use it later in the tests. By using the before(done) function we ensure that classes will be available before any test. Calling done() callback is necessary because we’re dealing with asynchronous module loading, thus we have to notify Mocha that modules are available. If we don’t call done(), tests will fail because they will be called before requirejs() call ends.

Note: The describre(), before(done) and it() methods are BDD assertions style (as shouldjs). The TDD equivalents are suite(), setup(done) and test()

Once the setup is done we can do the tests as usual:

describe('#instanciation', function(){
    it('should work without problems', function(){
        Card.should.have.property('new');
        var c1 = Card.new(1);
        var c2 = Card.new();
        c1.should.have.property('img', "");
        c1.should.have.property('cost', 1);
        c2.should.have.property('img', "");
        c2.should.have.property('cost', 0);
    });
});

Remember to use the done() callback when dealing with asynchronous code!

Boilerplate

You can find the boilerplate here:

https://github.com/posva/mocha-requirejs-boilerplate

The Gruntfile contains more targets that help development, such as:

serve: simple HTTP server
deploy: Compress and unify every js file using requirejs
jshint: run jshint on project files.
default: will run test, jshint and deploy

There’s also a Victory class to show that everything works just fine with more that one module loading.

Spacecraft

2014-09-09T00:00:00+00:00

I’m very late as this project ended in June but better late than never! Anyways, this project was done during the 2nd year speciality project. We were three: Arthur Sonzogni, Smea and myself. The original idea was first introduced by Smea.

Minecraft in Space.

From this point I won’t talk about Minecraft, so you better google it if you don’t know what it is.

Motivation

Minecraft is cool. Exploring infinite worlds, destroying, creating things, crafting, etc. But you are not on a planet, you cannot go around the world, you’ll never reach your original location. Imagine if you just could fly away from the planet and visit other planets or other solar systems!. That would be so cool!

However the duration was bout three weeks, so we didn’t have enough time to implement everything. Therefore we focused on Level of Detail, procedural generation and saving world modifications. Using some nifty shaders we accomplished nice looking effects. Mainly by using an atmospheric scattering shader and noise generated sun surfaces.

Screenshots

Results

We were very happy of the results. Personally I learned a lot from this project even if I focused more on technical stuff than the engine related things, which is the more interesting and difficult part.

The code of the project is available on Github. There are detailed instructions about how to build it for Linux, OS X and Windows. Controls are really hard, reading them before even trying to move around is a must.

Making your server public

2014-07-25T00:00:00+00:00

The server

When you run a local server with PHP, python, Java or node, you can access it from any other computer in the same network by just typing the address of the computer inside the local network followed by :port. Usually localhost:8080, localhost:3000 or localhost:8000 when working on the same computer that is serving.

The application

Once your web application is ready to be used you need to deploy it. With PHP and Java you can use many free servers that are available online and that will surely fit all of your needs, but when developing a node application the choices are quite limited yet. On top of that if your application won’t borrow too much bandwidth or you just need it to run for some time and then turn it off, you can deploy it yourself either in your personal computer or in raspberry pi or beagle bone.

In order to deploy yourself in your own computer you will obviously need to install the server application and launch the server. The problem is that your computer is mostly invisible to the global network (no global ip) or that the IP may change. Here I am going to explain an easy solution I found to make your little application available globally. You can also use a service like no-ip or DynDNS

Deploying it

You need two things:

static ip
redirection
- port redirection
- requests redirection

The first thing is done by changing the DHCP setting where you can assign a static IP to a mac address. This way everytime the computer is connected to the router the router gives this computer the same IP. This is needed by the redirection.

Then you need to activate the demilitarized zone (DMZ) and use the static IP you gave to your computer. Finnally web request are sent to the port 80 but your server is serving on another port. You have to redirect the request to the correct port. This is achieved by using the NAT/PAT rule system and adding one rule to redirect the TCP request at port 80 to the port you are serving:

+-----------------+----------+-------------+-----------------+-----------------+
|Name of the rule | Protocol | Source Port | Device IP       | Destination Port|
+-----------------+----------+-------------+-----------------+-----------------+
|Webserver        | TCP      | 80          | rpi 192.168.1.5 | 3000            |
+-----------------+----------+-------------+-----------------+-----------------+

Now you can retrieve the global address of your computer, which is actually the router’s one by going to any website like http://www.whatismyip.com/ and then give it to anyone who needs to access the app.

Address

But this is… annoying, right? Well if you buy a domain you just need to add an A record pointing to this address. You can do it with a subdomain as well.

Now you have some nice (app.domain.com)[app.domain.com] address to yourself hosted server :D

Random theme Vim

2014-05-12T00:00:00+00:00

Motivation

Do you really need one? IMO I get tired of using the same theme every time. The solution is simple, just take the themes you love, put theme on an array and choose randomly one at startup.

Code

The code is pretty simple. You create an array and then choose one randomly using the localtime.

  let themes = ['monokai', 'mustang', 'vitamins', '256-grayvim', '256-jungle', 'peaksea', 'xoria256', 'ir_black']

  execute 'colorscheme '.themes[localtime() % len(themes)]
  unlet themes

Have fun!

configure.py

2014-03-03T00:00:00+00:00

configure.py

I already did a bash version that is posted here. Although I was not very happy of the performance. The script was slow, very slow. 14 seconds were needed to generate a makefile for my project Kill da Duck. With this python version only 0.5 seconds are needed.

How does it work

The behaviour is quite the same, I just added memoization to make it faster

Parse options
Find directory tree inside the src-dir
Fin files inside src-dir
Generate standalone rules
For each file find its dependencies and create a rule

Python actually made the coding very easy, I don’t know it very well yet but still, it really makes a difference. Even more if we compare it to bash.

The use of dictionaries, lists and sets that are built-in types made the dev easy and fast.

Performance

At the beginning I was very impressed by the performance as I was used to my old, slow version in bash. I didn’t tested too much because I don’t really need it as I must be the only one using this script but if someone report an issue I’ll fix it asap.

Source Code

Get the source code here

Moving cursor in console

2013-12-22T00:00:00+00:00

Cursor

While printing text for your tests or any other thing you sometimes want to make better output to make your tests look more elegant or whatever reason.

Using colors makes them quite cool but if you want to take it to the next level you can move cursor and rewrite over your text to make it look as an update.

How to do it

This is more like a note to myself because I’ll be using it shortly for my sh2d project that you can find here and for which I’ll write a post later.

Meaning of symbols:

<L> Line
<C> Column
<N> a number

Here they are:

Position the cursor: \033[<L>;<C>H or \033[<L>;<C>f. If you don’t change the cursor position again the shell prompt may erase other things you wrote earlier
Clear the screen and move to current position: \033[2J. This one is odd, test by yourself, you’ll understand…
Move the cursor up: \033[<N>A. It never erase before the first visible line
Move the cursor down: \033[<N>B. It never scroll down more than the number of visible lines
Move the cursor forward: \033[<N>C. It never goes over to the next line
Move the cursor backward: \033[<N>D. It never goes back to the previous line
Save the cursor position: \033[s
Restore the cursor position: \033[u

This is not an exhaustive list but it covers the main codes and it’s enough to work with.

Reference

To find more characters sequence you can check them here: ANSI escape code. Again it’s not a complete list ^^