After watching the video, I found glass behaves a little bit different to my previously understanding, it is could be a disadvantage of Google Glass, and will hurt the experience a lot!
Current design of the display on the Glass is to project the digital image on your right eye from a very close distance, which works like you have a transparent display near you right eye. Since the display it so close to you eye, so the digital image will fall out of focus when you are looking around. When you really want to read something from the Glass, you need to ask your eye to focus on the image, on that time, the world around falls out of your focus!
According to the video, what Google is purchasing is a technology that can interact with user without any distraction, reads, bring the user out of the world. In this point of view, Google Glass is huge improvement comparing to classic digital devices, but is still not perfect!
From the distraction view, this little disadvantage isn’t really hurt the experience of Google Glass, if you feel happy that moving your eyeball on the top right of your view very often. But form enhanced reality point of view, it is a breaking blocker!
The most basic requirement of Enhanced Reality is to overlap the digital image contains descriptive information on the optical view of real world. But for Google Glass, it doesn’t provide a way for people to see the digital view and real world, but it is not simultaneously! Because you cannot see the digital view and surrounding world clearly simultaneously, then it is impossible for Google Glass to overlap the digital image over the optical image.
That’s what I means that Google Glass isn’t really an Enhanced Reality Device as a lot of people imagined and expected!
Here are 2 images that explain the idea:
View when you look around The view around is clear, but the map is blur
View when you read Glass The map become clear, but the view around is blur
To solve this problem, it requires device to detect the focus point of human eye, then adjust the image accordingly in real time. But still now, we don’t have mature technology that can detect the eye focus point and compact enough to built into a wearable device.
But any way, I still believe that Google Glass is an exciting milestone of purchasing real Enhanced Reality technology in human history! It must evolve and incubate a lot of future technologies!
Javascript is famous for its lack of preciseness, so it always surprises and make joke with the developers by breaking the common sense or instinct.
Javascript doesn’t provide integer type, but in daily life, integer sometimes is necessary, then how can we convert a trim a float number into integer in Javascript? Some very common answers might be Math.floor, Math.round or even parseInt. But besides calling Math functions, is there any other answer?
The answer is bitwise operations. Amazing? Yes. Because bitwise operations are usually only applied to integers, so Javascript will try to convert the number into "integer" internally when a bitwise operation is applied, even it is still represented in type of number
Suppose value = 3.1415926, and we want integer is the trimmed value of value, then we can have:
Trim Float Number
1
2
3
4
5
6
7
8
9
10
11
12
var value = 3.1415926;
var integer = Math.floor(value);
integer = Math.round(value);
integer = parseInt(value);
integer = ~~value; // Bitwise NOT
integer = value | 0; // Bitwise OR
integer = value << 0; // Left Shift
integer = value >> 0; // Sign-propagating Right Shift
integer = value >>> 0; // Zero-fill Right Shift
For more detail information about bitwise operation in javascript, please check out the MDN document
All approaches listed before are working, but with different performance. And according to the result from JsPerf, I sort the algorithms by performance from good to bad:
integer = ~~value;
integer = value >>> 0; and integer = value << 0;
integer = Math.floor(value);
integer = value >> 0;
integer = value | 0;
integer = Math.round(value);
integer = parseInt(value);
NOTE: The test cases are running in Chrome 24.0.1312.57 on Mac OS X 10.8.2
Application is usually required to run in different environments. To manage the differences between the environments, we usually introduce the concept of Environment Specific Configuration. In Rails application, by default, Rails have provided 3 different environments, they are the well known, development, test and production. And we can use the environment variable RAILS_ENV to tell Rails which environment to be loaded, if the RAILS_ENV is not provided, Rails will load the app in development env by default.
This approach is very convenient, so we want to apply it to anywhere. But in node.js, Express doesn’t provide any configuration management. So we need to built the feature by ourselves.
The environment management usually provide the following functionalities:
Allow us to provide some configuration values as the default, which will be loaded in all environments, usually we call it common.
Specific configuration will be loaded according to the environment variable, and will override some values in the common if necessary.
Rails uses YAML to hold these configurations, which is concise but powerful enough for this purpose. And YAML provided inheritance mechanism by default, so you can reduce the duplication by using inheritance.
In express and node.js, if we follow the same approach, comparing to YAML, we prefer JSON, which is supported natively by Javascript. But to me, JSON isn’t the best option, there are some disadvantages of JSON:
JSON Syntax is not concise enough
Matching the brackets and appending commas to the line end are distractions
Lack of flexility
As an answer to these issues, I chose coffee-script instead of JSON. Coffee is concise. And similar to YAML, coffee uses indention to indicate the nested level. And coffee is executable, which provides a lot of flexibilities to the configuration. So we can implement a Domain Specific Language form
To do it, we need to solve 4 problems:
Allow dev to declare default configuration.
Load specific configuration besides of default one.
Specific configuration can overrides the values in the default one.
Code is concise, clean and reading-friendly.
Inspired by the YAML solution, I work out my first solution:
YAML is data centric language, so its inheritance is more like “mixin” another piece of data. So I uses underscore to help me to mixin the specific configuration over the default one, which overrides the overlapped values.
But if we jump out of the YAML’s box, let us think about the Javascript itself, Javascript is a prototype language, which means it had already provide an overriding mechanism natively. Each object inherits and overrides the value from its prototype. So I worked out the 2nd solution:
This approach works, but looks kind of ugly. Since we’re using coffee, which provides the syntax sugar for class and class inheritance. So we have the 3rd version:
module.exports = new Config[process.env.NODE_ENV]()
Now the code looks clean, and we can improve it a step further if necessary. We can try to separate the configurations into files, and required by the file name:
