• How To Run Node Apps In Docker

    •

    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.

    read more

  • My Gulp Files: Ionic App Projects

    •

    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

    read more

  • My Gulp Files: Library Projects

    •

    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

    read more

  • My Gulp Files: Rest Api Projects

    •

    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

    read more

  • My Gulp Files

    •

    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.

    read more

  • Continuous Integration For Node Projects

    •

    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.)

    read more