这些年，很多很优惠的产品、羊毛产品，屡见不鲜。比如我使用了3年的北京电信ifree卡(0月租，拨打京津冀电信号码免费)、使用了1年的河北阿福卡(0月租，本地本网免费)，北京移动5元卡(长/市话0.12元)，一旦获得、或者转入这些套餐，几乎是终身优惠的。还有国外的很多主机、VPS产品，一旦用优惠码购买，再次续费大多为当初购买时的优惠价。

最近的海航卡，突然开始对很多老用户收取来电显示费，引发很多老用户的不适。尽管我当时没有入手这种海航卡，但是也希望海航卡不要采取这种方式。永久优惠制，是双赢的，老用户用着踏实，运营商也获得了这些老用户的认可，何尔而不为？

Feedval以及我之后开发的项目，都同时支持手机版、PC版，英/简/繁切换，无需安装客户端软件。

这两天有些家里的琐事，影响了开发进度。还有个原因是现在到了开发最核心的功能的阶段，正好这个“更新RSS”的数据分布设计十分复杂，无从下手，思考了两天都没有完成数据设计。不过，从昨晚开始，终于有了这一项的数据设计思路。单是“更新RSS”，目前已知的，至少要建立6-8个数据表，才能完成预计的功能。

这6-8个数据表，大致内容包括：更新RSS后，综合显示(大杂烩式)，分组中按作者显示。单个RSS的更新储存，考虑到这个功能可能很多用户不会用到，所以暂时不做这一功能。综合显示、按作者显示里面，需要再细分数据表。

添加分组、编辑分组、添加RSS功能前几天已经基本完成90%。又用了一天多的时间，把一些JavaScript功能做了修改。因为“更新RSS”功能有些未知的数据表，这些数据表有些是在添加分组、添加RSS时建立的，所以需要翻回去再修改添加分组、编辑分组、添加RSS。

等“更新RSS”的程序彻底完成之后，接着需要再进行RSS编辑、RSS删除、收藏、在线升级的程序开发。

开发进度截图：

英文版截图：

手机网页版截图：

从今年我才开始有了写、发布开源软件的想法。因为开源软件，能积累更多忠实用户。无收入的事情没有人愿意做，就像2003年时期的Webshu，整整运营了1年，Alexa排名3万多保持了约半年，但是0收入，导致了后面的运营失去了方向。为什么Webshu我总是会提到2003年、2004年？因为那个平台只有2003年、2004年有故事，后来那个平台的故事基本上空白。幸好这么多年来，网页一直还存在，域名我也每年续费。

使Webshu中断最大的原因是2004年3月，我去了深圳，当时在华强北，差一点就转向另一个行业──电子元件，2004年底才又重新回到了互联网。华强北有国内最大的电子元件采购市场：华强电子世界、赛格广场、都会、新亚洲。

这些年，我写过的程序不计其数。因为我喜欢把关联较强的语句，都写在同一行，所以无法计算出写过多少行程序，只能以小时计算。我从一个网页制作者，变成了设计者、前端开发者，2002年编写了第一个留言板程序之后，成了程序员。

虽然程序的工作量是难以想象地庞大，但是只有程序才能创造想要的平台。

经过这十几年的开发和测试，每写一段程序，都需要考虑它在高并发时候的情景，所以对于程序效率是十分谨慎的。写程序时，一次就写好，将来无需再优化，因为写程序时已经做到优化。如果将来再优化，改动的工作量可能是惊人的。

促使我爱上编写开源软件的原因，也是因为开源软件能够把作者的想法传播出去。无论是作者通过别的渠道有较高收入，或者较少收入，那么你仍然是优秀的程序员。因为想成为优秀的程序员，你必须有作品，必须有能够说得出来的作品。这也是我废寝忘食、奋力加班编写开源软件的原因，哪怕生活中有各种事情阻断我写程序。

程序和平面设计、诗歌一样，同样优美。但不同的是，尽管程序的工作量异常庞大，但程序相对较容易完成。因为平面设计、诗歌，如果没有题材和素材，是很难凭想象而产生作品。程序是根据需要、根据功能来编写，不需要像设计那样去凭空想象。程序开发就像做数学题一样，很多思路是不可预知的，是在开发中自动产生的。

同时，由于程序的工作量庞大，我写过的程序一般也不再去阅读。当程序完成之后，3个月之后，自己写过的程序还能马上读懂70%-80%；有些复杂的部分，可能要解读半天～一两天的时间才能还原开发时的思路。因为程序的工作量庞大，要记的东西实在太多太多，这种情况下记忆力不好是很正常的。

如果别人给我一个类似的程序成品让我看，我也看不懂，因为思路无法在程序中体现，无法还原。所以，很多程序，只有作者一个人懂。对于成品，我一般不写注释，因为一是很花时间，二是影响程序效率。只有单机版的程序，便于二次开发，我才会写注释。

程序里曾经出现过很多巧妙的解决方法、高效率的优化方式，这部分对我来说是像诗歌一样优美，单一小段优美的程序，说3天都说不完。

虽然程序工作很繁重，但促使我爱上写程序的原因之一是：程序能越写越优美。

促使我爱上写程序还有一个原因：不用框架，而大部分语句都用原生的程序语言、函数，这样能够写出自己风格的程序；或者需要时也会常常用到别人写的代码、少数时候需要用到类。比如一个预计20K的程序项目，如果用框架，光是一个JQuery文件就是100多K，或者一个框架就是几百K、几M，怎么能够实现自己需要优化的效果呢？所以应该脱离框架，用原生的程序语言才能让程序达到最优的优化效果，因为框架里有大量模块是用不到的。

也可以自己编写模块、框架。尽管如此，程序的开发工作量依然庞大，我最近最常谈到的词是重构、从0编写，因为可重复复制的模块，并不多。当然，程序开发最开心的事情就是能够重复复制模块，可以大大缩短开发时间。

在不久的时间里，大家将能免费下载到我编写的第一个开源程序：Feedval RSS阅读器，敬请关注！

2018-12-12 09:09更新：关于bug的问题，因为程序我在编写时都有很多的情形测试，所以bug较少。只有超出测试情形的时候，才会有少量的bug出现。

或者由于客户端的网速很慢，也会造成一些bug的出现、数据写入错误，在这种情况下程序里是能够写防错、或者自动纠错的程序，防错的程序已经写了很多；但是自动纠错的程序、自动重建数据表的工作量很大，因为程序里面对数据库的写入语句实在太多，一般在服务器的内部传输不会出错，只有在用户post数据的时候，网络阻塞时，input或textarea区域会有一定的数据丢失，这一块儿将会重点编写防错程序。自动纠错的部分，暂时不编写。除非是一个极其重要的数据项目，才会大量写入自动纠错的程序(工作量会增加很多)。

万一实在是出现了软件崩溃，我会编写相应的修复程序，并且在用户数据不丢失的情况下，这种情形一般不会出现，这么多年也尚未遇到过。

前天的测试中，除去图片的因素，HTML传输方面，HTTP在几次测试中都快于HTTP2，如文中的最后6次对比。

这一次，专门制作了一个网页，加载50个完全不同的小图片，50张图片总体积195K，我们来测试一下实际的加载速度，是否能够体现HTTP2的多路复用的优势？下列表格右边的“https的图片”，都是https的链接，测试网页也是https的链接。

gtmetrix.com的Fully Loaded Time(完全加载时间)对比：

	http的多图片	https的多图片
第1次	0.6s	0.6s
第2次	0.6s	0.6s
第3次	0.5s	0.6s
第4次	0.5s	0.6s
第5次	0.5s	0.6s
第6次	494ms	0.6s
第7次	0.5s	0.6s
第8次	0.6s	0.7s

为了提高精确度，这次做了8次测试。每次都是先测试完http，再立刻测试https，间隔不到10秒钟，所以可以大致排除网络因素。每次测试中，无论是HTML传输、还是大量小图片，https没有一次跑分超过http的。

结论：现阶段，https的速度无法超过http。如果您的网页用https访问很快，那么用http会更快一点。https现阶段的瓶颈在于，SSL的hash算法过于复杂。

但值得庆幸的是，https的访问速度没有比http减少多少，因此在需要https的场合下，可以放心投入使用。但如果在高并发场合，用http会有更高的稳定性。比如在flickr成名之前，有个很早的pbase.com。pbase.com是个照片发布站，上面有大量的数码相机各个型号的样图，如今这个网站以http为主，登录页用https。因为对于高并发的场合，https会损耗很多资源和流量。

在这次的多路复用测试中，服务器环境是Ubuntu+Apache+PHP，Apache只开了默认的10个进程，但是加载图片同样很快。

再测试一张195K左右的图片的加载速度，图片实际为194K，跑分如下：

	http的单图片	https的单图片
第1次	332ms	455ms
第2次	391ms	0.5s
第3次	347ms	443ms
第4次	346ms	446ms
第5次	364ms	468ms

https链接的单张图片加载速度，仍然比http慢。与第1个表格对比，同样体积的1张图片，和50张小图片，多张的加载时间约是单张的1.5倍。

结论：http下的多张图片的加载速度还是相当快的。

我的VPS前些天都转到了Ubuntu系统，整体真的有了明显的提升，每个单页的响应都加快了一点。一直没有做测试，昨天测试了一下，单页确实有区别。这个整体，指的是整体的稳定性，以前使用CentOS的时候，整体没有现在稳定，表现为单页加载之前，有时会多延迟0.5秒～1秒。使用Ubuntu系统之后，这种延迟的机率减少了很多。

在本次的测试中，重装了几次系统，用同一主机、同一页面测试，Ubuntu的单页比CentOS的单页快。在Ubuntu+Apache下，https和http的测试数据上，速度完全一样，实际访问起来也较难看出区别。但我还是感觉http应该会更快一些，毕竟有大量的hash加密的负载的因素，SSL的hash算法过于复杂。

这次的测试中，页面加载的图片都是http，所以测试结果中没有体现出http2的多路复用的优势。现阶段，我还是更喜欢用http，也许将来某一天发现https好用，才会转向https。因为站点多的时候，https的维护、安装实在是麻烦。

在速度、负载上，http1.1和http2哪个效率更高，还真的不好说。因为现行的http2是和SSL绑定在一起的，假设当初浏览器开发者没有把http2和SSL绑定，而是http地址也无需任何改动，直接把http1.1传输升级到http2；或者把SSL的hash算法简化一下，那么性能会有一定的提升。

现行SSL肯定不是最优化的模式，因为复杂的安装、复杂的模块关联，过于复杂的hash算法。较为理想的方式是将来如果有人去开发http3，对现行的https重新优化，简化hash算法，也完全不需要第三方安全认证。很难想象出现在的SSL的第三方安全认证的意义是什么。

测试页：
http://www.auiou.com (页面1) 博客首页，有常规图片
http://www.auiou.com/relevant/00000980.jsp (页面2) 博客内页，有少量图片
临时https镜像站：
https://www3.auiou.com (页面1)
https://www3.auiou.com/relevant/00000980.jsp (页面2)

gtmetrix.com的测试结果如下：
(附：gtmetrix的打分只供娱乐，没有参考价值，因为这个打分是取决于加载完整个网页的时间，时间越短，分数越高，所有的图片、CSS、JS文件也要算进去。但这个网站有个作用是给开发者自己的同一页面进行性能对比，网页、或环境经过一定的修改，加载时间确实有明显变化。)

上述的页面1的Performance Scores对比：

	PageSpeed Score	YSlow Score
Ubuntu 12+http 页面1	93%	89%
CentOS 6+http 页面1	89%	89%
Ubuntu 14+http 页面1	93%	89%
Ubuntu 14+https 页面1	93%	89%

上述的页面2的Performance Scores对比：

	PageSpeed Score	YSlow Score
Ubuntu 12+http 页面2	98%	94%
CentOS 6+http 页面2	96%	94%
Ubuntu 14+http 页面2	98%	94%
Ubuntu 14+https 页面2	98%	94%

从数据上看，同一页面，http和https没有任何变化。但非常欣慰的是，https没有使访问变慢，不知道在高并发的情况下如何。

2018-12-09 10:16更新：
在上面的测试中，忽略了Fully Loaded Time(完全加载时间)，刚才对页面2的http和https多次测试，http的加载时间多数时候比https短，虽然PageSpeed Score的得分完全相同。再次做几次的对比：

页面2的Fully Loaded Time(完全加载时间)对比：

	http+Ubuntu	https+Ubuntu
第1次	292ms	473ms
第2次	260ms	393ms
第3次	292ms	345ms
第4次	379ms	414ms
第5次	331ms	426ms
第6次	302ms	347ms

部分截图：

Ubuntu 12+http 页面1：

Ubuntu 14+https 页面1：

Ubuntu 12+http 页面2：

Ubuntu 14+https 页面2：

由于项目需要先完成参数数据的操作，所以第一步先完成参数设置的程序，参数设置的程序约用了4-5天完成。之后下一步的程序开发是建立分组(每个分组可添加100个RSS)，再下一步是开发常用分组。之后的程序开发是编辑分组(包括改名、排序、设置为常用分组、排序、设置为头版等等)，再一步的程序开发是删除分组。

这些完成之后，才能开发添加RSS。之后，开始测试最核心的功能：更新RSS。接近尾声的时候，再开发收藏、点赞的功能。Feedval正好能通过这个收藏、点赞的功能，产生一个新的社区──Blogval.com，如果一篇博文被5个人收藏或点赞，会自动升级为优质博文，如果被20人(数值可修改)收藏或点赞，会自动升级为精品博文。

上述每一项的开发，都非常消耗时间。昨天开始编写建立分组、编辑分组的程序，尤其是编辑分组，要考虑很多因素，单是这个功能，没有5-15个小时以上是不可能完成的。因为分组、常用分组是2组数据库，如果用户提交的相关数据没有发生变化，则不对相应的数据库进行操作。规则定为，不允许出现完全相同的分组名称，以避免重复。

为了提高易用性(使用的简易性)、减少复杂度，建立分组或编辑分组时，没有把所有的表单都呈现出来(如下最后的图3，是把所有的表单都呈现出来了)。建立分组时，只输入分组名称，只有一个唯一的选项：设置为“常用分组”，如下图：

编辑分组，有2个排序，一个是总分组的排序，一个是常用分组的排序。为提高用户识别度，如果未设置为常用分组，则不出现常用分组的排序框，只有打上勾时才会自动出现，如下的2个截图：

从11月26日开始正式编写这个项目的程序，到今天已经11天，现在每天编程7-9小时左右，合计已经用了80小时以上。项目进展比较顺利，尚未遇到解决不了的问题。

只是远低估了这个项目的工作量。有很多都是从未写过的新模块，这一块儿占用的时间多一些。这个项目用多少时间，完全无法预估。

去年帮我同学写的程序，原来预估两三天就能完成，然后答应了。结果……没有回头路，答应的事就得做到，后悔也来不及了。用了120-150小时以上，合26个正式工作日，连续加班才完成。

Feedval、Eachval都是全免费的程序项目。最初预估的是Eachval的工作量是Feedval的30倍以上，现在看来，得重新预估了。

如果一个程序项目在一个月内能完成，已经相当快了。预估虽然误差很大，但是我需要有个时间计划。去年就曾有一次估计四五天的一个小程序，结果一个下午就完成了。

预计Feedval的程序需要200小时左右，Eachval的程序需要300-400小时，Blogval的程序需要100-200小时的工作量。祝我好运！

程序编写非常消耗时间，开发程序的时候，需要考虑的因素太多，少一个工序都不行，进度很慢很慢……

即使一个项目是10个人里有9个人说不好，却有1个人会说“太好了”、“好得不得了”，那么这个项目依然是很完美的好项目。何况大多数项目(已知名的)，10个人里至少有5-8个人说好。所以，我们还有很多机会。(当然，有很多项目用户并不会去体验好不好，而是不关注。)

就像现在已经很少人用的“过时”产品，XP系统、Ubuntu 12、CentOS 5、安卓2.3、安卓4.1，等等，我依然在使用。因为我发现了这些老版本的闪光点，越是老版本，运行速度越快。

比如安卓手机，现在人们多是使用5.1、6.0～8.0的系统版本。我却发现5.1版本开始很难root，6.0以上已经彻底禁止root。root是很重要的权限功能，禁止root的手机会有很多重要的功能无法实现。所以，安卓最经典的版本只停留在4.2、4.3、4.4。

那么，安卓2.3和4.1现在还有使用的意义吗？回答是肯定的。因为安卓2.3和4.1都能root，也都能运行ES文件管理器，这样可以更换内置的/system/media/audio目录下的铃声、提示音、闹钟铃声。打电话的手机，用安卓4.1～4.4，绝对经典好用。安卓2.3，也能用来打电话，或者当闹钟。

这个时候，可能使用功能机的朋友要笑了，功能机更好用。是的，功能机最方便的地方在于，体积小，携带最方便。

以前用功能机的时候，携带真的很方便。功能机大部分是2.4英寸屏，喜欢功能机的朋友，其实有一种替代品，就是安卓2.2的电阻屏手机，也能用指头触屏操作，屏幕大约2.8英寸，体积只比功能机稍微大了一点。但是这种安卓2.2的手机，也能root，同样能更改/system/media/audio的铃声，所以比功能机强大很多，也比功能机便宜很多。

可见，无论什么产品，都有很特定的用户群、忠实用户，本文用我们每天的贴身产品手机做一个例子，实际上现在很多人的主力手机都使用1000多、2000～3000以上的高端机型。

项目中总是需要用到这3种语言，这是第4篇将这3种语言进行对比。在长期的实战中，从语法、易用性、易读性上来看，PHP在这3者中，相对是最简洁的。

JavaScript和PHP，一个是前端(客户端)，一个是后端(服务器端)。PHP比JavaScript易学、易读。两者的语法，高度相似。先学PHP，再学JavaScript会容易很多，有一个很重要的原因是PHP能独立实现一个项目，较容易有成就感。JavaScript学了很久，都无法完成一个项目。(当然无法完成，因为JavaScript本身无法执行服务器端的任何数据操作。)

但JavaScript是不可缺少的，很多新潮、炫酷的效果，都需要JavaScript来完成。如下2图，就是PHP和PHP+JavaScript的对比，功能是类似的，图1是我编写的Arsue Blog的后台页面，用的是PHP+HTML；图2是我在开发中的Feedval的webapp版的参数设置页面，用的是PHP+HTML+JavaScript。

JavaScript已经是一种应用广泛、日益变得历史悠久的底层web语言，如今流行的JQuery就是在JavaScript的基础上编写而成的组件。

很多需要进行人机交互的功能，例如Webapp，完全依赖于JavaScript，可以模拟很多手机的操作。我在项目中，最高频使用的特性是.innerHTML，可以使某个id区域，不用刷新而让数据产生变化。

2001年我买的一本将近2cm厚的JavaScript的书，看了几个月都没有学到什么。让我学会JavaScript的是学会PHP之后，因为语法太相似，几乎完全相同，所以不用刻意另外学，会了PHP就会JavaScript。

Shell编程，基于bash程序，易读性比PHP复杂了不少。对于习惯了PHP编写的我，遇到需要数据处理的时候，我宁愿用PHP编写，然后在Linux服务器上用wget来获取这个PHP文件产生的数据，来传给CentOS/Ubuntu/Debian系统。

Shell编程一是可以执行服务器的操作，二是有些PHP无法实现的功能，正好某个CentOS/Ubuntu/Debian系统下的软件、组件、或命令能实现，这时交给Shell编程来完成。

这3种，PHP的语法最简洁，环境的兼容性最好。JavaScript会受客户端不同的影响，某些特性不支持；Shell也会受系统的影响，某些命令在一些系统下不支持。