之前的时候 iphone 在 4.3.2 完美越狱出现之后，因为嫌需要装的一些必要的东西太多，不想折腾，就一直没升级到 4.3.3 。

终于，昨天看到新的越狱工具 http://www.jailbreakme.com// 发布了，看上去是如此简单。想了想，既然这么简单，那就升级吧。于是打开 iTunes 点了升级。事后证明，这真是手贱地一点啊。

手贱地插播一句，用了 http://dns.v2ex.com/ 的 dns 之后，iTunes Store 的连接速度流畅地想哭啊。

接着说那手贱地一点的下场。下载 4.3.3 ，提取，升级，一切都按部就班地就行中，问题就出现在最后一点，进度条停止在大概 2/3 处，一直等了半个小时，一点没动。

强制退出 iTuens 、重启机器、等等，还是外甥打灯笼 － 照旧。好吧，回家再说吧。

吃饭前，开机、连上 iPhone。吃完一看，还是那样，跟我妈跑大悦城柴米油盐买了一堆回来一看还这样，怒了，可恨正好网络还停了。算了，碎觉。

断网之前先跑去看看能不能预约天才吧，结果西单大悦城的最早能预约11号地、三里屯的直接没法预约。好吧，实在不行哥就跑去霸王见天才们了。

今天到了公司，又试了一次，发现又让外甥打了回灯笼，真不好意思。爪儿，不会真就变砖了吧。叶总都已经打主意让我寄过去给她砸核桃永乐。想了想，不能便宜了这些幸灾乐祸的人，找了个关键词，google 了一下。

终于，发现了罪魁祸首啊，Wi-Fi Sync ，这个我很久之前一次手贱装上，但是没成功用过一次的东西。

这货的站点上用红字标出：

Don’t attempt to restore or update your device while Wi-Fi Sync is installed on your PC; uninstall first, restore, then reinstall. If you update iTunes, you must reboot (Mac) or reinstall Wi-Fi Sync (Windows).

坑死个人了啊，都这样了，大哥你还卖 $9.99 啊。

又跑去搜了搜怎么卸载 Wi-Fi Sync ，看到一哥们洋洋洒洒写了一小篇。直接 Finder 进入文件目录还不行，还得在 Terminal 下才行。楼下一哥们还哭喊着步骤不详细，要楼主再写详细点，再往下看，乐p了。

一哥们说

到 http://www.getwifisync.com/ 下载反安装程序即可

好，卸载，连上 iPhone 重新升级，一切顺利。

啧啧，因为手贱给自己挖了这么多坑，坑死哥人咧。

最近再次仔细把《HTML5设计原理》重新过了一遍，比起上次粗粗的浏览，收获更多，这篇文章没有任何关于 HTML5 标签、api 的使用的详细解释，而是对其背后的设计原理做了详细说明。这是 HTML5 一切纷繁表象背后的真义，值得每个前端工作者多次阅读。

下午和小飞 @shawphy 讨论一些问题的时候，说到了中文书写里的“的、得、地”地区别。据说现在已经把这三个 de 统一，不做区分了。想想也是，虽然我受教育的时候是区分三者使用的，但是我也一直没弄清楚它们之间的区别。因为最近的一些书写要求，还想趁过年期间回去请教下俺那当了一辈子语文教师的爹来着。

小飞说：“有一种观点认为，语言是活的，随着人们的使用而变化的。如果大部分人都不分了，那也就不要再分了。感觉着就像是HTML5一样。HTML5 很宽容，比如关于属性引号。按理需要有引号，但现在有没有都无所谓了。”

这就不得不提到 HTML5 设计原理其中的一条：“发送时要保守；接收时要开放。” HTML5 以包容的心接受开发者书写的文档，这些文档发送到同样敞开胸怀的浏览器，以使得那些不够标准的文档也可以渲染出来。

与之相对的是已经死去的 XHTML2 ，（呃，突然发现 XHTML 。。。2。想起郭德纲的一句玩笑：“CCTV。。。2，多大的勇气，谁好意思承认这个，人家还写上了。”）XHTML2 是绝对的理想派，要求严格使用 XML 的错误处理模型，也就是遇到一个错误就会停止解析。这对文档书写着的要求得多高啊。当然最为开发者，我们应该遵从最佳实践，尽量保证文档格式的正确。但是谁也不能保证 100% 的正确性，作为开放的互联网，对错误零容忍，导致浏览器无法渲染确实不是那么回事。

尤其是技术就像数码产品，越来越先进，但是价格（门槛）越来越低。我之前有私心，眼看国内一些人对技术的滥用，导致的网上的虚假信息、垃圾信息泛滥，甚至一度希望一些技术应该保有一定的门槛。但是后来想明白了，互联网本身就是开放到，技术生来也应该是服务每一个人的，至于怎么使用，那就要看人自己的选择了。

遵从伯斯塔尔法则（Postel’s Law）的 HTML5 在于完美理想话的 XHTML2 的角力中胜利了。或者应该说是人性再一次取得了胜利，人人追求完美，但是最后还得面对现实。

我们应该看到伯斯塔尔法则其实是同时对发送者和接收者有要求的，”接收时要开放“是对标准和浏览器的要求，而”发送时保守“则是对文档作者的要求。

回到“的 得 地”这个问题。小飞问：”这些坚持 三个 de 不同的人，是不是就好像坚持 xhtml2 的人呢？“ 我认为不然，这些人是选择了发送时保守的“开发者”。不区分这三个 de 的人，如果是普通人，自然无可厚非，但是作为职业的作家，如果无法区分这三者，就算不上好的作家。

同样的产品，不同的工艺就决定了价值的不一样。A货再能以假乱真，也不能和真品等价。同样，作为一名职业的前端工程师，在职业的道路上，我们的选择决定了输出的产品的质量，产品质量反过来也决定了我们自身的价值。

啰哩巴嗦的说了这么多，其实是希望各位前端工程师（其实也可以延伸至各个行业的从业者）能更加专业些，在发送时更加”保守“些。Be pro，这也是 2011 我对自己的要求。

其实很简单，首先需要安装一个 Firefox 插件 MozRepl （在 github 的 mozrepl wiki 页安装）。然后在 VIM 配置里面加上以下设置：

autocmd BufWriteCmd *.html,*.css,*.gtpl :call Refresh_firefox()
function! Refresh_firefox()
if &modified
write
silent !echo ‘vimYo = content.window.pageYOffset;
\ vimXo = content.window.pageXOffset;
\ BrowserReload();
\ content.window.scrollTo(vimXo,vimYo);
\ repl.quit();’ |
\ nc localhost 4242 2>&1 > /dev/null
endif
endfunction

其中的文件格式可以自己设置。之后每次 VIM 保存之后，Firefox 就会自动刷新了。不过现在来看有个问题，这个工具还没有智能到刷新源码对应的页面，只会刷新当前处于激活状态的标签页。不过 Firefox 对我来说，已经沦落到纯粹的开发工具了，这点小不爽可以接受。

Mactonish 安装 rsync

获取 rysnc

首先去 rsync 首页 获取最新的源码包，当前是 3.0.7 版本。然后就是编译、安装，前提同样需要 c 编译器（如 Xcode）。

同步

以下另存为 rsync-example.sh 。
# 设置一个 lock 文件，防止多次运行
LOCK_FILE="/tmp/rsync_backup.lock"
LOG_FILE="/tmp/rsync_backup.log"
# rsync 路径
RSYNC="/usr/local/bin/rsync"

if [ -e $LOCK_FILE ]; then
	TIMESTAMP=$(date)
	echo "$TIMESTAMP: lock file exists, exit now" >> $LOG_FILE
	exit
fi

cat /dev/null > $LOG_FILE

touch $LOCK_FILE

# 需要自己定制的命令
rsync -avz --rsh="ssh -l user" local/folder user@remotehost:remote/folder

rm $LOCK_FILE
赋予它可执行权限
chmod +x rsync-example.sh
执行
./rsync-example.sh
不用这个脚本，直接用其中的命令 rsync -avz --rsh="ssh -l user" local/folder user@remotehost:remote/folder 也是一样。
参考资料

 How to use rsync on mac os x, windows and linux
 rsync man

顶着被 @adamsxu 鉴定为闲得蛋疼的危险，开始折腾 Mac 下的使用。shell 脚本中获取图片的方法直接可用，就是后面设置为桌面的方法 Mac 还是不同的。

然后想到了 AppleScript，折腾了下搞定。不过当时用的 do script 方法，每次都要跳出一个 Terminal 窗口，比较不爽。

然后遭 @adamsxu 鄙视，说回去给我写一个。

第二天参照他的方法换为 do shell，结合之前的设置为壁纸方法。然后再添加到 crontab 中，设置为每 15 分钟更换一次，收工。

确保系统装有 wget、feh

Mac 下安装 wget 的话，需要有 C 编译器，我是从同事那里拷来的 XCode。
首先去 官网下载源程序，解压。然后 terminal 进入 wget 目录。

  	cd ~/wget
  	./configure
	make
	sudo make install

期间看 terminal 的提示操作就好了。

用到的脚本如下。getwallpaper.sh 和 wallpaper.scpt 在文件夹 wallpapers 中，位于 home 路径下。用得时候要修改下相应的路径。

* getwallpaper.sh

	#!/bin/sh
	/usr/local/bin/wget http://sentense.me/  -O - -q |\
	sed -n 's/.*"\([^"]*14400x900[^"]*\.png\)".*/http:\/\/sentense.me\1/p'|\
	/usr/local/bin/wget -i - -P wallpapers -nc -q

* wallpaper.scpt

	do shell script "/Users/gaowhen/wallpapers/./getwallpaper.sh"
	tell application "Finder"
		set theList to files of folder "wallpapers" of folder "gaowhen" of folder "Users" of startup disk
		set theNum to random number from 1 to (count theList) with seed (time of (current date))
		set desktop picture to item theNum of theList
	end tell

然后加入系统的定时任务中。terminal 中

	crontab -e

如果系统中已有 crontab 文件则打开，没有则创建一个新文件，并用 vi 打开。在其中输入

	*/15 * * * * osascript ~/wallpapers/wallpaper.scpt

保存退出(:wq)，一样要注意路径。

crontab 语法

選項與參數：
-u  ：只有 root 才能進行這個任務，亦即幫其他使用者建立/移除 crontab 工作排程；
-e  ：編輯 crontab 的工作內容
-l  ：查閱 crontab 的工作內容
-r  ：移除所有的 crontab 的工作內容，若僅要移除一項，請用 -e 去編輯。

範例一：用 dmtsai 的身份在每天的 12:00 發信給自己
[dmtsai@www ~]$ crontab -e
# 此時會進入 vi 的編輯畫面讓您編輯工作！注意到，每項工作都是一行。
0   12  *  *  * mail dmtsai -s "at 12:00" < /home/dmtsai/.bashrc
#分 時 日 月 週 |<==============指令串========================>|

详情可以参考

• cron维基词条
• 第十六章、例行性工作排程 (crontab)

如果不想折腾，或者嫌弃 sentense.me 的壁纸过于单调的话，还可以尝试下 desklickr。免费软件，自动从 Flickr
获取图片并设为桌面的，也挺不错。

之前在总结最近的一些关于前端开发这个职业的想法。从对团队和个人两方面的要求谈起，折腾了几天，絮絮叨叨地关于个人方面还没写完。

昨天（3月27号）去腾讯北京参加 web 标准交流会第六次活动，讨论前端开发与其他职位的沟通协作问题。突然想到，其实对于团队也好、个人也罢，所有的要求可以概括为两点：“一要专业，二要追求专业”。

首先说下另一个问题：目的。

做一件事情之前，首先要把目的弄明白。列几个至少能说服自己的理由，为什么要做这件事情，做这个会给自己给别人带来什么。明确了目的之后，后续的一切才能有可行的基础，不然指不定轨道会偏到哪里去了。

我们先问问自己为什么要做前端开发这个工作。从目前业内的情况来看，其实这个岗位在公司里受重视程度并不高。而且作为一个衔接上下游的岗位，要掌握的知识以及技能又有很多，与上下游交接之间又存在很多灰色空间。综合来看，前端开发并不是什么舒服的让人羡慕的职业。从我的观点来看，如果仅仅把这个职业当作一个用以赚钱糊口的工作，其实是一件非常痛苦的事情。简直就像在一个地主家扛着漫无目的的长工，工作的每一分钟都是煎熬。

要在这个岗位上坚持下去，需要也须要把它当成自己的事业，才能享受到其中的乐趣。

不过，目前来看尽管好多人发自内心地热爱这个职业，但是没有多少人享受到了乐趣。原因如上：不专业，不追求专业。

这不仅仅是对个人的要求，更是对周围所有人的要求。也就是对整个团队的要求。额外插一句，不要把团队这个概念仅仅限定在周围这几个人身上。要有“大前端”的概念，产品、视觉、前端、后台整个加起来也是一个团队，整个团队是奔着一个目标而去，有这样的气氛和共识，才能尽可能地减少一些不必要的推诿和摩擦。

不专业也不是什么问题，怕就怕只有一部分人追求专业，另一部分浑浑噩噩应付了事，追求上的差异必然导致矛盾的产生。

因此，我现在愈来愈感觉到一个专业的团队对一个有追求的人来说是多么的重要。

在一个不思进取的团队中工作，无论你多么有热情、有激情、多么积极努力，到最后肯定不是被同化，就是被离开。而这个过程不会有什么机会能给个人和团队留下什么有益的东西。

所以，首先要求自己专业化，然后，要么抛掉理想，找个地方混日子去；要么努力向前，找个专业的团队实现理想。

之前都是用文件夹下新建文本文件的方法来记录一些知识。这种知识管理的方法很不方便，有时候想找一些东西的时候会突然找不到。各种 wiki 程序当然是首选，不过对我来说可能本地用得更多一些，正好 Vim 也用了一段时间了，愈发地感觉到了 Vim 的强大。于是就找到了VimWiki 这个插件。

vimwiki 是 Vim 的个人 wiki 插件。– 一个有它自己的高亮语法和链接的文本文件。

使用 vimwiki 你可以：

• 组织笔记和想法；
• 管理待办事项列表；
• 写文档。

虽然目前我对 vimwiki 还不是很熟悉，但是 vimwiki 确实很强大。其强大的语法以及直接转成 html 文档的命令很方便。

这里提供了 vimwiki 的一个 快速指南。

现在 闲耘 正在对 vimwiki 的文档进行翻译，目前已经完成了约 1/4，有兴趣的同学可以关注一下 vimwiki 文档

dropbox + vimwiki

对 dropbox 就不多做介绍了，利用它可以在多机器多系统下很方便的同步资料。

同样，这里也利用 dropbox 打造可同步的 vimwiki 资料库。其实只需要把 vimwiki 资料文件夹指定到 dropbox 同步文件夹中就行了。

在 vimrc 文件加上(Mac 下)

“vimwiki
let g:vimwiki_use_mouse = 1
let g:vimwiki_list = [{'path': '~/Dropbox/vimwiki',
\ 'path_html': '~/Dropbox/vimwiki/html',
\ 'html_header': '~/Dropbox/vimwiki/template/header.tpl',}]

windows 下，修改相应路径就可以了。

通过 Textmate 下的 bundle 才认识了代码的快捷编写方式。

Notepad++ 下有同样的 Quicktext 插件。

VIM 下有好几个类似的插件，这个 snipMate : Textmate-style snippets for Vim 是我觉得用着最舒服的一个。虽然现在也有 VIM 下的 zencoding 插件了，但是我倒是觉得不怎么需要，或者是我没真正体会 zencoding 强大的缘故？

虽然有人说这样时间长了会忘记拼写，不过用了也不算短的一段时间了，拼写我倒是都还记得。

使用时也是使用 tab 激活，修改 snippet 也是相当方便的，只要修改 vimfiles\snippets 目录下的相应文件就可以了。

这里共享下我用的 css 和 html 的 snippets。

ziduu：snippets.zip

box.net snippets.zip

话说各类编辑器我还真用过不少。最好的时候用过 Ultraedit，后来用 Editplus 编辑 html，Topstyle 编辑 css。再后来入了小二黑，发现水果上既好看又好用的编辑器也好多，尝试了 Coda，Espresso, 后来一直用 TextMate。TextMate 除了不能完美支持中文外，它的 blackboard 主题以及各类 bundle 应用真是强大啊。

再后来配了台式机，在 PC 下用上了 Notepad++，它的 QuickText 和 TextMate 里面的 bundle 的快捷键以及激活键都不一样，很别扭。费劲巴拉地把快捷键基本统一之后，Np 要用 Ctrl+P¹ 激活，而 TextMate 是用 Tab 激活，这两者在用的时候老是会搞混。而且在家用 TextMate，在公司用 Np，这个切换的过程很难受。

鉴于在不通编辑器间移动的痛苦和更换熟悉编辑器的成本，我想找一个跨平台的来保持统一性。Aptana 和 IntellJ IDEA
倒是都满足，而且功能都很强大，但是我觉得它们算是 IDE 了，比较臃肿，而且 Java 的东西，启动速度有点慢。于是我就想到了我一直不间断尝试而未掌握的 VIM。

VIM 的强大自然不用多说了，我之前一直觉得不能掌握的原因大致如此：

• 没有适合的配置

之前都是拿网上所谓的最强大的配置文件来用，虽然确实是强大无比，但是不适合自己，而且那么长的配置文件，看着也晕。这次是慢慢从最基础的解决文字乱码开始，一点一点地增加配置，用来满足自己的一些需求。这样在自己理解的基础上也可以做些调整，不会像以前那样一头雾水。现在的配置文件很短，但是加上几个插件，完全可以满足目前日常的使用和大量关于 Html 和 css 的工作。

• 学而不用。
  有句话说的好，VIM 不是学出来的，而是用出来的。以前帮助文件看得多，实际用得少。现在虽然还是只了解一些基础的命令，但是用起来也已经比较熟练了，一些稍微高级点的命令可以慢慢再去摸索。简单命令虽然笨点，但是依然有效。

以下是我目前的配置文件，大部分有注释，应该能看懂，看不懂的话先 Goodu² 再问。

1. [1] 最新的 Np + QuickText 已经可以修改激活键。
2. [2] Google + Baidu = Goodu

set nocompatible

source $VIMRUNTIME/vimrc_example.vim

source $VIMRUNTIME/mswin.vim

behave mswin

set diffexpr=MyDiff()

function MyDiff()

let opt = ‘-a –binary ‘

if &diffopt =~ ‘icase’ | let opt = opt . ‘-i ‘ | endif

if &diffopt =~ ‘iwhite’ | let opt = opt . ‘-b ‘ | endif

let arg1 = v:fname_in

if arg1 =~ ‘ ‘ | let arg1 = ‘”‘ . arg1 . ‘”‘ | endif

let arg2 = v:fname_new

if arg2 =~ ‘ ‘ | let arg2 = ‘”‘ . arg2 . ‘”‘ | endif

let arg3 = v:fname_out

if arg3 =~ ‘ ‘ | let arg3 = ‘”‘ . arg3 . ‘”‘ | endif

let eq = ”

if $VIMRUNTIME =~ ‘ ‘

if &sh =~ ‘\<cmd’

let cmd = ‘”"‘ . $VIMRUNTIME . ‘\diff”‘

let eq = ‘”‘

else

let cmd = substitute($VIMRUNTIME, ‘ ‘, ‘” ‘, ”) . ‘\diff”‘

endif

else

let cmd = $VIMRUNTIME . ‘\diff’

endif

silent execute ‘!’ . cmd . ‘ ‘ . opt . arg1 . ‘ ‘ . arg2 . ‘ > ‘ . arg3 . eq

endfunction

“处理文本中显示乱码

set encoding=utf-8

set fileencodings=utf-8,chinese,latin-1

if has(“win32″)

set fileencoding=chinese

else

set fileencoding=utf-8

endif

“处理菜单及右键菜单乱码

source $VIMRUNTIME/delmenu.vim

source $VIMRUNTIME/menu.vim

“处理consle输出乱码

language messages zh_CN.utf-8

“font

“set guifont=Monaco:h10:cANSI

set guifont=Courier_New:h11:cANSI

“set guifontwide=YouYuan:h11:cGB2312

“”set guifont=YaHei_Consolas_Hybrid:h11:cANSI

“设置tab大小

set tabstop=4

“隐藏工具栏

set guioptions-=T

set guioptions-=m

“不产生bak文件()

set nobackup

“显示行号

set nu

“自动缩进

set autoindent

“colo

“colo blackboard

colo textmate

“NERDTree

map td :NERDTree <CR>

“自动识别文件类型，自动匹配对应的文件

filetype on

filetype plugin on

“高亮显示匹配的括号

set showmatch

“Calendar

let g:calendar_diary=’d:\diary’

map ca :Calendar<cr>

“自动闭合各类括号

if has(“autocmd”)

filetype plugin indent on

augroup vimrcEx

au!

autocmd FileType text setlocal textwidth=78

autocmd BufReadPost *

\ if line(“‘\”") > 0 && line(“‘\”") <= line(“$”) |

\   exe “normal g`\”" |

\ endif

augroup END

function! AutoClose()

:inoremap ( ()<ESC>i

:inoremap ” “”<ESC>i

:inoremap ‘ ”<ESC>i

:inoremap { {}<ESC>i

:inoremap [ []<ESC>i

:inoremap ) <c-r>=ClosePair(‘)’)<CR>

:inoremap } <c-r>=ClosePair(‘}’)<CR>

:inoremap ] <c-r>=ClosePair(‘]’)<CR>

endf

function! ClosePair(char)

if getline(‘.’)[col('.') - 1] == a:char

return “\<Right>”

else

return a:char

endif

endf

“auto close for PHP and Javascript script

au FileType php,c,python,javascript,html,css exe AutoClose()

endif

” 确保语法高亮

if exists(“syntax_on”)

syntax reset

else

syntax on

endif

“fullscreen

map <F11> <Esc>:call libcallnr(“gvimfullscreen.dll”, “ToggleFullScreen”, 0)<CR>

“opacity

“map <F10> <ESC>:call libcallnr(“vimtweak.dll”, “SetAlpha”, 200)<CR>

“set mapleader

let mapleader=”,”

“fast reload the .vimrc

map <silent> <leader>ss :source d:\vim\_vimrc<cr>

“fast edit the .vimrc

map <silent> <leader>ee :e d:\vim\_vimrc

“when .vimrc is edited, auto reload

autocmd! bufwritepost _vimrc source d:\vim\_vimrc

set fdm=indent

set shiftwidth=4

上周六的时候去参加了《Web标准交流会》的第二期活动。有收获，也有点感想。

之前的时候只是知道自己在专业知识方面肯定有差距，但差距多大，差在哪里不知道。这次的交流会就一点一点地把这些差距给具现化了。汗颜啊，差距不是一般大。可能有这种感觉的人都抱着学习的态度老老实实地“听课”了，造成了这次相对短时间的快速解决了问题。然后大家开始大眼瞪小眼，两眼瞪四眼。不过后半程的气氛明显热烈起来，大家的热气和积极性都慢慢热起来了。因此，可以说这次的交流会是个慢热的过程。可能如一个朋友提议的一样，大牛们更适合做总结，前期应该让更多的未来大牛们多发表意见。

偶尔提到css选择符的从右向左匹配问题，显然是一个关于效率的问题。有人说这个影响不大，有人说还需要考虑。再用一个小例子，*号通配符的Reset，大家都知道肯定有效率问题，那有人说这么做不好，有人说可以忽略，凭感觉和自己单方面的认知去PK的话，我觉得这个问题无解，至少谁也无法说服谁。

这里就反映出一个问题，关于一个方法的好坏，现在大多还是没有具体的数据证明，而单单凭赶紧说好坏，显然是不严谨的。这方面，国外显然做的比我们好些，关于css选择符的效率问题，我近期看了些文章，也正准备做些总结。给我印象最深刻的是，国外的文章大多有实际测试的数据，而国内的文章鲜有测试数据。这从一个侧面反映了我们研究问题的标准思想以及方法的缺失，这些都是应该在大学教育时普及的，可惜的是我们的大学教育依然再延续应试教育的老路，而没有交给我们做研究的方法，至少我的大学是这样的。当然这种研究不是人人必须做的，但是肯定需要一部分人去做。

所以，看见一些人的图表的时候我还是很欣喜的，提及的一些工具也解了我一个很大的疑惑。此行除了人际方面的拓广外，这是我最值得高兴的一个收获了。

会后的总结裕波一直有些自责，我倒认为大可不必。无论任何方面的提高，肯定都需要一个过程，想靠短期的交流达到立竿见影的效果显然不是很现实。每一次的交流会都是一个量的增加，这个量达到一定程度，才有可能由量变产生质变嘛。因此能长期稳定的举办类此的交流会才是目的，各位工作人员以及为此付出了很多努力，再为这些而自责就没有必要了。

看到崔凯的总结，很认同他说的第三点教就是最好的学，分享时第一受益者其实是分享者本人。要分享，就得从头去梳理下相关的知识，这个梳理的过程中可能会发现一些以前没注意的更细致的问题。这和我们做前端观察的想法其实是一样的，作为英语不是母语的人来说，读英文的文章一来有点头疼，二来读的能有多深入就不好说了。翻译就不一样，要一字一句的揣摩，因此最大的受益者其实是我们自己，分享不只是提高了别人，同时也有益于我们自己，何乐而不为呢？

谢谢工作人员的无私付出，也希望交流会越办越好。