HackUpstate http://hackupstate.com #hackupstate
If you live in Upstate New York you should attend the hack upstate event! So what are you waiting for go register!
Also Retweet this:
My First 5 Minutes On A Server; Or, Essential Security for Linux Servers
Excellent read on sever security. My First 5 Minutes On A Server; Or, Essential Security for Linux Servers
twitter / typeahead.js
Inspired by twitter.com’s autocomplete search functionality, typeahead.js is a fast and fully-featured autocomplete library.
mac sudo autocomplete
After getting tired of autocomplete not working with sudo I came across this: http://bit.ly/YLB7rE
If you are using bash and have homebrew installed just do this:
$ brew install bash-completion
Refactor to modules
Today I decided to factor out code I have been using consistently into separate modules. Some of it is still a work in progress.
My npm profile can be found here: http://bit.ly/Z43DTk
The first module I published can be found here: http://bit.ly/YL4eLw
TJ Holowaychuk: Jade Mixins & Includes
The latest release of Jade 0.13.0 adds mixins and includes. Jade users have longed for some method of static include, so it’s (finally) here, and compliments mixins nicely, allowing you to store mixins in one or more separate files.
Mixins
A mixin definition takes the form
mixin <name> [(...
Mixins will save you time.
Every man takes the limits of his own field of vision for the limits of the world.
Node Mongoose attr_accessible - toJSON Blend
Coming from Rails I would like to have the ability to whitelist any attributes that get sent to a user from my node.js server. If you are a rails user you are familiar with attr_accessible where you can set select attributes to be accessible for modification.
I wanted to do something similar where I could also specify select attributes to be public when calling toJSON to spit data back to the user after a request. Because mongoose puts in properties such as “__v” and because I have a bunch of additional book keeping properties I don’t want all the data that gets queried with mongoose to simple be sent to the user.
Looking over the mongoose api one of the first things I noticed was the ability to do a select on a query. You can even specify default properties to be selected in your schema. This sounds great until you begin to realize you don’t want to have to write custom queries all the time. I probably could have looked into this more but I didn’t want to worry about any unintended behavior, like “__v” possibly being returned when I don’t ask for it.
Continuing to look at the mongoose api I came across transform. What transform does when set, is takes a function that will allow the object or JSON object to be modified before it is returned when calling toObject() or toJSON(). I actually took a little while to make this giant method that removes any unwanted properties and even does this nice recursive thing. In each of my schema types I even specified an “isPublic: true” value that was checked before removing the property from the object to be returned. This worked great, only the code started to get rather large for edge cases (such as meta data which has no schematype, as far as I can tell). I also had concerns about rather large objects blocking the event thread. So I scrapped that.
Finally I just said the hell with it and put a toPublic method in each of my models. Each model is responsible for this method and it pretty much just hard codes the object to be produced. To call each toPublic method I used the async.map function. This means that I can pass a property that is of type DocumentArray to the map function and it will asynchronously call the toPublic method on each of the sub documents, and finally adding them to the object to be returned.
Overkill? Maybe, but I have my concerns that if a document is rather large it could block for longer then I would like. To throw some even more possible overkill into the mix I wrapped the map functions in async.parallel. I’m sure DL would give me the “huhm” of disapproval for this, but now any time I add another property that is a DocumentArray I can simply put it’s async map function into the array to be run by async parallel. All of these async parallel functions modify a single object that holds all the properties. I wouldn’t consider this to be “thread safe” for lack of a better term but since I’m really only adding new properties to the new object thats to be returned and not modifying anything, I’m gonna call it “safe enough”.
The code for this is below.
Javascript - Improved For Loop
I’m not exactly sure how much performance gain you will achieve with this (if any) by writing your standard for loop like this:
This post on stack overflow: http://bit.ly/VCYcuN
I guess since you are comparing to 0 and not some other variable this must save on some execution but with optimizations these days, who knows.
JSPerf might be a good place to test this out. http://jsperf.com/faster-loop/22
Placeholdr - Image Placeholders
I’ve been working on a website recently that needs some images that I don’t have yet. In the meantime I found this awesome image placeholder flickholdr.com that uses flickr to provide images based on tags.
Image placeholder sites are nothing new. However, being able to provide images relative to the site’s content might help with development, although I’m not sure how useful it will be from a color/design perspective.
Playing with my new MacBook Air.
Node.js Array Trim Elements
Got really sidetracked today.
So I’m sitting there working on this website and I’ve got this resource in node that can accept arrays from a post sent to the server.
Now I would really like to sanitize all the elements in the array. So I’m looking around and I find this https://github.com/chriso/node-validator and a nice little express.js wrapper for it https://github.com/ctavan/express-validator. Ok. That’s great except it doesn’t have the ability to sanitize an array if one is provided as a param.
https://gist.github.com/4474520
…I keep looking… and I find https://github.com/substack/js-traverse which is great and I could probably use but then I started playing with it:
now it’s like 5am at this point and I’ve been getting all sorts of out of memory errors and this function which seems like it should be super simple to recursively traverse arrays and trim them is starting to get rather complex and rather then do anything sensible like take a break I throw together a bit of code using the async module thinking it will speed things up.
https://gist.github.com/4474548
Anyway this thing tends to throw these out of memory errors too so I’m thinking it might require some kind of stream to parse and fix these things that can get rather large. However, the more I think about it the more I’m realizing I probably won’t ever run into an issue with a size like this, but it’s fun to try to figure it out anyway.
A master in the art of living draws no sharp distinction between his work and his play: his labor and his leisure; his mind and his body; his education and his recreation. He hardly knows which is which. He simply pursues his vision of excellence through whatever he is doing, and leaves others to determine whether he is working or playing. To himself, he always appears to be doing both.
François-René de Chateaubriand (via love4excitement)
L. P. Jacks - Education through Recreation (1932)
A few days ago I spent and afternoon relaxing and playing minecraft. It got me thinking. I began to wonder if anyone had attempted to write the minecraft server in javascript on node.js. After a quick search I found jsmc. Surprisingly, it runs extremely well.
As I played around with it I noticed it was missing a lot of features —ie. dying from falling, dropping blocks after they are broken etc. so I spent a few hours here and there familiarizing myself with the project and added a few new plugins. The code can be found here: github.com/nickpoorman/jsmc.
At first, my thought was I’ll add in damage from falling. That should be easy right? Well… not so much. Turns out there is a lot of variables that go into health and damage. At first glance the formula looks like [damage = number_of_blocks - 3] where number_of_blocks is the height the player fell from. So I thought that’s simple enough, if the player falls from more then 23 blocks they’re dead because they only have a max of 20 health. Then I realized there was no health implemented yet on the server. So I had to implement health. Then I started thinking about what should happen if you are flying and then you fall, and the case if you are in creative mode and/or are invulnerable, and the case if you fall into water (which I think takes into account velocity) and many other things.
One tricky edge case the protocol doesn’t support real well is if a player is swimming and they begin to fall. According to the protocol you are on_ground if you are swimming but it didn’t seem to hold true in practice. So in order determine if a player is swimming I had to find the block type the player is in by loading the chuck and checking the block based on the players x, y, z position.
All in all it looks like minecraft has been designed quite well and since it’s been around for quite some time now, Mojang has added in hordes of features and edge cases that need to be taken into account when developing the server.
One thing is for sure. I definitely had loads of fun working with protocols again.





![A few days ago I spent and afternoon relaxing and playing minecraft. It got me thinking. I began to wonder if anyone had attempted to write the minecraft server in javascript on node.js. After a quick search I found jsmc. Surprisingly, it runs extremely well.
As I played around with it I noticed it was missing a lot of features —ie. dying from falling, dropping blocks after they are broken etc. so I spent a few hours here and there familiarizing myself with the project and added a few new plugins. The code can be found here: github.com/nickpoorman/jsmc.
At first, my thought was I’ll add in damage from falling. That should be easy right? Well… not so much. Turns out there is a lot of variables that go into health and damage. At first glance the formula looks like [damage = number_of_blocks - 3] where number_of_blocks is the height the player fell from. So I thought that’s simple enough, if the player falls from more then 23 blocks they’re dead because they only have a max of 20 health. Then I realized there was no health implemented yet on the server. So I had to implement health. Then I started thinking about what should happen if you are flying and then you fall, and the case if you are in creative mode and/or are invulnerable, and the case if you fall into water (which I think takes into account velocity) and many other things.
One tricky edge case the protocol doesn’t support real well is if a player is swimming and they begin to fall. According to the protocol you are on_ground if you are swimming but it didn’t seem to hold true in practice. So in order determine if a player is swimming I had to find the block type the player is in by loading the chuck and checking the block based on the players x, y, z position.
All in all it looks like minecraft has been designed quite well and since it’s been around for quite some time now, Mojang has added in hordes of features and edge cases that need to be taken into account when developing the server.
One thing is for sure. I definitely had loads of fun working with protocols again.](http://24.media.tumblr.com/7f4f85a1a4548706f130e6eb03919968/tumblr_mg4x2mwRRb1rcjaifo1_1280.png)