有时候会有心浮气躁的感觉，看看主机搬迁恢复以来的第一篇《第一篇，仅此而已》，很无奈的感觉~

下面不知道写些什么了，这就是我目前的状态吧，希望自己能尽快的调整过来~

之前都是随性直接写的，今年感觉自己做的事情有些凌乱，甚至都不太记得了。总的来说2011这年没有进行太多的挖掘，而是更多的时间去释放精力，偏重生活要多于技能的提高，工作三年多了，身边接触的朋友同事和之前的有些不太一样（老朋友、新朋友大家都有些工作年限），茶前饭后不像刚来到异地工作时那份对生活美好的向往，以前工作就像打了鸡血一样。而现在更多的是工作选择的迷茫，家里的房子空的，人在外地租房子上班，还有几个朋友被婚前婚后分居工作生活困扰，IT行业在二线城市做起来真的不给力。虽然我还是孤身一人，但我也渐渐的进入适应了大家讨论的话题。有《网易新闻2011年终策划：最好的生活》的感觉。

2012快乐的工作生活状态 — 300天有么

2011回顾下：

工作时间

#多屏相关项目，电视屏 > 后台管理系统 > 手机屏 > PC屛

(PS：HTML5就像打折一样喊得到处都是，来年主要学习扩充基础知识面，新知识也要跟进，但我将其排在次级，真的还有很多要学)

个人时间

#大部分是在睡觉

#买了扎古红色MG — 仅做了拼接工作，打磨、水贴、消光什么的都没有折腾（AJ和Rex好这一口多些，Tom造型帝，经常给我的红扎摆各种猥琐的动作，可见内心的强大）

#从iphone换到android — iphone一代丢了（不说了，无语~），换了G12刷了MIUI系统，用起来感觉还不错，和iPhone的体验差距一直在缩小，很不错的ROM，新买的第一周在公车上拆掉保护壳欣赏背面（HTC的背面真的好丑），下车的时候保护壳丢了。。 还好不是新买的手机掉了，师大附近买了黑色磨砂（坏了），换了Rock轻彩的黄色壳子。

#入手松下GF3，还在试用感觉不错

#博客空间从Wopus国外转到Elinkhost国内 — 拥抱HTML5和webrebuild年会上中奖得到的Elinkhost香港空间，速度提升了许多，断过一次，易联小黄帮忙解决了。

#将显卡（好像是世盟的，后来又测出是七彩虹的，各种XX），换成ZOTAC 索泰 GT440-1GD5雷霆版 MA 显卡(GT440芯片组/1024M/GDDR5)，给力多了，现在确定下来剩余的噪音是由机箱不给力造成的轰鸣，用云南白药的牙膏顶在侧面施压OK消除大概70%

#入手G13 – 给小妹买了白色的G13，刚出来的比较新，没有找到给力的破解，各种没权限+中毒。。 回家重新给刷下系统

#三张存储卡 — 东芝8G C10、三星 8GC6、Lexar 雷克沙 16G C6 ，个人感觉8G其实已经足够了，速度上东芝、三星的要比雷克沙的要快很多，一分价格一分货（PS.易讯上买这些小数码商品还是挺给力的，包邮、品质、售后）

#搬家 – 总的来说还不错相比之前的住房：面积*2、 价钱/2、 距离*2、 小区环境*4

#尝试重新激活个人淘宝店 — 今年到不了四钻了，做的是虚拟，实体的客服售后没有时间精力去搞（之前尝试过七匹狼皮具经营），不用担心，这不会影响自己的工作时间，都是自动发货的，下班后到家review一下待处理信息。

#水果零食吃的比以前多了 — 基本每周会有一次去逛下大超市，KEY：柚子、薯片、果汁等一些。

#读书 — 书买了一些，读的没有几本，要养成看书的习惯

#游戏 — 手机游戏、war3基本上是这两个（喜欢看xiaoY解说，尤其是吃饭的时候。。）

#女友 — 没走到一起，随缘吧~

#博客&微博 — 微博主要是用来收集信息的，用的不太多，个人觉得会分散掉很多时间；博客更新频率不高，深入的内容不多，还抽了些时间折腾了主题，还有很多地方需要去完善，内容笔记的更新还是在第一位。

到这里吧，还有公司的周报、年底总结要写，新年快乐~

公司从分部调来一位前端MM，以缓解最近项目上的压力，毕竟目前公司的整个项目流程上前端这个位置处于瓶颈（我们整个工作流程视为环链，决定环链的强度的关键因素在于最弱的那个环，也就是说最弱的那个环就是我们所说的制约因素、瓶颈，部门的工作成果品质或是效率，并不会因为某个人的出色表现而如何如何。）

另一方面也是为了减少沟通成本，团队起步期需要逐渐形成规范文档，加强团队配合。下面是工作沟通过程中的其中一部分：

代码精简取舍

关于模块化一词，在工作中被很多人谈到认可，之前整理了两篇相关的《淘宝栅栏布局模块化命名浅析》、《Column布局参考 – 圣杯》大体记录整站或单页面中的一种布局及命名方式。

这篇不会给出小模块的细节部分代码示例，网上真的很多，例如 Ghost的这篇《页面重构中的模块化思维》及文中提到的《从宜家的家具设计讲模块化》 ，这些都是中工作生活中累积下来的，和前端知识收集与管理习惯有关，这里让我想起一些微博上的一些短句：“别人比你牛B并不可怕，可怕的是比你牛B的人比你更努力。” 真的压力好大，想想自己除了工作，大部分时间都在吃睡玩，在此写出来勉励下自己博客要坚持更新。

鸡蛋的例子

上图结合代码重构可以简单的理解为：

a.鸡蛋数量较少时 – 减少使用固蛋装置，书写精简的HTML结构会显得很自然贴切

b.鸡蛋数量适中时 - 使用固蛋装置，将一枚枚鸡蛋嵌入到已经制作好的模具中，方便存取及安全防护

c.鸡蛋数量较多时 - 可能会用到不同的交通工具输送到不同的场合时，使用固蛋装置，多个模块的平稳融合，方便存取、安全防护及协作维护

在网站重构过程中，项目初期适当的增加标签嵌套，尽量的统一每个模块中的标签结构，同时注意标签语义化，并为这些结构标签添加统一规则的类命名，使得制作出的模型有统一的接口（凹槽、挂钩），方便后期的扩展、降低维护成本。重构工作入门相对简单，但越是简单的东西，要处理的贴切得当，过程中所要做出的取舍需要不断的总结积累。

欢迎拍砖哈，共同进步~

这一年的经历包括到现在，让我认识到了很多，心态较上一年更加的平稳了。折腾了这么多事情，发现我还能活着，这真是太好了。

87年到现在，到今天我才真正认识到自己已不再是个孩子了。很多事情，公司的也好、个人的也好，都应该换一个角度去看待，不再只有期待和等待了，比如像小的时候，只要你乖或者不乖，就会有糖吃或是别的奖励。现在只能自己争取，看见同龄人有的已是为人父母，有的已是事业有成。

忽然间发现自己什么都不会，家里的一些习俗，甚至是连回家的路都不记得了。变化的实在是太快了，这里的人每个都很真实，都很热情，但能叫上名字的却不多。

2011年我在这里写下，我要用两倍的努力去丰富自己，改变自己。自己的专业技能只是其中的一部分，但很重要，直接关系到我的温饱。你会发现博客的更新情况会较往年的要好很多，之前有和Cherry还有Linda谈到过（这里不写全名了..），也很高兴她们能参与进来，我希望我们能够将自己工作学习包括生活中的一些积极的信息记录下来，相互鼓励相互学习。
不去在意访问数、评论等一些外在因素，当然我不会关闭评论，不想闭门造车，我知道我们整理的东西，还是很需要有人能来指点的。

任何事情都有个过程，博客能够坚持更新下去，这一年就一定是有收获的。

我常扮演人群中比较安静的一个角色，并不是因为韬光养略，而是我能量不太够.

－－－－－－－－－－－－－－－

我对facebook的运转着迷。这是一个很独特的环境，不容易被复制（他们的体系并不适合所有的公司，即使他们努力尝试过）。下面是我和facebook的朋友们关于他们如何开发和管理项目的记录。

现在距离我收集的这些信息又过去6个月了，我相信facebook肯定又对他们的项目开发实践进行了改进。所以这些记录可能会有点过时。同时facebook的工程师驱动文化也越来越为大众所知。非常感谢那些帮助我整理这篇文章的facebook的朋友们。

记录：

• 截止到2010年6月，facebook有将近2000名员工，10个月前只有1100名，一年之间差不多翻了一番。
• 两个最大的部门是工程师和运维，每个部门大概都是400-500人。这两个部门人数大约占了公司的一半。
• 产品经理与工程师的比例大约为1-7到1-10。
• 每个工程师入职时，都要接收4-6周的培训，通过修补bugs和听高级开发工程师的课程来熟悉facebook。
• 培训结束后，每个工程师都可以接触线上的数据库(更大的权力意味着更大的责任，也有一份”勿做清单”，不然可能会被开，比如共享用户的隐私数据)。
• 有非常牢靠的安全体系，以免有人不小心/故意做了些不好的事。
• 每个工程师可以修改facebook的任何代码，随时可以迁入。
• 浓厚的工程师驱动文化。”产品经理基本可以被忽略”，这是facebook一名员工的话。工程师可以修改流程的细节，重新安排工作任务，随时植入自己的想法。
• 在每月的跨部门会议上，由工程师来汇报工作进度，市场部和产品经理会出席会议，也可以做些简短的发言，但如果说得太多，很可能就会被打小报告。他们确实想让工程师来主导产品的开发，对自己的产品负责。
• 项目需要的资源都是自愿的
  • 一个产品经理把工程师们召集到一起，让他们对他的想法产生兴趣。
  • 工程师们决定开发那些让他们感兴趣的特性。
  • 工程师跟他们的经理说：”我下周想开发这5个新特性”。
  • 经理会让工程师独立开发，可能有时会让他优先完成一些特性。
  • 工程师独立完成所有的特性——前端/后端/数据库，等等所有相关的部分。如果需要得到设计人员的帮助，需要先让设计人员对你的想法产生兴趣。其他如架构之类的也一样。但总体来说，工程师要独立完成所有的任务。
• 对于某个特性是否值得开发的争论，通常是这么解决的：花一个星期的时间完成他，并在小部分人群中(如1%)进行测试。
• 工程师常常希望解决难题，这能获得声望和尊敬。他们很难对前端项目或UI设计产生太大的兴趣。这跟其他公司可能正好相反。在facebook，后端任务，比如新的feed算法，广告投放算法，memcache优化等等，是工程师真正感兴趣的。
• 所有的代码修改都要进行审核(通过一个或多个工程师)，但News Feed是个例外，因为太重要了，Zuckerberg会亲自review。
• 所有的修改至少要被一个人审核，而且这个系统可以让任何人很方便地审核其他人的代码，即使你没有邀请他
• 工程师负责测试，代码修复，和维护自己的项目。
• 每个办公室或通过VPN连接的员工会使用下一版的facebook，这个版本的facebook会经常更新，通常比公开的早1-12小时。所有的员工被强烈建议提交bugs，而且通常会很快被修复。
• 很奇怪只有很少的QA或自动测试——”大部分工程师都能写出基本没有bug的代码，只是在其他公司他们不需要这么做。如果有QA部门，他们只要把代码写完，扔给他们就行了”
• [针对上一条]我们有自动测试，代码发布前必须要通过测试。我们不相信”所有的工程师都能写出没有bug的代码”，毕竟这是一个商业公司。
• 很奇怪，缺少产品经理的影响和控制——产品经理是很独立的和自由的。产生影响力的关键是与工程师和工程师的领导们们搞好关系。需要大致了解技术，不要提一些愚蠢的想法。
• 所有提交的代码每周二打包一次。
• 只要多一分努力，终于一天会发生改变。
• 星期二的代码发布，需要所有的提交过代码的工程师在场。
• 代码打包前，工程师必须在一个特殊的IRC channel上。
• 运维执行打包过程
  • facebook有大约60000台服务器
  • 有9个代码发布级别
  • 最小的级别只有6台服务器
  • 星期二的代码发布会先发布到6台服务器上，运维组会检测这6台服务器的反应，保证代码正常工作，然后再提交到下一级
  • 如果发布出现了一些问题（如报错等等），那么就停止下一级的部署，提交出错代码的工程师负责修复问题，然后从头继续发布。
  • 所以一次发布可能会经历几次重复：1-2-3-fix. 回到1. 1-2-3-4-5-fix. 回到1. 1-2-3-4-5-6-7-8-9
• 运维组是受过严格训练，倍受尊敬，而且有商业意识的。他们的工作包括分析错误日志，负载和内存状态等等。还包括用户行为。
• 代码发布期间，运维组使用IRC-based页面系统，可以通过facebook/email/irc/im/sms ping每一个工程师，如果需要他们注意的话。对运维组不做回应是一件很羞愧的事。
• 代码一旦发布到第9级，并且稳定运行，就算发布成功了。
• 如果一个特性没有按时完成，也没什么大不了的，下次完成时一并发布即可。
• 如果被svn-blamed,public shamed或工作经常疏忽就很可能被开除。”这是一个高效的文化”。不够高效或者不够聪明的员工会被剔除。管理层会在6个月的时间里观察你表现，如果不合格，只能说再见。每一级都是这个待遇，即使是C级别和VP级别，如果不够高效，也会被开除。
• 被责骂不会导致解雇。我们特别尊重别人，原谅别人。大部分高级工程师都或多或少犯过一些严重的错误，包括我。但没有人因此被解雇。
• 我也没有遇到过因为上面提到过的犯错误而被解雇。有些人犯了错，他们会非常努力地去修复，也让其他人得到了学习。

英文原文：How Facebook Ships Code
中文翻译：Facebook 是如何管理代码的

这篇文章在我的草稿箱里呆了两天左右的时间，因为最近手头上的工作较多，产生了一些消极疲惫，我选择用两天的时间来重新看待问题并作出调整（前面有看到唐某的一句话，大致意思是他会选择用两周的沉默时间来思考… …）

没有了消极观念，而是积极应战，帮助自己调整好一个良好的心态去面对生活。

一些经历

08年5月份到的上海，到现在已经工作两年零两个月了，记得应聘上第一家公司华印，那天刚好是我的生日，当时很高兴，感觉是跳着回去的:-)

再到后来的蜕变，给了我很大的影响，爽的责任感，腊肉妹的细心，Chenbingo的热情，Grace的蜕变精神等。这些给了我很深刻的印象，这期间我也养成了一些较好的习惯：写博客、每日阅读、定期整理文档、操作体验。

到现在的Milestone大家都很幽默，在快节奏的工作中练就出的一身本领，每个人都有自己拿手的幽默方式，当然我们有自己的学习计划，这是我近两个月的学习，效果还是在的：

SEO学习

近一阶段，完成了SEO的学习，工作学习当中整理了数篇文档，把学到的通过文字、语言的形式表述出来，真的效果加倍。

不过这项工作仍需要大量的实践经验，本身门槛不算高，前端这个职位至少需要了解这一项，在我看来这很重要。

HTML5+CSS3尝试

完成Milestone整站的HTML5、CSS3的新布局重构。

喜欢HTML5的新标签的语义化，页面不只是靠样式来赋予色彩，语义化的标签组合搭配，让我觉得代码一样很好看，就像大家所说的代码如诗。

无穷尽的新特效仍有待学习和发掘。

特殊的力量

4月我遇到了我的GF。这股力量属于现在、未来，我将这股力量看作是永动机，她使我的生活丰富多彩。你不只是像某个电视剧里的一段台词，“我的生活就是这样，除了工作还是工作，下班回到一个暂属于自己的小屋子里，抬头看看天花板…”这种想法是可怕的。

难以想象，我将我的游戏时间缩减到了每周五晚上的2小时WarⅢ，水平也越来越臭了，囧~

小学就读到的一句话：“读书破万卷，下笔如有神”。没事儿看点儿好书。

关于后面要做的事

2010是金牛座忙碌收获的一年，想必每个人都有自己的年底总结，不要把太多时间浪费在重复计划上面，需要的是有效的执行。

Title：前端工程师的知识收集与管理
Description：知识收集与知识管理：包括个人的和团队的，从工具、流程到平台！

本期上海是在The NetCircle，这里很有趣，关键字：酷工厂、苏州河、复式、玻璃缸鱼、碟子；

还有倒着的路标哦:-)：

关于收集知识的工具：
Google Reader 、Notepad 、 FF插件 、 WIZ 、 PKM2 、 Wiki 、 以及本地搭建服务器，其实大伙谈及到的都差不多;

关于规范文档的整理：
赞同Neil同学，团队起步期需要逐渐形成规范文档，加强团队配合;
抛出如何建立遵循文档，来自盛大创新院的童鞋(印象中上海第一届WEB会举办来过的，强人~)指出了其实重要的不是规范文档，每个公司团队都会有自己的规范，而是工作流程当中的有效沟通配合，相对来说更为重要。

对于某同学的规范文档(大家的名字都还不太记得-_-|||)
其中有四点我个人觉得可以改变下：

1、去掉HTML注释，避免IE6的注释BUG；
关于删掉这点不太赞同，因为网站页面的布局SEO人员需要通过注释来了解页面的布局情况，便于作出优化调整；

2、拼音命名
这个是要避免，但不一定是要全部避免，对于SEO来说，重要页面采用拼音命名是被认可的，有时候拼音来的更直接些，甚至是可以是中文汉字命名；

3、图片大小控制
我觉得如果所有的图片都不对其大小进行设置，那么比如：对于一些图文混排的布局，网速慢的情况下，页面上的大图加载前后，会产生“动态效果”；

4、CSS书写顺序，先外观后..
这个是习惯问题，我比较倾向于按字母a-z的顺序来书写样式文档；

另外使我印象比较深刻的是：
这是第二次见某位同学准备好了稿子发言，向他学习；
还有在语言表达方面，语言层次分明，断句断词处敲到好处，不像我一股脑的说完，多听多思考比较；

PPT分享部分：
感谢Neil同学的PPT分享，这里我做了下简单的记录：

《敏捷开发》

敏捷开发

传统开发：1 2 3 4 瀑布式 传统开发方法问题

敏捷(Scrum)开发优点

如何进行敏捷开发

敏捷开发来历

敏捷开发团队组成

•7-15人
•管理者主持
•… …

大团队的组成

Scrum开发团队的组成

Scrum开发人员角色和责任

Scrum开发是如何工作

Scrum工作流程图

Scrum工作与审查

总结：用敏捷开发的优势

•可迅速满足不断变化的需求
•… …

缺点
•不适合大型项目的开发
•不适合跨区域（地理）的发展
•可能导致长期成本的升高
•不适合自下而上的工程
•… …

Scrum开发的核心就是：有组织、有计划、有效率、有目的沟通

如此顺水的写了下来，很荣幸能参与到WEB标准化交流会和大家一起交流分享，相信下一期会更精彩~

PS：.ORG后缀名换成大写的似乎要更cool一些，域名选购相对来说只是了解一些，选择这个域名可能是因为里面有Stone这个单词吧，公司的域名里面刚好也有一个，这样深刻一些。至于说怎么不直接来个www.公司域名2.com，还真没这个勇气~

第六期了，其实上海站还是第二期，刚起步，大家都很用心。

月底了，在结束掉这个月之前还是抓紧时间总结下，总是拖着只会消磨掉自己，我的语句杂乱，就这么整吧。

二期要比一期好些，虽然去的时候说这次没请什么嘉宾，但看起来效果不错，就是觉得前面有2/3的时间都是在陈述，以及抱怨流程中出现的种种情况及问题(自我介绍那段很好，拉近了大家伙的距离，这可能也是这次比上次觉得热闹的原因之一吧)；之后有1/3的时间有PPT的演讲，就是觉得这部分时间有些短，刚好讲完，刚好结束的那种。

很多问题都只是将其浮在表面，大家提供的经历、经验、流程案例用来很好的借鉴，不同性质的工作环境，需要不同的协作流程来应对吧。

前些天刚好有读到《目标》这本书，物理学家与企业管理大师的高德拉特博士写的一本形似小说的读物，文中的一切事情都围绕找出目标，认清方向，分析问题，提出假设，进行验证，持续改进来展开。
比较深刻的词汇是瓶颈、制约因素、衡量指标。
比较深刻的句子：“每个组织都为了某个目的而创办，我们不是只为了组织的存在而创办了我们的组织。”
“假如任何组织都是由一群人所组成的，那么我们可以推论，必须综合众人的努力来达到组织的目的。”

结合到工作流程：小到一个部门的工作流程（我们将其视为环链，决定环链的强度的关键因素在于最弱的那个环），也就是说最弱的那个环就是我们所说的制约因素、瓶颈，部门的工作成果品质或是效率，并不会因为某个人的出色表现而如何如何。

一个很小的假设：如果设计师给到的PS稿，不够精确或是仍有反复修改的可能性，那么负责切图的将会很郁闷，即便两者各自的操作技能再怎么熟练，其中一方总会成为项目进度的制约因素，不是PS稿不确定、就是精度不够丢给另一方调整（xx效果图层、xx栏宽..、已经不像以前的table布局可以方便的手动拖拽了），这样一来，单就静态页制作这块就已经是弱环了，拖累了整个项目的进度。

因此，沟通很重要，有效沟通很难得，如何有效沟通是一个不断尝试的过程 (PPT还没有细看，先标记到这里吧~)

最后感谢携程的场地提供，感谢WEB标准化交流会能把我们聚在一起，感谢大家的PPT分享。

此篇只为Cherry，我的好朋友。