Mike Hodnick's Blog

Plight of the Open Source Windows JavaScript Developer

If you are a Windows developer and want to contribute to open source JavaScript projects, prepare for a little bit of pain and suffering.

"Why the pain and suffering?"

Why? Because the Linux and Mac kids are having all the fun right now. They took the initiative and you have to follow in their footsteps. They aren't using Windows tooling (duh!). They are developing their own tooling on node.js or using tools that depend on bash.

Most Windows devs don't have much exposure to node.js, let alone bash.

"What tooling are you talking about?"

The most Windows-unfriendly tooling is the combination of Make and node.js libraries. Separately they are not a problem on Windows, but it isn't so easy (or even possible) to get them to work together on Windows.

The good open source JavaScript projects out there do not use this combination and instead only depend on node.js. However there are still projects out there that use this combination.

In the Linux and Mac world, Make typically runs bash commands to do things like file system manipulation, run tests, and concatenate your JavaScript files. The problem is that Windows can't run bash commands.

One solution is to run Cygwin - which is a Unix emulator for Windows that will run bash. For vanilla Make tasks, this will work just fine. However this becomes a problem when you want to run node.js commands from a Makefile.

"Whoa whoa whoa... can you back up and explain node.js a little?"

In the JavaScript developer world, node.js is exploding. node.js is a JavaScript runtime that abstracts away system details so you can focus on writing JavaScript apps for your system. For the .NET devs out there, think of it this way: node.js is to JavaScript as the .NET Framework is to C#.

The best JavaScript tooling is being built on top of node.js. Take for example two popular node.js libraries: UglifyJS and grunt. UglifyJS is arguably the fastest and most valid JavaScript minifier in existence today. Many JavaScript projects are using it. Grunt is "a task-based command line build tool for JavaScript projects". Use Grunt to structure your JavaScript projects and carry out Make-like build tasks. These two libraries are run in the node.js runtime.

These two libraries are just a taste. There are hundreds of JavaScript libraries built on node.js that make your own JavaScript development more productive.

I should mention that node.js installs and runs on Windows just fine. You can even alias it in PowerShell.

"Ok, so what's the problem with Cygwin and node.js?"

Some open source JavaScript projects use a combination of both Make and node.js. For example, they use Make to fire off UglifyJS minification. On Windows, this would mean you'd need to get node.js running on Cygwin. However, if you want to try and get node.js running on Cygwin, you are in for a world of hurt: github.com/joyent/node/wiki/Building-node.js-on-Cygwin-(Windows).

Simply put, node.js isn't going to be supported by Joyent to run on Cygwin anytime soon.

"So I should get to know node.js on Windows, and for a new JavaScript project I should use only node.js libraries for build and dev tasks. Easy enough."

Yep.

"But since I develop on Windows I can't contribute to projects that depend on both Make and node.js?"

Because we're talking about open source, the answer is no!!!

The real task at hand is to eliminate the dependency on Make and to roll with 100% node.js tooling for JavaScript projects. Grunt does what Make was already doing in JavaScript builds, so eliminate the dependency on Make.

Leverage the fact that this is open source. Contribute to projects to help eliminate the bash and Make dependencies. The owners of the projects will most likely be delighted that someone is willing to contribute and improve the code base; that has at least been my experience with open source projects.

"Wow, that doesn't sound too painful."

It isn't, but it's a different world for the average Windows .NET developer who spends most of their time in Visual Studio. If you don't have much experience working from a command line then prepare for a different learning curve. Unless you want to dig in deep and spend a lot of extra time developing some plugins, you are going to get your hands dirty in the command line with node.js. In my opinion, this is a good thing.

For straight-up JavaScript development, big IDE's aren't going to give you much. JavaScript doesn't use a compiler. There is no need for Solution, Project, Resource, or UI meta-files. Keeping it real with the command line and a good text editor are what it's about with JavaScript. However, arguing about a programmer's preference in editors is like religious warfare. The bottom line is to use what makes you most productive, whether that's Notepad, Notepad++, Notepad2, Vim on Windows, or an IDE like Visual Studio [1].

If you are a Windows JavaScript developer, or a Windows developer at all for that matter, get to know node.js on Windows. Install it and start using it. Develop for it. It is how JavaScript development on Windows should be done, especially if it is for an open source project. It levels the playing field for JavaScript development across all of the main operating systems.

[1] Personally I have fun using tmux to host a Vim editor and additional console prompts to run builds and tests. You never leave the keyboard and it's faster than Alt+Tab'ing since it's only one Window. However, tmux is not supported in Cygwin, so you need to dev on a Linux or Mac machine to go this route. Yet another pain for the Windows developer...if you want to go the tmux route.

The Git Rap (+ remix)

"just a touch that file .gitignore"

A couple of weeks ago, a GitHub user by the name of Marak created a repo and posted tracks for a song he wrote and recorded called The Git Rap. He posted not only a final mix but the instrumental and vocal tracks as well. Basically it is a repo of wav files.

I couldn't help but do something with it...

After a week of slicing, copying, pasting, and turning knobs on synthesizers, I'm pleased to share with you The Git Rap - Kindohm Cherry-Pick Mix:

Marak accepted my pull request to the repo a few days ago, and the remix is now a permanent part of the repo! I may make another remix...we'll see.

You can listen to the original here:

Iowa Code Camp 9

This past weekend I was in Cedar Rapids, Iowa for Iowa Code Camp. This event was their ninth one, and it was great!

I had the fortune of doing a presentation at the event on building an HTML5 audio player with buzz.js and knockout.js. If you attended my presentation and are looking for the content and code that I showed, you can get it all here: github.com/kindohm/icc9-html5audioplayer. Heck, even if you didn't attend my presentation you can still take a peek!

I should also mention that there were plenty of llamas in my presentation content. Full size, all the way:

The event was great, and I thought this tweet really summed up one of the reasons why:

Attended my 1st @iowacodecamp. Just as good if not better than a paid event.I am hooked.Will be a future regular.Keep up good work.
— Brent Greiner (@BrentGreiner) May 7, 2012

Brent is absolutely right! Code camps are free and full of great technical content. I think one of the reasons for this is that us programmers want to come out and talk code for no other reason than because we love doing it. Nobody gets paid to speak - so you're getting speakers that want to be there on their own pure motivation to share cool stuff and their own knowledge and experiences.

Twin Cities Code Camp is no exception - so if the Twin Cities is a better location for you make sure you subscribe to the RSS feed on the TCCC web site for info on the next TCCC event. @TCCodeCamp is on Twitter too.

Our next Twin Cities Code Camp date will probably be sometime in October.

But don't let location restrict you... folks from as far away as Idaho attended this last Iowa Code Camp!

Fast Fourier Transforms with audiolib.js

"So this one day I was using an oscillator..."

audiolib.js has been one of my favorite JavaScript libraries to work with so far. Being somewhat of a synthesizer and audio geek, I love using it to produce audio with code.

Aside from audio synthesis and generating samples, audiolib.js includes fft.js to perform Fast Fourier Transforms (FFT). If you're not familiar with what an FFT is, think of any graphical output you've seen in a car stereo or MP3 player that displays the frequency specturm of the music being played. FFT's are used to compute those displays. With audiolib.js, you can use FFT's to create your own similar display on an HTML5 canvas.

Before digging in to the code, here is a quick demo (source code):

So how does this work exactly...

Basically in the audiolib.js callback where samples are generated you push the samples to an FFT object:

oscillator.generate();
sample = oscillator.getMix();
fft.pushSample(sample);

In the context of the entire audio callback it looks like this:

function audioCallback(buffer, channels) {
	var i, n, sample, bufferLength = buffer.length;

	for (i = 0; i < bufferLength; i += channels) {

		oscillator.generate();
		sample = oscillator.getMix();
		fft.pushSample(sample);

		for (n = 0; n < channelCount; n++) {
			buffer[i + n] = sample;	
		}
	}
}

When this code starts running, the FFT fills up with thousands of samples and it starts to do some analysis. Luckily you don't need to know anything about the magical code in fft.js that does all that!

Now you just need to draw the FFT spectrum on a canvas, which basically just some simple x/y graphing:

var width, height, context;

window.addEventListener('load', function() {

	var canvas, button;
	
	canvas = document.getElementById('canvas');
	context = canvas.getContext('2d');
	width = canvas.width;
	height = canvas.height;
	context.fillStyle = "#ff0000";
	context.lineWidth = 1;
	
});

function drawFFT () {

	var length, count;
	length = fft.spectrum.length / 8;

	context.clearRect(0, 0, width, height);
	context.beginPath();
	context.moveTo(0, height);
	
	for (count = 0; count < length; count++) {	
		context.lineTo(count / length * width, 
			fft.spectrum[count] * -height * 2 + height);
	}
	
	context.moveTo(width,0);
	context.closePath();
	context.fill();
	context.stroke();	
}

You can use setTimeout() to continuously call the drawFFT() method. You can also use the Sink object, which is from the sink.js project and also bundled with audiolib.js:

Sink.doInterval(function(){ 

	drawFFT();

}, 1000/fps);

Cake! Now you can add some nice graphical output to your audiolib.js apps! fft.js can be used outside of audiolib.js too, if you have another use for it. Happy coding!

501 Development Ebbs and Flows

The 501 Manifesto has been going around in developer circles recently. The basic idea of the manifesto is that programmers should have a life outside of writing code.

I was glad to see this blog post as I don't agree with 100% of the 501 Manifesto. It's a question of what your likes and hobbies are, isn't it? One man's love is another man's labor. I write on this blog, contribute to open source projects on GitHub, speak at developer events, and try to stay on top of new and emerging technologies as much as I can. I also play hockey, write and record music with others, play video games, spend almost every minute with my daughter while she is not in school or sleeping, go to Minnesota Wild hockey games, and relax and have fun with my wife.

In this discussion of the 501 Manifesto, nobody has brought up ebbs and flows. You don't have to be a 501 developer 100% of the time. Nor do you have to be uber-passionate about code 100% of the time. There is middle ground. Can't our activities ebb and flow with what our job and interests demand?

I have more hobbies and interests (on top of programming) than the average guy out there. I'm spread really thin, but there are still short lengths of time (e.g. a few days to a few weeks) when I focus most of my free energy on writing code or technical activities. For example, I'm coming off a two-day Twin Cities Code Camp weekend, prefixed by a week spent preparing my presentation I gave at that event. I am preparing for another presentation at Iowa Code Camp and am also trying to get a Windows 8 app developed. It's been an intense period of geeking out. Time to change it up. I wasn't a 501 developer for a while, so can't next week be different?

The point of the manifesto should be a wake-up call to developers to live rich, healthy lives. The point should not be to identify specific, arbitrary traits of developers that may or may not hurt a single developer's quality of life. Take from the 501 Manifesto its spirit, not its specifics.