Aug 13, 2015 •

I like to use docker to run my server side apps and my node apps aren’t
exception. Decided to show the docker file I use for my node apps and explain
what I’m doing there. I copy the entire source, having the files I want to
exclude in docker ignore file. The most important thing to note is I don’t copy
node_modules directories, I do fresh install in docker. Main reason is that
docker container is kinda different operating system and potentially a different
distro (Debian in this instance, because I love it!) than dev or CI box.
So why not build the code where it’s gonna run and if there are issues I’ll
know about it sooner. Also note that I run npm install with production
switch so it doesn’t install dev dependencies, which I don’t really need to run
my app.

Aug 13, 2015 •

For Ionic projects also I use CoffeeScript, Sass, Jade although ionic generates
the project in JavaScript and Html. Here we have front-end components,
compilation, browser testing, live reload, and all that goodness. Here we do
need to compile CoffeScript to JavaScript, Sass to Css and Jade to Html.
Another thing that needs to be solved since browser will run JavaScript, Css
and html instead of CoffeScript, Jade, Sass so debugging will be really
challenging. To solved that problem I generate source map files. I also use
CoffeScript for my gulpfile since it makes it much more clean and compact.
Some people who do that like to also create gulpfile.js file with

Aug 13, 2015 •

For this type of projects I use CoffeScript, Chai and Mocka for unit testing,
Istanbul for code coverage, Sinon and Proxyquire for mocking, Jenkins for
continuous integration. This type of projects are easy to build because those
don’t have front-end components, compilation/optimization, browser testing,
live reload etc. Here we do need to compile CoffeScript to JavaScript since
we’re gonna publish the package with JavaScript code and not CoffeScript. What I
do is keep my coffee code in src directory instead of lib. At compile time I
generate JavaScript code into lib directory, add src directory to .npmignore and
lib directory to .gitignore. That way my CoffeeScript ends up in git repo but
not generated JavaScript and my JavaScript ends up in published package and not
JavaScript, pretty smart right :). I also use CoffeScript for my
gulpfile since it makes it much more clean and compact. Some people who do
that like to also create gulpfile.js file with

Aug 13, 2015 •

For this type of projects I use CoffeScript, Chai and Mocka for unit testing,
Istanbul for code coverage, Sinon and Proxyquire for mocking, Jenkins for
continuous integration. This type of projects are easy to build because those
don’t have front-end components, compilation/optimization, browser testing,
live reload etc. And for server side code we don’t need to compile CoffeeScript to
JavaScript since it’s running on server and we can use coffee executable to
run the code instead of node executable. I also use CoffeScript for my
gulpfile since it makes it much more clean and compact. Some people who do
that like to also create gulpfile.js file with

Aug 13, 2015 •

Recently I decided to upgrade to Gulp 4 even though it’s not released yet.
And since there are some breaking changes I had to go over my gulp files.
I usually do three type of projects in node/js, rest apis, library projects
(npm packages), ionic and angular apps. I decided to write blog posts and share
my gulp files in case other will find it useful. I do like to use the most loved
and hated language in node world, CoffeeScript. I sure give it some love here,
not because I find JavaScript hard or don’t know how to properly scope my
variables or make objects, but because I find code written in CoffeScript much
more readable and maintainable (yep, all that brackets and parentheses.)
Other libraries I religiously use are Chai and Mocka for unit testing, Istanbul
for code coverage, Sinon and Proxyquire for mocking, Jade for templates,
Sass for stylesheets and of course Jenkins for continuous integration. So this
combination on it’s own makes my gulp files pretty unique. Listing links to
individual posts where I have my gulp file and I’m explaining which task is
doing what.

Aug 14, 2015 •

A while ago I wrote a post about continuous integration with Jenkins for scala
projects and I thought I would do one for node developers also. Make sure to
check out my other posts about how to write your gulp files since we’ll heavily
really on those gulp tasks. I will put the links at the end of this post.
So what is continuous integration, at the very high level it’s about hey is
the code in a good state, no matter by how many people code is being updated,
how often code is being changed or of how many building blocks project consists of.
When you start working on a feature you’re gonna branch of mainline and start
introducing changes. At some point when you find things are broken now you have
to spend time to see if it’s because of your changes or project was already in
a bad state. And when you find out that it was already in a bad state you
would want to start tracing. A who introduced the breaking changes and B when.
So to avoid the head each and frustration what you really want to know is
if project is in a good state before you even start working on it.
One option would be to compile the code before you start changing it.
But if code compiles is it enough? Oh you you also wanna know if unit tests are
passing. But is this enough? Check for compiler warnings? Style violations?
Code coverage? What if you run code coverage and it shows that it’s 85%,
does it mean everything is good, what if code coverage was 95% last week and
code without proper code coverage got committed and code coverage dropped
(do you remember what code coverage was last week, can you even find
out without going back in commits and running coverage reports on those commits.) are you sure
you want to introduce your changes on top of those changes?
Let’s make it even more complex, what if the project consists of many other
projects and the project you’re working on brings all those dependencies
tougher. Maybe you should checkout all those dependency projects
and see if those are in a good state also.
Let’s make it even more complex, what if the project isn’t just set of
projects that get bundled into one big project.
What if the whole code base consists of many micro services that talk to each other
via some form of PRC. OK maybe you can manage to do all this to know if code is
in a good state before you introduce your changes what about the point B I
brought earlier about when code broke, because longer it was in that states
longer it’s gonna take to trace the breaking change and longer to fix.
Can you go and check every single project every time someone makes a commit
to make sure that commit is good? Well actually you can, you just need a
build server. So all those points I was bringing was about whatever your
integration is it should be continuous and it’s continuous if it runs after
somebody changes something (or maybe before is a better option?☺ I’ll get
to this later.)