13
Nov 11

node grinding the crack (between Windows and Linux)

Let me apologize up front for the terrible title. I have been recently inspired.

I met some fantastic people at the fantastic Keeping It Realtime Conference last week. The speakers were great. The conversations were fantastic. The parties were fun. I will go again next year. There was so much information to consume that I am just now sorting some of it out. In my mind, the experience plays backs like ten thousand snapshots in rapid succession. A blur of events, conversations, people, code, and crappy wifi. A couple of faces stand out: the crew from Microsoft, Paul Batum, Glenn Block, and of course Scott Hanselman. They left a big impression on me. Not because I was in shock that Microsoft was actually represented at this event (though I was), or that these guys were deep behind enemy lines (you should have seen the mac/win ratio), or because they were all wickedly smart (they were). No, it was that Microsoft seems to be genuinely making a go of supporting node on Windows and it actually looks pretty good.

Okay. So what does this have to do with base jumping wingsuit insanity? Well, dear reader, not much. But I’ll try and tie it back. If you browse back through my archives or follow me on twitter, you will get a lot of Linux and node content. But every so often, something Windowsy slips through. You see, the truth is: I am .NET developer. Or at least I used to be. Now, I manage a team of developers–a mixed team. We are about 50/50 .NET and Django with a sprinkle of node on top. Our various products have to integrate with each other and I make platform decisions on a daily basis where I am pitting a Windows stack against a Linux one. In short, I “grind the crack” between them. But without the wingsuit and inevitable spectacular death.

Back to the conference. At the opening event, I met Glenn and Paul. I had a great discussion with them about where my team is and where we are going. I like node and I see some great use cases for it in our business. At one point, Glenn asked me, “What would it take to you get you choose windows?” I answered that it was probably too late for us, “We have node programs running on Linux. Why would we switch?” I told him that I wholeheartedly supported node on Windows for the good of the node community, but that we were already past the point of needing it ourselves.

Fast forward two days. I make sure to attend Glenn’s and Tomasz’s talk on node for Windows (the main point behind the recent 0.6.X release by the way). I didn’t expect to hear anything I wasn’t already aware of. And I was surprised. Floored even. They have actually done a great job creating a Windows “story” for node. They want you to run node with IIS. If you do that, you get some pretty awesome stuff for free:

  • built-in process management ala forever
  • load balancing between node processes
  • graceful auto-refresh of the node process when code changes
  • remote node-inspector (hell yes!)
  • logs over http

Yes, I know you can get all these things on Linux. And, maybe there are arguments to be made about scaling (haven’t seen benchmarks, so I have no idea). But you know what? I don’t have scaling issues. We have a modest user base. Our biggest challenges are building a great experience for our users, integrating disparate systems, and maintaining our automated deployment and testing infrastructure. With iisnode, I can just include the node javascript along side our existing .NET app and ship it with the same TeamCity deployment. I won’t even need to restart IIS!

We were already planning on using node and WebSockets to bring some realtime features to our ASP.NET MVC app and Microsoft just made my life simpler. Glenn: you got me back (at least partly). I am excited to see what you guys do next.

Bravo.

24
Sep 11

Quick vim tip #1 (and I am not dead)

Sorry for the summer hiatus. Work, vacation, and mountain biking put a serious squeeze on my free time hacking and blogging activities. I have been working on some cool stuff lately and the cold weather is starting to arrive here in Spokane, so I should have plenty of blog posts coming up.

Anyway, quick vim tip #1. If I have a chunk of a code with a string:

var blah = "Some string that I want to replace" + previouslyDefinedVariable

I want to replace it with “new string”. In vim, do:

  1. Put your cursor on the first character inside the quotes of the string you want to end up with, in our case, the n from “new string”.
  2. Type yi” – yank inbetween quotes
  3. Navigate to the string you want to replace
  4. Type di” – delete inbetween quotes
  5. “0P – paste content from yank buffer
  6. Marvel at your vim prowess.

Got any great vim tips? I would love to here about them. Send them to vimtips@fzysqr.com. Check out my full vim config fork of scrooloose’s config on github (here)[https://github.com/jslatts/vimfiles].

Updated Cory Schmitt wrote in with a helpful suggestion that saves two keystrokes!

  1. Put your cursor on the first character inside the quotes of the string you want to end up with, in our case, the n from “new string”.
  2. Type yi” – yank inbetween quotes
  3. Navigate to the string you want to replace
  4. Type vi”p – visual mode select inbetween quotes and paste over
  5. Congratulate yourself for being awesome.
20
Jun 11

Version 0.0.9 of Stalker for node.js is available

I have just released 0.0.9 of Stalker. Improvements (some from 0.0.7 as well) are:

  • Added batch mode to group callbacks
  • Added second callback for file removal notices (this works in batch mode as well)
  • Switched unit tests to vows.js and added additional coverage
  • Made errors callback immediately in standard node-fashion.
  • Fixed bugs

Get it on npm now or head to github.

Thank you for all the feedback.

08
Jun 11

Introducing stalker, a node.js module. Now your files can get restraining orders against you too.

I released my first node.js module today on npm, aptly named stalker. stalker is basically a wrapper around fs.watchFile(). It will watch a directory tree for new files and fire off your callback whenever it finds one. It tries to be smart about entire nested folder/file structures and tricksy add/removal/add type of stuff.

Get it on npm: npm install stalker

You can test it by running node example/test.js and then dropping files and folders in the example directory.

To incorporate it in your program, simply call stalker.watch with your callback:

stalker.watch('/var/foo', function(err, file) {
  console.log('stalker saw file %s', file);
});

Code is at github: https://github.com/jslatts/stalker

29
May 11

node-inspector and the missing –start-brk option

Quick tip to anyone having trouble finding the right way to start a node-inspector debugging session with an initial break point. Lot’s of youtubes and how-to’s mention a –start-brk=file.js option. If you try and actually use it, it doesn’t work. The correct way to do this now is:

node-inspector &
node --debug-brk --debug server.js 

Head to http://0.0.0.0:8080/debug?port=5858 to find your app nicely stopped on the first line.

Happy noding!

21
May 11

Kilnauth Plugin for Mercurial on a Mac

Do you use Kiln from FogCreek? Do you use a Mac? Are you having trouble getting the kilnauth plugin to work on your Mac? If so, you probably have a bad hgcookies file. To fix:

  1. Find a colleague with Windows who has a properly functioning kiln client (or follow the process in this kiln stackexchange post).
  2. Have them open up their user profile and look for an _hgookies folder. Open the cookie file inside.
  3. There will be a line that looks something like (DBID’s have been changed to protect the innocent): servername FALSE / FALSE DBID o1sev3t3dn01dabdppin90wexczimb
  4. Have them send you the DBID value
  5. On your Mac, open the cookie in your ~/.hgcookies/ and add the missing DBID value.
  6. You might have to hg logout, then try an hg get/in to put your credentials in. After that it should stop prompting you.
16
May 11

Impress your friends with client side updates

Of the many life lessons I have learned creating nodechat.js, one of the most poignant was that people like to leave their browsers (and tabs) open for a long time. This should not have been a surprise to me–I often have tabs open for weeks in the vain hope that I will get back to whatever I was doing on that page someday. This phenomena meant that users would log into nodechat, click away to another tab (or restart their browser, or suspend their PC), only to revist the nodechat tab later and find that the chat appeared frozen. The same issue occured everytime I pushed a new server update: all clients would be cut off until the user refreshed the page. Clearly this was a subpar user exeperience. This is how I fixed it.

Continue reading →

11
Apr 11

Sending your clients to purgatory (a node.js/socket.io tutorial)

Updated As has been pointed out, sending the username and password hash over to the client is not the most secure thing you can do. I wholeheartedly agree. Please do not do this on anything for real-ish. Treat this tutorial as a simple demo of how to isolate a connection until you give it some sort of approval. A much better approach would be to use a one-time throw away key or create a salted hash using the incoming client’s IP address. Or probably a million other things. The concept of isolating a connection to socket.io within a closure still applies.

Now back to your regularly scheduled programming:

One of the problems I have had with nodechat.js is that using sessions to handle the transition of authenticated users between express and socket.io has always been somewhat finicky.

Nodechat.js and the previous nodechat-tutorials have used sessions to manage this transition by storing a username and password in the session after initial login and making it available to the socket.io listener on new connections and during each message. While adequate most of the time, this method never worked correctly with all the various socket.io transports and it seemed like clients would frequently get stuck when reconnecting, requiring them to reload the page to get back into nodechat.js.

I now have a pretty decent way to address this issue and I am going to share it with you. A little technique I came up with that I call Purgatory…

Continue reading →

27
Mar 11

Nodechat.js continued – authentication, profiles, ponies, and a meaner socket.io

As promised, here is a follow up tutorial on the node.js/socket.io/backbone.js/express/connect/jade/redis stack that powers nodechat.js.

The first nodechat.js tutorial introduced some fancy ideas, like using backbone.js on the server and streaming models over socket.io which is all well and great, but it left some of the more practical questions unanswered. Issues like coordinating authentication between express/connect and socket.io and creating, storing, and retrieving user profiles, are less sexy, but still quite important for real world use. So that is what the next this tutorial will look at. Practical stuff. Besides, everything is more fun when you do it in node, right?

I will also sprinkle you with some other neat wisdom nuggets along the way. If you want.

Continue reading →

14
Mar 11

nodechat achieves glorious internet notoriety

Two weeks ago, I released a tutorial on using node.js, backbone.js, socket.io, and redis to make a simple realtime chat app. Someone posted it to Hacker News and it made it the front page. fzysqr.com enjoyed brief fame and notoriety. The number one complaint (other than my awesome user interface) was that there was no demo. So without thinking (at all) I threw the code up on a Joyent no.de (Joyent are a bunch of node-ninjas and no.de is the best thing since ponies, check them out) and posted the link on HN and on fzysqr.com. Whups.

I have learned a few things over the last couple weeks. Good “lessons” I will share with you now:

  1. Don’t actually put your crappy code online, publicly, for abuse. It will crash.
  2. Sanitize inputs for your crappy demo code before you try to run it (in violation of rule number 1). XSS attacks will significantly lessen the quality of the experience you are trying to provide your audience.
  3. Check for nulls. Everywhere. The internet is a cruel place and people are mean. They will look through your crappy demo code and figure out how to crash your crappy demo.
  4. Running production-ish code on node.js requires a different mindset. If anything takes the process down, it is down for everyone. Coming from a typical web-development background, it took much crashing before I realized this. Writing robust, fault tolerant code is CRITICAL if you are hosting it on node.js
  5. If you write a silly chat room and hang out it in all day, you will meet many interesting people.
  6. There is a ton of interest in node.js. People are really excited to work with this stack.

People seemed to enjoy nodechat.js so I have been hacking out new features as fast as I can. Things that have changed since the demo:

  • Authentication: reserve your username now, before they are all gone!
  • Rightside up chat
  • Mashtags: like #hashtags but #mashier
  • Users online: now people are more than numbers
  • Direct messages: now you can tell @jslatts how much you hate the UI in private
  • Notifications: blinky tab thingies
  • Linkify URLS / em / bold
  • Flood control (yes, that one guy who knows who he is, I am thinking of you)
  • Works in Firefox (sorry FF, I don’t test in you)
  • Still Fun Chat Messages only

As always, you can find the latest code at github.

I am working on a follow up tutorial to cover authentication and some other fun tidbits I have discovered in the last couple weeks. Stay tuned.