我对《高达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)
{
// 验证通过，继续操作
}HTML 5的<video>是一个相当不错的标签，但是它刚发布的时间，最大的问题是它不能像Flash那样实现真正的全屏。幸好，几个月后，大部分浏览器已经原生地支持全屏。
在2011年10月15日，W3C发布了一份全屏API草案（由Opera团队的一名成员编写），它跟Mozilla的草案有两个主要的不同点：
在HTML中指定一个区域放置时钟：
<div id="clock" style="position: relative;"></div>时钟的一些外观设定：
var width = 260; // 桌布宽度
var height= 260; // 桌布高度
var dot = {
x : width / 2,
y : height / 2,
radius : 6
}; // 圆点位置、半径
var radius = 120; // 圆半径
var borderWidth = 6; // 圆边框宽度