标签：web

做一个应用程序有非常多不同的技术选择。使用 Web 技术既可以用做小的开发成本做出跨平台的应用，但是性能和功能又有诸多限制。完全使用原生技术则需要极高的成本。选择技术的因素固然有很多，不同的技术可能实现相同的功能，但体验上是有差异的。

下面介绍的顺序是从更接近 Web 技术到更接近原生技术。

Web 后端渲染

典型的 Web 应用模式，网页在后端进行渲染，配合少量的 JavaScript而构成的应用。这种模式适合交互简单，以内容为主的应用。典型的例子是 GitHub, WordPress, Wikipedia 之类的网站。

后端渲染对服务器的压力更大，每跳转一个页面，浏览器都要等待至少数秒钟。除了 Safari 之外的移动浏览器都有一个刻意而为的点击延迟 (300ms)，这让点击链接跳转在移动端的体验变得更差了。速度是最大的弊端。

单网页应用

使用 Angular, React, Vue 之类的 JavaScript MVC/MVVC 框架制作的应用。前端作为 JavaScript 被整个或部分加载到浏览器。然后只从服务器获取需要的数据，更新页面的部分内容而不需要重载页面。服务器不再需要处理网页渲染，数据可以缓存，数据库查询等耗时操作也更少。这种模式适合交互频繁，数据更新频繁的应用。典型的例子有 Twitter, Facebook, Instagram 之类的网站。

缺点仍然很多：

1. 初次加载仍然非常耗时。
2. 受到浏览器限制，尤其是移动浏览器。
   1. 大多数移动浏览器在滚动时会自动隐藏地址栏。如果有浮动元素的话，这会非常讨厌。
   2. iOS Safari 强制所有网页可两指手势缩放。这种缩放可能会破坏原有布局，给人一种不可靠的感觉。而原生应用是不可以被整个自由缩放的。
   3. 仍然有点击延迟 (300ms)。这是单网页应用给人一种比原生应用慢的最常见原因。
   4. 移动浏览器的性能导致很多动画变得缓慢卡顿。
3. 设计/开发模式的问题。
   1. Web 开发者通常不会花心思去做手势操作和过渡动画。
   2. 在桌面用响应式设计模式开发，并不能完全模拟实际设备的交互感觉。主要问题在于屏幕尺寸，手指的精度和活动范围，以及导航栏和键盘的影响。
   3. 桌面和手机共用结构和组件，常常在手机上不太好用。

Electron 和 Cordova

这两个东西都是提供了原生系统接口的 Web 容器。Electron 主要用于桌面应用，只要 NodeJS 可以做到的它都可以做到，因此可以使用非常之多的原生接口。Cordova 或者 PhoneGap 面向移动平台，能使用的接口由插件提供，非常之有限。

1. 加载时间快，不需要下载界面组件。
2. 界面仍然是 Web 引擎渲染的。运行性能仍然比原生差，但是优于浏览器。
3. 相比浏览器，消耗更多的系统资源。
4. 浏览器界面的干扰被削弱。没有标签页，地址栏，更像是单应用。
5. 无法使用一些原生的库和系统接口。

React Native

JavaScript + 原生 UI。一个性能和快速跨平台开发的折中选择。但也可能是一个陷阱。

1. 界面与原生应用几乎没有差异，交互非常流畅。
2. 只提供了原生 UI 组件的一个子集。
3. 可用的原生系统接口有限，第三方 SDK 就更少了。很多功能仍然用 Web 技术实现，变成了混合式应用。
   
4. 可能会使用更多的资源，启动较为缓慢。

原生应用

原生应用可以在所支持的平台上做尽可能多的优化，取得最好的效果。但代价是巨大的开发成本。

以视频播放器为例，原生应用可以支持任意视频格式，并尽可能优化性能，获得悬浮窗等系统权限。

总结

待续……

一周的进展

本周做了 Santakani 网站首页的改版。

对比旧版，新版将首页/设计/设计师三个列表页面合并为全新的首页。导航栏因此得到简化，只有 Design，Map 和 Story 三个选项。首页顶部采用了一种浅色有机纹理，取代了滚动的图片。文字也大大简化，更注重表达简介明了的含义，无需深度阅读。列表我最终还是决定用设计师作为主体，一行照片，一行产品。希望每个设计师的设计风格得以表达，而不是被散落在随机的产品列表中。图片采用了类似 500px 的等高填充布局，让横版和竖版的照片都能完美呈现，只做微小裁剪。

本周做的另一个项目是 openSUSE 的新网站主题。

试用了 Bootstrap 4 Alpha 6 版。虽然还有很多小缺陷，但整体上非常棒。使用 Bootstrap 自身的 Utility 类就能调节各种布局，大大减少了自己写 CSS 的工作量。

在 Google+ 上分享这个 Demo 之后得到了很多好评，感觉动力满满。

另外参考 KDE 的翻译项目，给 openSUSE 的文档项目添加了 XML ↔ PO 转换功能，这样就可以利用 Weblate 网站翻译文档。

毕业设计艰难进行！做了一次范围更大的问卷调查，参与调查的女性 100%，好像很不科学的样子。或许就像老师曾说的，女性更热衷于参与和奉献。

验证码：UX 终结者

网络验证码技术虽然是外国人发明的，但却在天朝泛滥成灾。

我们有那么多同学去做 UX ，花了那么多心思给用户提供更好的体验。到最后，被一个验证码全毁了。万恶的验证码，以及走不动的进度条，总是最烦人的。

简单的麻烦——淘宝的滑动验证码

淘宝和微博目前使用这个验证码，原理和 Google 的 reCAPTCHA 2 类似。第一步让用户拖动滑块（触屏或鼠标），然后记录鼠标或手指触摸的轨迹，猜测用户是人还是机器。同时还会测试浏览器的排版引擎，JavaScript 引擎等等，确定这是一个人类使用的浏览器，而不是机器人程序。

在滑动过程中，鼠标位置/手指位置的数据是发送到服务器进行验证的（密文，如下图）。由于这一过程很短，采样率有限，而且直线滑动的人为特征性也不是很明显，即使算法再好也很容易被破解程序骗。

如果第一步判断不是人或者把握不准，则进入第二步，即传统的图形验证码。

有没有必要

它挡不住破解程序。滑动验证比图片验证要弱，所以图片验证码才会作为第二道防线。只要写一个程序控制鼠标，并且让鼠标轨迹看起来不那么有规律就可以了。（配合浏览器，骗过浏览器性能验证机制）

如果是通过用户的交互行为来判断其是人还是机器，大可不必显示这个滑块。用户在浏览网站或使用应用的过程中必然要进行大量交互，记录这些数据要比滑动那么一下有效得多。

滑动验证是不能证明其对错的，它的数据和算法都是不透明的，而且可以推测其原理极其复杂。即使用户觉得自己是滑动到了最右端，它仍然可以强硬地不通过验证，给用户一种很无奈的挫折感。目前看来这算法确实有问题，因为通过率出奇地低于文字验证码的通过率。如是玄学，寡人不服 XD

这就造成了两种常见结果：

1. 破解程序没被挡住。
2. 一些用户验证了两步。

在我使用的十次当中，有七次没有通过滑块验证码，而不得不使用图形验证码。滑动和使用图形验证码所需的反应时间其实是差不多的，这意味着我比使用单一图形验证码反而多用了 70% 的时间。

而某些破解程序，已经能够做到 80% 以上的成功率。令人唏嘘不已。

两步验证码的组合更是浪费时间。

我只能说：这不合理。

四处滥用

昨天，有个人在微博上给我发消息，我用 Android 应用回他一下，然后就冒出了验证码，必须要完成验证才能发送消息。然后连续输入错误，消息没有发送成功。

我今天在淘宝注册账号，更改设置，总共输入了十几次验证码。即使我已经输入了短信验证码，后续还是被要求输入滑动验证码。

对于已经登录的用户，验证码通常是没有必要的。如果想验证用户是不是机器人，为什么不在登录的时候提前验证好？如果想验证用户是不是本人，则应该输入密码或者短信验证码。

我在使用 Facebook 和 Twitter 的这些年里，除了短信验证码和手机令牌，从来没有遇到过滑动验证或文字验证码的时候。Paypal 和 Amazon 的验证码也出现得极少，甚至于我都忘记了他们的验证码是什么样子。

当一个交互过程需要安全检查，而人们又想偷懒的时候：加个验证码吧。

验证码是一个在设计过程中绝对应该尽可能避免的东西。不管形式怎么变，用户都会反感，因为它带来了麻烦，且不止一次。它不能保证安全，任何现有的验证码机制都有破解之法。越复杂的验证码，对于人类的挑战也越大。

Sweet Captcha

参考链接

1. Inside reCAPTCHA – Google “点击验证”的原理和简单破解方法
2. 淘宝滑动验证码研究

世界上的语言有成百上千中，不只有英文，俄文，法文，西班牙文，中文这样的广义语言，还有方言，古语等狭义语言，比如美式英语，英式英语，简体中文，繁体中文，文言文，吴语，粤语等。地理分布越广，文化组成越复杂的语言，其分支往往越多。中文尤其复杂。

如果要设计一个互联网应用，并希望支持多语言，就有很多问题需要考虑。 继续阅读 →

如何愉快地学习网页编程

之前有同学和我说想学习网页编程，我随口答应帮忙，却一直到现在才有空写写。网页编程的教材网上有很多了，我只是搜罗一下，并附上一些学习建议。 继续阅读 →

在写下这一篇的时候，我们的维基还是一个知名度不高的校内网站。经过近一年的尝试调整，渐渐得到了发展的方向。去年的时候，我们开始构想一个校内百科。动机很简单，我们觉得每个大学都会需要一个百科全书样的东西。我们的参考目标是维基百科，依靠mediawiki和理想化的社群模式运作。而在这之前，至少有五个类似的网站已经失败。

开始的时候我们有一系列定位和发展规划。制订了内容收录规范，以及社群守则。因为蓝本是维基百科，所以我们觉得它会像维基百科一样依靠用户贡献发展。问题是很多事情不一样。

首先是网站本身的意义。学生们并不是非常需要了解学校的历史，建筑和人物。即便需要的时候，他们也会去查询谷歌搜索。基本的信息维基百科都可以包含，我们只是做了一个更详细的工作，却花费了太多时间。既然是内容主导的网站，什么样的内容最被需要才是关键。

然后说说用户群体。我们的用户群体，是本校学生和教师。我们希望大家能通过此平台分享知识，互助协作。然而师生对此理念并不了解，网站在大多数人眼里仍是一个放内容的工具。一个开始就没有内容的网站，如何让用户参与其中呢？他们会怀疑网站未来的延续问题。

在技术上同样存在麻烦。mediawiki的内容编辑是通过代码实现的，十分复杂，而且不够直观。这严重阻碍了一般用户的参与。

我们的运营也有不少失误。太多的限制和质量要求让早期的内容积累举步维艰。像版权问题，我们并没有能力去验证，实际上是形同虚设的要求。

后来我们陆续进行了几项改变。

收录内容范围扩充，计划成为校内资料库。包含校内信息，在线教材，学习经验，共享文件等。

组建内部编辑组，积累原始内容。我们还通过技术从其他网站导入信息。内容积累足够多，用户对它的认可度也会增加。

在可视化编辑器部署之前，我们通过提供简捷的帮助，降低用户参与的难度。

同时也取消了不可执行的规则，以促进早期的内容积累。

现在的校内维基，已经改变了很多。我们很希望它会是一个成功的网站。

原理

MediaWiki的插件一般由php脚本和javascript脚本组成，直接上传到服务器，并在配置文件内添加插件路径即可使用。

Math插件的安装比较繁琐，因为它还依赖于其他本地应用程序，如mineTex。Math是一个统一化的接口，用户使用同样的数学公式代码，却可以通过不同方式生成公式。这些方式包括：PNG图片，LaTex，Tex，HTML，MathML等。而Math并没有实现这些功能的模块，需要调用其它应用程序。

目前默认的后端是Texvc，它可以生成PNG图片。这种方式需要服务器安装mineTex本地应用程序。然而对于共享空间上的站点来说，可能无法安装软件。PNG图片的显示效果也不好，在屏幕分辨率高的情况下不够清晰平滑，不能随文本缩放。因此，MediaWiki未来将会采用另一种表现更好的方式——Mathjax。

MathJax是一个开源的JavaScript数学公式显示引擎，适用于几乎所有现代浏览器。它被广泛应用于Wiki，WordPress博客等站点。使用它非常简单，只要在网页上的head标签内加入

<script type="text/javascript"
   src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>

即可。对于WordPress，MediaWiki等平台，若需要在整个站点启用此特性，则应在站点皮肤的HTML/PHP脚本中添加。

可以看出，这实际上是调用了MathJax在线引擎，JavaScript脚本存放于远程服务器上。若是在本地局域网内不能访问国际互联网，则可以下载MathJax并安装在本地，链接修改为本地站点。

步骤

对于MediaWiki，通过Math插件添加更加方便控制，且能应用于所有皮肤中。

第一步，下载Math插件。

第二步，上传Math插件。将插件解压并将文件夹上传到extension目录中，命令文件夹为Math。

第三步，注册Math插件。打开LocalSettings.php，在插件注册部分添加：

require_once("$IP/extensions/Math/Math.php");

第四步，配置Math插件。打开/extensions/Math/Math.php，更改如下几条配置信息：
1.关闭Tex

$wgUseTeX = false;

2.开启MathJax

$wgUseMathJax = true;

3.设MathJax为默认

$wgDefaultUserOptions['math'] = MW_MATH_MATHJAX;

Math默认调用MathJax官方网站的引擎。若你在不连接国际互联网的情况下使用，或者希望使用自己的服务器提高效率，可以安装自己的MathJax引擎。

第一步，下载MathJax引擎。

第二步，上传MathJax到服务器。

第三步，修改Math插件配置：

$wgMathJaxUrl = 'http://yoursite.org/mathjax/MathJax.js?config=TeX-AMS_HTML';

URL修改为你的MathJax引擎所在的位置。

对于学校内，企业内，组织内的网络系统，可以搭建一个开放MathJax引擎，供所有内部站点使用。

phpBB本身可谓几近节俭之极，甚至没有自动缩放图片的功能。

因此我们需要安装MOD，ReIMG是个不错的选择。

首先在phpBB官方网站下载此插件。

然后按照安装说明，上传文件到ftp，并修改相应文件。

最后是安装，在浏览器中输入域名+安装文件install-reimg.php。安装完成。

这时可能还不能立即看到效果，必须在管理面板首页“清空缓存”。

这时，reimg可以在默认phpBB主题下使用，但如果你想在自定义主题下使用，就需要同样照安装说明修改其他风格文件夹中的文件，并上传mod文件夹到每个风格的template文件夹中。

对很多人来说，Thunderbird应该算是老朋友了吧。除了Outlook之外，Thunderbird应该算得上最流行的邮件软件了。

正当它如日中天的时候，Mozilla基金会宣布停止了Thunderbird的开发。我们不得不与可爱的蓝鸟说再见了。

Thunderbird 的谢幕，标志着上一个时代结束。那时候，计算机，本地程序就是我们的全部，而互联网只不过是服务于本地软件的附庸。而现在，越来越多的功能被转移到web 上，我们在网页上收发邮件、聊天、编辑文档、甚至远程会议。在本地管理庞杂而无条理的资源，应对一堆复杂繁琐的软件，实在是令人恼火。相对的，web上正 引导一种快速、便捷、稳定的生活方式。我们不必再理会是否需要安装软件，它如何使用，它崩溃又该怎么办。只要打开网页，完成工作就行了。

未来，mailto标签会立即将我们引导到一个页面，而不是花几十秒打开一个邮件程序。这是时代思维与观念的转变。