Copy using the command line without overwriting existing files

I learnt about cp‘s -n (or “no clobber”) option that lets you copy, but not overwrite files that already exist:

cp -Rvn folderA folderB

The above would Recursively copy the contents of folderA into folderB, and print a message per file it copies (with the v option). Great to know when things get stuck or interrupted 🙂

It’s quite useful when trying to copy from something like a folder in a remote drive that keeps disconnecting. So if the network times out you can always run the command again after reconnecting, and it will skip files that are already there.

Note that if a file has been partially copied, then cp will skip it the next time and not complete the download. So don’t use this method for stuff that requires some degree of integrity–you’d better reach for tools such as scp.

Publishing to gh-pages from Travis CI

I figured out how to ‘publish to gh-pages’ (i.e. building and publishing a website into GitHub pages) using Travis CI. Instead of messing with the serious repository, I made a simple repository which builds and publishes its web page daily, using Travis CI’s cron feature. You can clone/fork it and read the instructions on the README or you can read on here for why I did it this way.

Continue reading “Publishing to gh-pages from Travis CI”

The furthest I’ve ever been

(Inspired by Diamond Geezer’s series: N W E S)

  • North: Höfn, Iceland (64°15′13″ N 15°12′43″ W)
  • South: Melbourne, Australia (37°48′49″S 144°57′47″E) – followed very closely by Montevideo, Uruguay (34°53′1″S 56°10′55″W)
  • West: Kitsilano Beach in Vancouver, Canada (49°16′26″N 123°9′18.4″W)
  • East: Sydney Airport (33°56′46″S 151°10′38″E)

This is a fun game to play and I’m thinking of extending it to “local” versions such as: the furthest I’ve been in… Europe, Spain, the UK, London, and maybe my past and present boroughs? Or another variation: the further you’ve been to each of the tube lines.

I guess if this was 2005 I would tag five more bloggers to continue the game meme in their blog, but it isn’t, so if you like the idea, feel free to take part on it! It’s never too late to start a blog!

Giving things up to find out if you really liked them, or: a year without drinking coke

We went on holidays a year ago. The plan was to go to a far away place, disconnect and rest.

A voluntary part of the scheme was giving up alcohol and caffeine during the stay, and optionally two weeks before the holidays, to let the body go through any withdrawal symptom it wanted to go through beforehand.

I don’t normally drink a lot of alcohol, so that seemed easy. But not drinking coffee!?

I embraced the challenge anyway.

I only had a minor headache for a couple of days, and I wasn’t even sure if it was due to the stormy weather. I just had to be conscious of what I was doing, instead of automatically reaching for the coffee grinder in the mornings, or heading to a cafe on the afternoon.

When we arrived to the holiday place, I didn’t really miss coffee. I was too busy observing nature, reading, drawing… and sleeping… a lot of sleeping… I don’t think I had slept as much in years!

Back in London, I still kept for a couple weeks of no coffee.

Eventually, I drank a good coffee.

It was sublime. I enjoyed every bit of it: the inviting scent of the cafe as soon as you stepped through its door, the beans on display, the golden lights tinting it all;  the steam coming out of the cup and bringing out the aromas,  the thick layer of creamy foam, the first taste when it’s all a mix of sour and fruity depths, and the final moment when it’s over, and you’re really satisfied that you had it.

If coffee and coffee culture such as preparation, beautiful cafes, neatly arranged cups, etc make me happy, there’s no point in giving them up, unless I want to pass as a First World Martyr.

When on holidays, I had no need to go to a cafe to have some personal time. I was having that all the time! But back in the city, going to a cafe or preparing my own coffee is an intentional permission from myself to treat myself nicely and give myself a break.

In contrast, I did not drink Coke during this whole year.

I used to occasionally grab one from the office fridge at lunch time, or maybe if it was really hot outside, or instead of an alcoholic drink when everyone else is having it and having “just water” is a sort of shame.

Reflecting about it, consciously, I do not like its flavour: the acid aftertaste, the gas, the eventual tummy upsetting… And if I had any doubt, I just need to read the label in the can to think: I am NOT getting THAT into my body!

There was another interesting realisation: I drink a lot more water than before. Somehow, it felt as if drinking coke removed your sense of thirst. Was my body thirsty all this time?

I found the idea of stepping away from things you think you like in order to decide if that’s actually the case very interesting.

Maybe you like the thing. Or maybe you just like aspects of the thing, or at some times and in some places only. Or maybe you don’t like it at all, and would rather do something else instead.

It’s healthy to question ourselves and ask why do we do what we do, but sometimes we examine behaviours that are so commonly encouraged, that even questioning them seems silly.

Temporary withdrawal is a resource to help us take a step back and decide. Use it! 😀

Don’t force users to install node modules globally when you can avoid that

How often have you seen instructions for installing a project that are something like this?

git clone https://wherever/the/project/is
cd cloned_folder
npm install -g gulp # <-- 😱

(or, instead of gulp, any other utility that the project requires for development)

This is not a good idea. You’re installing the same version of a utility globally, and perhaps the project has not been tested with that version. Things might break or even worse, work not-so-well in a strange, undebuggable way!

Don’t do it.

A better way is to use npm scripts, which belong to the project, and specify development dependencies in package.json, so when you run npm install, it also installs devDependencies locally to the projects’ node_modules folder. This keeps everything under control and does not pollute other people’s computers global space.

So, for example, if a project was asking users to run npm install -g gulp, they should do this instead:

  1. Install gulp locally as a development dependency, saving it to package.json:
    npm install --save-dev gulp
  2. Add a new entry to the scripts array in package.json:
    "build": "gulp"
  3. Ask users to run
    npm install

    the first time. And

    npm run build

    each time they need to build the project

The reason this works is because when npm runs a script, it modifies the current PATH variable to add node_modules/.bin, which contains any binaries that you installed as part of your modules. So your computer will search for binaries starting in the .bin folder, before searching in any other default location for binaries in your computer (e.g. /usr/bin)

You can find more documentation about this behaviour in the run-script page of the npm manual. I really encourage you to read it as it has lots of good stuff and Things You Wished Had Known Before 🙂

And in case it makes things clearer, this is how a hypothetical package.json would look before:

{
  devDependencies: {}
}

And after:

{
  devDependencies: {
    "gulp": "12.34.56"
  },
  scripts: {
    "build": "gulp"
  }
}

With this, the devDependency is clearly stated on the package.json file, the project developer will be developing with that version, and will not get surprises! (and the users of the module won’t either).

Another advantage of this approach is that you are not tying the project to a specific utility.

If you decide to use grunt instead of gulp later on, you just need to do whatever changes you need (Gruntfile instead of Gulpfile, edit package.json etc), and yet users of the project will still start the build process with npm run build.

It’s invisible to them (except perhaps running npm install again)!

You’re hiding internals that they do not necessarily need to know about, so it’s a good abstraction. Seriously—you won’t even need to update your getting started guide! Good stuff.

Hope that helps!

If you want to learn even more cool npm scripts tricks, I recommend Kate’s talk and accompanying post. Actually, I just realised she explained the same thing I did, so here’s her take, haha!