最近在看 Interactive Computer Graphics: A Top-Down Approach with WebGL ，里面看到一个很有意思的几何问题，分享一下。

Recently, I'm doing some experiments to try to rewrite our Nodejs service in a more maintainable style. I'd like to write several posts to share my findings.

Last week we try to reproduce an incident in our production system which is caused by an eleviation of HTTPS connection creation rate. The service was flooded by more than 2000 concurrent connections per server at peak.

When writing unit tests, the most ugly & painful & stupid thing you might have to do is to expose some internal implementation of your module to the testing code so that:

• It is easier to enumerate all possible conditional branches to cover some edge cases; (although if you have a complex design, you can always achieve this by mocking things, however sometimes it's an overkill)
• It is possible to inspect side effects of your code; (accept the dark side of the reality, you cannot totally avoid side effects)
• It is easier to replace some dependencies with mocks. (although if you have a good design, you should be able to inject all dependencies, but it's not a common thing in javascript realm)

At Hulu, we use Nodejs to build a proxy or orchestration service to expose APIs to our client applications in order to provide a unified interface (in API schema) which hides the complexity to deal with our versatile backend “micro-services”.

The reason we choose Nodejs over other technologies is that its asynchronized nature perfectly fits the requirements of the service:

• Handling large number of concurrent clients;
• Requesting backend micro-services to get the data, where most of the time is spend on IO;
• Enhancing the backend response with data from other backend micro-services.

This is a typical front-tier API service that has low CPU consumption and high concurrent IO requirement.

However when you deploy the application to production, it is very likely that you would hit CPU bottleneck if you are not careful enough when writing code. Javascript is so flexible that can easily get you trapped into performance problem if you don't understand the execution engine (v8) well enough. Recently, I spent a lot of time doing profiling and investigating the performance issues of our service.

In this post, I'll list some tools and techniques I have used to profile/debug Nodejs program for daily development and production trouble-shooting as a summary of the work I've done.

.gitignore file looks simple. However, if I ask you the question:

What’s the difference between log/* and log/?

I bet most people cannot tell correctly.

I came across this question when I did a .gitignore file clean-up in my project. It took me a while to understand the difference and I find it super easy to be forgotten. After looking up the manual and doing experiments several times, I decide to write this post. Hope it can help those who think about this question as well.

上周碰到一个很有意思的问题，同事找我来跑一个node的程序，结果跑完了最后一个step，但是程序没有退出。

这对刚从同步编程世界转过来的同学来说简直是不可思议的事情。刚开始我也以为是程序的bug，如果不是bug的话有可能是在等待某个callback，但一直没有触发，同事也不明白是为什么，正好我刚入职就让我investigate一下。之前虽然写过一些node的程序，但是都是小打小弄，所以刚开始没什么头绪。