1. 首先要有GOHOME—GOHOME是一个环境变量，用来指定一个路径存放所有的源代码和一些lib。

2. 所有代码需要放在$GOHOME/src/路径下（比如$GOHOME/src/YOUR_PROJECT），然后才能使用go build等命令。

3. 其次要设GOPATH—它也是一个环境变量，用于指定一个路径存放go get命令下载的第三方库。

4. go get — 可以直接把远程托管的代码下载到$GOPATH/src/路径下。

5. 可以使用govendor来获取项目所需的依赖包 – 类似于Python的pip。项目的依赖项可以统一写在一个文件里，然后用一个shell脚本来govendor所有的依赖包。

6. go现在支持跨平台编译（比如说我在mac OS上编译的代码可以放在Windows上跑），做起来也非常简单，在go build之前加上一些平台的信息：

   CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build …
   

   其中GOOS可以填windows或linux，GOARCH可以填amd64或386或arm（分别对应64为架构，32位架构和安卓）。

7. 要debug Go的话，官方提供了一个tool，叫做GDB。想要用IDE来debug的话，目前还没有哪个特别牛X的，我试用了下Pycharm的Go语言插件来debug，目前还不是特别完善。

I encountered these problems when I try to use Mesos to run my Python scripts as tasks. I found some tasks cannot finish as expect although the main process/thread is terminated.

Problem 1

See code first:

import multiprocessing
import time


def hang():
    while True:
        print 'hanging..'
        time.sleep(10)


def main():
    p = multiprocessing.Process(target=hang)
    p.start()
    time.sleep(10)
    print 'main process exiting..'


if __name__ == '__main__':
    main()

Run the above code by python myscript.py, and we can see the output result is:

hanging..
hanging..
main process exiting..
hanging..
hanging..
hanging..

From the result, we may find the finish of main process will not terminate its subprocesses. And the commandline is blocking until we press ctrl-c.

Why I need to use PDB to debug Python script

现在各种强大的Python IDE都已经很好地实现了debug的功能，那么我们为啥还需要这样一种命令行的工具来进行debug呢。

这是个好问题，因为我也一直是用Pycharm来调试Python脚本的，感觉也非常方便好用。直到最近，在部署一个服务器应用的时候出现了问题，这个问题在本地无法重现。当然，我首先想到的是使用Remote Debugging来进行调试（参见Remote debugging with Pycharm），毕竟比较熟悉了。然而Remote Debugging有以下问题是比较麻烦的：

• 本地环境和远程环境不一致（包括操作系统、Python编译器版本、Python package版本等）
• 一旦远程或本地的代码有所改动，会影响debug的断点位置
• 需要的配置有些小复杂（比如要配置本地和远程的代码路径的mapping）

因此，在遇到上述问题时（尤其是环境不一致的问题），登陆到远程机器使用PDB来debug是一个不错的选择。

简单的说，PDB有如下优势：

• 不需要安装，源自Python标准库
• 纯命令行操作（这点在没有可视界面的操作系统上非常重要）
• 非常容易上手（虽然相比IDE debug起来不那么直观）

定义

对于一个给定的显示器而言，PX, PT衡量的是绝对大小（static measurements），而%, EM和REM衡量的都是相对大小（relative measurements），其中前两者都是相对于父元素（parent element）中定义的尺寸的相对大小，而REM是相对于根元素（root element）中定义的尺寸的相对大小。（所以说，根元素总是要定义一个绝对大小，这样其他元素才能根据它把相对大小转换成绝对大小。）

而对于不同分辨率(准确说是不同dpi)的显示器而言，上述的绝对大小也变成了相对大小了:

the CSS px unit does not equal one physical display pixel. This has always been true – even in the 1996 CSS 1 spec.

CSS defines the reference pixel, which measures the size of a pixel on a 96 dpi display. On a display that has a dpi substantially different than 96dpi (like Retina displays), the user agent rescales the px unit so that its size matches that of a reference pixel. In other words, this rescaling is exactly why 1 CSS pixel equals 2 physical Retina display pixels.

Problem

由于Jekyll使用了liquid模板语言来编译生成每个静态页面，这个编译转换的范围也包括了所有的markdown文件（因为每个markdown写的blog要先转换成html才能在网页展示嘛），所以如果我们在markdown文件里面如果包含了liquid的语法，编译时是会出问题的。

比如如标题所言，{% variable %}这样的双花括号是liquid的语法，不能在markdown里面直接这样写的。

Solutions

基本上是两种思路吧，一种是通过hack Jekyll的编译函数，使得Jekyll对特定的内容不进行liquid语言的编译，而直接展示raw content；另外一种则是利用了liquid语言的特性来work around。

这里主要说第二种解决方法，因为依靠monkey patch来解决第三方库的问题非常依赖于第三方库（这里就是Jekyll）的稳定性，假如第三方库升到新的版本后改动比较大，那monkey patch可能就失效了，维护起来会很麻烦。

Solution 1

使用liquid中的tag：{% raw %} 和 {% endraw %}，把不需要liquid语法编译的部分放在两者之间即可：

{% raw %}

​ {{ variable }}

{% endraw %}

Solution 2

利用一些escape字符的技巧，可以用{{ “{% variable “ }}%}来展示{% variable %}，用{{ “{{ variable “ }}}}来展示{{ variable }}。