/page/2

Using node.js for a build script

Lately we‘ve been amazed by how node allows you to use plain JavaScript for all your scripting needs. My coworkers still rely on Python or Ruby for those stuff, but since I’m a frontend guy, this comes in really handy for me. (Don’t get me wrong, Python and Ruby are really great languages, but I’m just too lazy to learn, when I can achieve the same thing with the language I’m using day to day).

Amazed and inspired by the many approaches the OpenSource community has towards using node for build script stuff I decided to hack my own build script for a few of my recent projects. Again, I’m being pretty lazy here. I could have just learned my way into one of the existing build scripts out there, but I wanted full flexibility and a syntax I could easily hack for different project structures. So let’s get started.

If you’re coming from the frontend like me, you’ll know that the essential part of frontend building is file concatenation and minification of assets. So that’s where I started. Concatenating files is pretty straightforward in using nodes built in filesystem-module. So my basic script workflow looks like this: Find all the files, concatenate them into a temporary file, minify the contents of the temporary file to the build target and delete that temporary file. (Lot’s of temporary going on there…)

Let’s say you have an array of files you want to concatenate that looks like this:

var paths = ['js/script1.js', 'js/script2.js', 'js/script3.js'];

You can then simply make one file from these three files using map and node’s very own filesystem module:

var _fs = require('fs');

// map the contents of all files to the array "out"
var out = paths.map(function(path) {
    return _fs.readFileSync(path, 'utf8');
});

// join "out" with a linebreak and save that stuff to a temporary file
_fs.writeFileSync('tempFile', out.join('\n'), 'utf8');

It’s that simple! Next step is to minify that stuff. No need to reinvent the wheel here. Before rolling my own script I’ve been pretty happy using Google’s Closure Compiler for Javascript and YUI Compressor for CSS. Nice thing about node: It also has a child_process module, that let’s you run command line stuff from inside your scripts. So simply take the syntax you’re using on the command line and drop it inside your script. (You’ll obviously have to place the .jar files of YUI Compressor and GCC in the same folder as your node script…)

var exec = require('child_process').exec;

// ClosureCompiler
exec('java -jar google_closure_compiler-r1810.jar --js=tempFile --js_output_file=script.min.js', function (err, stdout, stderr) {
    // Put some callback stuff here
});

// YUI Compressor
exec('java -jar -Xss2048k /yuicompressor-2.4.7.jar tempFile -o style.min.css', function(err, stdout, stderr) {
        // Again, callback should go here
});

That’s all there is to using node for build scripts. You’ve just learned how to concatenate and minify assets with node.js. This is all you need to know to get started hacking a build script for your own project.

Rodolphe Stoclin has written a nice node module called “node-minify” to provide some great abstraction over those minification called. You can find it on github: https://github.com/srod/node-minify

At the time of writing this, “node-minify” has no ability to automatically concatenate files. So I’ve forked the module, added that stuff and sent a pull request to Rodolphe. I’ll keep you updated. In the meantime you can check out my implementation at https://github.com/lnolte/node-minify

So in the end file concatenation and minification in node becomes as simple as this:

var compressor = require('node-minify');

// This will concatenate your script files and minify them using Google Closure Compiler (gcc)
new compressor.minify({
    type: 'gcc',
    fileIn: ['public/js/plugins.js', 'public/js/scripts.js'],
    fileOut: 'public/js/script.min.js',
    callback: function(err){
        console.log(err);
    }
});

From now on I’ll be using node a lot more for streamlining my frontend build processes. I’m still trying to figure out a nice way to distribute the whole process, but I feel like I’m getting there.

What are your experiences with build proccesses? Please let me know. Thanks for reading!

PaintinPal App Icon – Icon for a coloring book app for iOS and Android

PaintinPal App Icon – Icon for a coloring book app for iOS and Android

Motion Graphic I created for a german text-writing PaaS called wordguru.de

Implementing DNS resolving with node.js

We recently decided we needed a nice interface for our internal DNS-Resolver. Having wanted to play around with node.js on some work-stuff (I’ve only used to build a tool, that streams Rebecca Black’s Friday song on all connected machines in the office so far – but more on that later) I decided to take it for a spin.

For the backend we set up our own DNS Recusor using PDNS Recursor (which is insanely fast). Once installed it’s pretty basic to access it via command line by calling dig with a custom Recusor address:

dig @127.0.0.1 example.com NS +short

But what about bulks of domains. Sure you could write yourself a nifty-wifty bash-script that takes domains from a text file and resolves the name servers, writing the output to another text file. But we wanted things to be beautiful as well. DNS Lookups should be fun.

So we needed a frontend for this. Since, we’re only using the tool internally (at least so far) I decided to implement websockets (via socket.io). I mean how cool is it to see results while they’re happening? So here is how the app is flowing:

You paste in the domains you want to check into a textarea, the domains then are send to the node-based server in bulks by an asynchronous post request. Node forks a child process running the dig statement for each domain. The child process uses a timeout mechanism to respond to non-existing our misconfigured nameservers. The results of a bulk of domains are then send back to the client via a websocket. Each received message from the socket bumps the number of checked domains in a dashboard view. It feels really awesome to paste in a few domains and see the result count increment in real time. I also experimented with sending a socket message for each checked domain, but due to the insane speed of Power DNS the rate of incoming messages made webkit crash for large bulks of data. So we decided to send bulk messages (10 results per message right now). We’re still trying to find the optimal balance between “real time awesomnesssssss” and “reasonable resource usage”.

What I learned from this project is that node is generally awesome! It’s non-blocking nature (even the child processes are callback-based) allows for an asynchronous user interface that’s never frozen. You can still do stuff, while waiting for the server to respond. Once you’re able to get your mind off the classical blocking model (which took some time for me and caused me to yell at my screen several times) coding in node will pay off with results, that amaze your co-workers.

PHP Ranking Algorithm

For a current project at work we needed some sort of ranking as it’s done by reddit, digg, hackernews etc.

So after stumbling about interesting articles about how reddit’s algorithms work, we decided to simply implement them in PHP (Since our whole project is php – we’ll probably change to Go or C, once we get more traffic and need faster calculations).

Check out our PHP Implementation.

Surprising A/B results

While running some quite not revealing A/B Tests over at my new job I stumbled about this pretty interesting post. What are your thoughts on this?

Media Queries JavaScript Style

Recently I was pulling all kinds of CSS3 media-query wizardry up my sleeves for a client just to realize that the site needed different event-handlers for different screen sizes. If only there was a way to add media-queries to my JavaScript.

Well I could use window.innerWidth but this doesn’t give me stuff like orientation.

Instead I stumbled upon window.matchMedia() which is a pretty neat function. Simply pass in your media-query as an argument and your almost good to go.

The funky thing about this function is, that it doesn’t simply return a bool value but a MediaQueryList object. (Open your console and see for yourself). So instead of simply calling the function we have to retrieve the value of the returned MediaQueryList object’s matches property. So you simply type:

window.matchesMedia('only screen and (max-width: 960px)').matches

and you’re good to go. You’ll now get a neat bool value of whether this media query is applied or fails.

Check out the article over at MDN to learn more.

Obviously BMW puts form over function on their toilets un BMW world in Munich. While looking clean and minimalistic their lavatories a pretty hard to use.

Obviously BMW puts form over function on their toilets un BMW world in Munich. While looking clean and minimalistic their lavatories a pretty hard to use.

Bind JavaScript events to screen size in responsive layouts

Recently I’ve been working on a neat responsive layout for a client. I wanted to implement a featured image that slides larger when hovered on huge screens.

Problem: The stupid image was also sliding on smaller screens when hovered causing the layout to break and look like total crap. I was almost about to cry, when I realized the neat window property of JavaScript. So all I had to do was wrapping my event-listeners in an if-clause checking for the screen size. Problem solved!

if(window.innerWidth > 1399) {
/* Neat code goes here */
}

Just wanted to share this snippet with you! Hope it helps you out. Of course you can (and probably should) take this a step further by including something like Modernizr and check whether media-queries are supported by the client’s browser. Otherwise IE6 on a 30” screen could still cause the image to slide down while not the biggest layout is displayed. I know, sounds weird. But I guess, you know what I’m saying?

Further reading

Finally it’s online! Waited for so long! Such a great video. Really shows the toughness of the race.

(Source: vimeo.com)

Hyphenation arrives on the web

Well this is great news. In the past I often dealt with clients, who wanted me to add manual hyphenation to their website’s copy. This can be a pretty hairy task, since there are differences in font-size-rendering across different browsers. So I explained this to my clients but most of them continued thinking in their print-methodology.

Anyways, with yesterdays release of Firefox 6 and the release of Safari 5.1 earlier this month we now have two major browser releases that support the CSS3 hyphen property for automatic hyphenation. As with all CSS3 properties we need to add vendor-prefixes if we want to start using those features now. It looks like this:

p { -webkit-hyphen: auto; -moz-hyphen: auto; }

For manual hyphenation simply change auto to manuel. Check out FontDeck’s blog entry on this.

This is a pretty exciting new feature! In my opinion this offers great possibilities to adaptive design, maintaining nice-looking hyphenation across multiple layout widths.

Update: I’m trying to get this added to HTML5Boilerplate. Check out the discussion.

Another Update: Hyphenation works with different languages but I requires a lang-attribute to be set. You can do this in your site’s header or add it directly to the element you need be hyphenated. Check out the fiddle we prepared.

What do you think about this?

Git on Dropbox

I really dug into git lately and I’m truly amazed by it’s possibilities. Today I figured it’d be neat to have your git repositories on your Dropbox. For those of you who don’t know Dropbox is an online storage solution offering free accounts with 2GBs of storage. They also offer great apps to keep your data in sync across different devices. So it’s basically a server. You’ll need: git installed on your computer + obviously a Dropbox account.

Fire up terminal and cd into your Dropbox folder.

$ cd /Volumes/Work/Dropbox

Next create a directory for your repositories.

$ mkdir repos

Clone existing repos to your Dropbox.

$ git clone . /Volumes/Work/Dropbox/repos/Project-name.git

And finally add the Dropbox repo to your local code copy.

$ git remote add dropbox /Volumes/Work/Dropbox/repos/Project-name.git

You’re all set. This is how you roll your own sort of git server using Dropbox. Your repos will stay in sync across all of your computers. Or if you have a company Dropbox account, across your whole company. Neat!

What else do you use your dropbox for these days? Let me know!

Using node.js for a build script

Lately we‘ve been amazed by how node allows you to use plain JavaScript for all your scripting needs. My coworkers still rely on Python or Ruby for those stuff, but since I’m a frontend guy, this comes in really handy for me. (Don’t get me wrong, Python and Ruby are really great languages, but I’m just too lazy to learn, when I can achieve the same thing with the language I’m using day to day).

Amazed and inspired by the many approaches the OpenSource community has towards using node for build script stuff I decided to hack my own build script for a few of my recent projects. Again, I’m being pretty lazy here. I could have just learned my way into one of the existing build scripts out there, but I wanted full flexibility and a syntax I could easily hack for different project structures. So let’s get started.

If you’re coming from the frontend like me, you’ll know that the essential part of frontend building is file concatenation and minification of assets. So that’s where I started. Concatenating files is pretty straightforward in using nodes built in filesystem-module. So my basic script workflow looks like this: Find all the files, concatenate them into a temporary file, minify the contents of the temporary file to the build target and delete that temporary file. (Lot’s of temporary going on there…)

Let’s say you have an array of files you want to concatenate that looks like this:

var paths = ['js/script1.js', 'js/script2.js', 'js/script3.js'];

You can then simply make one file from these three files using map and node’s very own filesystem module:

var _fs = require('fs');

// map the contents of all files to the array "out"
var out = paths.map(function(path) {
    return _fs.readFileSync(path, 'utf8');
});

// join "out" with a linebreak and save that stuff to a temporary file
_fs.writeFileSync('tempFile', out.join('\n'), 'utf8');

It’s that simple! Next step is to minify that stuff. No need to reinvent the wheel here. Before rolling my own script I’ve been pretty happy using Google’s Closure Compiler for Javascript and YUI Compressor for CSS. Nice thing about node: It also has a child_process module, that let’s you run command line stuff from inside your scripts. So simply take the syntax you’re using on the command line and drop it inside your script. (You’ll obviously have to place the .jar files of YUI Compressor and GCC in the same folder as your node script…)

var exec = require('child_process').exec;

// ClosureCompiler
exec('java -jar google_closure_compiler-r1810.jar --js=tempFile --js_output_file=script.min.js', function (err, stdout, stderr) {
    // Put some callback stuff here
});

// YUI Compressor
exec('java -jar -Xss2048k /yuicompressor-2.4.7.jar tempFile -o style.min.css', function(err, stdout, stderr) {
        // Again, callback should go here
});

That’s all there is to using node for build scripts. You’ve just learned how to concatenate and minify assets with node.js. This is all you need to know to get started hacking a build script for your own project.

Rodolphe Stoclin has written a nice node module called “node-minify” to provide some great abstraction over those minification called. You can find it on github: https://github.com/srod/node-minify

At the time of writing this, “node-minify” has no ability to automatically concatenate files. So I’ve forked the module, added that stuff and sent a pull request to Rodolphe. I’ll keep you updated. In the meantime you can check out my implementation at https://github.com/lnolte/node-minify

So in the end file concatenation and minification in node becomes as simple as this:

var compressor = require('node-minify');

// This will concatenate your script files and minify them using Google Closure Compiler (gcc)
new compressor.minify({
    type: 'gcc',
    fileIn: ['public/js/plugins.js', 'public/js/scripts.js'],
    fileOut: 'public/js/script.min.js',
    callback: function(err){
        console.log(err);
    }
});

From now on I’ll be using node a lot more for streamlining my frontend build processes. I’m still trying to figure out a nice way to distribute the whole process, but I feel like I’m getting there.

What are your experiences with build proccesses? Please let me know. Thanks for reading!

PaintinPal App Icon – Icon for a coloring book app for iOS and Android

PaintinPal App Icon – Icon for a coloring book app for iOS and Android

Motion Graphic I created for a german text-writing PaaS called wordguru.de

Implementing DNS resolving with node.js

We recently decided we needed a nice interface for our internal DNS-Resolver. Having wanted to play around with node.js on some work-stuff (I’ve only used to build a tool, that streams Rebecca Black’s Friday song on all connected machines in the office so far – but more on that later) I decided to take it for a spin.

For the backend we set up our own DNS Recusor using PDNS Recursor (which is insanely fast). Once installed it’s pretty basic to access it via command line by calling dig with a custom Recusor address:

dig @127.0.0.1 example.com NS +short

But what about bulks of domains. Sure you could write yourself a nifty-wifty bash-script that takes domains from a text file and resolves the name servers, writing the output to another text file. But we wanted things to be beautiful as well. DNS Lookups should be fun.

So we needed a frontend for this. Since, we’re only using the tool internally (at least so far) I decided to implement websockets (via socket.io). I mean how cool is it to see results while they’re happening? So here is how the app is flowing:

You paste in the domains you want to check into a textarea, the domains then are send to the node-based server in bulks by an asynchronous post request. Node forks a child process running the dig statement for each domain. The child process uses a timeout mechanism to respond to non-existing our misconfigured nameservers. The results of a bulk of domains are then send back to the client via a websocket. Each received message from the socket bumps the number of checked domains in a dashboard view. It feels really awesome to paste in a few domains and see the result count increment in real time. I also experimented with sending a socket message for each checked domain, but due to the insane speed of Power DNS the rate of incoming messages made webkit crash for large bulks of data. So we decided to send bulk messages (10 results per message right now). We’re still trying to find the optimal balance between “real time awesomnesssssss” and “reasonable resource usage”.

What I learned from this project is that node is generally awesome! It’s non-blocking nature (even the child processes are callback-based) allows for an asynchronous user interface that’s never frozen. You can still do stuff, while waiting for the server to respond. Once you’re able to get your mind off the classical blocking model (which took some time for me and caused me to yell at my screen several times) coding in node will pay off with results, that amaze your co-workers.

PHP Ranking Algorithm

For a current project at work we needed some sort of ranking as it’s done by reddit, digg, hackernews etc.

So after stumbling about interesting articles about how reddit’s algorithms work, we decided to simply implement them in PHP (Since our whole project is php – we’ll probably change to Go or C, once we get more traffic and need faster calculations).

Check out our PHP Implementation.

Surprising A/B results

While running some quite not revealing A/B Tests over at my new job I stumbled about this pretty interesting post. What are your thoughts on this?

Media Queries JavaScript Style

Recently I was pulling all kinds of CSS3 media-query wizardry up my sleeves for a client just to realize that the site needed different event-handlers for different screen sizes. If only there was a way to add media-queries to my JavaScript.

Well I could use window.innerWidth but this doesn’t give me stuff like orientation.

Instead I stumbled upon window.matchMedia() which is a pretty neat function. Simply pass in your media-query as an argument and your almost good to go.

The funky thing about this function is, that it doesn’t simply return a bool value but a MediaQueryList object. (Open your console and see for yourself). So instead of simply calling the function we have to retrieve the value of the returned MediaQueryList object’s matches property. So you simply type:

window.matchesMedia('only screen and (max-width: 960px)').matches

and you’re good to go. You’ll now get a neat bool value of whether this media query is applied or fails.

Check out the article over at MDN to learn more.

Obviously BMW puts form over function on their toilets un BMW world in Munich. While looking clean and minimalistic their lavatories a pretty hard to use.

Obviously BMW puts form over function on their toilets un BMW world in Munich. While looking clean and minimalistic their lavatories a pretty hard to use.

Bind JavaScript events to screen size in responsive layouts

Recently I’ve been working on a neat responsive layout for a client. I wanted to implement a featured image that slides larger when hovered on huge screens.

Problem: The stupid image was also sliding on smaller screens when hovered causing the layout to break and look like total crap. I was almost about to cry, when I realized the neat window property of JavaScript. So all I had to do was wrapping my event-listeners in an if-clause checking for the screen size. Problem solved!

if(window.innerWidth > 1399) {
/* Neat code goes here */
}

Just wanted to share this snippet with you! Hope it helps you out. Of course you can (and probably should) take this a step further by including something like Modernizr and check whether media-queries are supported by the client’s browser. Otherwise IE6 on a 30” screen could still cause the image to slide down while not the biggest layout is displayed. I know, sounds weird. But I guess, you know what I’m saying?

Further reading

Finally it’s online! Waited for so long! Such a great video. Really shows the toughness of the race.

(Source: vimeo.com)

Hyphenation arrives on the web

Well this is great news. In the past I often dealt with clients, who wanted me to add manual hyphenation to their website’s copy. This can be a pretty hairy task, since there are differences in font-size-rendering across different browsers. So I explained this to my clients but most of them continued thinking in their print-methodology.

Anyways, with yesterdays release of Firefox 6 and the release of Safari 5.1 earlier this month we now have two major browser releases that support the CSS3 hyphen property for automatic hyphenation. As with all CSS3 properties we need to add vendor-prefixes if we want to start using those features now. It looks like this:

p { -webkit-hyphen: auto; -moz-hyphen: auto; }

For manual hyphenation simply change auto to manuel. Check out FontDeck’s blog entry on this.

This is a pretty exciting new feature! In my opinion this offers great possibilities to adaptive design, maintaining nice-looking hyphenation across multiple layout widths.

Update: I’m trying to get this added to HTML5Boilerplate. Check out the discussion.

Another Update: Hyphenation works with different languages but I requires a lang-attribute to be set. You can do this in your site’s header or add it directly to the element you need be hyphenated. Check out the fiddle we prepared.

What do you think about this?

Git on Dropbox

I really dug into git lately and I’m truly amazed by it’s possibilities. Today I figured it’d be neat to have your git repositories on your Dropbox. For those of you who don’t know Dropbox is an online storage solution offering free accounts with 2GBs of storage. They also offer great apps to keep your data in sync across different devices. So it’s basically a server. You’ll need: git installed on your computer + obviously a Dropbox account.

Fire up terminal and cd into your Dropbox folder.

$ cd /Volumes/Work/Dropbox

Next create a directory for your repositories.

$ mkdir repos

Clone existing repos to your Dropbox.

$ git clone . /Volumes/Work/Dropbox/repos/Project-name.git

And finally add the Dropbox repo to your local code copy.

$ git remote add dropbox /Volumes/Work/Dropbox/repos/Project-name.git

You’re all set. This is how you roll your own sort of git server using Dropbox. Your repos will stay in sync across all of your computers. Or if you have a company Dropbox account, across your whole company. Neat!

What else do you use your dropbox for these days? Let me know!

Using node.js for a build script
Implementing DNS resolving with node.js
Media Queries JavaScript Style
Bind JavaScript events to screen size in responsive layouts
Hyphenation arrives on the web
Git on Dropbox

About:

I like to create beautiful and usable stuff...

Following: