How to debug Node itself
If you wanna dive into Node itself and debug it, you can follow the below steps:
- Download the source code of Node from its Download Page
Extract the package of the source code and go to the root directory of it, then run the following command:
./configure —prefix install/path —gdb (here you should enable the —gdb flag)
make
Go to the out directory and run:
gdb ./Release/node (Important here. You can’t go to Release directory and run gdb ./node, in which, gdb can’t find the source code)
If you wanna run a external node file, you can set args with gdb:
(gdb) set args path/of/node/file.js
Then you can debug node itself using gdb.
That’s all! Pretty simple, right? Enjoy it!
Nproxy: The Mjolnir for UI Developers
As a UI developer for enterprise-level softwares, I have to do a bunch of building tasks everyday:
- update code
- compile Java code
- download/update packages via maven or solve dependency via ivy
- …
- merge/compress static files
- deploy to server
- …
That’s a really crappy thing and costs lots of time, especially with terrible network and building issues. Sometimes, I have to wait for building for a long time and get a “Build Fail” message at last. Then what I can do is to copy the damn error track and sent it to the whole team to ask for help and wait, wait ,wait.
The following chart is the reflection of my work flow:
TimeLine open
+ Computer <------------- Me(UI Develoepr)
| + +
| | |
| v v
| +-------------+ +----------------+
| | update code | | |
| +-------------+ | have a cup of |
| + | coffee |
| | | |
| v | have another |
| +-------------+ | cup of coffee |
| | build task#1| | |
| |-------------| | have lots of |
| | build task#2| | coffee |
| +-------------+ | |
| | ... | | I hate coffee |
| |-------------| | |
| | build task#n| | ... |
| +-------------+ | |
| + | ... |
| | | |
| v | ... |
| +-------------+ | |
| |Build Success| | have ... coffee|
| +-------------+ +----------------+
| +
| |
| v
| +----------------+
| | coding |
| +----------------+
| +
| +----------------+ |
| | ant deploy-js |<----------------+
| +----------------+
| +
| | +----------------+
| +------------------>| coding |
| +----------------+
| +
| +----------------+ |
| | ant deploy-css |<----------------+
| +----------------+
|
|
| ... ...
|
v
Actually, these building tasks are necessary for Back-End Developers but not for UI Developers. What we cares are only three things: HTML, CSS and JavaScript. All of them are dynamic and don’t require most of these building tasks.
As you can see in the chart, everytime I change my code, I have to run deploy task to do something like merging several js files into one, adding i18n messages referred by JavaScript files and deploying it to jboss server, which is the most painful things to me.
What I expect is to change the code, refresh the page and then it comes with all my changes.
Reminded of proxy? Bingo. It is exactly proxy that can save “my life”. I can replace files from server requested by browser with local ones. So, I start finding proxy softwares which meet my requirement. Here lists my basic requirement:
- Support Mac, Linux and Windows: Mac is mandatory. I work on it. Windows is recommended, for I’ll debug some issues in IE. If Mac and Windows are supported, why just leaving Linux alone?
- Support replacing single file(html,css,js,images)
- Support replacing combo files with separated source files: Most JavaScript and CSS files will be merged and compressed in production, which makes it hard to debug.Proxy should replace merged file with its source files(local files)
There are four proxy softwares caught my eyes: Fiddler, Charles, Rythem and Tinyproxy. I compared them according to my requirements:
+---+---------+---------+---------+-----------+
| R | Fiddler | Charles | Rythem | TinyProxy |
|---------------------------------------------|
| A | Win | Y | Mac&Win | Mac&Linux |
|---------------------------------------------|
| B | Y | Y | Y | N |
|---------------------------------------------|
| C | N | N | Y/N | N |
+---------------------------------------------+
A: Support Mac, Linux and Windows
B: Support single file prelacing
C: Support combo file replacing
Y: Yes
N: No
Y/N: Not fully supported
- Rythem is developed with Qt, it should have supported Linux, but I find it is hard to install in Linux. It provides installer for Mac and Windows only.
- Rythem supports group replacing but not any files from different directories.
Though these proxies have such drawbacks as listed in the above table, each one has its own advantage. For instance, Fiddler is a really great tool to inspect http/https request, it does good in listing request line and inspecting request header and body.
As shown in the above table, combo file replacing are all not support. In practice, this functionality is really useful to debug in the production. This is the reason why I wanna introduce Nproxy here.
Nproxy is a cli proxy tool specialized in file replacing supporting both single file and combo file. And of course it meets all of my requirements. And it’ll support plugins for some special cases.
More details informations about how to use Nproxy can be found there.
Nproxy is just like a Mjolnir to me and Using nproxy improves my work efficiency to a large extent.
TimeLine open
+ Computer <------------- Me(UI Develoepr)
| + +
| | |
| v v
| +--------------------------+ +-------------------+
| | update code if necessary | | have a cup of tea |
| +--------------------------+ +-------------------+
| + +
| | |
| v v
| +--------------------------+ +-------------------+
| | build task if necessary | | have a cup of tea |
| +--------------------------+ +-------------------+
| +
| |
| v
| +--------------------------+
| | replacing file via nproxy|
| +--------------------------+
| + +-------------------+
| +------------------> | coding |
| +-------------------+
| +
| |
| v
| +-------------------+
| | coding |
| +-------------------+
| +
| |
| v
| +-------------------+
| | focus on coding |
| +-------------------+
|
v
As you can see from the above chart, there is no need to deploy during the development. And I don’t need to update code and build tasks until other colleagues change some code my code depends on. Cool, right!
Last but not least, Nproxy is open sourced. Any contributions and suggestions are all welcomed!
How to detect the charset of the page
It is the precondition for a web page crawler program to parse the fetched content that it have to detect the charset of the page(Especially when it has some non-ASCII characters like Chinese and Japanses).
But how on earth to do this detection? Let’s take a look at the corresponding specification from W3C:
- An HTTP “charset” parameter in a “Content-Type” field
- A META declaration with “http-equiv” set to “Content-Type” and a value set for “charset”
- The charset attribute set on an element that designates an external resource
The above describes the priority of the ways to detect the charset of a page: Http “Content-Type” Field > META declaration > Charset Attribute(such as the link tag and script tag) > ISO-8859-1(which is the default charset)
As it is in the W3C specification, which it to say, the standard browsers do this job in this way, too.
Debug Node Applications with Node-Inspector
In the progress of software development, we spend more time debugging than coding.
So, to some extent, more easier the way we debug in, more efficiently we develop our applications.
Accordingly, when developing the applications with node, we also wanna find an elegant way to debug it. Commonly, we can debug node apps with the console object which exposes several methods used to put some log in the console, which more or less takes some effects. This is maybe enough for some small applications but not qualified for large scale applications definitly. Because this way is neither directviewing nor convenient.
joyent suggests using eclipse as a node debugger. Java programmers using eclipse as the development IDE are familiar with this way of debugging. On the one side eclipse has a debug view in which you can set breakpoints, look into the status of variables in the runtime and even control the execution flow step by step. This is very powerful. And on the other side, joyent’s debugging way is to communite with the node app via its remote debug port(default debug port of node is 5858 ) and make the debug possible, which is the same way as debugging remote Java programs.
Here I will introduce another debug tool for node named node-inspector. It uses the same way to enable the debug work that it listens the node debug port via socket.io and uses the browsers’ developer tool to debug the node applications.
The following is the brief tutorial of using node-inspector:
- Prepare a test node application(we can just pick up the example from joyent):
// dbgtest.js
var sys=require('sys');
var count = 0;
sys.debug("Starting ...");
function timer_tick() {
count = count+1;
sys.debug("Tick count: " + count);
if (count === 10) {
count += 1000;
sys.debug("Set break here");
}
setTimeout(timer_tick, 1000);
}
timer_tick();- Start this node application in debug mode:
- node —debug[=port] dbgtest.js (default port is 5858)
- node —debug-brk[=port] dbgtest.js(default port is 5858. And this way will force the application to stop at the first line)
Here we use second way(—debug-brk). Because we can even know how node internally works when running our applications via this way.
When you see this log displayed in the console, it means node runs your code in a debug mode and has stopped your application at the first line:
debugger listening on port 5858- Start node-inspector:
Simply run this command: node-inspector in the console, and it works if such log is shown:
info - socket.io started
visit http://0.0.0.0:8080/debug?port=5858 to start debugging- Use browser developer tool to debug the node application(Here we use chrome’s developer tool):
Creat a new tab or window, and type http://localhost:8080/debug?port=5858, then you can see a familiar debug view which is same as it we have to debug front-end JavaScript code:
Now, the code has stopped at the first line. And I think there is no need to tell you how to debug it via developer tool. You are must very good at it. Right?!
Enjoy it!
Rise of Node - Part I
A brief introduction about node which probably fit best for node beginners.
F2E 