After reading about and following the hackathons that have occurred in recent months I decided that I wanted to challenge myself with a “hackathon” of my own. The rules were simple: create a working application of any type, in any language, within 5 days. Nowhere near as challenging as most, but a worthwhile goal nonetheless.
Read More
I’m going to assume a few things since you’re viewing this post. First, you’re using ExpressJS version 3+ (and by extension nodeJs). Second, that you’re using the Jade templating engine, although I think EJS would work as well.
So with the requirements out of the way let’s throw down some code, shall we? As the title suggests we’re going to use a function that we’ve written/downloaded in our Jade template. This sounds more complicated than it actually is so stay with me. Oh and to streamline things a bit it would be easier to download a function that I wrote. You can use a function of your making, just make sure that it returns something.
Read More
Let me preface this post with the fact that I’m big on modular programming. There are many benefits to structuring your code in a manner that would support simplicity. And at the top of the simplicity hierarchy, for me, is the ease of tracking down errors. Because let’s face it, none of our applications are infallible so being able to diagnose and fix issues quickly is of the utmost importance. But, I also know that there are some people (I was one) that dread having to require a boatload of files multiple times like:
// some-file.js
var file1 = require('./lib/library1/file1')
, file2 = require('./lib/library1/file2')
, file3 = require('./lib/library1/file3')
// And so on...
;
Read More
Seeing as how I’m a pretty big fan of NodeJS I also had to become a fan of its package manager npm. Not a very hard thing to become fond of to be honest. But, there was a point when I had no clue what it was or how to use it and so I searched for any snippet or command that could be useful.
These are just a few of the different commands that I tend to use regularly.
Read More
One little, two little, three little command prompts. Four little, five little, six little.. yea, that doesn’t have the same ring to it. Moving on then. While the rhythm may be different, the problem is the same: you’re developing an app - be it web or otherwise - and need to have a plethora of command prompts (terminals) open and running different processes that your app relies on. That’s not using your screen real estate wisely, now is it?
Read More
Hopefully this little tip isn’t as no-brainy as I thought it was, ‘cause if it is then I’m a jackass. But, before I just start throwing instructions at you I need to set-up the situation. Let’s say you use.. I don’t know, maybe Mocha, as your testing framework. Normally you would just npm install it with every new application or you would add it to your package.json file. Now this is a logical way to do it, but what happens when the interface gets updated? You now have to go back and update all of your applications that use it. I don’t like making things harder for myself and since I develop primarily on a Windows box I don’t get to use the cool -g flag.. or could I?!
Read More
Alright, I’m bringing you yet another Stylus quick tip. This time I’m going to show you another escape issue I ran into that I think may be pertinent to you (and myself). Examples speak better than I can explain so:
Read More
Writing a module that can be used in your node.js application(s) is easier than you think. So long as you think. Ready? Let’s do this.
Now I know it’s boring, but you’re getting a Hello, world example. Don’t like it? Tough. My creative juices are running low at the moment.
// well.js
module.exports = function() {
console.log('Hello, world!');
};
And that’s our module; she’s not much to look at it, but she’s ours. Now let’s see her in action. (note: you could just as easily use the REPL but the goal is to put this in an application at some point)
Read More
Okay, so a few weeks ago I was trying to bind a click event to a selector like so:
$('ul#something').find('li.orOther').on('click', function() {
alert('Do work.');
});
All good; or so I thought. You see that li element? That little bastard after .find(‘? Yea, that one. That element gets created dynamically, and since I was using .on() it was supposed to be ‘live’. Well, it wasn’t. The worst part: I never went and figured out why it wasn’t firing on the newly created lis. Or is it lises?
Anywho, what I did do was what any programmer who wants to get the job done quickly does. Threw the event at the document:
$(document)
.on('click', 'ul#something li.orOther', function() {
alert('Did work.');
});
That code feels a bit.. klunky, but it worked. And hey, that’s why we refactor!
Side note: I have a sneaking suspicion that the first code snippet doesn’t work because of the use of .find(). Not 100% on that one though.