作者文章: Fenng

或许真的无法帮你什么

时不时的会收到一些的救助邮件,内容特征大致类似,发信人要么是还在校的本科生或研究生,或者是刚走上工作岗位的,都是感到迷茫,不知道如何学什么更有前途,或者是如何学习某项技能才能更快的找份好工作,或者是如何才能进入到某公司工作……

code_guy.jpg

以前收到这样的邮件,基本上我还是愿意回复的(回复的邮件观点在我的网志上其实都能找到,比如 毕业生该怎么找互联网行业的工作 ),不过后来类似的邮件越来越多,看多了,回复也烦了(类似的内容如果重复几十次几百次没人不烦),都快成连岳了,不过连岳还有报社给稿费呢。更多的时候看到这些邮件是感觉到无奈,感觉到悲哀。其实求助人的迷茫我也是感同身受,但是我能真的帮你什么呢? 我短短的一封邮件,几个字儿,能是九阴真经? 能是葵花宝典? 按照我说的能练成神功麽?

再者说来,我也没有给大家指点的资格。 自己其实都还没捣鼓明白呢,给人当指路人不怕被带到沟里去阿? 要打算学技术,网络上能提供给你所有东西,钻进某个专业技术论坛潜水一段时间,可能也比你在学校学一些垃圾课程要好得多;学会看第一手资料,学会找信息来源,而不是到一些垃圾信息堆积站去吸取所谓的”营养”。另外,要是问如何成功之类的事情,可以找一下李开复老师嘛,当然他也是告诉你答案 “做最好的自己” 。学会思考,不要盲从盲信。

没有那么多一蹴而就的事情,每个人的面对的场景不同,所有人的路都是不可复制的,我的建议是还是要靠自己领悟,光靠别人的灌输或者指引是不行的,你需要的信息其实全在那儿,只是你自己没注意到,没重视起来,没实践一下,没坚持下去。

另外头疼的一点是我根本没那么多时间,尤其是一对一的问答(在 IM 上直接以问问题的名字找我聊天的我都会直接 Block 掉),最消耗时间与精力,所以,我更愿意写出来,这样后来人也能看到,效率起码高一点。这篇小文就算对类似求助邮件的统一回复吧。

EOF


下面的读者留言也很有趣,比如 “”努力加专注”…不过做到的人很少”。

此文作者:, 位于 MyLife 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

从 Twitter 运维技术经验可以学到什么

没有一个网站的性能像 Twitter 这样这么令人牵肠挂肚,看见那条大鲸鱼总是让人感觉很无奈。Twitter 的运维专家 John Adams 在 Velocity 2009 上做了一篇题为 Fixing Twitter 的技术分享(PDF),人家也是一直在努力阿。John Adams 在 2008 年七月加入的 Twitter ,对于 Twitter 的站点稳定的确做了不少工作。

Twitter 运维团队的职责:

  • 软件性能(后端) Software Performance (back-end)
  • 可用性 Availability
  • 容量规划 Capacity Planning (metrics-driven)
  • 配置管理 Configuration Management

看完这个接近 50 页的 PDF ,除了满足我们一小部分技术窥探的癖好,或许也可以学到点什么。

不重复发明轮子

对于监控,Twitter 用的就是 RRDtoolGangliaMRTG 这些已经成为很多网站标准配备的组件。而不是自己写一大堆功能重复的东西。值得注意的是, Twitter 也一直在用 Google Analytics 进行业务分析。

不重复发明轮子,可以打磨轮子,比进行如一些功能脚本定制之类的工作。

发明不重复的轮子

Twitter 开源了他们自己用的一个 Apache 模块 mod_memcache_block(a distributed IP blocking system),这个模块根据 HTTP 代码请求限制访问频率。熟悉 Twitter 的朋友会知道这是针对第三方应用程序的必须的一个功能,否则的话,会产生类似 DDos 的效果 :) John Adams 说这个模块是他多年以来就期待的东西,我相信,如果有人已经做了同样的事情,他们肯定不会自己再写一个。

尽可能的自动化

无论是配置管理还是针对各项功能的”开关”,都尽可能的自动化。依赖于人来控制一些事情容易”规范”,但是流程冗杂,节奏变慢。

更好的理解硬件

拥抱新技术体系,使用更有经济效益的硬件(比如对 8 核 CPU 的选型与更换)会带来更好的收益。而这个要建立在对硬件体系的正确理解上才行。

另外几句话要记住:

  • Disk is the new Tape. (内存是新类型的磁盘. 磁盘是新类型的磁带)
  • Kill long running queries before they kill you. (问题是如何提前发现? 有效的监控!)
  • Use metrics to make decisions, not guesses.
  • “Cache Everything!” not the best policy

或许还应该学到更多…

EOF

此文作者:, 位于 Arch 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

网站优化应重视 DNS 预获取(DNS Prefetching)

网站优化技术总是在进化。今天重新阅读了一下以前的前端优化笔记,发现对于 YSlow 优化 34 条准则关于减少 DNS 查找 (Reduce DNS Lookups)的部分或许应该修正一下了。

DNS 作为互联网的基础协议,其解析的速度似乎容易被网站优化人员忽视。现在浏览器厂商已经有在针对 DNS 进行优化,典型的一次 DNS 解析耗费 20-120 毫秒,减少 DNS 解析数是个优化的方式,而能够缩减 DNS 解析的时间也是有经济效益的事情。这就是浏览器厂商重视 DNS Prefetching 的主要原因。DNS Prefetching 对于性能的收益可以简单的用”DNS 同步请求到异步”来解释,也就是具有此属性的域名不需要用户点击链接就在后台解析,而域名解析和内容载入是串行的网络操作,所以这个方式能减少用户的等待时间,提升用户体验。

Google Chrome 内置就有 DNS Prefetching 技术(注意之前有几个小版本因为这一特性反而带来了性能问题) ,而 Firefox 3.5 也引入了这一 新特性。至于 IE 8,暂时还看不到有什么举措(或许是我没注意到?)。

对于一个网站来说,如果希望能充分利用用户浏览器端的这个功能,可以在页面添加 link 属性的锚点来做到。类似:

<link rel="dns-prefetch" href="http://www.google-analytics.com/">

另外还有这个 x-dns-prefetch-control 也有必要适当用一下。对于某些站点引用了 Google 的某些服务脚本,可能这尤其有用。

另外一种加速 DNS 的途径是考虑使用 pdnsd 之类的缓存 DNS 代理服务器来加速某些 DNS 请求。

在 Chrome 中,可以通过在地址栏输入 about:histograms/DNS 来观测一些有趣的 DNS 性能数据。

EOF

登陆框的密码遮盖问题以及其他

几天前看到的这个关于密码遮盖(Password Masking) 问题的讨论,顺着链接有找到了一些讨论来看,继而发现相关文章已经有人翻译了(refer),但中文技术社区好像很少见到讨论(也可能是我孤陋寡闻)。

这是个令人印象深刻的话题,因为挑战的是习惯性的设计方式。放眼看去,所有需要输入密码才可登录的网站都是遮盖密码的。密码遮盖带来的坏处是显而易见–用户的输入成了盲区,不知道自己输入的是否对,点击登录变成了变相的试错操作,产生比较多的再次登录操作,对给用户造成非常糟糕的使用感受。然而似乎很少有人如何去考虑改进这个现状。关注别人视而不见的问题才会带来革新与创新,要不怎么说人家 Jakob Nielsen 是用户体验方面的大牛呢,要从别人口中出来这个论断可能会被人笑话,而大牛就敢于挑战常规,弄个问题就给大家带来思考了–扯远了。

似乎多数人赞同添加一个额外的检查框(CheckBox),安全性要求不高的应用,默认不遮挡,用户输入完毕之后,再选择旁边的检查框对密码进行遮挡;对于安全性要求比较高的应用,默认密码遮挡,但可以选择显示一下密码明文一下,方便用户检查是否有拼写错误。

如果你用过苹果的产品,比如 iPhone 新 OS 3.0 的版本,你会发现密码的处理又进了一步,密码输入时是显示明文的,方便用户确认没有输错,在几秒钟后或者输入下一个字符的时候再对这个字符遮盖。(很多移动厂商好像现在都这么设计了)

iPhone_Password_Masking.png

(截图有点喧宾夺主,对付着看吧)

这个想法真的很让人欣赏,对于手持设备能够比较有效的防止了窥探(peeking over your shoulder),也减少了用户输入错误的频率。只是不知道是不是已经被手机厂商申请了专利。对于大屏幕显示器来说,窥探的可能性有多大?缺乏数据支持,很难说明。或许,这里的安全专家的分析对质疑者也会有点帮助。

其实我觉得密码遮盖问题在用户初次注册的时候带来的问题尤其严重。在这个环节如果添加一个 CheckBox 要用户知道自己连续两次输入的密码是什么应该是有必要的(有人举手同意麽?) ,否则的话,用户要的密码可能不是自己输入的,短时间内连续两次输入,出现键入错误的几率并非不存在。

好吧,现在开始审视一下自己的网站登录框设计以及注册页面吧…新的问题或许是,你有勇气做点修改麽?


如果觉得上面说的都是废话,那么不妨考虑这两个问题:

  • 为什么我们之前就没考虑到这一点?
  • 如何才能先于别人一步想到这一点?

EOF

延伸阅读:Better Password Inputs, iPhone Style

此文作者:, 位于 Web 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.