由于手头有些港股的股票需要出掉，但自己又总是不记得去看行情，于是就想着写个爬虫每天把股价推到手机或者邮箱中去。
在网上查了一下新浪财经就有现成的股票查询接口（"http://hq.sinajs.cn/list="），后面附加上逗号分隔的股票代码就可以得到相应的个股行情。由于相关的介绍在网上已经很多，具体细节不再赘述。
但是我发现对于返回的记录结构，绝大部分相关的资料都与现在实际情况有出入。因此我索性根据相对靠谱点的资料以及实际数据分析了沪深股市股票以及港股查询返回的结构，记录在这里。
| 字段索引 | 字段名称 | 数据示例 | 字段说明 |
|---|---|---|---|
| 0 | 股票简称 | 平安银行 | |
| 1 | 今日开盘价 | 9.500 | |
| 2 | 昨日收盘价 | 9.520 | |
| 3 | 最近成交价 | 9.720 | |
| 4 | 最高成交价 | 9.750 | |
| 5 | 最低成交价 | 9.480 | |
| 6 | 买入价 | 9.710 | |
| 7 | 卖出价 ... |
最近两天在家折腾自己机器，解决了几个小问题。解决的问题个人觉得有些用处，而且看了看网上似乎没有什么相关的资料提到，就合在一起说一下。
tmux有个很有用的功能，就是可以帮助用户监控某个窗口的活动或静止状态。简单解释就是用户在tmux中的某个窗口执行一个长时间运行的命令（比如make）后，可以要求tmux监控该窗口然后切到其它窗口去工作；到该窗口的输出状态改变时，tmux会在它的状态栏显示提示信息或者以蜂鸣声提醒用户，用户就可以切回该窗口继续下一步工作了。
前面所说的窗口及状态栏都是tmux中的概念而非窗口管理器中的概念。换句话说，当我在rxvt中使用tmux时，提示信息只能在rxvt中显示，正在使用浏览器的用户是注意不到提示的；蜂鸣声也不适合在公共场合使用，这迫使用户仍然要时不时的自行切回tmux窗口检查状态。
需要补充说明一下的是tmux中窗口的状态改变是由窗口是否产生新输出来判定的。即窗口放置一段时间后产生了新输出即为静止（silence）状态变为活动（activity）状态，持续产生输出的窗口一定时间内不再产生输出了即为活动状态变为静止状态。
对此我希望能配置tmux使用notify-send来发送通知。目标是让tmux在其状态栏显示提示的同时，X桌面会弹出桌面通知我哪个tmux任务的哪一个窗口有了新输出或停止了输出。
很少有人提到的是，tmux提供了针对少量内部事件的hook机制，其配置语法为:
set-hook [-g] [-t target-session] hook-name command
支持的事件类型只有几种：
因为著名的GIL问题，Python提供了一个标准库multiprocessing，并建议用它编写多进程并发程序，以解决CPU密集型程序的运行效率问题。这个库内部主要是在处理各种跨平台问题，使用起来比较繁琐。不过其中提供了一个进程池的实现，善加利用的话倒是能满足许多场景的需求。
虽然自Python 3.2起又有一个concurrent库实现了进程/线程池并提供了更简便的接口，但从几个角度来讲我更倾向于使用multiprocessing的进程池：
关于multiprocessing.Pool的使用介绍目前已经遍地都是，我就来对它的内部机制做一点简单的分析。
以下分析均基于Python 3.5.1的源码。
所有多进程协作的程序都会涉及进程间的通信问题，因此在谈论进程池的设计前，关于进程间通信的限制就不可不知。
与多线程模型相比，由于每个进程的地址空间是独立的，因此进程间传递数据就必须依托于操作系统提供的机制。这些机制可能是共享内存/消息队列/信号量或Domain socket等 ...
Contents
最近正在琢磨解决做图太费劲的问题，因此开始玩起了graphviz。但是偏偏这些天graphviz的官网动不动就打不开，没法看在线文档，耽误了不少事。所以一气之下就把这篇类似总纲的文档翻译了过来放在自己的地盘上。总体感觉看懂这篇文档再参考网上现有的中文教程已经可以解决90%以上的graphviz做图问题了，所缺失的只是支持的属性及其取值列表（将来有需要或有时间也许会译）而已。
原文中粗体字显示的词（作为keyword）都保留为英文，另外edge的含义因为与中文的"边"相差甚大也全部保留为英文单词。此外由于水平所限，有些不理解或吃不准的内容保留未译或附上了原文，以供核对。
下面是DOT语言的抽象语法定义。Terminals（译者：分界词？）显示为粗体，nonterminals显示为斜体。字面上的字符包含在单引号中，圆括号 ( 及 ) 表示分组。方括号 [ 和 ] 包围可选的元素。管道符 ...
自Docker诞生之初，就采用了aufs做为唯一的存储驱动。但因为aufs一直没有进入内核主线，所以各大发行版只有Ubuntu默认包含了aufs支持，这让Docker某种程度上成了专用于Ubuntu的容器技术。
直到后来红帽工程师为其实现了devicemapper存储驱动，其它发行版上使用Docker的技术门槛才低了许多。但是受内核的devicemapper机制的限制，Docker的devicemapper驱动在性能和资源消耗上相比aufs驱动都仍有差距。
直到内核版本3.18，另一个unionfs文件系统实现overlayfs并入了内核主线。而Docker（自1.4.0版本开始）在很短的时间内就提供了对overlayfs存储驱动的试验性支持。从此在各大发行版上使用unionfs做为Docker的存储驱动才成为了可能。
而我本人由于Docker+devicemapper驱动在使用中的种种问题，当然是盼望着尽快试用Docker的overlayfs驱动。
国内下载官方镜像太过费劲，因此在环境更新前要首先将已有的镜像导出。导出使用save命令：
$ docker save -o /media/Storage/dockers/centos.tar centos:centos6
$ docker save -o /media/Storage/dockers/debian ...Contents
话说上次利用Docker建立Oracle测试环境之后，环境创建和销毁都成了很轻松的事情，我似乎从此过上了幸福快乐的日子。无奈美梦从来最易醒，在这段时间的使用过程中，理想与现实的差距却逐步暴露了出来。其中一些问题甚至直接影响到Docker的可用性，让人实在不吐不快。
吐槽之前得说明一下我对Docker的使用方式。先看一眼Docker的服务启动文件：
# cat /lib/systemd/system/docker.service
[Unit]
Description=Docker Application Container Engine
Documentation=http://docs.docker.com
After=network.target docker.socket
Requires=docker.socket
[Service]
ExecStart=/usr/bin/docker -d -H ...前一阵子，有个朋友在某客户现场的性能测试中指标一直压不上去，所以找我去从应用和中间件角度做了一次诊断。最近消息传来，他们经过不断的排查后，最终找到了罪魁祸首，正与我判断的方向相符。这次案例的最终结果和中间的诊断过程都有一定的特点，值得说道一下。
首先得介绍一下整件事情的背景和性能测试整体的环境。
事情的起因是我那位朋友（为了方便，我在下面把前面提到的那位朋友就简称为L），L供职的H公司有个客户正在规划将一套OLTP系统从大型机迁移到开放平台来的方案。于是该客户挑了几支核心业务交易，找来了中外好几家公司来分头做迁移并进行性能测试，客户根据测试的结果决定跟谁合作以及最终的迁移方案。跟大型机有关的事情从来不是小单，H公司为此调来了在欧洲专做COBOL代码迁移的小组，这个小组使用工具将应用代码迁移到了Linux平台，中间件则采用了Tuxedo，客户端与Tuxedo的通信是采用阻塞方式的tpcall。
必须要说明的一点是由于只能使用该客户指定的机器接入测试网络，唯一能将信息存入个人设备的方式就是给屏幕拍照。因此下面的描述主要是根据我的记忆整理，所有命令输入我能写出来，但输出就无法复制了。这种条件下细节与事实难免会有些出入，但我会尽力保证整体的描述的准确性。
迁移后的系统部署上采用的是银行业常用的三层架构：客户端、应用服务器、数据库服务器。其软件环境大致如下：
| 层 | 基础软件 |
|---|---|
| 客户端 | Windows/LoadRunner ... |
Contents
最近一直在研究Docker，尝试拿它做一些小型的开发试验环境，确实是相当好用。
某日突发奇想，打算将我的Oracle实验环境迁到Docker中来。虽然最终得到的镜像有点头重脚轻，不太符合Docker推荐的使用方式，但相比虚拟机好歹也节省了些开销。
实验过程中各种方式折腾了好几轮，感觉都不太完美。先将过程做个记录，期望将来能找到更好的办法。
我的笔记本本地硬盘是128G的SSD，所以实验过程中使用了外置硬盘做存储，好在是USB3.0连接。另外，基本的软件版本信息如下：
OS: Arch Linux (内核3.16.4-1)64位 Docker: 1:1.3.0-1 容器OS: CentOS 6 ...