工作经历(三)——3G门户篇

工作生活  |  4年前

从网易离职之后,我选择了进入另一个领域——后端开发。之所以做这个选择,是想让自己的知识更全面些。后端技术中,我最熟悉的就是ASP.NET,找工作的时候自然也是往这个方向找。然而,做互联网的人都知道,能在自家产品中应用微软技术的,是少之又少,3G门户是其中一家。

用过手机上网的朋友都应该知道3G门户网站(3G.cn),它可以说是国内最早的移动门户网站。经过几轮面试,我顺利被这家公司录用,不过由于我在ASP.NET方面的经验并不丰富,所以薪资还是跟在网易的时候差不多。

公司给我安排的辅导员是一位项目经理(不过真正辅导我的是另一位同事),在他身上我学到了不少项目管理的经验,其中最有趣的是打牌。这里的打牌既不是锄大地也不是斗地主,而是评估某项功能工时的时候,每人以半天为时间单位打出自己的牌(比如1天,就打数字为2的牌)。如果大家评估的工时不一致,就得各自说明原因后再决定;如果大家都评估出较长的工时,则把这项功能分解为几项子功能后再评估。

1044次阅读,2条评论

写在《高达SEED重制版》即将结束之际

工作生活  |  4年前

我对《高达SEED》这部动画的印象是非常深刻的,除了剧情和机械设定的吸引,最重要的是它曾经带给我很多美好的回忆。

《高达SEED》首播期间,我在读高中。当时是每逢周六播一集,一般当天晚上就有生肉(没字幕的版本),第二天就有清晰度稍低的熟肉(带字幕的版本),大约一周后就有清晰度稍高的熟肉。那会儿家里还是用的56K拨号网络,下载一集的时间成本和金钱成本都挺高的,所以主要还是求助于家里有ADSL的亲戚和同学帮忙下载,再用一个旧硬盘拷回来。而那时候的硬盘容量还在几十G的水平,不断往里面塞视频的话,很快就会满。所以在凑够一定集数之后,我就把它们刻录成光盘保存。班上几个感情比较好的同学也问我借这些光盘,拷回家里看(成非法传播了)。

此外,我还开办了高达主题的网站和论坛,它们随着《高达SEED》的播出而红火,也随着《SEED Destiny》的结束而没落。这里面有我与几位网友的努力及不舍。

BBS.GundamGene.Net

1643次阅读,3条评论

工作经历(二)——网易上篇

工作生活  |  4年前

动网先锋篇中提到,由于各种原因,我并没有回到动网公司工作。后来,我在BlueIdea论坛看到网易招页面工程师的贴子,投简历后没多久就接到面试通知。第一轮是技术面,跟美术总监以及前端主管聊了一会儿,过程非常简短;第二轮是HR面,其实也就是形式上过一下。之后没多久就接到主管电话,让我注册一个网易泡泡帐号,然后把我拉进了前端组的泡泡群。不过正式入职还要等老板签字后,由HR通知。

这一等就是一个月,刚好在上班前把毕业设计做完了。当时前端组隶属美术中心,仅负责HTML+CSS。至于我的职位,既不是前端工程师也不是页面工程师更不是JS工程师,而是美术编辑。工作方面,就是不断重复接工作单、做页面、提交这个过程。虽然可以提高技能水平,不过做的页面比较零散,没什么成就感。然而,没过多久,部门就重组了,主要变化是:

  • 前端组从美术中心划归技术中心。
  • 原技术中心的Flash组、模版组合并到前端组。

时至今日,还有人讨论前端应该隶属设计部门还是技术部门,站在自己的角度,我更偏向于后者。为什么呢?因为,我跟技术同事有更多的共同语言

1207次阅读,9条评论

工作经历(一)——动网先锋篇

工作生活  |  5年前

2007年上半年,当时的我是一名大三的学生,按照学院的安排,暑假就要开始实习了。实习岗位可以由学院安排(当然名额有限)、自己去找、或者跟老师做项目。学院提供的大多是软件开发的岗位,而我自己的兴趣则在Web方面,所以我更希望去互联网公司实习。正当伤脑筋之际,我在动网先锋网络科技有限公司(下面简称动网公司)官方论坛看到一则消息说他们来广州发展业务了。

2005年,我使用BBSXP搭建了一个以Gundam为主题的论坛,后来论坛被SQL注入盗取了管理员密码,我便转而使用更安全、更强大的动网论坛程序(下面简称Dvbbs)。使用Dvbbs以来,改皮肤、装插件,折腾过很多次,可以说对其非常熟悉。

我急忙写了一封求职信,把这两年来使用Dvbbs的经历都写在上面,并以Email形式发给了他们。然而,过了一段时间之后并没有收到回复。此时,辅导员催促我们赶紧落实实习,于是,我又发了一封Email过去。不久,他们回电话给我,说让我去面试。这是我第一次找工作,因为本来就没什么经验,所以就没写简历。面试官是符先生(管行政的)以及孙先生(管技术的),聊了一段时间后。他们同意让我去实习,并确定了到职时间以及实习补助费。除此以外,他们也希望我在实习过后能够继续留下来工作,当然,那时候我也是这么想的。

1111次阅读,6条评论

Sublime配置手记

前端开发  |  5年前

最近一年都在用Notepad++进行开发,这个工具实在是有不少缺点,于是就在考虑换一个开发环境。候选者是WebStorm和Sublime。WebStorm是一个名副其实的IDE,启动慢,配置复杂,用起来非常不爽;相比起来,Sublime要轻很多,且五脏俱全。

(注:WebStorm和Sublime都是收费软件,WebStorm有一段试用期,而Sublime的未注册版偶尔会在保存的时候提示购买)

Sublime最吸引人的是其代码高亮,各种颜色搭配地完美无瑕,赏心悦目。

Sublime代码高亮

另一亮点是代码缩略图。这个功能在其他工具中从未见到过,不过实际作用并不大,主要就是实现快速跳转罢了。

15098次阅读,4条评论

如何使用npm发布Node.JS程序包

Node.js开发  |  5年前

npm是Node.JS的程序包管理器。进行Node.JS开发时,经常使用它安装/卸载程序包。实际上,发布程序包的工作也是由它来完成的。

配置package.json

要打包程序,首先要配好各项设置,这些设置都由程序包根目录下的package.json指定。package.json的内容必须是严格的JSON格式,也就是说:

  • 字符串要用双引号括起来,而不能用单引号;
  • 属性名一定要加双引号
  • 最后一个属性后千万不要多加一个逗号

配置对象的属性很多,具体可以参阅这里,这里列一下常用的项目:

  • name:程序包名,不能跟已有的程序包重复。
  • version:版本号。
  • description:一段简短的介绍。
  • author:作者信息。包含name、email、url三项属性。
  • bin:如果程序中有可执行文件(主要是命令行里面调用的),就在这里指定,可以指定多个。
  • main:使用require调用本程序包时的程序入口。
  • dependencies:依赖的程序包,可以指定版本号。
7023次阅读,1条评论

Javascript Module Loader实现原理

前端开发  |  5年前

前段时间我开始基于SeaJS开发2.0版本的JRaiser,主要目的就是把这个库模块化。结合实际开发过程中遇到的问题,我重新写了一个更符合自身需求的JRaiser Loader以代替SeaJS(另一方面也是为了亲手写一个Loader)。与SeaJS一样,JRaiser Loader也是Wrappings规范(关于AMD与Wrappings的区别,这篇文章有详细说明)的实现,主要接口也与SeaJS保持一致(但功能暂时比SeaJS少)。下面以JRaiser Loader的实现为例介绍一下Loader的实现原理。

先介绍几个术语:

  • 模块:模块化开发中的一个功能单元。它有一个唯一的Id作为标识,并可以依赖于其他模块。
  • 任务:全局require函数的回调函数。在JRaiser Loader的内部处理中,任务也是模块。
  • 就绪:当某个模块已经加载完成,并且不依赖于任何模块或者它依赖的所有模块已经就绪,这个模块就是就绪状态。

在模块化开发中,一个模块可以依赖于任意个模块,而被它依赖的模块又可以依赖于任意个其他模块。这就要求加载模块时必须一层一层把所有依赖的模块都加载进来,类似于树的遍历。由于前端动态加载JS的过程是异步的,也就是说,这是异步的遍历。在算法上,JRaiser Loader采取自顶向下的遍历方式以及自底向上的通知方式。假设有A、B、C三个模块,A依赖于B,B依赖于C。当通过加载A模块时,其加载过程如下(红色箭头部分为异步流程):

加载流程

2018次阅读,7条评论

使用Javascript获取当前目录的绝对路径

前端开发  |  5年前

一谈到路径相关的问题,大家都会往window.location上想,确实这个对象提供了相当多的路径信息,其中常用的就包括:

  • location.href:当前页面的完整URL
  • location.pathname:当前URL中的路径名
  • location.hash:当前URL中的锚点
  • location.search:当前URL中的查询参数

然而,location没有一个属性能直接获得当前目录(不含文件名的绝对路径。通过Google我发现了一些错误的方法,比如说把URL通过“/”分离成数组,把数组的最后一项去掉以后再连接成字符串。但如果URL中没有指定文件名,结果就大错特错了。

根据以往编码的经验,a元素的href属性总是会返回绝对路径,也就是说它具有把相对路径转成绝对路径的能力。使用下面的代码尝试了一下,果然成了:

var a = document.createElement('a');
a.href = './';
alert(a.href);
a = null;
4821次阅读,4条评论

验证码的几个常见漏洞

其他开发  |  5年前

把验证码存储在Cookie中

一般来说,我们会把验证码的值用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)
{
    // 验证通过,继续操作
}
1460次阅读,3条评论

[译]原生全屏Javascript API

前端开发  |  5年前

HTML 5的<video>是一个相当不错的标签,但是它刚发布的时间,最大的问题是它不能像Flash那样实现真正的全屏。幸好,几个月后,大部分浏览器已经原生地支持全屏。

全屏API简史

  1. 第一个原生的全屏接口是在Safari 5.0(和iOS)中添加的 webkitEnterFullScreen() 函数。不过,它只能用于<video>标签。
  2. 在Safari 5.1中,苹果修改了这个API使它更接近于Mozilla的全屏API草案(比苹果的实现更早)。现在,所有DOM元素都可以调用 webkitRequestFullScreen() 方法。
  3. Firefox和Chome表示它们将会添加原生全屏API支持,而且这个特性已经在Chome 15+以及Firefox Nightly中实现。

在2011年10月15日,W3C发布了一份全屏API草案(由Opera团队的一名成员编写),它跟Mozilla的草案有两个主要的不同点:

  1. Mozilla/Webkit使用大写字母'S'(FullScreen),但W3C则不是(Fullscreen);
  2. Mozilla/Webkit使用cancelFullScreen,W3C使用exitFullscreen
6696次阅读,2条评论