[{"data":1,"prerenderedAt":314},["ShallowReactive",2],{"page-7":3},{"title":4,"articles":5,"hot_article":103,"month_arch":162,"total":310,"cover":311},"第7页 - 独孤影的博客",[6,16,25,35,45,55,64,74,84,93],{"id":7,"title":8,"uri":8,"author":9,"tags":10,"created_at":13,"view_count":14,"content":15},54,"linux打开文件数太多","duguying",[11,12],"linux","打开文件数","2017-04-28 17:36:42",3116,"\u003Cp>今天dus服务并发量稍高，然后程序内部不停地报错&nbsp;too many open files ，linux 系统对打开文件数是有限制的。介绍这个的文章很多。查看服务器上系统设置的最大限制，运维设置的是 102400，列出所有进程的打开文件数目&nbsp;\u003Cspan style=\"color: rgb(44, 44, 44); font-family: Arial; font-size: 14px; background-color: rgb(255, 255, 255);\">lsof -n|awk &#39;{print $2}&#39;|sort|uniq -c |sort -nr|more ，服务程序打开文件数最大时也才1w多，所有进程打开文件最大值加起来也才五六万，远远没有达到 102400，一直不解为何报这个错误，最后查看程序进程的限制 cat \u002Fproc\u002F32523\u002Flimits ，发现限定值居然是 1024\u003C\u002Fspan>\u003C\u002Fp>\u003Cpre class=\"brush:plain;toolbar:false\">Limit&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Soft&nbsp;Limit&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Hard&nbsp;Limit&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Units&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\nMax&nbsp;cpu&nbsp;time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unlimited&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unlimited&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;seconds&nbsp;&nbsp;&nbsp;\nMax&nbsp;file&nbsp;size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unlimited&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unlimited&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;bytes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\nMax&nbsp;data&nbsp;size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unlimited&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unlimited&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;bytes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\nMax&nbsp;stack&nbsp;size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8388608&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unlimited&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;bytes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\nMax&nbsp;core&nbsp;file&nbsp;size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unlimited&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;bytes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\nMax&nbsp;resident&nbsp;set&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unlimited&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unlimited&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;bytes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\nMax&nbsp;processes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;31170&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;31170&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;processes&nbsp;\nMax&nbsp;open&nbsp;files&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1024&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4096&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;files&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\nMax&nbsp;locked&nbsp;memory&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;65536&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;65536&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;bytes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\nMax&nbsp;address&nbsp;space&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unlimited&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unlimited&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;bytes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\nMax&nbsp;file&nbsp;locks&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unlimited&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unlimited&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;locks&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\nMax&nbsp;pending&nbsp;signals&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;31170&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;31170&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;signals&nbsp;&nbsp;&nbsp;\nMax&nbsp;msgqueue&nbsp;size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;819200&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;819200&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;bytes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\nMax&nbsp;nice&nbsp;priority&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\nMax&nbsp;realtime&nbsp;priority&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\nMax&nbsp;realtime&nbsp;timeout&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unlimited&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unlimited&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;us\u003C\u002Fpre>\u003Cp>\u003Cspan style=\"color: rgb(44, 44, 44); font-family: Arial; font-size: 14px; background-color: rgb(255, 255, 255);\">\u003C\u002Fspan>服务是通过 systemd 启动的，原来在 service 中有个设置项可以设置程序能打开的最大文件数，可是我的 service 文件中没有设置，于是默认限定为 1024，很容易就超了。修改添加配置项\u003C\u002Fp>\u003Cpre class=\"brush:plain;toolbar:false\">[Service]\nLimitCORE=infinity\nLimitNOFILE=102400\nLimitNPROC=102400\u003C\u002Fpre>\u003Cp>\u003Cspan style=\"color: rgb(44, 44, 44); font-family: Arial; font-size: 14px; background-color: rgb(255, 255, 255);\">重启服务，再次查看&nbsp;\u003Cspan style=\"color: rgb(44, 44, 44); font-family: Arial; font-size: 14px; background-color: rgb(255, 255, 255);\">cat \u002Fproc\u002F\u003C\u002Fspan>\u003Cspan style=\"color: rgb(44, 44, 44); font-family: Arial; font-size: 14px; background-color: rgb(255, 255, 255);\">32523\u002Flimits ，Max open files 成功变为 102400，再也没有报这个错，解决。\u003C\u002Fspan>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp>\u003Cbr\u002F>\u003C\u002Fp>",{"id":17,"title":18,"uri":18,"author":9,"tags":19,"created_at":22,"view_count":23,"content":24},52,"2016阶段总结",[20,21],"工作","总结","2016-11-25 23:55:17",4377,"\u003Cp>随着时间的推移，我的上一份工作已经告一段落，今后的一段时间离我将会作为Golang软件工程师而存在，而不是现在的Java程序员。\u003C\u002Fp>\u003Cp>\u003Cstrong>关于语言\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>我由初入职场时的Java语言开发到现在的转向Golang开发，这并不意味着我觉得Golang比Java好，只是单纯的改变了一下技术方向而已。对于编程语言，我并不像大多数人那样有固定的偏好，而且部分人在语言之争上比较偏激；对于我来说我接触过的所有的编程语言我都喜欢，同时，我也不像大多数人那样只会一门编程语言，比如Java或PHP，在某些技术社区上Java开发者与PHP开发者总是为了诸如“谁是最好的编程语言”这一议题争得不可开交。\u003C\u002Fp>\u003Cp>从我接触编程到现在先后接触了一些语言，最早在高中的时候是Visual Basic，后来进入大学了正式学习编程了，在大一上学期自学入门的语言是JavaScript，因为我在高中时候就有一个建网站的梦想，所以了解前端技术栈相对于我的同学要早，因此我进入大学的时候就知道了JavaScript在前端技术中的地位。大一下学期大学课程开始学习C++了，与此同时我开始自学PHP，开始了解并使用MySQL数据库，也是此时我正式开始理解“面向对象”这一概念，后来大二学校课程学习了C#这门语言，同时这一年我在学校学生组织里面开始为学校建设网站，用的是PHP语言，MySQL数据库以及Linux服务器，对Linux服务器的了解也是从此时开始的。用PHP写网站大概写了一年多的时间，期间由于我对前端非常了解，那时的我算是个比较菜的全栈工程师了。大二是疯狂的一年，每天晚上至少凌晨2点才睡觉，因此导致一些课程挂科了，大三是反省的一年。同时大三也是技术沉淀的一年，大三我开始重新学习C语言，这回是认认真真的学习，在解决了一个个的内存错误（segment fault）之后，对编程有了新的理解，对于内存，指针，文件，网络这些东西有了进一步的了解。那一年我开始写了一些小项目以及pinyin-php，同时学习了Golang，当时我觉得Golang太好学了，从完全不了解Golang到用Golang的Beego框架写出一个博客系统只用了两周时间，或许是因为之前在学C语言，初学Golang感觉自己如同解放了一般。\u003C\u002Fp>\u003Cp>总之，我对任何语言都是一视同仁，我并没有觉得Java不好，相反，我觉得Java是各方面都比较完备的一门语言。而且，就我目前来看，我更想了解的是语言的本身，因此我将编译原理作为我之后要研究的领域之一。\u003C\u002Fp>\u003Cp>\u003Cstrong>关于项目\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>论项目经验，我从大学时开始做第一个真正的项目到现在也有大约4年了吧。最初无人领路不框架为何物，靠着自己的毅力不停的堆代码，发现最后自己堆砌的PHP代码的复杂都已经超出了我的理解范围了，项目开始混乱得我已经无法维护了，于是，第一个项目以失败告终。后来，了解并学习了Web框架发现使用框架写代码更加得心应手。而最近的项目中的经历再次印证了一个好的框架是多么的重要；由于目前的项目的创始人打着“验证无框架开发的思路”的旗号搞了现在这么个项目——底层封装度非常底，该封装的都没有封装，而他所写的简单的封装并没有做到一个“框架”所应当做的事情，导致现在这个项目面临了许多比较坑的问题，比如数据库不能使用联查，这一问题同时导致了大家尽量避免联查，因此，项目在建数据表的时候也尽量的避免联查，于是数据表中出现了大量的冗余，再加上项目的各种改需求，数据结构已经变得不能看了。\u003C\u002Fp>\u003Cp>这些项目经历告诉我“无框架”是扯淡，当项目复杂到一定程度“无框架”的项目将会复杂到无法维护，一个比较好的项目首先是要有一个比较好的框架，而不是无框架，好的框架应该是低耦合的，而且该有的基础功能都是有的，并且应该是可以扩充的，比如某些框架中的中间件概念。\u003C\u002Fp>\u003Cp>\u003Cstrong>关于工作\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>有时候在一个岗位上待久了并不是一件好事。首先，时间一长，在技术上就难以有新的收获，每天过着写业务逻辑的日子早就让我厌倦。然后，呆久了就不知道自己现在的价值如何了，也不了解市场的行情如何，所以我觉得不管是否有换工作的打算，每年都应该出去面试一波，一来了解一下自己目前的价值，二来了解一下市场行情。\u003C\u002Fp>\u003Cp>\u003Cstrong>关于生活\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>这一年，我有了她……\u003C\u002Fp>",{"id":26,"title":27,"uri":27,"author":9,"tags":28,"created_at":32,"view_count":33,"content":34},49,"用latex排版中文书籍",[29,30,31],"latex","ctex","排版","2016-10-31 11:12:02",8645,"\u003Cp>由于最近在翻译《parsing techniques》，所以想着待翻译完毕将其打印成标准书册自己研习，于是学习了如何用latex排版书籍出版物。\u003C\u002Fp>\u003Cp>之前也曾用过两次latex，第一次是大学期间想着使用latex排版毕业论文，于是想用latex做一个毕业论文模板，奈何，长江大学的论文只能用Word写，还在格式上死扣，时间紧迫也只好作罢，模板残篇在这儿 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fduguying\u002Freport\" _src=\"https:\u002F\u002Fgithub.com\u002Fduguying\u002Freport\">https:\u002F\u002Fgithub.com\u002Fduguying\u002Freport\u003C\u002Fa>&nbsp; 。第二次使用latex是在自己的简历上，因为毕业了需要找工作，在网上找了一波简历模板，发现Modern CV这套模板很漂亮，于是也就用了，Modern CV是基于latex的模板，简历在这儿欢迎勾搭&nbsp;\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fduguying\u002Fresume\" _src=\"https:\u002F\u002Fgithub.com\u002Fduguying\u002Fresume\">https:\u002F\u002Fgithub.com\u002Fduguying\u002Fresume\u003C\u002Fa>&nbsp;。经历三次使用latex（尤其是最近一次）对latex中文书籍排版也有了一定的了解。\u003C\u002Fp>\u003Cul class=\" list-paddingleft-2\" style=\"list-style-type: disc;\">\u003Cli>\u003Cp>latex工具选择\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>我选用的是texlive套装，里面包含了latex、xelatex等工具，我们编译中文书籍主要用到的是xelatex，因为xelatex原生支持UTF8，不需要任何的额外包。\u003C\u002Fp>\u003Cul class=\" list-paddingleft-2\" style=\"list-style-type: disc;\">\u003Cli>\u003Cp>包选择\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>中文支持最常用的自然是ctex，我使用的是ctex中的ctexbook类包，他专为长篇书籍排版而生。\u003C\u002Fp>\u003Cul class=\" list-paddingleft-2\" style=\"list-style-type: disc;\">\u003Cli>\u003Cp>编辑器\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>只要有latex语法高亮支持即可，依个人的爱好选择，我用的是sublime text作为编辑器。\u003C\u002Fp>\u003Cul class=\" list-paddingleft-2\" style=\"list-style-type: disc;\">\u003Cli>\u003Cp>书籍结构\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>ctexbook中，一般有如下结构：chapter（章）, section（节）, subsection（子节）, subsubsection（三级子节）, paragraph（段落）, subparagraph（子段落）等，用得最多的是前五种。最基础的文章结构为段落，分段常用空行的方式进行，之前我误以为 \\paragraph{内容} 是分段的方式，结果发现段落全部默认粗体字了，后来才明白，\\paragraph{} 应当作为“段落标题”或是成为“段落首句加粗”，其起着重作用。上一层结构就是三级子节了，如果书籍中没有那么细的分节，三级子节可以不要，三级子节默认加粗，左对齐，\\subsubsection{三级子节} 被\\subsubsection命令括起来的部分就是三级子节的标题了，如下图；\u003C\u002Fp>\u003Cp>\u003Cimg src=\"\u002F\u002Fduguying.oss-cn-qingdao.aliyuncs.com\u002F2016\u002F10\u002F31\u002Fsubsubsection.png\" title=\"\" alt=\"subsubsection.png\"\u002F>\u003C\u002Fp>\u003Cp>再上一层的结构就是子节，\\subsection{子节} 子节标题默认左对齐，\\subsection命令中括起来的就是子节名，带章节号，如下图\u003C\u002Fp>\u003Cp>\u003Cimg src=\"\u002F\u002Fduguying.oss-cn-qingdao.aliyuncs.com\u002F2016\u002F10\u002F31\u002Fsubsection.png\" title=\"\" alt=\"subsection.png\"\u002F>\u003C\u002Fp>\u003Cp>再上一层就是节，\\section{节} 节标题默认居中对齐，\\section命令括起来的就是节名，带章节号，如下图\u003C\u002Fp>\u003Cp>\u003Cimg src=\"\u002F\u002Fduguying.oss-cn-qingdao.aliyuncs.com\u002F2016\u002F10\u002F31\u002Fsection.png\" title=\"\" alt=\"section.png\"\u002F>\u003C\u002Fp>\u003Cp>再上一层就是章，\\chapter{章} 章标题居中对齐，\\chapter命令括起来的就是章名，章节号为汉字，如下图\u003C\u002Fp>\u003Cp>\u003Cimg src=\"\u002F\u002Fduguying.oss-cn-qingdao.aliyuncs.com\u002F2016\u002F10\u002F31\u002Fchapter.png\" title=\"\" alt=\"chapter.png\"\u002F>\u003C\u002Fp>\u003Cul class=\" list-paddingleft-2\" style=\"list-style-type: disc;\">\u003Cli>\u003Cp>内容结构\u003Cbr\u002F>\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>内容结构可分为，\u003Cstrong>前序言\u003C\u002Fstrong>，\u003Cstrong>正文\u003C\u002Fstrong>，\u003Cstrong>后序言\u003C\u002Fstrong> 这三者。\\frontmatter 命令表示接下来的内容是前序言部分，\\mainmatter 命令表示接下来的内容是正文部分，\\backmatter 表示接下来的部分是后序言部分。一般来说，序言部分的页码系统是与正文部分的页码系统区分的，例如前序言部分的内容，页码会以罗马数字标注（i,ii,iii,iv）, 而正文部分的页码会以常规的阿拉伯数字标注（1,2,3,4），下面是示例代码展示了如何使用该三个命令定义内容区\u003C\u002Fp>\u003Cpre class=\"brush:latex;toolbar:false\">\\documentclass[hyperref,UTF8]{ctexbook}\n%&nbsp;\\documentclass{amslatex}\n\\usepackage{src\u002Fpt}\n\n\\begin{document}\n\n%&nbsp;\\pagestyle{plain}\n\n%&nbsp;前言开始\n\\frontmatter\n\n\\include{data\u002Fpreface2}\n\\include{data\u002Fpreface1}\n\n%&nbsp;正文开始\n\\mainmatter\n\n\\tableofcontents\n\n\\include{data\u002Fchap1}\n\\include{data\u002Fchap2}\n\n%&nbsp;尾言开始\n\\backmatter\n\n\\end{document}\u003C\u002Fpre>\u003Cul class=\" list-paddingleft-2\" style=\"list-style-type: disc;\">\u003Cli>\u003Cp>前言中定义章节\u003Cbr\u002F>\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>我们有时候会有多个前言，或者书籍请多个名人来作序，于是可能对每个前言\u002F序需要区分为一章节，但是又不希望出现“第x章”这样的字样。其实在序言部分的章节默认是不带章节号的，因此，可以如同正文一般在序言中做章节处理，无须顾忌其他。如下图\u003C\u002Fp>\u003Cp>\u003Cimg src=\"\u002F\u002Fduguying.oss-cn-qingdao.aliyuncs.com\u002F2016\u002F10\u002F31\u002Fpreface_chapter.png\" title=\"\" alt=\"preface_chapter.png\"\u002F>\u003C\u002Fp>\u003Cp>不过，如有节(section)应当用如下命令以不产生节号\u003C\u002Fp>\u003Cpre class=\"brush:latex;toolbar:false\">\\section*{关于练习和问题}\u003C\u002Fpre>\u003Cp>如下图\u003C\u002Fp>\u003Cp>\u003Cimg src=\"\u002F\u002Fduguying.oss-cn-qingdao.aliyuncs.com\u002F2016\u002F10\u002F31\u002Fpreface_section.png\" title=\"\" alt=\"preface_section.png\"\u002F>\u003C\u002Fp>\u003Cp>若没有*号将会产生章名为0的节号。\u003C\u002Fp>\u003Cul class=\" list-paddingleft-2\" style=\"list-style-type: disc;\">\u003Cli>\u003Cp>绘制表格\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>绘制表格常用的命令对是 \\begin{tabular}\\end{tabular}，详细的使用可以在谷歌上查阅，示例颇多不再赘述，下面只给一段示例代码\u003C\u002Fp>\u003Cpre class=\"brush:latex;toolbar:false\">\\begin{figure}[!htbp]\n\\centering\n\\begin{tabular}{llp{5cm}ll}\n&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;\\textbf{S}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;&nbsp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;\\textbf{S}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\\\\\n&nbsp;1b&nbsp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;&nbsp;&amp;&nbsp;1b&nbsp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\\\\\n&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;\\textbf{L\\&amp;N}&nbsp;&nbsp;&nbsp;&amp;&nbsp;&nbsp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;\\textbf{L\\&amp;N}&nbsp;&nbsp;&nbsp;\\\\\n&nbsp;2a&nbsp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;&nbsp;&amp;&nbsp;0c&nbsp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\\\\\n&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;\\textbf{N,L\\&amp;N}&nbsp;&amp;&nbsp;&nbsp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;\\textbf{L\\&amp;h}&nbsp;&nbsp;&nbsp;\\\\\n&nbsp;0b&nbsp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;&nbsp;&amp;&nbsp;2a&nbsp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\\\\\n&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;\\textbf{d,L\\&amp;N}&nbsp;&amp;&nbsp;&nbsp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;\\textbf{N,L\\&amp;h}&nbsp;\\\\\n&nbsp;2b&nbsp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;&nbsp;&amp;&nbsp;2b&nbsp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\\\\\n&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;\\textbf{d,N\\&amp;N}&nbsp;&amp;&nbsp;&nbsp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;\\textbf{N,N\\&amp;h}&nbsp;\\\\\n&nbsp;0c&nbsp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;&nbsp;&amp;&nbsp;0c&nbsp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\\\\\n&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;\\textbf{d,h\\&amp;N}&nbsp;&amp;&nbsp;&nbsp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;\\textbf{N,h\\&amp;h}&nbsp;\\\\\n&nbsp;0c&nbsp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;&nbsp;&amp;&nbsp;0c&nbsp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\\\\\n&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;\\textbf{d,h\\&amp;h}&nbsp;&amp;&nbsp;&nbsp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&nbsp;\\textbf{d,h\\&amp;h}&nbsp;\\\\\n\\end{tabular}\n\\caption{句子形式变为\\textbf{d,h\\&amp;h},&nbsp;与最左边和最右边替换}\n\\label{fig:method}\n\\end{figure}\u003C\u002Fpre>\u003Cul class=\" list-paddingleft-2\" style=\"list-style-type: disc;\">\u003Cli>\u003Cp>绘制插图\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>这里只介绍常见的普通线条插图绘制。普通的无规律线条插图我们可以借助Adobe Illustrator绘制矢量图，然后将其另存为eps格式的矢量图。接下来用如下命令转化为pdf图（假设eps文件名fig2_19.eps）\u003C\u002Fp>\u003Cpre class=\"brush:bash;toolbar:false\">epstopdf&nbsp;fig2_19.eps\u003C\u002Fpre>\u003Cp>如此，同目录下将会生成名为 fig2_19.pdf 的图片。然后在正文中按如下引用\u003Cbr\u002F>\u003C\u002Fp>\u003Cpre class=\"brush:latex;toolbar:false\">\\begin{figure}[!htbp]\n\\centering\n\\includegraphics[scale=0.6]{figure\u002Ffig2_19.pdf}\n\\caption{Production&nbsp;tree&nbsp;for&nbsp;a&nbsp;context-free&nbsp;grammar}\n\\label{fig:method}\n\\end{figure}\u003C\u002Fpre>\u003Cp>其中\\caption为图片介绍，图片会自动编号。\u003Cbr\u002F>\u003C\u002Fp>\u003Cp>若是规律性比较强的图片可以使用latex代码画图，其中会用到tikz等包，可自行查找研究如何使用。若是插入位图的话，引用graphicx包后可以直接插入，将上述路径中的pdf图改为相应的位图便可以轻松插入。\u003C\u002Fp>\u003Cul class=\" list-paddingleft-2\" style=\"list-style-type: disc;\">\u003Cli>\u003Cp>页面结构\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>页面结构一般纵向会分为\u003Cstrong>页眉\u003C\u002Fstrong>，\u003Cstrong>主体\u003C\u002Fstrong>，\u003Cstrong>页脚\u003C\u002Fstrong>三部分，横向会分为\u003Cstrong>左边距\u003C\u002Fstrong>，\u003Cstrong>主体\u003C\u002Fstrong>，\u003Cstrong>右边距\u003C\u002Fstrong>，\u003Cstrong>测注\u003C\u002Fstrong>。默认是页面布局会给正面（奇数页）的右侧预留\u003Cstrong>侧注\u003C\u002Fstrong>的空间，因此，看起来右边会比左边宽。\u003C\u002Fp>\u003Cp>\u003Cimg class=\"loadingclass\" id=\"loading_iuyssqyh\" src=\"\u002F\u002Fduguying.oss-cn-qingdao.aliyuncs.com\u002F2016\u002F11\u002F1\u002Fpage_layout.png\" title=\"page_layout\"\u002F>\u003C\u002Fp>\u003Cp>许多初接触ctexbook的人会奇怪，这个空白多的一侧应该是装订预留白吧，可是为啥会在右侧呢，其实人家仅仅只是为\u003Cstrong>侧注\u003C\u002Fstrong>留的空间而已。侧注是个啥？如下图左侧注\u003Cbr\u002F>\u003C\u002Fp>\u003Cp>\u003Cimg src=\"\u002F\u002Fduguying.oss-cn-qingdao.aliyuncs.com\u002F2016\u002F10\u002F31\u002Fside_note.png\" title=\"\" alt=\"side_note.png\"\u002F>\u003C\u002Fp>\u003Cp>那么如何调整使得看不到为侧注所预留的空间呢，我们可以自定义边距即可\u003C\u002Fp>\u003Cpre class=\"brush:latex;toolbar:false\">\\usepackage[left=2.2cm,right=1.8cm,top=2.0cm,bottom=2.5cm]{geometry}\n\\geometry{papersize={18.00cm,23.00cm}}\u003C\u002Fpre>\u003Cp>上例调整左边距2.2cm，右边距1.8cm，上边距2.0cm，底边距2.5cm。\u003C\u002Fp>",{"id":36,"title":37,"uri":37,"author":9,"tags":38,"created_at":42,"view_count":43,"content":44},47,"关于kill进程链",[39,40,41],"进程","子进程","kill","2016-09-30 00:02:21",2929,"\u003Cp>之前在做 Goj 项目的时候执行服务器部分使用 go 语言 kill 进程，发现无法 kill 该进程的子进程，后来发现貌似别的语言也无法直接 kill 掉当前进程的子进程链。kill 子进程链的应用场景是这样的，我在做 judger服务器的时候发现我调用 gcc 编译源码会在某些极端的情况下卡死，然后卡死后我需要 kill 掉 gcc 的进程，我使用 go 语言的相关 api kill 掉 gcc (因为我拿得到 gcc 的进程 id)，然而，我发现 gcc 会调用别的命令，记忆中貌似是一个叫做 ar 的命令，实际上是这个子进程卡死了，于是我 kill 掉身为父进程的 gcc 之后，它的子进程依然存在，变成了孤儿进程，继续卡着。但是我没有 api 可以拿到 gcc 卡死的子进程的进程 id，所以我也无法 kill 掉它。我当时的临时解决方案是调用 killall 命令去按照名称杀掉它。\u003C\u002Fp>\u003Cp>之后一次在某个群里提到这件事情，随口问了一句如何获取某个进程的子进程，linux api 中是没有这种 api 的，一位同学提醒了我，你可以从 \u002Fproc 目录中查。今天我用 go 语言实现了它，linux 系统中 \u002Fproc 目录记录了所有的进程信息，但是这些信息中依然没有记录某个信息的子进程，不过它记录了某个进程的父进程，于是我遍历了 \u002Fproc 目录中的所有进程的进程信息，然后根据进程的父代关系构成了一颗进程树，这颗树的顶端必定是 init 进程，于是，我便可以从这颗进程树上从上往下搜索查找出某个进程的子进程了。这样一来，一个简单的进程树便可以让我轻松的查找出某进程的子进程，同样也可以 kill 掉某颗进程树，将当前进程及其子进程 kill 掉已经不再是一件难事了。\u003C\u002Fp>\u003Cp>如果你对此感兴趣，欢迎参阅源码&nbsp;\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fgojudge\u002Fproc\" _src=\"https:\u002F\u002Fgithub.com\u002Fgojudge\u002Fproc\">https:\u002F\u002Fgithub.com\u002Fgojudge\u002Fproc\u003C\u002Fa>&nbsp;\u003C\u002Fp>\u003Cp>最后，我要说明的一点是：世界上没有什么事情是一棵树解决不了的，如果有，那么两颗树一定能够解决。\u003C\u002Fp>",{"id":46,"title":47,"uri":47,"author":9,"tags":48,"created_at":52,"view_count":53,"content":54},45,"Hibernate中自动建表unique无效的问题",[49,50,51],"Hibernate","建表","unique","2016-09-10 14:14:32",3563,"\u003Cp>使用Hibernate自动建表，User实体中的username字段希望给个唯一约束，但是自动建表却一直没有unique约束\u003C\u002Fp>\u003Cpre class=\"brush:java;toolbar:false\">@Entity\n@Table(name&nbsp;=&nbsp;&quot;user&quot;)\npublic&nbsp;class&nbsp;User&nbsp;{\n\tprivate&nbsp;int&nbsp;id;\n\tprivate&nbsp;String&nbsp;username;\n\n\t@Id\n\t@GeneratedValue(strategy&nbsp;=&nbsp;GenerationType.IDENTITY)\n\tpublic&nbsp;int&nbsp;getId()&nbsp;{\n\t\treturn&nbsp;id;\n\t}\n\n\tpublic&nbsp;void&nbsp;setId(int&nbsp;id)&nbsp;{\n\t\tthis.id&nbsp;=&nbsp;id;\n\t}\n\n\t@Column(unique&nbsp;=&nbsp;true,&nbsp;nullable&nbsp;=&nbsp;false)\n\tpublic&nbsp;String&nbsp;getUsername()&nbsp;{\n\t\treturn&nbsp;username;\n\t}\n\n\tpublic&nbsp;void&nbsp;setUsername(String&nbsp;username)&nbsp;{\n\t\tthis.username&nbsp;=&nbsp;username;\n\t}\n\n}\u003C\u002Fpre>\u003Cp>键表的结果是索引中并没有唯一索引，多番尝试解决如下\u003Cbr\u002F>\u003C\u002Fp>\u003Cpre class=\"brush:java;toolbar:false\">@Entity\n@Table(name&nbsp;=&nbsp;&quot;user&quot;)\npublic&nbsp;class&nbsp;User&nbsp;{\n\tprivate&nbsp;int&nbsp;id;\n\tprivate&nbsp;String&nbsp;username;\n\n\t@Id\n\t@GeneratedValue(strategy&nbsp;=&nbsp;GenerationType.IDENTITY)\n\tpublic&nbsp;int&nbsp;getId()&nbsp;{\n\t\treturn&nbsp;id;\n\t}\n\n\tpublic&nbsp;void&nbsp;setId(int&nbsp;id)&nbsp;{\n\t\tthis.id&nbsp;=&nbsp;id;\n\t}\n\n\t@Column(unique&nbsp;=&nbsp;true,&nbsp;length&nbsp;=&nbsp;20,&nbsp;nullable&nbsp;=&nbsp;false)\n\tpublic&nbsp;String&nbsp;getUsername()&nbsp;{\n\t\treturn&nbsp;username;\n\t}\n\n\tpublic&nbsp;void&nbsp;setUsername(String&nbsp;username)&nbsp;{\n\t\tthis.username&nbsp;=&nbsp;username;\n\t}\n\n}\u003C\u002Fpre>\u003Cp>原因是我未指定 username 字段的长度，然后自动建表的字段长度是255字符，于是没有唯一索引，将长度指定为 20 ，删除表，重新执行建表便有了唯一索引。另需注意的是 nullable = false 。\u003C\u002Fp>",{"id":56,"title":57,"uri":57,"author":9,"tags":58,"created_at":61,"view_count":62,"content":63},44,"浅谈软件众包",[59,60],"众包","思考","2016-08-26 17:17:43",2715,"\u003Cp>互联网在发展，也有众多的思维与新颖的产品逐步产生。譬如国外的 Airbnb, Uber，又如国内的 滴滴打车，这些都是众包这一概念衍生出的产品。近年来，国内又有一些公司开始了尝试软件众包。软件众包的难度却往往不是 Airbnb, Uber, 滴滴打车 这些“众包”产品所能比拟的。因为软件开发的复杂程度远远超出了Airbnb的临时住宿，Uber滴滴打车的租车业务。\u003C\u002Fp>\u003Cp>要想做好软件众包已经不仅仅是简单的将需求方与开发者联系到一起，有人说 Airbnb 的成功在于将房屋出租者与有住宿需求的人联系到一起，Uber和滴滴打车他们的成功在于将身为有车族的临时司机或专业司机与乘客联系到一起，而做软件众包的人若是觉得他需要做好的仅仅是将软件需求方与开发者联系到一起那么便是大错特错了，因为将软件需求方与开发者联系到一起这种简单的事情是不会产生生产力，软件需求方不懂技术，热衷于技术的众多基础开发者也是不懂得与需求方“周旋”因为他们往往不具备项目经理、产品经理的能力，而缺了这些往往无法成功的将开发者与需求发黏在一起，被开发者吐槽的项目经理产品经理往往是开发者不可缺少的，他们之间存在一种微妙的共生关系。而对于一个项目并不是简单的需求方与开发者碰撞的产物，我个人认为，普通开发者与需求发的碰撞往往只有一个结果——双方都会被对方撞成渣渣。\u003C\u002Fp>\u003Cp>若是有人觉得我将软件需求方与开发者联系到一起就能够实现软件众包，那么你趁早将“软件众包平台”改名为“软件外包竞标平台”。作为一个资深的开发者（原谅我的装逼），我是没有打算转行做项目经理或是产品经理，我有的是技术，靠技术吃饭，让我做与需求方“周旋”这种事情，那是浪费我写代码研究技术的时间，我不会跟需求方讨价还价也不希望需求方跟我讨价还价，多少钱买多少代码多少功能，只要我觉得合适我就干，少一分也不干。所以，众包平台若是简单的将需求方与开发者联系到一起，绝对会发生碰撞，而且一定会撞得头破血流。\u003Cbr\u002F>\u003C\u002Fp>\u003Cp>假如我是一个开发者：我心目中的众包一定要有分得足够细致的需求，而且还是明码标价的，完成某个ISSUE给多少钱，而我只需要接收那个我觉得出价合适的ISSUE(或称为细分的需求)，在指定的时间内完成便可以拿到上面所标注的价格。接收需求后我所需要做的只是将所有的精力放在我所钟爱的编码上即可。\u003Cbr\u002F>\u003C\u002Fp>\u003Cp>假如我是一个测试人员：我心目中的众包应该是有一个个的功能模块和一个个的需求供我选择测试，明码标价。按照ISSUE分的测试任务，按照模块分的模块测试任务，甚至是整项目业务逻辑回归测试，安全漏洞悬赏测试。不同粒度的测试任务价格也是不同的，当然，因为我是资深的测试人员，你也可以雇佣我为当前项目的测试顾问，负责维护整个项目的整体可靠性保障。\u003C\u002Fp>\u003Cp>假如我是一个项目经理……\u003C\u002Fp>\u003Cp>我不想写那么多假如了，上面的所有假如必须有众多的幕后工作才可能实现，否则一切皆空。\u003C\u002Fp>\u003Cp>项目经理、首席技术总监，者两种角色便是上面假设成真的保障，谁来跟需求方确立最终的需求，谁来跟需求方“周旋”，这是项目经理所应当做的事情。谁来讲上面假设变为现实，需要将需求拆分为如此细致的开发任务，并且保障整体的有效性与可用性，这些便是技术负责人该项目的首席技术总监所要做的事情。\u003C\u002Fp>\u003Cp>我不知道我为什么要写这篇文章，或许是在众包项目组待了这么长时间，也或许是别的原因。纵观国内的软件众包平台，根本没有能够达到这个要求的，我也不愿意一一点评。倒是我之前在某在线视频教育平台找的兼职讲师有点这种感觉，他们让我签什么狗屁协议，上面写的如果违约对方有权利罚款5w，我特么当然不签，最终还是他们妥协了，事实如我所料，我并没有太多时间去录制他们要求的“高质量”的视频，干了三课就休业了，这种想干就干，想不干就不干的感觉才是自由职业者所追求的自由。或许有人说，你这么不负责，撒手不干了，岂不是打乱了别人的课程计划？你想多了，从来都不缺会录课会教学的人，即便没人接我的班，我所录的课程也会一直为他们产生价值创造财富，他们甚至会将我所录的三节课编入别的分类体系中。\u003C\u002Fp>\u003Cp>不管是举例还是装逼，假如我决定做自由职业者的话，这种自由都没有，我特么还是去别人公司老老实实的上班去吧。\u003C\u002Fp>",{"id":65,"title":66,"uri":66,"author":9,"tags":67,"created_at":71,"view_count":72,"content":73},40,"Git团队开发中PR工作模式的反思",[68,69,70],"git","pr","工作流","2016-07-14 21:41:07",3424,"\u003Cp>在公司团队协作用了大半年的Git了，PR工作模式也用了半年。由一个用Git装逼的假老手成长为真正用Git进行团队协作开发的老油条。这其中也有一些值得反思的东西。我很崇拜PR的工作模式，因为它基本上是优秀的开源软件工作模式的代表，众多的开发者自发的给开源项目发送PR，以前总是盼望着自己的开源项目会有人发送PR，若是接收到PR就像是收到别人的礼物一般高兴。\u003C\u002Fp>\u003Cp>我之前赞同的PR工作模式是这样的，开发者拿到开发需求之后，在自己的分支开发，然后向主仓库的相关分支发送PR，之后由测试人员在测试机上拉取主仓库相关分支的代码，然后fetch PR所在仓库分支的代码合并(merge)到本地主仓库相关分支，进行测试，测试完毕通过之后才合并PR到分支。我这一想法的灵感来源于 travis-ci 单元测试的工作模式：开发人员发送PR，travis-ci自动进行单元测试，PR管理者参考PR在 travis-ci 上单元测试的结果进行初步判定是否可以合并。但是我忽略了一点，测试人员并非是 travis-ci 上的单元测试。在工作的过程中往往是这样的：\u003C\u002Fp>\u003Cp>开发人员初步开发出某个功能，然后经过自己的初步测试，发送PR到主仓库，测试人员看到有PR了，需要测试了，于是开始测试，但是测试有问题，于是开发人员就必须继续修改提交，然后再次测试，还有一些问题被发现依然存在，继续开发……可是，你突然发现，你的PR被合并了或者是被关闭了，因为要下班了；或者是要下班了，\u003Cspan style=\"line-height: 22.5px;\">PR管理员会问这个PR能否合并\u003C\u002Fspan>，测试人员暂时没发现新的问题，于是测试人员告诉PR管理员“没有问题”，于是PR被合并了。或者没有上面的“PR管理员的询问”，但不管怎样，最后的结果往往是PR被草草的合并了。于是，没有充分测试的PR进入了仓库，甚至进入了发布分支，最终的结果可想而知。\u003C\u002Fp>\u003Cp>在这个过程中，人们往往没有意识到其实是被PR给影响到了。因为开发者一个PR创立之后，在他会有一个潜意识希望PR被合并，测试人员同样也有这么一个潜意识，因为测试PR就是他的工作之一，他也希望PR被合并，对于PR管理员来说同样也有这么一个潜意识，希望PR被处理，不管是合并还是关闭。就是这些潜意识推动这个PR尽早被合并。\u003C\u002Fp>\u003Cp>我个人感觉正确的做法应该是当测试人员测试充分之后再发起PR，避免这些潜意识促使PR过早的被合并。事实上，不管PR是否存在，测试人员都能够从开发者的分支上拉取到开发者的代码合并到主仓库，PR不过是一个形式而已，给合并者带来方便。但是那些错误的理解了PR的人们往往会搞出诸多莫名其妙的东西，比如PR用来人工做代码审核，比如搞个CheckList让人工去查代码中哪儿写得不规范，这些应该是让 Sonar 自动扫描PR中存在的不规范，谁又会有时间去为别人的PR人工做Sonar该做的事情。经过测试人员的充分测试之后，开发者创建PR，这时单元测试测试一遍，然后Sonar扫描一遍，后两者自动化测试通过之后代码才能入库。\u003C\u002Fp>\u003Cp>总之，测试人员功能测试通过之后开发者才能创建PR，自动化工具进行单元测试和Sonar扫描通过后，PR管理员才能允许合并。这才是比较靠谱的PR工作流。\u003C\u002Fp>",{"id":75,"title":76,"uri":76,"author":9,"tags":77,"created_at":81,"view_count":82,"content":83},39,"结构化数据缓存管理设计",[78,79,80],"数据库","缓存","管理","2016-07-08 15:55:36",3471,"\u003Cp>\u003Cspan style=\"line-height: 22.5px;\">现代web开发中，在数据库和应用程序服务器之间使用缓存是常见的手段，它有效的减轻了后端数据库服务器的压力。结构化数据库中的数据是按照表、字段这种结构存储的，而作为缓存系统的memcached或是redis-server是以key-value的方式存储数据的。如何将结构化的数据存储到非结构化的缓存系统是一个问题，对于MySQL等结构化数据库我们可以按照以下方式存储。\u003C\u002Fspan>\u003C\u002Fp>\u003Cp>\u003Cspan style=\"line-height: 22.5px;\">首先，对于表中单条数据我们可以按照Bean存储在缓存中，key为“表名+id”，value为Bean对象。\u003C\u002Fspan>\u003C\u002Fp>\u003Cp>\u003Cspan style=\"line-height: 22.5px;\">然后，对于列表查询，我们可以使用“select id from article where status=1 limit 10”这种语句查出article表的id列表 List&lt;Long&gt; 。然后通过id从缓存中逐条加载 Bean ，最终形成我们需要的 List&lt;Bean&gt;。而我们可以将通过sql查出来的List&lt;Long&gt;结构的id数组作为一个缓存对象，其key可以按照某种规则生成，例如“方法名+override_index+参数...”。\u003C\u002Fspan>\u003C\u002Fp>\u003Cp>\u003Cspan style=\"line-height: 22.5px;\">上面说的两种数据对象的存储方式都没有问题，而其中的难点在于如何管理缓存，我们知道，一个列表查询的结果List&lt;Long&gt;在这张表发生增删改的时候都会发生变化，因此，详细来说我们应该在列表的某个字段发生增删改的时候清理掉这个id列表缓存，等下次查询的时候再自动重建新的缓存，以保证缓存的正确性。不过，若是联表查询呢？联表查询“select user.id from article, user where article.userid=user.id and article.status=1”查出的是一个id列表，我们将其缓存假设key为key1，但是一旦article表和user表其中之一发生增删改，那么这个缓存数据应当失效，也就是说，Article在进行 Update()、Save()、Delete() 的时候我们应该清理掉这个key为key1的缓存，同样对于User在进行&nbsp;\u003Cspan style=\"line-height: 22.5px;\">Update()、Save()、Delete() 的时候我们也应当清理掉 key1 的缓存。在这儿只是列举了两个表联查，并且只是提到了一个联表查询，假如有N个表联表，而且有M个联表查询语句那么我们应该在多少个方法中调用清理这种缓存的方法呢M*N*3，好多好麻烦呀。\u003C\u002Fspan>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp>为了管理list的缓存，定义一个树形结构如下\u003C\u002Fp>\u003Cp>\u003Cimg src=\"\u002F\u002Fduguying.oss-cn-qingdao.aliyuncs.com\u002F2016\u002F7\u002F8\u002Fcache_manage_struct.png\" title=\"\" alt=\"cache_manage_struct.png\"\u002F>\u003C\u002Fp>\u003Cp>t开头的节点表示表名，tA、tB 表示 A 表和 B 表，f开头的表示字段，fAa 表示 A 表 a 字段，fAb 表示 A 表 b 字段，k开头的表示列表的缓存键。这个数据结构表达了我们应该如何清理缓存，比如A表中的a字段发生的改变（增删改），那么我应该清理掉键名为k1, k2, k3的缓存，A表字段b发生增删改时应该清理掉键名为k1, k2的缓存，B表a字段发生增删改时应该清理掉键名为 k1 的缓存。然后将该树形结构拆分为三级，分别用三类的key-value存储起来就好，也不必担心结构过于庞大，上图可以拆为6个key-value：\u003C\u002Fp>\u003Cpre class=\"brush:plain;toolbar:false\">[0]&nbsp;&nbsp;&nbsp;&nbsp;_init-&gt;(tA,&nbsp;tB)\n[1]&nbsp;&nbsp;&nbsp;&nbsp;tA-&gt;(fAa,&nbsp;fAb)\n[1]&nbsp;&nbsp;&nbsp;&nbsp;tB-&gt;(fBa,&nbsp;fBb)\n[2]&nbsp;&nbsp;&nbsp;&nbsp;fAa-&gt;(k1,&nbsp;k2,&nbsp;k3)\n[2]&nbsp;&nbsp;&nbsp;&nbsp;fAb-&gt;(k1,&nbsp;k2)\n[2]&nbsp;&nbsp;&nbsp;&nbsp;fBa-&gt;(k1)\u003C\u002Fpre>\u003Cp>\u003Cspan style=\"line-height: 22.5px;\">\u003Cspan style=\"line-height: 22.5px;\">上图的结构来自于如下三个SQL查询\u003C\u002Fspan>\u003C\u002Fspan>\u003C\u002Fp>\u003Cpre class=\"brush:sql;toolbar:false\">[K1]&nbsp;&nbsp;&nbsp;select&nbsp;id&nbsp;from&nbsp;A,&nbsp;B&nbsp;&nbsp;where&nbsp;&nbsp;A.fAa&nbsp;=&nbsp;?&nbsp;and&nbsp;A.fAb&nbsp;=&nbsp;?&nbsp;and&nbsp;B.fBa&nbsp;=&nbsp;?&nbsp;...\n[K2]&nbsp;&nbsp;&nbsp;select&nbsp;id&nbsp;from&nbsp;A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;where&nbsp;&nbsp;A.fAa&nbsp;=&nbsp;?&nbsp;and&nbsp;A.fAb&nbsp;=&nbsp;?&nbsp;...\n[K3]&nbsp;&nbsp;&nbsp;select&nbsp;id&nbsp;from&nbsp;A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;where&nbsp;&nbsp;A.fAa&nbsp;=&nbsp;?&nbsp;...\u003C\u002Fpre>\u003Cp>\u003Cspan style=\"line-height: 22.5px;\">\u003Cspan style=\"line-height: 22.5px;\">\u003C\u002Fspan>\u003C\u002Fspan>\u003Cbr\u002F>\u003C\u002Fp>",{"id":85,"title":86,"uri":86,"author":9,"tags":87,"created_at":90,"view_count":91,"content":92},38,"状态码设计的智慧，1234还是1248",[88,89],"状态码","设计","2016-06-13 23:44:34",3724,"\u003Cp>一个事物有5个流程，ABCDE一般的程序员通常会定义为 status 有5个状态 0\u002F1\u002F2\u002F3\u002F4 ，流程的顺序是 A-&gt;B-&gt;C-&gt;D-&gt;E ，可是有一天项目经理说这个流程会有个快捷流程 A-&gt;B-&gt;E 。于是原本的 0-&gt;1-&gt;2-&gt;3-&gt;4 就有部分数据变为了 0-&gt;1-&gt;4 ，这些都不会有太大的问题，然而，后来项目经理跟你说我需要区分在E状态下它是经历了 ABCDE 还是直接经历 ABE ，于是乎，你就懵逼了。\u003C\u002Fp>\u003Cp>\u003Cimg src=\"\u002F\u002Fduguying.oss-cn-qingdao.aliyuncs.com\u002F2016\u002F6\u002F13\u002Fmengbi.jpg\"\u002F>\u003C\u002Fp>\u003Cp>有另外一种设计方式倒是可以获取详细的经历的流程结点，那就是 A:1, B:2, C:4, D:8, E:16 。于是A-&gt;B-&gt;C-&gt;D-&gt;E 表示的状态码切换过程为 1-&gt;3-&gt;7-&gt;15-&gt;31 。A-&gt;B-&gt;E 表示的状态码切换过程为 1-&gt;3-&gt;20, 有人说，你这样当处于E状态时就有可能有两个状态码了31和20，我如何判定他是处于E状态呢，其实这是位运算上的一个小技巧，我们可以很简单的判定出他是否在E状态 status &amp; 0x10 &gt; 0 若计算结果为true，则表示有经历E状态，按照你的流程方向便可以判定是处于哪一未置\u003Cbr\u002F>\u003C\u002Fp>\u003Cpre class=\"brush:java;toolbar:false\">switch&nbsp;(true)&nbsp;{\n\tcase&nbsp;status&nbsp;&amp;&nbsp;0x10:\n\t\treturn&nbsp;&quot;E&quot;;\n\tcase&nbsp;status&nbsp;&amp;&nbsp;0x08:\n\t\treturn&nbsp;&quot;D&quot;;\n\tcase&nbsp;status&nbsp;&amp;&nbsp;0x04:\n\t\treturn&nbsp;&quot;C&quot;;\n\tcase&nbsp;status&nbsp;&amp;&nbsp;0x02:\n\t\treturn&nbsp;&quot;B&quot;;\n\tcase&nbsp;status&nbsp;&amp;&nbsp;0x01:\n\t\treturn&nbsp;&quot;A&quot;;\n}\u003C\u002Fpre>\u003Cp>这一设计方式在ERP等系统的权限控制中更是常见\u003C\u002Fp>\u003Cp>例如某一项目下有10个操作不同的用户可以配置不同的操作权限，那么就有 0b0000000000 到 0b1111111111 ，呃……，1024种权限配置方式，如果是100个【weightValue.size()】操作，那么就有 2^100 种权限配置方式。我们只需要给该用户一个 int(11) 类型的字段就可以完成权限配置。\u003C\u002Fp>\u003Cp>又例如，某简历需要计算简历完整度，简历中分为10个【weightValue.size()】模块，不同的模块占分权值不同，那么我们也可以用一个字段来标记该简历的各模块的完成状况，0b0000000000 到 0b1111111111 ，你可以这样计算分值\u003C\u002Fp>\u003Cpre class=\"brush:java;toolbar:false\">int&nbsp;value&nbsp;=&nbsp;0;\nint&nbsp;weightValueNumber&nbsp;=&nbsp;weightValue.size();\nint&nbsp;zerokeep&nbsp;=&nbsp;math.pow(2,&nbsp;weightValueNumber);\nstatus&nbsp;=&nbsp;status&nbsp;+&nbsp;zerokeep;\nfor&nbsp;(int&nbsp;i&nbsp;=&nbsp;0;&nbsp;statusMove&nbsp;-&nbsp;zerokeep&nbsp;&gt;&nbsp;0;&nbsp;i++)&nbsp;{\n\tstatusMove&nbsp;=&nbsp;status&nbsp;&lt;&nbsp;(i&nbsp;+&nbsp;2);&nbsp;\u002F\u002F&nbsp;左移&nbsp;(i+1)+1&nbsp;位\n\tint&nbsp;nakedValue&nbsp;=&nbsp;(statusMove&nbsp;&gt;&nbsp;(i&nbsp;+&nbsp;2))&nbsp;^&nbsp;status&nbsp;-&nbsp;zerokeep;\n\tboolean&nbsp;checked&nbsp;=&nbsp;nakedValue&nbsp;&gt;&nbsp;0;\n\tif&nbsp;(checked)&nbsp;{\n\t\tvalue&nbsp;+=&nbsp;weightValue.get(i);\n\t}\n\tstatus&nbsp;=&nbsp;nakedValue&nbsp;+&nbsp;zerokeep;\n}\nreturn&nbsp;value;\u003C\u002Fpre>\u003Cp>这种算法的始祖应该算是 Linux 系统上的权限管理机制吧，chmod 777 \u002Fxxx 这种操作后面的智慧便是如此。若是铁定的不涉及到取某个结点ABCDE的独立状态详情，那么你可以随意定义状态码 1\u002F2\u002F3\u002F4\u002F5 或是 -2\u002F-1\u002F0\u002F1\u002F2 随你所好，但是假如某一天你遇上了坑爹的项目经理突然告诉你需要知道是否经历了CD状态，那么你在懵逼的时候是不是也会想起Linux系统上 chmod 指令的智慧呢？1234还是1248取决于你最初的设计。\u003C\u002Fp>",{"id":94,"title":95,"uri":95,"author":9,"tags":96,"created_at":100,"view_count":101,"content":102},37,"Linux内核的安装",[11,97,98,99],"内核","安装","kernel","2016-06-07 14:15:00",3346,"\u003Cp>此文不介绍Linux内核的编译及编译配置，只讲述在编译完成之后的内核部署相关内容，此文环境 CentOS 7，内核源码版本 4.4.12 。注意编译安装完成后 \u002Fusr\u002Fsrc\u002Flinux-4.4.12 目录不能删除\u003C\u002Fp>\u003Cp>内核编译完成，编译所在目录 \u002Fusr\u002Fsrc ，接下来执行\u003C\u002Fp>\u003Cpre class=\"brush:bash;toolbar:false\">make&nbsp;modules_install\u003C\u002Fpre>\u003Cp>他会将编译后的文件拷贝到 \u002Flib\u002Fmodules\u002F4.4.12 目录，接下来拷贝内核\u003Cbr\u002F>\u003C\u002Fp>\u003Cpre class=\"brush:bash;toolbar:false\">cp&nbsp;\u002Fusr\u002Fsrc\u002Flinux-4.4.12\u002Farch\u002Fx86_64\u002Fboot\u002FbzImage&nbsp;\u002Fboot\u002Fvmlinuz-4.4.12.x86_64\u003C\u002Fpre>\u003Cp>进入 \u002Fboot 目录并开始创建临时文件系统\u003Cbr\u002F>\u003C\u002Fp>\u003Cpre class=\"brush:bash;toolbar:false\">cd&nbsp;\u002Fboot\nmkinitrd&nbsp;initramfs-4.4.12.img&nbsp;4.4.12\u003C\u002Fpre>\u003Cp>将会从 \u002Flib\u002Fmodules\u002F4.4.12 目录生成&nbsp;initramfs-4.4.12.x86_64.img 文件，便是临时文件系统，我们可以看到该目录下的文件目录\u003C\u002Fp>\u003Cpre class=\"brush:bash;toolbar:false\">➜&nbsp;&nbsp;4.4.12&nbsp;ls&nbsp;-al\ndrwxr-xr-x.&nbsp;&nbsp;3&nbsp;root&nbsp;root&nbsp;&nbsp;&nbsp;4096&nbsp;6月&nbsp;&nbsp;&nbsp;7&nbsp;22:31&nbsp;.\ndrwxr-xr-x.&nbsp;&nbsp;4&nbsp;root&nbsp;root&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;47&nbsp;6月&nbsp;&nbsp;&nbsp;7&nbsp;21:44&nbsp;..\nlrwxrwxrwx.&nbsp;&nbsp;1&nbsp;root&nbsp;root&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;21&nbsp;6月&nbsp;&nbsp;&nbsp;7&nbsp;21:44&nbsp;build&nbsp;-&gt;&nbsp;\u002Fusr\u002Fsrc\u002Flinux-4.4.12\ndrwxr-xr-x.&nbsp;13&nbsp;root&nbsp;root&nbsp;&nbsp;&nbsp;4096&nbsp;6月&nbsp;&nbsp;&nbsp;7&nbsp;22:31&nbsp;kernel\nlrwxrwxrwx.&nbsp;&nbsp;1&nbsp;root&nbsp;root&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;21&nbsp;6月&nbsp;&nbsp;&nbsp;7&nbsp;22:30&nbsp;source&nbsp;-&gt;&nbsp;\u002Fusr\u002Fsrc\u002Flinux-4.4.12\u003C\u002Fpre>\u003Cp>可以看到build目录链接到 \u002Fusr\u002Fsrc\u002Flinux-4.4.12 ，因此上面说不能删除该源码目录，重命名 img 文件\u003C\u002Fp>\u003Cpre class=\"brush:bash;toolbar:false\">mv&nbsp;initramfs-4.4.12.img&nbsp;initramfs-4.4.12.x86_64.img\u003C\u002Fpre>\u003Cp>为何我们要将这些文件名命名成这样呢，我们可以看到 boot 目录下的文件如下\u003C\u002Fp>\u003Cpre class=\"brush:bash;toolbar:false\">➜&nbsp;&nbsp;\u002Fboot&nbsp;ls\nconfig-3.10.0-327.el7.x86_64\ngrub\ngrub2\ninitramfs-0-rescue-a21a5e0aa76b4b0c85aeb76161573b23.img\ninitramfs-3.10.0-327.el7.x86_64.img\ninitramfs-3.10.0-327.el7.x86_64kdump.img\ninitramfs-4.4.12.x86_64.img\ninitrd-plymouth.img\nsymvers-3.10.0-327.el7.x86_64.gz\nSystem.map-3.10.0-327.el7.x86_64\nvmlinuz-0-rescue-a21a5e0aa76b4b0c85aeb76161573b23\nvmlinuz-3.10.0-327.el7.x86_64\nvmlinuz-4.4.12.x86_64\u003C\u002Fpre>\u003Cp>可以发现，centos 7 系统原来的内核命名已经临时文件系统命名是有规律的，vmlinuz-&lt;version&gt;.&lt;arc&gt; 是内核命名规则，initramfs-&lt;version&gt;.&lt;arc&gt;.img 是文件系统文件名。这么有规律的文件名是因为 centos 7 的 grub2 的默认配置文件中是按照这种规则自动搜索内核的，所以，centos 7 中如此命名新的内核可以不必额外配置 grub2 的配置文件，当然如果你熟悉 grub2 的配置，你也可以任意命名，在配置文件中写入正确的配置即可。\u003Cbr\u002F>\u003C\u002Fp>\u003Cp>参考文献：\u003C\u002Fp>\u003Cp>[1]&nbsp;\u003Ca href=\"http:\u002F\u002Fblog.chinaunix.net\u002Fuid-24782829-id-3211008.html\">http:\u002F\u002Fblog.chinaunix.net\u002Fuid-24782829-id-3211008.html\u003C\u002Fa>\u003C\u002Fp>\u003Cp>\u003Cbr\u002F>\u003C\u002Fp>",{"title":104,"list":105},"最热文章",[106,112,118,124,130,132,138,144,150,156],{"id":107,"title":108,"uri":109,"author":9,"created_at":110,"view_count":111},28,"docker容器目录与主机目录同步","\u002Farticle\u002Fdocker容器目录与主机目录同步","2014-12-31 12:34:08",15573,{"id":113,"title":114,"uri":115,"author":9,"created_at":116,"view_count":117},21,"beego中使用fis","\u002Farticle\u002Fbeego中使用fis","2014-12-03 10:47:56",9253,{"id":119,"title":120,"uri":121,"author":9,"created_at":122,"view_count":123},20,"用github登录，oauth开发","\u002Farticle\u002F用github登录，oauth开发","2014-11-23 13:33:37",9115,{"id":125,"title":126,"uri":127,"author":9,"created_at":128,"view_count":129},18,"windows服务注册工具nssm","\u002Farticle\u002Fwindows服务注册工具nssm","2014-10-31 21:34:39",9054,{"id":26,"title":27,"uri":131,"author":9,"created_at":32,"view_count":33},"\u002Farticle\u002F用latex排版中文书籍",{"id":133,"title":134,"uri":135,"author":9,"created_at":136,"view_count":137},19,"texlive中文书签乱码","\u002Farticle\u002Ftexlive中文书签乱码","2014-11-15 02:54:01",8466,{"id":139,"title":140,"uri":141,"author":9,"created_at":142,"view_count":143},6,"Windows上的软件包管理器chocolatey","\u002Farticle\u002FWindows上的软件包管理器chocolatey","2014-08-10 15:55:22",8012,{"id":145,"title":146,"uri":147,"author":9,"created_at":148,"view_count":149},3,"利用开源和免费资源搭建CI环境","\u002Farticle\u002F利用开源和免费资源搭建CI环境","2014-07-04 16:54:58",7740,{"id":151,"title":152,"uri":153,"author":9,"created_at":154,"view_count":155},16,"php-fpm网站目录权限配置","\u002Farticle\u002Fphp-fpm网站目录权限配置","2014-10-18 01:36:10",7276,{"id":157,"title":158,"uri":159,"author":9,"created_at":160,"view_count":161},27,"sublime text 2插件开发，外部修改文件无法重新加载","\u002Farticle\u002Fsublime text 2插件开发，外部修改文件无法重新加载","2014-12-26 20:24:13",7055,{"title":163,"list":164},"按月归档",[165,169,172,175,178,181,184,188,192,195,198,201,205,208,211,215,218,221,224,228,231,234,237,240,243,246,249,252,255,258,261,264,267,270,273,276,279,282,285,288,292,295,298,301,304,307],{"title":166,"uri":167,"view_count":168},"2026年7月","\u002Farchive\u002F2026\u002F7\u002F1","[1]",{"title":170,"uri":171,"view_count":168},"2026年1月","\u002Farchive\u002F2026\u002F1\u002F1",{"title":173,"uri":174,"view_count":168},"2025年4月","\u002Farchive\u002F2025\u002F4\u002F1",{"title":176,"uri":177,"view_count":168},"2024年6月","\u002Farchive\u002F2024\u002F6\u002F1",{"title":179,"uri":180,"view_count":168},"2024年5月","\u002Farchive\u002F2024\u002F5\u002F1",{"title":182,"uri":183,"view_count":168},"2024年4月","\u002Farchive\u002F2024\u002F4\u002F1",{"title":185,"uri":186,"view_count":187},"2023年12月","\u002Farchive\u002F2023\u002F12\u002F1","[6]",{"title":189,"uri":190,"view_count":191},"2023年11月","\u002Farchive\u002F2023\u002F11\u002F1","[2]",{"title":193,"uri":194,"view_count":168},"2023年10月","\u002Farchive\u002F2023\u002F10\u002F1",{"title":196,"uri":197,"view_count":168},"2023年7月","\u002Farchive\u002F2023\u002F7\u002F1",{"title":199,"uri":200,"view_count":191},"2023年6月","\u002Farchive\u002F2023\u002F6\u002F1",{"title":202,"uri":203,"view_count":204},"2023年5月","\u002Farchive\u002F2023\u002F5\u002F1","[3]",{"title":206,"uri":207,"view_count":191},"2023年4月","\u002Farchive\u002F2023\u002F4\u002F1",{"title":209,"uri":210,"view_count":191},"2023年3月","\u002Farchive\u002F2023\u002F3\u002F1",{"title":212,"uri":213,"view_count":214},"2023年2月","\u002Farchive\u002F2023\u002F2\u002F1","[5]",{"title":216,"uri":217,"view_count":168},"2023年1月","\u002Farchive\u002F2023\u002F1\u002F1",{"title":219,"uri":220,"view_count":191},"2022年12月","\u002Farchive\u002F2022\u002F12\u002F1",{"title":222,"uri":223,"view_count":214},"2022年11月","\u002Farchive\u002F2022\u002F11\u002F1",{"title":225,"uri":226,"view_count":227},"2022年10月","\u002Farchive\u002F2022\u002F10\u002F1","[4]",{"title":229,"uri":230,"view_count":187},"2022年9月","\u002Farchive\u002F2022\u002F9\u002F1",{"title":232,"uri":233,"view_count":214},"2022年8月","\u002Farchive\u002F2022\u002F8\u002F1",{"title":235,"uri":236,"view_count":168},"2019年7月","\u002Farchive\u002F2019\u002F7\u002F1",{"title":238,"uri":239,"view_count":168},"2019年2月","\u002Farchive\u002F2019\u002F2\u002F1",{"title":241,"uri":242,"view_count":168},"2018年9月","\u002Farchive\u002F2018\u002F9\u002F1",{"title":244,"uri":245,"view_count":168},"2018年8月","\u002Farchive\u002F2018\u002F8\u002F1",{"title":247,"uri":248,"view_count":168},"2017年11月","\u002Farchive\u002F2017\u002F11\u002F1",{"title":250,"uri":251,"view_count":168},"2017年8月","\u002Farchive\u002F2017\u002F8\u002F1",{"title":253,"uri":254,"view_count":168},"2017年5月","\u002Farchive\u002F2017\u002F5\u002F1",{"title":256,"uri":257,"view_count":168},"2017年4月","\u002Farchive\u002F2017\u002F4\u002F1",{"title":259,"uri":260,"view_count":168},"2016年11月","\u002Farchive\u002F2016\u002F11\u002F1",{"title":262,"uri":263,"view_count":168},"2016年10月","\u002Farchive\u002F2016\u002F10\u002F1",{"title":265,"uri":266,"view_count":191},"2016年9月","\u002Farchive\u002F2016\u002F9\u002F1",{"title":268,"uri":269,"view_count":168},"2016年8月","\u002Farchive\u002F2016\u002F8\u002F1",{"title":271,"uri":272,"view_count":191},"2016年7月","\u002Farchive\u002F2016\u002F7\u002F1",{"title":274,"uri":275,"view_count":214},"2016年6月","\u002Farchive\u002F2016\u002F6\u002F1",{"title":277,"uri":278,"view_count":168},"2015年12月","\u002Farchive\u002F2015\u002F12\u002F1",{"title":280,"uri":281,"view_count":168},"2015年10月","\u002Farchive\u002F2015\u002F10\u002F1",{"title":283,"uri":284,"view_count":191},"2015年2月","\u002Farchive\u002F2015\u002F2\u002F1",{"title":286,"uri":287,"view_count":168},"2015年1月","\u002Farchive\u002F2015\u002F1\u002F1",{"title":289,"uri":290,"view_count":291},"2014年12月","\u002Farchive\u002F2014\u002F12\u002F1","[8]",{"title":293,"uri":294,"view_count":191},"2014年11月","\u002Farchive\u002F2014\u002F11\u002F1",{"title":296,"uri":297,"view_count":214},"2014年10月","\u002Farchive\u002F2014\u002F10\u002F1",{"title":299,"uri":300,"view_count":204},"2014年9月","\u002Farchive\u002F2014\u002F9\u002F1",{"title":302,"uri":303,"view_count":204},"2014年8月","\u002Farchive\u002F2014\u002F8\u002F1",{"title":305,"uri":306,"view_count":204},"2014年7月","\u002Farchive\u002F2014\u002F7\u002F1",{"title":308,"uri":309,"view_count":191},"2013年9月","\u002Farchive\u002F2013\u002F9\u002F1",104,{"url":312,"title":313},"https:\u002F\u002Fimage.duguying.net\u002F2022\u002F09\u002Fij6x8o4s.webp","老家 摄于2020年秋",1790781604698]