2018年12月的文档 17篇:

永久优惠制的益处:双赢
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)

2018.12.4昨天中午的亲子小对话:关于读书和未来挣钱的关系
2018年12月04日 21:30

我平时和女儿交流的时间有限,所以到了吃饭的时候,经常有说不完的话。昨天的内容:

1. 为什么有的人,读书1年能比别人3年读得还多?因为很多人不珍惜时间。时间荒废了,效率就低了。
为什么有的人,新到一个地方3个月就成为团队里专家、主力,有的人永远都是在很底层?因为人家早就深思熟虑无数次,在一个领域里如果已经达到较高水平,换了一个领域也很快能达到较高水平,方法都是相通的。
一个勤奋学习的人,如果除去人事排挤的原因,在团队里至少能做得很出色,并成为不可替代的主力。勤奋的人,永远都会有更多的机会。

2. 一个人,无法和一个团队、或者一个平台相抗衡。有平台的人(已成功的创业者),是少数。没有平台的时候,可能需要不得不做很多工作,为了谋生。没有人能例外。
一旦平台有了,就可以删掉那些繁重而低效益、甚至卑微的工作。

当然,无论一个人是处于什么角色,无论做什么工作,只要努力、辛勤地工作,就是很值得赞扬的,辛勤的人总是能给人带来很多感动

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

网站图标的制作利器──CorelDRAW
2018年12月04日 07:14

我使用的是十几年前的版本CorelDRAW 9。有的网站效果很好,是因为有图标的原因。图标设计难不难?其实并不简单,有的图标设计可能一小时内就完成,有的图标设计可能需要半天、几天的时间。

网站里有很多小图标,logo里也有图标,如果一个图标设计得好,用户会印象很深刻。如果想给用户更深的印象,尽可能地创新。

CorelDRAW有一个很好的工具──贝兹曲线工具,如下图:

这个工具很容易上手,如果你开始运用了这个工具,等于是节省了很多的学费,瞬间进入了专业化,可见这个工具有多重要。创新都来源于生活,这个工具能把任意图片上的图形,通过描点,转化成矢量图。

在2000年底我刚接触电脑时,看到别人制作的那些大量的图标,非常羡慕,如今自己也能绘制图标。虽然CorelDRAW有可能不是最专业的图标软件,但CorelDRAW也能绘制出很专业的图标,尤其是网站的各种图标。它的放大镜能无限放大,这就是很多小图标看起来专业的原因,因为都是在放大镜下绘制的。那么小的图标,任何人都是无法在100%显示比例下完成,也太损耗眼睛。

比如在Feedval新项目里,我需要绘制一个图标,表示一个文本器,正在接收声波,是这样绘制的:先画一个文本,把线条的属性设置为1.2毫米粗,颜色设置为蓝色。

画一个环形和三角形,使三角形的一个角和环形的中心重合:

如果使用“窗口→泊钨窗口→交叉”的工具,无法得到声波,因为会封住口,如下图:

只好想个办法,只要用一个圆形,填充为白色,然后用这个三角形切掉一定角度,这个白色圆形原来是360度,现在剩下约270度,最后用这个270度的非整圆,盖住刚才画的蓝色环形,就得到波形了:

最后,得到这样的图标:

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

Webapp VS APP
2018年12月03日 09:27

我从去年开始开发手机版网页、Webapp,当时是帮我同学从0写了第一个企业跟单程序,经过连续加班,耗时累计120小时左右(合26个工作日)。

Webapp和APP这两者的优缺点,是比较显而易见的。手机客户端软件,优点是不用输入网址,有利于平台推广;用户安装之后,会节约一定的流量,这是因为很多数据已经缓存到本机;客户端软件自身为一个数据外壳,加载新数据时,只获取相关的数据,而无需加载整个页面,因为页面已经由客户端软件的外壳提供。

手机客户端软件(特别指国产),缺点是臃肿速度过快,冗余代码、冗佘数据过多,比如3-5年前,一个不到10MB的手机软件,现在大多已经达到50-100MB以上,比如工行APP,现在已经超过100MB了,这些大多可以精简在10MB以内。(相对来说,PC版软件优化比手机软件好太多。)
很多APP很卡,新安装的时候就比较卡,很多APP版本越高,速度越慢。

强制更新的问题。大多数的国产手机客户端软件,不强制更新,比如很多3年前的手机软件,现在还能用。什么时候必须强制更新?就是当和远程服务器的数据接口完全无法对接的时候。其实这个问题,也可以通过一定的方案解决,就是局部数据更新。(少数强制更新的软件,比如某电力APP,隔两三个月就要求升级才能使用,已经卸载很久了。)
冗佘数据过多,比如一个APP自身的体积是50MB左右,但是安装之后,/data/data/软件 的目录,一下子增加了200MB~300MB以上,现在很多国内流行的APP就是这样的。百度贴吧,今年年初的新版本,刚安装时,/data/data/ 的占用量超过1G,只好卸载,安装回2年前的版本。

大多的APP,都能改为Webapp。只有很少量客户端功能,以及需要手机系统权限、或者root权限,才需要用到客户端软件,例如拍照、录制语音等功能。

Webapp的优点和缺点,和上述的APP刚好相反。但如果加以优化,Webapp能克服很多自身的缺点。Webapp的界面,完全能和APP做得一模一样。其实说白了,就是手机版网页。手机版网页的开发,比过去PC版网页要容易得多,因为屏幕尺寸小,布局简单,只需把原来的字体调大,用相关的语句让其适应手机、PC的宽度。因此,所有网页设计者,经过几个月的练习,就能很快适应Webapp的开发。

Webapp的优点:

  1. 不用安装APP,不占用 /data/data/ 目录。节省手机CPU、RAM资源,十分流畅,3年前的安卓4.1都可以流畅地运行。
  2. 启动速度快,只要手机浏览器打开,打开收藏夹、或者输入相关网址,1秒钟打开。
  3. 不用升级APP。
  4. 对于超大流量、高并发的平台,如果想大幅度节省流量,可以制作一个“外壳”网页,设置此网页的缓存时间为72小时以上,数据由JavaScript调用。或者更理想的是,除了制作“外壳”网页,所有的数据也设置缓存时间为15天以上,由一个变量来判断是否有更新,当有更新时,则自动获取相关的最新数据,这一种也是这一年中我一直在思考怎样开发的,具体实施起来有一定难度。

Webapp的缺点:

  1. 就是上面谈到的,少量的手机客户端功能无法实现,但一般没有大碍。
  2. 所有的人机即时交互功能,都依赖于JavaScript,会有非常大量的JavaScript语句编写,所以对于手机浏览器的兼容性有一定要求。要避免这个问题,就是尽量地使用原生的JavaScript,尽量使用10年前的浏览器都可以支持的JavaScript语句。当然,这个问题不大,一般可以避免。
    交互功能,尽多地交给远程服务器来完成,因为远程服务器来处理数据,能够避免所有的浏览器兼容问题。

Webapp,上述的缺点一般情况下都不是缺点。唯一的缺点是手机浏览器自带的悬浮导航,这个是无法去掉的。这个底部的悬浮导航,以安卓系统为例,安卓4.2会在打开网页,或者滑动网页后约3秒消失,安卓4.4则在4.5秒-5秒消失。安卓5.1,这个底部的悬浮导航,一直存在,占用了99像素的高度。所以,Webapp的菜单按钮,很难放在网页的最下方。

为了解决这个问题,我去年曾把Webapp的菜单按钮放在网页的最底部,刚打开网页时,由于悬浮导航的存在,先让这个Webapp的菜单向上提高90像素(以躲开悬浮导航),5秒钟后自动落到最底部,外观看起来和APP没有区别。当滑动网页时,悬浮导航又自动出现,这时Webapp的菜单还会向上提高90像素(以躲开悬浮导航),5秒钟后自动落到最底部。这样做,虽然暂时解决了,但是缺点是Webapp的菜单总在上下跳动,让人感觉不稳定,二是到了安卓4.4,悬浮导航更频繁地出现,稍微点击一下浏览器,底部的悬浮导航就会出现。

到了安卓5.1,底部的悬浮导航一直存在,导致Webapp的菜单已经无法放在网页底部,只能放在网页的顶部了。如下截图,是安卓5.1的底部的悬浮导航:

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

底层讨论:家电──抽油烟机用什么价位?
2018年12月02日 08:17

用了10多年的抽油烟机,在前几天彻底不转了,只好重新买一台。我们这里的人际圈,都明智地发现一条规律:抽油烟机如果脏了,不要清洗,直接换,因为清洗2次的价格比换一次新机还贵;抽油烟机转速慢了、坏了,直接换,因为维修费+配件比换新机还贵。

这是真的,因为一台好用的抽油烟机,现在价位也就在150元上下。清洗一次,10年前的价格是70元,现在没有问过。我搜索了某宝上的最低价位,全封闭电机款大多在138-158元,开口电机款在108、118、128元。我买的是138元的全封闭电机款(还包邮),纸箱包装看起来也和大品牌完全一样。

半年前,我也帮家人在京东买过一台158元的,很好用。这次是在某宝买,发现外观一模一样。本来还是想在京东买同一台,但是京东那个链接下架了。

前几年,我家人买的都是900多元的,用了5年多就转得很慢,明显是电机坏了。这个100多元的,实测功率慢速137W,快速147W,用起来明显比当年900多元的风力还大得多,外观看起来也差不多。

我得出一个结论,900多元的抽油烟机在各种环节中要被赚取700元的利润。更不用说那些1000多、2000多的抽油烟机的利润。商家最喜欢“一分价钱一分货”的宣传理念。
这些的构造都是一样的,就是一个电机+外壳,电机的成本在几十元~100多元左右。

这种100多元的抽油烟机,总利润估计也就在20-30元最多了,这也许是同行价格战竞争的结果,产品以接近成本价出售,它的纸箱包装成本至少都在10元左右。而且,有很多品牌都是完全相同的外观。这种电子产品模式,是成熟的,利国利民。向这些厚道的商家致敬!

那么,这么便宜的抽油烟机安全性怎么样?因为它的电子构造很简单,就是一个普通电机。电机在电子产品中应用太多,比如各种泵、吹风机、鼓风机、洗衣机、电力车等等,安全性是一样的。而且,电机是消耗品,所以抽油烟机也是消耗品,再贵的抽油烟机性能也差不多,用了几年转速可能会变慢,原来买得太贵会舍不得换

昨天把出风口和管道的地方,有漏风的地方都用透明胶粘严了,几乎没有一点漏风,这是抽油烟机的构造原因,不是质量问题。

2018-12-02 08:38更新:需要补充一下噪声问题,电机本身没有多大声音,声音大是风声。就像电脑CPU的风扇,实测功率在3W左右。3W风扇的风声都那么大,更不用说137W的风声。声音太小的抽油烟机,风力必然小。所以,噪声不是问题,因为那是风声。

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

什么样的博文链接是最好的?
2018年12月01日 10:44

最近开发中的Feedval、Blogval项目,需要对每一篇博客的地址进行分析,分析出该地址在数据库中是否存在,如果存在,则不写入相关的数据库。通过这个项目,我发现短链接有很多好处。

为什么有时候一些明明可以很短的链接,在网上却非常长呢?比如一些新闻链接、搜索链接、大网站的平台链接等等,网址特别长。可能有2个原因:原因1. 没有及时精简、优化,比如搜索结果中有很多空的查询字段,如item.do?a=&b=&c=2,在等号后面如果没有值,这个链接完全可以在程序中精简为item.do?c=2。原因2. 面门装修、充门面,网址特别长,让人感觉是大网站,不排除这种可能,可能至少有20%以上的平台有这种现象。

和上述的原因2相反的,短链接,会不会显得不专业呢?不会。大约在2006年,我常关注oreilly.com这个网站,那个时候是个大的技术社区,有点类似于现在的csdn.net,但更像现在的Donews,因为oreilly当时不仅仅讨论PHP、Web前端、JSP、ASP.net,里面还有各种故事,甚至飞行员也在上面发文章。

当时的oreilly,每篇文章就是超短的链接,例如 oreilly.com/abc/2312 这样的,很多文章的回复数很多,这是一个短链接平台的绝佳成功案例、励志案例。当然,如今这个网站的社区可能已经取消了,已经变成了类似于企业网站。

本博客也在当初开通的时候,想过这个问题,最后决定用中等长度,不长不短,既不会看起来不专业,又不会过长。当时的另一个“外观装修”,是文章的ID从1001开始计数,发了240篇之后,我十分后悔,又重新从1开始计数。经过了12年,本博客的文章ID即将和当初的计数开始相连。(有几十篇博客我最近删除了,原来的文章ID重新回收利用。)

很遗憾当初我的博客没有用 http://www.auiou.com/rel/973 这样的短链接。当时没有用这种短链接,一是当时的主机不支持404错误页或Rewrite,更主要是当初自己没有这个技术,直到2009年才掌握了这个技术;二是“外观”因素。如今想改成这种短链接,技术上容易实现,但是可能会影响搜索排名,所以不会轻易改,只能用建新博客的办法。

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

较大损失:丢了一个心爱的香港号码
2018年12月01日 09:49

前几天正要给我的一个香港手机号码充值时,发现号码已经没有信号,这个号码是3A号,5985 AAA0。虽然号码不怎么值钱,但是是去年关注了三四个月,经过很多天的精挑细选,才拿下了这个心爱的号码,所以损失很惨重。再关注一两年,都未必能拿到类似的号码。

一直记得这个号码是2018-11-08到期,一咨询客服,该号在9月初停机。香港移动规定,号码在停机后,会保留30天,所以这个号码怎么都拿不回来。

当时买这个号是为了做香港的业务,虽然暂时用不上,先提前买上备用。香港移动的系统,有一个世界上最不好的规定,储值卡的号码有效期不能累加。充值之后,有效期最多180天。而且,充值之后,之前的有效期全部清除。

例如:某张卡的余额在2019.3.30到期,现在充值后的有效期,按照传统的理论应该是2019.3.30+180天≈2019.9.30到期。

实际上不是这样计算,香港移动会这样计算,假如今天充值,有效期为2018.12.1+180天≈2019.5.1到期。

充值4张卡,按照传统的理论,有效期应该是180×4=720天。但是香港移动,无论充多少张,有效期都不累加,所以,号码稍不留神就过期。

这不像我们的域名续费、或者过去的神州行充值能累加有效期

这么心爱的号码就这样丢失了,一时难以适应,请大家允许我难过一段时间。解救的办法,只有重新买一个类似的号码补上。

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

Feedval RSS阅读器项目如何跑完马拉松
2018年12月01日 07:12

PHP版的RSS阅读器,我看了一下本机的文件夹创建时间,整整在一年前,2017年11月29日,当时我大概用了两三天的时间,完成了单机版的程序,大约完成了70%左右。由于没有彻底完成,所以这个程序一直没有用过。这类PHP版的程序,开发思路比较简单,主要就是运用file_get_contents()的远程调用函数,获取各RSS之后,进行分析。

这类单机版PHP版的程序,这几年在我电脑里写过一些。比如5年前写过的百度贴吧清爽版,当时有博友问能否下载,那个很难发布,因为那个应用产生的原因纯属是因为贴吧上的头像、签名很眼花缭乱,自己急需一个清爽版,由于网上找不到,只好自己写;二是这类可能需要经过百度许可,开发者个人怎么用都不会有问题。
除了这个百度贴吧清爽版,当时我也写了常去的论坛的清爽版,就是运用file_get_contents()函数,然后截取出相关的数据,再用PHP重新生成简洁的HTML页。

单机版程序,比公用版开发简单得多。比如本博客是一个单机版程序,2006年时用了大约10个工作日从0完成,2010年底程序又从0重新重构(博客和评论数据保留),当时花了4天左右的时间。然而,2012年从0编写为公用版的时候,后台程序增加了很多功能,则用了60个工作日以上的时间。

同样,当这个Feed阅读器要发布为公用版时,开发周期比单机版长得多。因为当有新版本时,升级时不能让用户把原来的删除,再重新安装,这样会导致用户的数据丢失。因此,需要用在线更新的功能,用户数据部分则保留。
公用版还需要考虑功能的完整、完善、用户体验,例如Feedval公用版的一些参数计划

Feedval项目,需要经历这样的马拉松开发过程:
1. 在线安装程序。是的,整个项目必须先从这个程序开始,才能进行下一步。
2. Feedval的主体程序、在线升级程序开发。
3. Eonval帐号的开发。
4. 用Eonval帐号测试登录Feedval。

为什么需要用Eonval帐号?一方面,需要用密码登录才能使用;一方面,用户只要注册了一个Eonval帐号,就能用同一帐号使用平台下的其它产品;另一方面,平台容易整合。

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

王志勇: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