永久优惠制的益处:双赢
2018年12月15日 08:00

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

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

固定链接 | 发表评论(0) | Trackback(0)

相依为命的比利时兔、熊猫兔
2018年12月14日 07:48

最近发现这2只都是公兔。熊猫兔(图1的白兔)已经养了11个月,体重7.4斤。比利时兔(图1的棕兔)已经养了2个月,体重5斤多,来的时候体重不到半斤。图片看起来,好像棕兔比白兔大了,是因为白兔比较胖,睡觉时缩成一团。

兔子还有个习性,一旦适应环境后,白天大部分时间都在睡觉。这只棕兔从小就跟着白兔,把白兔当作是妈妈,每天形影不离,总是扎堆在一起。

下图就是比利时兔的一张正脸,现在已经长大了,经过了2个月就变成了少年兔,没有小时候那么萌了,遗憾的是,没拍下它小时候的照片。不过,比利时兔和北极兔小时候几乎一模一样这里有一段北极兔幼兔的求生视频,太萌了。

还有第3只兔,白色、粉耳朵,可能是新西兰兔,2006年的时候没有养活(当时的照片),那时候不会养,只喂菜,而且正好又是深圳的冬天,都拉稀死了。

这次又养了一只同样的,2018年10月26日买的,当时不到半斤,现在已经长到4斤多,生长也很迅速。现在会养了,怎么养都不会死,以草+兔粮为主,喂一些菜,无限量供应凉白开。兔子最喜欢的食物是:菜>兔粮>草,最健康的食物是草+兔粮。

下图是30天前拍的,是不是比利时兔长大了好多呢?所以说:兔子食量特别大,生长速度惊人。2个月就能从半斤,长到5斤。

固定链接 | 发表评论(0) | Trackback(0)

Feedval的开发实况(3)
2018年12月13日 07:33

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

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

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

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

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

开发进度截图:

英文版截图:

手机网页版截图:

固定链接 | 发表评论(0) | Trackback(0)

写开源软件居然会上瘾
2018年12月12日 07:25

从今年我才开始有了写、发布开源软件的想法。因为开源软件,能积累更多忠实用户。无收入的事情没有人愿意做,就像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区域会有一定的数据丢失,这一块儿将会重点编写防错程序。自动纠错的部分,暂时不编写。除非是一个极其重要的数据项目,才会大量写入自动纠错的程序(工作量会增加很多)。

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

固定链接 | 发表评论(2) | Trackback(0)

HTTP和HTTP2(多路复用)的实际跑分测试
2018年12月11日 10:08

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

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

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

http的多图片https的多图片
第1次0.6s0.6s
第2次0.6s0.6s
第3次0.5s0.6s
第4次0.5s0.6s
第5次0.5s0.6s
第6次494ms0.6s
第7次0.5s0.6s
第8次0.6s0.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次332ms455ms
第2次391ms0.5s
第3次347ms443ms
第4次346ms446ms
第5次364ms468ms

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

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

固定链接 | 发表评论(0) | Trackback(0)

Ubuntu/CentOS+HTTP/HTTP2的速度测试
2018年12月09日 08:45

我的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 ScoreYSlow Score
Ubuntu 12+http 页面193%89%
CentOS 6+http 页面189%89%
Ubuntu 14+http 页面193%89%
Ubuntu 14+https 页面193%89%

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

PageSpeed ScoreYSlow Score
Ubuntu 12+http 页面298%94%
CentOS 6+http 页面296%94%
Ubuntu 14+http 页面298%94%
Ubuntu 14+https 页面298%94%

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

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

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

http+Ubuntuhttps+Ubuntu
第1次292ms473ms
第2次260ms393ms
第3次292ms345ms
第4次379ms414ms
第5次331ms426ms
第6次302ms347ms

部分截图:

Ubuntu 12+http 页面1:

Ubuntu 14+https 页面1:

Ubuntu 12+http 页面2:

Ubuntu 14+https 页面2:

固定链接 | 发表评论(1) | Trackback(1)

Feedval RSS阅读器的开发实况
2018年12月08日 08:08

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

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

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

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

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

固定链接 | 发表评论(0) | Trackback(0)

低估了Feedval RSS阅读器项目的工作量
2018年12月07日 15:03

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

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

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

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

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

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

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

固定链接 | 发表评论(0) | Trackback(0)

做项目有时候真的简单
2018年12月06日 07:51

即使一个项目是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以上的高端机型。

固定链接 | 发表评论(0) | Trackback(0)

JavaScript和PHP、Shell(4)
2018年12月05日 07:55

项目中总是需要用到这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也会受系统的影响,某些命令在一些系统下不支持。

固定链接 | 发表评论(0) | Trackback(0)

下一页(旧) | 下一页(新) (共34页)

王志勇:1980-09-26 (38周岁)
程序设计,前端设计。

版权声明:本博客所有文章,均符合原创的定义,禁止转载,违者将必究;正确的方法是贴原文的标题和网址即可。

与此相关的链接
自由勇专栏

Blog存档 Archives

2018年12月
2018年11月(30)
2018年10月(30)
2018年09月(17)
2016年-2017年(9)
2014年06月-09月(10)
2013年 +

2012年 +
2011年 +
2010年 +
2009年 +
2008年 +
2007年 +
2006年 +
2005年09月(4)

Copyright © 2006-2018 auiou.com All rights reserved.
此Blog程序由王志勇编写 已经发布在Arsue