Mount HDD Linux and automount with fstab

1 – Check the drive is visible to the os

Which should spit out something like this:

NB:

instead of using fdisk you could also use

if you cannot see your drive, or you don’t have a parition yet see here

2 – Create a mount point

A mount point is basically an empty folder, typically this is in either /media or /mnt on linux systems. So choose one and create a sub-directory:

3 – Auto-mount the drive with fstab

To mount the drive reliably you should mount via the UUID, this is specific to the partition.

This will output a list of UUID’s to screen, based on the output from fdisk above you should be able to recognise which line belongs to which drive.

Now add a new new entry to /etc/fstab:

4 – Mount all from fstab

That’s it. You should now be able to see the contents of your drive in you mount point. A system reboot will auto-mount the drive again.

To unmount temporarily just unmount the mount point:

 

FIX: “Warning: No support for locale: en_GB.UTF-8”

Linux Mint 17 and seeing this warning ..

update-initramfs: Generating /boot/initrd.img-3.0.0-12-generic
Warning: No support for locale: en_GB.UTF-8

issue:
The problem is that /usr/share/initramfs-tools/hooks/root_locale is expecting to see individual locale directories in /usr/lib/locale, but locale-gen is configured to generate an archive file by default.

Fixed it by running:

Which should output something like:

Now run:

Stop services starting up on boot Ubuntu eg: MySQL or Apache

So running Linux Mint is great! I effectively develop on an OS extremely close to the production environment, I can run apache vhosts or nginx proxies, MySQL and MongoDB and it’s all just like production.

If you have ever tried developing on windows you are aware of the pains, slow php, ridiculous permission systems, tonnes of “updates” aka spyware. I have collegues who snigger then proudly point to their fashion accessory with a glowing apple on the cover… this is no better IMO. Yes apple have reasonable hardware and they are sturdy.. but the OS is defintely not for the serious programmer, multiple windows with no task bar for a start. Brew? And don’t get me starting on the hell hole that is xcode or the app store! And have you tried working on one of the those macs where they hide half the keys, what’s with that?

Anyway, enough windows and apple bashing as I could fill up an entire post on this topic. Back to the original topic.

OK, so the example is to disbale mysql on startup:

You should now be able to see a new file:

That’s pretty much it. The command basically writes a file with manual in it. Reboot your computer and you should find mysql is not started. This is great, you can now have many services ready and waiting, start them up as and when you want them eg:

Shhimples.

List node app scripts cli without opening the package.json

This was annoying me so much I was about to reach for my IDE and write my own global package to just list the scripts.. good job i reached for google first!

So many times you pick up a new project, or one lands on your lap and the usual thing happens.. no std script names. The usual trick:

You could pipe this to grep to pull out all you wanted but lifes too short for that.

Enter the likes of: https://www.npmjs.com/package/npm-ls-scripts. It is quite old code and code be optimized but it does a job and now just type:

Ahhh… itch has now been itched 🙂

https://www.npmjs.com/package/npm-ls-scripts

Testing via Mocha and Chai in ES5 and ES6

Testing via Mocha and Chai in ES5 and ES6

Testing is a crucial part for developing, for JavaScript as well. Since the foundation theories of testing is almost the same regardless of the languages you are using. I will focus on introduction to Mocha and Chai, and environment setting up in this article. And for both ES5 and ES6. And the library we are using is Mocha and Chai. Mocha is a BDD testing framework and Chai is an assertion library. And at the end, I will talk about why I don’t use Jasmine for testing.

 

1. About the versions:

  • “node.js”: “4.6.2”,
  • “babel-preset-latest”: “6.16.0”,
  • “babel-register”: “6.18.0”,
  • “chai”: “3.5.0”,
  • “mocha”: “3.2.0”

2. One minute for Mocha

There are so many little piece in Mocha, but you should know the following 3 for your first test. And conquer the rest at the homepage of Mocha, not that long.

2.1 Make your context via describe()

Your testing suites may consist of many parts. And you could distinguish them in a clear manner via describe(), you needs 2 parameters for it, the first one is the description and the second one is a function which will contain your tests afterwards.

1
2
3
4
5
6
7

describe(“Start to test function A”, function(){
// Your tests for fnA starts here
})
describe(“Start to test function B”, function(){
// Your tests for fnB starts here
})

If you have more cases to address, you can use another function called context() to do the trick:

1
2
3
4
5
6
7
8

describe(“Start to test function A”, function(){
context(“Test case 1”, function(){
// Your tests for case 1
})
context(“Test case 2”, function(){
// Your tests for case 2
})
})

2.2 Write your tests in it()

Your real code for tests locates in it(), it has a same function signature as describe().

1
2
3
4
5

describe(“Start to test function A”, function(){
it(“should return 2 when we pass 1 and 1”, function(){
expect(addTwo(1, 1)).to.be.equal(2)
})
})

Furthermore, if you are writing an asynchronous testing. Which means your testing code may ends later, but the whole block won’t wait your tests to finish. You can pass a done to the callback function of it() to fix it.

1
2
3
4
5
6

describe(“Start to test function A”, function(){
it(“should return 2 when we pass 1 and 1”, function(done){
expect(addTwo(1, 1)).to.be.equal(2)
done()
})
})

2.3 You can hook your tests to do some preparation

With its default “BDD”-style interface, Mocha provides the hooks before(), after(), beforeEach(), and afterEach(). These should be used to set up preconditions and clean up after your tests.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// Codes below are from Mochajs.org
describe(‘hooks’, function() {
before(function() {
// runs before all tests in this block
})
after(function() {
// runs after all tests in this block
})
beforeEach(function() {
// runs before each test in this block
})
afterEach(function() {
// runs after each test in this block
})
// test cases
it(“should return something”, function(){
// test codes here
})
})

3. One minute to Chai

Chai focus on assertion, it provides with 3 types of assertions. Codes below are from http://Chaijs.com/guide/styles

3.1 Assert

This one has a similar feeling as the build-in assert in node.js.

1
2
3
4
5
6
7
8
9

var assert = require(‘chai’).assert
, foo = ‘bar’
, beverages = { tea: [ ‘chai’, ‘matcha’, ‘oolong’ ] };
assert.typeOf(foo, ‘string’); // without optional message
assert.typeOf(foo, ‘string’, ‘foo is a string’); // with optional message
assert.equal(foo, ‘bar’, ‘foo equal `bar`’);
assert.lengthOf(foo, 3, ‘foo`s value has a length of 3’);
assert.lengthOf(beverages.tea, 3, ‘beverages has 3 types of tea’);

3.2 Expect

The BDD style assertion of expect() enable you to represent your tests in a more human-reading-friendly way.

1
2
3
4
5
6
7
8

var expect = require(‘chai’).expect
, foo = ‘bar’
, beverages = { tea: [ ‘chai’, ‘matcha’, ‘oolong’ ] };
expect(foo).not.to.be.a(‘number’);
expect(foo).to.equal(‘bar’);
expect(foo).to.have.length(3);
expect(beverages).to.have.property(‘tea’).with.length(3);

3.3 Should

Provides another approach to address your tests description. May have some issues when used with Internet Explorer, so be aware of browser compatibility.

1
2
3
4
5
6
7
8

var should = require(‘chai’).should() //actually call the function
, foo = ‘bar’
, beverages = { tea: [ ‘chai’, ‘matcha’, ‘oolong’ ] };
foo.should.not.be.a(‘number’);
foo.should.equal(‘bar’);
foo.should.have.length(3);
beverages.should.have.property(‘tea’).with.length(3);

3.4 Languages chains

You can chain your description via the following methods. Here is a little disadvantage of using Chai. Non-native speaker may have a trouble on combine these words to a sentence, but seems not a big deal, they are very basic English.

  • to
  • be
  • been
  • is
  • that
  • which
  • and
  • has
  • have
  • with
  • at
  • of
  • same

4. Set up for ES5 Testing

Very easy to set up.

4.1 First, you install them

1
2
3
4
5
6
7

# use NPM
npm init –yes
npm install mocha chai –save-dev
# or use fancy Yarn
yarn init –yes
yarn add mocha chai –dev

4.2 Second, import them in your tests and write a simple test

Create a file named test.js locates in test/ in your project folder.

1
2
3
4
5
6
7
8
9
10
11
12

var expect = require(“chai”).expect
var should = require(“chai”).should()
var addTwo = require(“../index”).addTwo
describe(“Test the behavior of addTwo()”, function () {
it(‘should return 2 when given 1 and 1 via expect()’, function () {
expect(addTwo(1, 1)).to.be.equal(2)
})
it(‘should not return 3 when given 1 and 1 via should()’, function () {
addTwo(1, 1).should.not.be.equal(3)
})
})

4.3 Third, write your function which needs to test.

The above tests will fail since there is no such addTwo(). It doesn’t matter, we will add one now.
Create a file named index.js locates in the root of your project folder with the following codes:

1
2
3

export addTwo = function (num1, num2) {
return num1 + num2;
}

4.4 Fourth, add the following section to your package.json.

If you already have a scripts section, you can replace it with the following one.

1
2
3

“scripts”: {
“test”: “./node_modules/mocha/bin/mocha test/*.js || exit 0”
},

4.5 Run your tests via command line

1
2
3
4

npm run test
# Or, just:
npm test

You can do the second trick since the test is a reserved keyword of NPM.

5. See the fancy result

1
2
3
4
5
6
7
8

> testMocha@1.0.0 test /Users/albertgao/codes/node/testMocha
> ./node_modules/mocha/bin/mocha test/*.js || exit 0
Test the behavior of addTwo()
✓ should return 2 when given 1 and 1 via expect()
✓ should not return 3 when given 1 and 1 via should()
2 passing (8ms)

6. Set up for ES6 Testing

Testing for ES6 takes few more steps since you need to transpile your ES6 code to ES5.

6.1 First, you install them

1
2
3
4
5
6
7

# use NPM
npm init –yes
npm install mocha chai –save-dev
# or use fancy Yarn
yarn init –yes
yarn add mocha chai –dev

6.2 Second, import them in your tests and write a simple test

Create a file named test.js locates in test/ in your project folder.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

import chai from “chai”
import {addTwo} from “../index”
let expect = chai.expect
let should = chai.should()
describe(“Test the behavior of addTwo()”, function () {
it(‘should return 2 when given 1 and 1 via expect()’, function () {
expect(addTwo(1, 1)).to.be.equal(2)
})
it(‘should not return 3 when given 1 and 1 via should()’, function () {
addTwo(1, 1).should.not.be.equal(3)
})
})

Something interesting happens here, I imported chai, then apply its two functions to local variables. Why not just import {expect,should} from "chai", saddly, you can do it for expect but not should,

According to the official docs now:

It isn’t possible to chain a function call from an ES2015 import statement – it has to go on its own line.

But I saw a request on Github, which will enable import "chai/should" in the future, hopefully in the 4.0 version. It mentioned in official docs. But I tried with no luck.

Second, I didn’t use arrow functions here since the nature of the arrow function, you will lose the context binding, let’s say you want to use the built-in this.timeout(200) to structure your tests. Then you shouldn’t use the arrow function even you are written in ES6. But if not, feel free to use it.

6.3 Third, write your function which needs to test.

The above tests will fail since there is no such addTwo(). It doesn’t matter, we will add one now.
Create a file named index.js locates in the root of your project folder with the following codes:

1
2
3
4
5

let addTwo = (num1, num2) => {
return num1 + num2;
}
export {addTwo}

6.4 Fourth, add the Babel support

1
2
3
4
5

# use npm
npm install babel-preset-latest babel-register –save-dev
# or use fancy Yarn, -D === –dev
yarn add babel-preset-latest babel-register -D

6.5 Fifth, create a .babelrc file at the root of your project folder

With the following contents:

1
2
3

{
“presets”: [“latest”]
}

6.6 Sixth, add the following section to your package.json.

If you already have a scripts section, you can replace it with the following one.

1
2
3

“scripts”: {
“test”: “./node_modules/mocha/bin/mocha test/*.js –require babel-register –reporter spec || exit 0”
},

The idea here is easy, Mocha just uses babel-register to transpile the file on the fly. Via this approach, you can write you tests and codes both in ES6, and tests them without pre-transpiling the code.

6.7 Run your tests via command line

1
2
3
4

npm run test
# Or, just:
npm test

You can do the second trick since the test is a reserved keyword of NPM.

7. See the fancy result

1
2
3
4
5
6
7
8

> testMocha@1.0.0 test /Users/albertgao/codes/node/testMocha
> ./node_modules/mocha/bin/mocha test/*.js –require babel-register –reporter spec || exit 0
Test the behavior of addTwo()
✓ should return 2 when given 1 and 1 via expect()
✓ should not return 3 when given 1 and 1 via should()
2 passing (8ms)

8. Why not Jasmine?

A little off-topic talking before ending. Why not Jasmine? It is good, it is full featured. Has built-in assert, mock(spy), ajax call, etc. And it’s easy to configure too. Sometimes just as same as Mocha, but with Mocha, you can choose your own favourite assertion library, like Chai or better-assert. And choose mock library like Sinon.js, and even for the reporter part, you can use different reporter for a different outlook, even for exporting a HTML report.

So the main differences between Mocha and Jasmine is that you don’t this so called javascript fatigue anymore with Jasmine. But this is just why we love JavaScript, right? (Not wierd, think about it. 🙂

Express validation + Joi for node applications

If you are coming from Laravel to Node you will likely be hunting for a few packages that enable you validate incoming requests and ensure standardised out for your API.

First up, validating your incoming requests with “express-validation” and “joi”.

Together these things can be used with your expressJs app to validate incoming requests and clearly describe to new developers on your project what the expected input to a rout should be:

Here is a full article on the topic, es5 and es6

Second standardizing your api output

If like me you prefer to stick to industry standards unless required, then you are probably in favor  on JSON API

There are lots and lots on implementations of the JSON API standard, but one in particular for me stands out for NodeJS: https://www.npmjs.com/package/jsonapi-serializer

This is a popular node package and most importantly to me, it is decoupled from any ORM/ODM. In other words you can get familiar one implementation and use it for almost any NodeJS app.

 

webpack, es6, babel, sass and custom webfont

Webpack has been gaining a heck of a lot of popularity over the past year. Webpack is a different breed to the messy likes of “gulp” or “grunt”, it prevents developers from creating long and whacky build files. One other option that also prevents whacky build files is quilk. 

Webpack can be hard to get your head into.. its like taking the std build tools but looking at them from reverse. Getting the basics up and running is fairly novice, but getting SASS with Webfonts can be a little more tricky.

In this git-repo I have put together a demo, es6+sass+custom webfonts.

https://github.com/jdcrecur/demo-webpack

Enjoy 😉

 

Running PLEX Media server as another user and serving files from another location

A. Create /etc/systemd/system/plexmediaserver.service.d. In it, create override.conf containing the following

INFO: It appears some systems want Umask while others want UMask. Please be cautious of this until fully resolved and noted here.

B. Now copy the existing library. (Resolve errors before deleting the original copy of your library)

C. Inform SystemD of the changes and test the related & reconfigured PMS

D. Test your system. Verify everything is exactly as it was. If not, resolve before proceeding

http://127.0.0.1:32400/web

E. Delete the old library in /var

Once you have created the override file, you can later edit it with systemctl edit plexmediaserver

 

thanks to this forum post: https://forums.plex.tv/discussion/277724/moving-pms-library

Expose all variables in a Twig template in Symfony

Ever worked on a big framework and been new to it.. then you have to somehow figure out a twig tpl without know what variables have been passed?

 

Simple solution, dump all the var keys in the twig tpl: