I Messed Up, Cascadia.js Kicked Ass, Defrag Conversations Continued Without Me!

I wasn’t able to get to Cascadia.js. Sometimes during the course of working smart and hard one misses the smart part and scheduling falls apart. Well, I messed up. I messed up and my scheduling got completed dorked for the last two weeks. What did that result in? I missed Cascadia.js, a codeathon in Spokane that I was putting together and to top it off I was missing Defrag in Denver – which really put me out because I was out of pocket personally for Defrag. Altogether it was a financial, logistical and scheduling nightmare for me.

To all, I apologize for my lapse in scheduling prowess!

Amid all of this mess, I’ve got some great new things coming up in the coming week for the OSS Projects I’m working on, the north west, a little emerald for Seattle, some earthy stuff for Portland and all around interesting tidbits here and there.

Before I go rambling on about those things, I wanted to leave this pre-weekend before Thanksgiving with some shout outs to the Cascadia.js Team & Presenters. Carter, Troy, Luc, Jerry, Laurie, Bobby & the whole lot of the team that put that together – you guys seriously ROCK!

The conference had a number of speakers, who totally rocked it, and here’s a few of my first views. I wasn’t there, as I said, so I was seriously stoked that the team put the videos online.

Angelina Fabbro @AngelinaMagnum presents

Matt Padwysocki @mattpodwysocki presents

Jason Denizac @leJden presents

Rick Waldron @rwaldron presents

Emily Rose @nexxylove presents

…and there ARE MORE PRESENTATIONS at Cascadia.js on youtube. Check them out, each is a blast!

Pull Request for People by Chris Williams

@voodootikigod <- but don’t look for him on Twitter… watch the ending keynote of his. It’s really good and we all need to think about what he is saying, seriously think about what he’s saying.

As for some of his questions he asks, I’ll have some answers to that – which I could indeed rattle off quickly, in response. I do say though, I don’t provide these answers to counter what he is saying. I do so only to state and reaffirm what he talked about. I am absolutely, 100% in agreement with what he is saying about the current state of the startup & tech sector.

With that, I’m going to spend some time with friends. Maybe even make some new ones. Cheers! 🙂

…as for Defrag, I’ll have more about that in the coming days too.

JSConf EU

In light of the upcoming Cascadia.js Conf I was digging around last night through some of the other JavaScript Conference videos and found the JSConf EU’s listings on Youtube. Here’s a few picks from the ones I watched. I’d highly advise checking these out, there’s a lot of great content there. With that quick introduction, here’s Max, Irene and James. Cheers!

Max Ogden @MaxOgden provides reasons how to help Government work better through various means…  absolutely great talk. Check it out.

Irene Ros @ireneros combining practices we’ve had for years into a better way to get data.

James Halliday (@substack and github) UNIX Philosophy and…  just watch this, James is kick ass and contributes a ton to the #nodejs community.

JavaScript Libraries Spilled EVERYWHERE! Series #002

In the last blog entry I wrote up vows.js for testing JavaScript, in this I’ve tried out another testing framework called mocha. This framework is pretty extensive as you can do the things you do with vows.js as well as a lot of other techniques. In addition to mocha I’ve added a few other things to the mix. As well as a few obvious points where I need to RTFM still about how mocha works.

mocha.js

Before falling off into a conversation about reading the manual, I’ll dive into a bit about mocha. Mocha is a project, hosted on github as you might expect, that aims to provide a very feature rich test framework that can run via node or the browser. It also enables asynchronous and synchronous testing with some pretty sweet reporting.

The installation is the standard simplicity of a beautiful and elegant package from npm for node.js.

[sourcecode language=”bash”]
$ npm install -g mocha
[/sourcecode]

Of course, depending on the way you’ve setup your machine, you may need to hit that command with sudo. The sample test on the main documentation & project page is pretty straight forward, I’ve copied it below for easy reference.

[sourcecode language=”bash”]
$ npm install -g mocha
$ mkdir test
$ $EDITOR test/test.js
[/sourcecode]

Note that above, where “$EDITOR” is whatever editor you’re using, such as Sublime 2, Textmate, Webstorm or whatever.

[sourcecode language=”javascript”]
var assert = require("assert")
describe(‘Array’, function(){
describe(‘#indexOf()’, function(){
it(‘should return -1 when the value is not present’, function(){
assert.equal(-1, [1,2,3].indexOf(5));
assert.equal(-1, [1,2,3].indexOf(0));
})
})
})
[/sourcecode]

Then run the test.

[sourcecode language=”bash”]
$ mocha

.

✔ 1 test complete (1ms)
[/sourcecode]

Overall, pretty sweet and simple. There are ways to setup mocha to do TDD or BDD style also. What I’ve done for my basic name generator I’m building has started of super simple. One of the other additions that I’ve added below is the should.js library. I’ll add more about this library, and the intent behind using it in the next blog article I write up.

My first tests I’ve put together I’ve entered below.

[sourcecode language=”javascript”]
require(‘should’);
var factory = require(‘./../lib/NameFactory’).nameFactory;

describe(‘when working with names using NameFactory’, function(){
var generateThisManyNames = 3;

describe(‘generating names’, function(){
it(‘should return a name between 3 and 20 characters’, function(){
factory.generate_names().length.should.be.approximately(3,20);
});
it(‘should return correct number of names’, function(){
factory.generate_names(generateThisManyNames).length.should.equal(generateThisManyNames);
});
})
});
[/sourcecode]

…and then I’ve implemented the absolute basic to get those tests to pass. You JavaScripters that have been at it for a while can likely detect my massive newbism among this code. I’d love feedback btw. 🙂 So here’s my basic implementation so far.

[sourcecode language=”javascript”]
module.exports.nameFactory = {
generate_names: function (count) {
if (count > 1){
return [”,”,”];
}
else{
return ‘stuff’;
}
}
};
[/sourcecode]

I’m still sketch on best practices around a number of object uses and creation in JavaScript. For instance in my code above, I’m creating a module, and setting up properties with functions, which leads to a number of questions… (maybe it is stack overflow time)

  • Is this an efficient way to create a JavaScript function for returning randomly created names?
  • What would your first tests be when creating a name generator? Any suggestions on some tests to add?
  • This shows some of my intent, such as returning a single result if no count is entered or it is less than 2, any suggestions on doing a kind of overloaded factory pattern method like that?
  • Now that I’ve gotten what I do above, I need some more tests to add to confirm that the returned content isn’t [”,”,”] <- cuz’ obviously that’s useless and not random, just returns the 3 string array that would prospectively have generated (or randomly selected) names. Ideas?
  • Is there another way to create a class or namespace that isn’t “module.export…” like I have above with “module.exports.nameFactory”? I’d love to just have a “NameFactory” or something. Not sure how or what way would be best in JavaScript land to put something like that together.

I’ve already moved past just this, but would love any feedback on the above questions and code snippets. I’ll post my results and the changes and additions from any body that posts feedback and suggestions in a subsequent post.  🙂

Cheers!

Coder’s Vacation : OMG! JavaScript Libraries Spilled EVERYWHERE! Series #001

NOTE: All parts of this series and my other series can be found on my series links page.

I sat down a few days ago on this trip to get a simple project setup, instead something else happened. It is my fault, entirely my fault. I could have stayed focused on a single library but instead I’ve let them explode. They’re everywhere now in my project!  😮  I’ve learned a great deal about breaking and fixing things though when working with testing frameworks and Node.js. All of this being rooted in my exceedingly simple project called NameFactory on Github. Here’s a few of the things I’ve stumbled through over the course of figuring out these testing frameworks.

vows.js (while chillin’ at Phils Coffee)

Phils Coffee, a staunch cup indeed!
Phils Coffee, a staunch cup indeed!

If you aren’t familiar with vows, here’s the brief description. Vows is a node.js testing framework that is built around the notion of BDD, Behavior Driven Development. The other important thing to note, is vows.js was built specifically to test asynchronous code. It can test others, but it is more oriented toward asynchronous code. Vows also runs tests in parallel, which thinking about that it takes the random order execution and ups the game even further by running them this way. It can really tighten up code execution and regression that things will indeed work in many different conditions. Building for web scale on the internet, that’s something we definitely need!  🙂

To install vows, it follows your standard pattern with npm:

[sourcecode language=”bash”]
npm install vows
[/sourcecode]

When I installed it I really bit the bullet and went for a global install.

[sourcecode language=”bash”]
sudo npm install -g vows
[/sourcecode]

From there I spun up a really simple example that is shown on the vows.js site:

[sourcecode language=”javascript”]
var vows = require(‘vows’),
assert = require(‘assert’);

vows.describe(‘Division by Zero’).addBatch({
‘when dividing a number by zero’: {
topic: function () { return 42 / 0 },

‘we get Infinity’: function (topic) {
assert.equal (topic, Infinity);
}
},
‘but when dividing zero by zero’: {
topic: function () { return 0 / 0 },

‘we get a value which’: {
‘is not a number’: function (topic) {
assert.isNaN (topic);
},
‘is not equal to itself’: function (topic) {
assert.notEqual (topic, topic);
}
}
}
}).run();
[/sourcecode]

From this example you run the tests by executing the code with the following command:

[sourcecode language=”bash”]
node division-by-zero-test.js
[/sourcecode]

This is all fine, but I’d rather be using the vows test runnner. To do that you’ll need to, instead of *.run(); call the *.export(); function instead. At this point I started scratching my head a bit and looking for parallels between my understanding of BDD and testing and what vows is doing. So I read further and came up with a few observations.

In vows the convention is to have one test suite per file and have the subject match the name. This makes sense to me, that’s how I’ve generally done similar things with Ruby, C# and the like. You end up with something like this for setting the subject and adding the various test suites:

[sourcecode language=”javascript”]
var suite = vows.describe(‘subject’);

suite.addBatch({/* run 1st */}).addBatch({/* 2nd */}).addBatch({/* 3rd */});

suite.addBatch({
‘A context’: {
topic: function () {/* Do something async */},
‘I am a vow’: function (topic) {
/* Test the result of this topic */
}
},
‘Another context’: {
topic: function () {/* Do something else async */},
‘I am another vow’: function (topic) {
/* Test the result of this topic */
},
‘I am another sub-context vow’: function (topic) {
/* Test the result of the topic */
},
‘And another sub-context’: {
/* Executed when the tests above finish running */
}
}
});
[/sourcecode]

Each of the topics are the thing that is being tested with the secondary element of each test being the test to verify the topic. Each of these things are run asynchronously, in parallel, so be sure to keep that in mind when using this framework. However note, in the sub-context tests above the sub-context happens in order. This can be used in various ways, but be sure to not abuse this execution model to avoid the asynchronous nature of JavaScript, I’ve only been working with vows for a few days and have already seen code snippets on the web that have done exactly that!

So this is the first part in a series where I’ll just cover all sorts of JavaScript libraries. It took a Coder’s Vacation however to get me started on this series, enjoy.

Coder’s Vacation : My Slide Deck for the Upcoming HTML 5 Developers Conference

Continuously Kicking Ass
Continuously Kicking Ass

Web development isn’t always easy. Really, there isn’t a form of application development that is easy, there’s a lot of steps, tools, and other traps to coding. One of the best unifying ways to insure that all this complexity doesn’t kick your ass, is to implement continuous integration & delivery practices. I’m going to cover that in a talk this Monday at the HTML 5 Developers Conference in San Francisco. As a precursor to the talk, here’s my slide deck… which I’ll admit isn’t the whole kit and kaboodle, because I will haz codez so subscribe and those I’ll be publishing during this Coder’s Vacation of mine.

NOTE: Pending on levels of connectivity, I’ll be showing a number of details, examples and a little code on implementing continuous integration for JavaScript, specifically with vows and Node.js elements.

Cheers!