Guys from Willow Garage used a hacked Kinect 3D controller for its robotics projects. As you can see from the video, with a bit of cailbration, now you’d be able to control your robot with Kinect. This technology might be used as well for simplifying human-robot interaction.
Javascript is all about objects and OOP concepts, however people still prefer to write it in a functional way leaving context and grouping features.
Quiet often people get this silly error, that really drives people crazy:
“Expected identifier” from IE, I’ve mentioned few times in my twitter, is something to keep JavaScript programmer on guard.
No matter if you used words “class”, “default” in your JSON object or elsewhere, IE will start to swear immediately about this error.
So, don’t forget the list of reserved words of JavaScript:
But that’s not the way he learned either. He said a lot of really great things and inspirational things, but he’s not always right. Neither am I,
but my take on it is this: Take a scientist in any field. The scientist gets older and says, “Oh, yes, some of the things that I’ve been doing have a really
great payoff and other things, I’m not using anymore. I’m not going to have my students waste time on the stuff that doesn’t make giant steps. I’m not
going to talk about low-level stuff at all. These theoretical concepts are really so powerful—that’s the whole story. Forget about how I got to this
point.”
Great book, interesting inspirational articles.
A “closure” is an expression (typically a function) that can have free variables together with an environment that binds those variables (that “closes” the expression).
It really has some beauty in it. A good part of closures is of course the variable scoping, that gives developers a way of not keeping lots of variables in the global scope.
A simple example of a Javascript closure:
function add(n) {
return function( addNum ) {
return n + addNum
};
}
var four = add(4);
alert(four(5) == 9);
Useful links on JavaScript closures:
A short memo for JS operators, that I keep forgetting:
A common mistake that developers are susceptible to is the lack of understanding of false values in JavaScript. In JavaScript, null, 0, ‘’, false, and undefined are all equal (==) to each other, since they all evaluate to false. This means that if you use the code test == false, it will evaluate true if test is also undefined or equal to null, which may not be what you want. This is where !== and === become useful. Both of these operators look at the explicit value of the variable (such as null), not just what it is equivalent to (such as false). JSLint requires that anytime you use != or == against a falselike value, you must use !== or === instead. (c) Pro Javascript Techniques
Sample:
// Both of these are true null == false 0 == undefined // You should use !== or === instead null !== false false === false
Finally, I’ve managed to get some code to public repos!
Never thought that it would be javascript, that i hated with all my heart a month ago. However, recently, I’ve stumbled upon a massive rework of Javascript on some of the projects, that made me change my mind on the subject.
Javascript is awesome! Javascript API for Google Maps is uber-awesome! First appearance for my code would be DistanceControl class that is used for Google Maps(v2).
Hopefully, there’d be more on Javascript and other stuff, but currently i’m burried under a pile of JS work, so expect more on Client-Side scripts, and a massive upgrade of it to Google Maps(v3).
For almost a week, I’ve been moving big chunks of code (didn’t have time for posting) of Javascript related to Google Maps and Dom manipulation of our project. The more I dive into JS, the more I like it, unfortunately, there’re no much information on OOP development on it.
The recent thing I had to do was to move tons of JS logic under the class scope (both literal notation, and JS Prototype classes).
//creating a basic class
MyClass = function() {};
//constructor
MyClass.prototype.initialize = function() {
this.self = this;
this.myVars = {};
};
MyClass.prototype.createSomeDomObjects = function() {
var self = this.self; //copying the initial object of MyClass
var myDomObject = document.createElement('select'); //creating basic select box
myDomObject.onchange = function() { self.test(); };
};
MyClass.prototype.test = function() {
console.log('test'); //alert('test') for IE-users, as console.log doesn't work in it.
};
Hopefully, it’ll be useful for folks playing around with Javascript.
Enjoy! 
Many JavaScript implementations do not warn against questionable coding practices. Yes, that’s nice for the site that “works best with Internet Explorer” (designed with templates, scripted with snippets copied from forums). But it’s a nightmare when you actually want to write quality, maintainable code.
That’s where JavaScript Lint comes in. With JavaScript Lint, you can check all your JavaScript source code for common mistakes without actually running the script or opening the web page.
For Fedora users:
sudo yum install -y jsl
Giving a test object for Javascript, assume ~/test.js:
var Test = {
version : 1.0,
another_var : {
one: "1",
two: "2",
},
};
Run from your terminal:
jsl -process ~/test.js
and get your mistakes shown.
Main packages to download:
sudo yum install -y mongodb-devel mongodb-server mongodb boost boost-*
service mongod start
In Fedora repos, MongoDB driver goes in mongodb-devel rpm.
Comparing the cookbook of MongoDB. Here’s a slightly updated c++ script to test connection to the database (mongo_test.cpp):
#include <iostream>
#include "mongo/client/dbclient.h" // since the dbclient is in /usr/include/mongo/ directory
using namespace mongo;
void run() {
DBClientConnection c;
c.connect("localhost");
}
int main() {
try {
run();
cout << "connected ok" << endl;
} catch( DBException &e ) {
cout << "caught " << e.what() << endl;
}
return 0;
}
To compile, run:
g++ mongo_test.cpp -lmongoclient -lboost_thread-mt -lboost_filesystem -lboost_system -lboost_program_options -o mongo_test