文接上篇，本篇主要讲一下工作以外的事情。
正式入职后，HR安排了一系列的培训，让新人熟悉公司的历史、文化、制度等。此外，公司还给应届毕业生组织了广州一日游，我虽是广州人，但广州的很多景点也没去过，所以也跟着一起去了。没想到这一去还闹出大麻烦了。旅游当天天气很热，车里面又有空调，结果进进出出，冷热切换频繁，导致重感冒，几天后的户外拓展也只好缺席了。
当年前端组和美术中心有一个团队博客，为了鼓励大家发文章，每个月都会进行一次投票，得票最多的前几篇文章的作者，可获得购物卡。久而久之，优秀文章也不少，部分文章还被转到蓝色理想。不过这个博客最终还是走向了没落，现在UED163.com已经不可访问了。
食堂在网易大厦10F，我刚入职那会儿，很多菜都是辣的，吃着很不习惯。后来换了家承包商，合口味多了。
每年中秋节前，公司都会举办一次美食节。简单来说，就是当天食堂有很多好吃的，想吃什么拿什么，想吃多少拿多少。不过糟糕的是，大家都忙着拿吃的，现场堵得水泄不通。
从网易离职之后，我选择了进入另一个领域——后端开发。之所以做这个选择，是想让自己的知识更全面些。后端技术中，我最熟悉的就是ASP.NET，找工作的时候自然也是往这个方向找。然而，做互联网的人都知道，能在自家产品中应用微软技术的，是少之又少，3G门户是其中一家。
用过手机上网的朋友都应该知道3G门户网站（3G.cn），它可以说是国内最早的移动门户网站。经过几轮面试，我顺利被这家公司录用，不过由于我在ASP.NET方面的经验并不丰富，所以薪资还是跟在网易的时候差不多。
公司给我安排的辅导员是一位项目经理（不过真正辅导我的是另一位同事），在他身上我学到了不少项目管理的经验，其中最有趣的是打牌。这里的打牌既不是锄大地也不是斗地主，而是评估某项功能工时的时候，每人以半天为时间单位打出自己的牌（比如1天，就打数字为2的牌）。如果大家评估的工时不一致，就得各自说明原因后再决定；如果大家都评估出较长的工时，则把这项功能分解为几项子功能后再评估。
我对《高达SEED》这部动画的印象是非常深刻的，除了剧情和机械设定的吸引，最重要的是它曾经带给我很多美好的回忆。
《高达SEED》首播期间，我在读高中。当时是每逢周六播一集，一般当天晚上就有生肉（没字幕的版本），第二天就有清晰度稍低的熟肉（带字幕的版本），大约一周后就有清晰度稍高的熟肉。那会儿家里还是用的56K拨号网络，下载一集的时间成本和金钱成本都挺高的，所以主要还是求助于家里有ADSL的亲戚和同学帮忙下载，再用一个旧硬盘拷回来。而那时候的硬盘容量还在几十G的水平，不断往里面塞视频的话，很快就会满。所以在凑够一定集数之后，我就把它们刻录成光盘保存。班上几个感情比较好的同学也问我借这些光盘，拷回家里看（成非法传播了）。
此外，我还开办了高达主题的网站和论坛，它们随着《高达SEED》的播出而红火，也随着《SEED Destiny》的结束而没落。这里面有我与几位网友的努力及不舍。
在动网先锋篇中提到，由于各种原因，我并没有回到动网公司工作。后来，我在BlueIdea论坛看到网易招页面工程师的贴子，投简历后没多久就接到面试通知。第一轮是技术面，跟美术总监以及前端主管聊了一会儿，过程非常简短；第二轮是HR面，其实也就是形式上过一下。之后没多久就接到主管电话，让我注册一个网易泡泡帐号，然后把我拉进了前端组的泡泡群。不过正式入职还要等老板签字后，由HR通知。
这一等就是一个月，刚好在上班前把毕业设计做完了。当时前端组隶属美术中心，仅负责HTML+CSS。至于我的职位，既不是前端工程师也不是页面工程师更不是JS工程师，而是美术编辑。工作方面，就是不断重复接工作单、做页面、提交这个过程。虽然可以提高技能水平，不过做的页面比较零散，没什么成就感。然而，没过多久，部门就重组了，主要变化是：
时至今日，还有人讨论前端应该隶属设计部门还是技术部门，站在自己的角度，我更偏向于后者。为什么呢？因为，我跟技术同事有更多的共同语言。
2007年上半年，当时的我是一名大三的学生，按照学院的安排，暑假就要开始实习了。实习岗位可以由学院安排（当然名额有限）、自己去找、或者跟老师做项目。学院提供的大多是软件开发的岗位，而我自己的兴趣则在Web方面，所以我更希望去互联网公司实习。正当伤脑筋之际，我在动网先锋网络科技有限公司（下面简称动网公司）官方论坛看到一则消息说他们来广州发展业务了。
2005年，我使用BBSXP搭建了一个以Gundam为主题的论坛，后来论坛被SQL注入盗取了管理员密码，我便转而使用更安全、更强大的动网论坛程序（下面简称Dvbbs）。使用Dvbbs以来，改皮肤、装插件，折腾过很多次，可以说对其非常熟悉。
我急忙写了一封求职信，把这两年来使用Dvbbs的经历都写在上面，并以Email形式发给了他们。然而，过了一段时间之后并没有收到回复。此时，辅导员催促我们赶紧落实实习，于是，我又发了一封Email过去。不久，他们回电话给我，说让我去面试。这是我第一次找工作，因为本来就没什么经验，所以就没写简历。面试官是符先生（管行政的）以及孙先生（管技术的），聊了一段时间后。他们同意让我去实习，并确定了到职时间以及实习补助费。除此以外，他们也希望我在实习过后能够继续留下来工作，当然，那时候我也是这么想的。
最近一年都在用Notepad++进行开发，这个工具实在是有不少缺点，于是就在考虑换一个开发环境。候选者是WebStorm和Sublime。WebStorm是一个名副其实的IDE，启动慢，配置复杂，用起来非常不爽；相比起来，Sublime要轻很多，且五脏俱全。
（注：WebStorm和Sublime都是收费软件，WebStorm有一段试用期，而Sublime的未注册版偶尔会在保存的时候提示购买）
Sublime最吸引人的是其代码高亮，各种颜色搭配地完美无瑕，赏心悦目。
另一亮点是代码缩略图。这个功能在其他工具中从未见到过，不过实际作用并不大，主要就是实现快速跳转罢了。
npm是Node.JS的程序包管理器。进行Node.JS开发时，经常使用它安装/卸载程序包。实际上，发布程序包的工作也是由它来完成的。
要打包程序，首先要配好各项设置，这些设置都由程序包根目录下的package.json指定。package.json的内容必须是严格的JSON格式，也就是说：
配置对象的属性很多，具体可以参阅这里，这里列一下常用的项目：
前段时间我开始基于SeaJS开发2.0版本的JRaiser，主要目的就是把这个库模块化。结合实际开发过程中遇到的问题，我重新写了一个更符合自身需求的JRaiser Loader以代替SeaJS（另一方面也是为了亲手写一个Loader）。与SeaJS一样，JRaiser Loader也是Wrappings规范（关于AMD与Wrappings的区别，这篇文章有详细说明）的实现，主要接口也与SeaJS保持一致（但功能暂时比SeaJS少）。下面以JRaiser Loader的实现为例介绍一下Loader的实现原理。
先介绍几个术语：
在模块化开发中，一个模块可以依赖于任意个模块，而被它依赖的模块又可以依赖于任意个其他模块。这就要求加载模块时必须一层一层把所有依赖的模块都加载进来，类似于树的遍历。由于前端动态加载JS的过程是异步的，也就是说，这是异步的遍历。在算法上，JRaiser Loader采取自顶向下的遍历方式以及自底向上的通知方式。假设有A、B、C三个模块，A依赖于B，B依赖于C。当通过加载A模块时，其加载过程如下（红色箭头部分为异步流程）：
一谈到路径相关的问题，大家都会往window.location上想，确实这个对象提供了相当多的路径信息，其中常用的就包括：
然而，location没有一个属性能直接获得当前目录（不含文件名）的绝对路径。通过Google我发现了一些错误的方法，比如说把URL通过“/”分离成数组，把数组的最后一项去掉以后再连接成字符串。但如果URL中没有指定文件名，结果就大错特错了。
根据以往编码的经验，a元素的href属性总是会返回绝对路径，也就是说它具有把相对路径转成绝对路径的能力。使用下面的代码尝试了一下，果然成了：
var a = document.createElement('a');
a.href = './';
alert(a.href);
a = null;一般来说，我们会把验证码的值用Session存储起来，通过对比用户提交的验证码和Session中的验证码，就可以知道输入是否正确。由于Session会占用服务器资源，我曾经想过是否可以把验证码的值加密后存储在Cookie中。不过事实证明，这只是异想天开罢了。
假设验证码的值是a，通过sha1加密后得到的值为b = sha1(a)，并且把b存储在Cookie中。而用户提交的验证码值为c，通过判断sha1(c)是否与b相等，可以知道输入的验证码是否正确。然而，Cookie是受客户端控制的。如果用户事先通过肉眼看到验证码的值是a，又从Cookie中得知此时的加密值为b，那么，他只要在提交前把Cookie的值修改为b，提交的验证码值为a，就可以永远通过验证。
这种情况可以直接用代码来说明：
if (Request["captcha"] == Session["captcha"] as string)
{
// 验证通过，继续操作
}