分类：折腾

做一个应用程序有非常多不同的技术选择。使用 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. 可能会使用更多的资源，启动较为缓慢。

原生应用

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

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

总结

待续……

为什么要设置主机名

一些软件需要知道主机名才能工作，不然会有警告和错误，比如 Apache。

可以使用 "hostname" 命令查看现在的主机名，用 "hostname -f" 命令查看完整域名(Fully Qualified Domain Name, FQDN)。如果查找 FQDN 失败，你需要按照以下步骤设置。

个人电脑 PC

PC 通常没有域名和固定不变的 IP 地址。通常情况下，PC 的软件是不需要主机名和域名来运行的。但是如果你开启了某些网络服务，就可能需要它了。

如果你没有注册过任何互联网域名，可以用一个假的，比如 yourname.local ，yourname.lan ，yourname.geek 之类的。因为 .local .lan .geek 目前不是 ICANN 顶级域名，因此不可能和任何互联网站点冲突。例子：

• linux-desktop.guoyunhe.local
• samba-storage.guoyunhe.local
• laptop-1.guoyunhe.local

如果你已经注册了一个域名，像是 yourname.com ，你可以用它来命名你的计算机设备的域名。因为你自己就可以确保相同域名不会被用在别处。例子：

• desktop.guoyunhe.me
• laptop.guoyunhe.me
• old-thinkpad.guoyunhe.me

第 1 步：修改 /etc/hostname 文件。主机名只能包含数字，字母和连字符。

linux-desktop

第 2 步：修改 /etc/hosts 文件。把完整域名 FQDN  "linux-desktop.guoyunhe.local" 放到主机名 "linux-desktop" 之前。

127.0.0.1    localhost
127.0.1.1    linux-desktop.guoyunhe.local linux-desktop

第 3 步：重启系统。

检查主机名和域名： "hostname" 命令输出 linux-desktop ， "hostname -f" 输出 linux-desktop.guoyunhe.local 。

服务器

如果你有一个服务器，绑定了多个域名：

• guoyunhe.me
• www.guoyunhe.me
• wiki.guoyunhe.me
• shop.guoyunhe.me

你可以选择 "www"， "wiki" 和 "shop" 中的任何一个作为主机名。也可以另取一个，比如 "server" ， "vps-1"。

第 1 步：修改 /etc/hostname 文件。主机名只能包含数字，字母和连字符。

server

第 2 步：修改 /etc/hosts 文件。把完整域名 FQDN  "server.guoyunhe.me" 放到主机名 "server" 之前。

127.0.0.1    localhost
127.0.1.1    server.guoyunhe.me server guoyunhe.me www.guoyunhe.me wiki.guoyunhe.me shop.guoyunhe.me

第 3 步：重启系统。

检查主机名和域名： "hostname" 命令输出 server ， "hostname -f" 输出 server.guoyunhe.me 。

验证码：UX 终结者

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

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

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

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

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

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

有没有必要

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

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

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

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

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

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

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

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

我只能说：这不合理。

四处滥用

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

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

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

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

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

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

Sweet Captcha

参考链接

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

MariaDB 和 MySQL 的全文索引的建立方式与查找方式，都和普通的索引不同。

建立索引

建立索引的语法可以简单也可以复杂：

FULLTEXT(title)

FULLTEXT(title,content)

FULLTEXT INDEX post_title_content_ft_index(title,content)

查询

1. 按照自然语言查询，匹配完整单词。比如查询 rabbit 可以匹配 rabbit, rabbits, Rabbits，但是查询 rab 不能匹配 rabbit 。

MATCH(title,content) AGAINST('rabbit')

2. 按照字符匹配查询，从单词开头开始。查询 rab 可以匹配 rabbit ，但是查询 bit 不能匹配 rabbit 。

MATCH(title,content) AGAINST('rabbit' IN BOOLEAN MODE)

多列索引与单列索引

对于普通的索引，如果建立了(title,content)的联合索引，就不必单独建立 title 和 content 的索引，也可以搜索单列。但是全文索引就不行，索引的列必须和查询的列完全一致。如果查询 title ，就要建立 title 单列的全文索引；如果查询 (title, content) 就要建立只包含 (title, content) 两列的索引。

搜索中文

MySQL 和 MariaDB 的全文索引一开始就不是为东亚语言设计的。单词断字是按照空格和标点符号的，但是中日韩文字单词之间没有空格。因此搜索"明月"无法匹配"床前明月光"。使用 IN NATURAL LANGUAGE MODE 只有在搜索整句的时候才能匹配到，基本上没有什么用处。使用 IN BOOLEAN MODE 的时候，只能搜索一句的开头，比如"床前*"可以匹配，而"明月*"就不行。* 通配符只能放在单词的结尾。

因此对中文而言，全文索引反而没有 %LIKE% 的效果好，虽然 %LIKE% 的效率很低。小型网站，可以采用。

MySQL 提供了额外的 ngram 技术，支持每 n 个字符断字。这样就可以用逐字搜索中日韩文字。但 MariaDB 还没有引进此功能。

周一完成了我的 Porn Button 。最开始的设计是比较隐晦的，但老师说不够直接不够大胆，于是最后的设计就比较淫秽了……题目要求是只能依靠触觉反馈，而不能有视觉和听觉传达。充分体现了以往看过的小黄漫中的精髓，简而言之就是还原性行为。

通过压力传感器采集手指按压的动作，电机拉动皮筋和半个气球使之收缩。本来想用一只避孕套的，然而其强度太差，玩不了几次就坏了。最基本的反射是按压的力气越大，收缩越剧烈。松开手指，收缩也会复位。然而这样一点也不智能也不色情乎。微控制器还会计算按压频率，频率升高也会使收缩更剧烈。有点类似生物的反应了。最后还有，如果玩过头就会触发崩坏——整个机器停止工作，需要二十秒冷却时间。（心领神会即可）

最开始想做成这样的盒子。

然而最后必须要用一个木头盒子把内容完全封闭起来，让人看不到里面，以隔绝触觉之外的感官。

盒子上不会标记这个 Button 的主题，因此体验者需要自己体会联想其中含义。但每个盒子有个字母标签方便评分，老师说必须要把"H"留给我……

周一的时候已经给我的一些同学玩过了，都觉得确实是那个意思……嗯。周二展示的时候也获得了强烈反响，相比其他主题这个真是太特殊了。男生比较喜欢，女生的态度则褒贬不一。很多人告诉我她们对我有了新的认识……But, I don't care!

su

zypper ref

zypper up

sudo -u wwwrun php occ maintenance:mode --off

sudo -u wwwrun php occ upgrade

我的硕士毕业设计题目是免费的互助共享社群，群体范围限定在阿尔托大学 Otaniemi 的学生村里。租借，共享，共享消费之类点子很多人已经做过了。这个项目的特别之处在于没有资金流动：借得东西，获取帮助的人不需要付费；借出东西，给予帮助的人也不会得到物质回报。当然，也没有押金。

不需要付费会更加方便，也更经济。但是会带来两个严峻问题：

1. 在没有租金和押金的情况下，陌生人之间如何信任？物品的价值如何影响人们的选择要不要信任他人？信任建立的过程中，有哪些有趣的互动？
2. 人们不仅要贡献自己的所有物，还要贡献宝贵的时间。在没有物质回报的情况下，如何激励人们持续贡献，如何给予他们精神回报和满足感？

第一个问题似乎比较容易用实验的方法得到结论，因为我们已经知道在一些案例中，陌生人是可以建立信任的，这就是 Airbnb 的核心理念之一。

第二个问题就难了。 继续阅读 →

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

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

译文：

如果机器生产一切人类所需，那么结果取决于我们如何分配这些财富。如果机器生产的财富能被所有人共享，每个人都能享受富足的生活；如果机器的拥有者阻止财富的再分配，大多数人最终会非常穷困。

到目前为止，趋势似乎倾向于后者。科技的发展导致不断增加的不公平。

— 史蒂芬·霍金

原文：

If machines produce everything we need, the outcome will depend on how things are distributed. Everyone can enjoy a life of luxurious leisure if the machine-produced wealth is shared, or most people can end up miserably poor if the machine-owners successfully lobby against wealth redistribution.

So far, the trend seems to be toward the second option, with technology driving ever-increasing inequality.

— Stephen Hawking

中国当代设计展（赫尔辛基）

来本次展览就是好奇在这样一个小博物馆的小展厅里会选哪些东西代表中国当代设计。其实我对中国设计也不了解，正好同班同学在此作解说，我就来补习一下。

此次展出只有五十件/套展品，大物件少，小物件多。名为「造·化—中国设计」（Artifact Beyond – Design in China Now）。

来的时候有点晚，第一部分和第二部分的讲解都错过了。转过头来手机就没电了，照片没拍成。参考此处。

进门的时候就有一个很长的桌子，人们席地而坐，欣赏茶具和茶艺。这一部分确实很中国，又能看出融合了现代工艺和古法的构思。

这一堆椅子，错落的结构很有意思。但单个椅子就禁不起推敲了，好像太过简洁了，没什么趣味。

这扇子画得还是蛮用心的。

这扇子我家也有，好像从古到今没啥变化。

这两把扇子的每一片木条分别是北京或上海的一座高层建筑物。不过这放淘宝也就五块钱一把。

这块竹子很厉害，单片竹子热处理展平，不用胶水拼接。工艺自然形成的类似流水一样起伏的表面也很有意思。大巧不工，赞。

这一盘让我想起老妈做的烧卖。学姐做的包子也是开口的，嗯。

海报上的就是这个，画得很粗糙，有点杀马特了。

这个凳子工艺很高超，每一片竹子都要弯不同形状。

这把椅子看见很多次了，确实不错。坐在上面，无聊了还可以撕纸玩。

到此处手机没电了，后面就没有照片了。

吐槽一下大疆无人机，在这个展览里唯一一个完全不能体现中国设计的东西。或许应该放到中国科技展，中国制造展上吧。