2014年年底的某一天,在家跟来爷通QQ电话讨论项目,发现我的Mac内置麦克风采集不到我说话的声音了。 前一天还是好好的,怎么突然就不能用了呢?刚开始以为可能是某个地方配置出问题了,把麦克风静音了。 但是查看系统配置,没有任何问题,不过有一个很奇怪的现象,就是配置中的电瓶显示能采集到我敲击外壳和键盘的声音。 我又试了几次,并且用录音软件试了下,果然是能录下来敲击键盘和外壳的声音,而说话的声音,必须要极端的大, 才能录制上蚊子的声音。

我在考虑是不是驱动因为当晚安装内录软件有问题了,于是卸载了内录软件,也没有效果,于是放狗开搜。 不要问我为啥不用百度,因为百度根本就屁毛都没有。。

于是搜到了很多麦克风的问题,大家都说到了要重置SMC重置PRAM,但是试过后也是无果。 不过他们跟我遇到的情况也不大一致,直到找到下面这个帖子:

http://forums.macrumors.com/threads/how-i-fixed-my-internal-microphone.410734/

不得不说,关键词的力量,之前一直用click来描述我的问题,换成flick后,就找到了这篇帖子。

这个帖子的楼主看来遇到了和我一样的问题,且时间很早,都是2008年的老帖子了。。。

不过楼主的解决方法很奇葩,就是敲了敲麦克风位置,然后。。。。然后就特么好了。。。

然后楼下好多人都成功了。。。

关键是,我都把手指头快敲断了,毛线效果都没有看到,这是闹哪样,难道是我的姿势不对?

又折腾了一天,于是放弃了。。。

时间回到当下,最近又想折腾下我的麦克风了(突然想到了一句歌:是谁抢走了我的麦克风。。。),于是继续google。

这次巧合的是,我又找到了当年的那个帖子,抱着侥幸的心理,又当当当的敲到手疼。。。。。然并卵。。。

不过我又找到了下面的一个帖子:

http://apple.stackexchange.com/questions/90123/internal-mic-stopped-recording-voice-but-hears-case-keyboard-touching

其中有人说到,用针戳一戳就好了。。。话说我当时也想到了这个问题,但是我仔细看过了麦克风的孔,很细, 也没有堆积灰尘,至少在肉眼看来是这样的。但是现在也没有办法了,就去找了根很细的针,轻轻的把针尖插入, 也仅仅只是能插入一毫米的针尖。转动了下,拿出来,针头上居然有灰!!!!!!

毫不夸张的说,这个灰的体积也就是1立方毫米!!!

然后我对着麦克风说话,看到配置界面的电瓶居然有反应了!!!!!

立马清理了所有的小孔,然后用Skype测试了下,麦克风终于恢复正常了!!!

真心觉得这个是个Bug,太丧心病狂的Bug了,心里真的是有一万匹草泥马奔驰而过呀。。。

去年下半年花了很久的时间从零开始,然后搞了个土壤湿度检测的东西,成品就是下图的样子:

成品

本计划是想直接把土壤湿度检测装置安装到树莓派上,然后用python之类的脚本语言去采集数据, 并发布到网络收集器上,同时提供低于阈值微信提醒。但是后来才知道,原来树莓派只接收数字信号, 不接受模拟信号,买到的土壤检测装置,如果想要提供具体的值的话,需要采集模拟信号。 对于一个非电子专业的人来说,终于借这个机会大体知道了什么是数电,什么是模电了。

既然没法直接搞,就看看中间加个转换,试了试之前那个不能用的arduino,好吧依旧不能用。 就花钱买了个ADC,结果搞了两个月也没有搞明白该怎么接线,就更不用说怎么写个支持树莓派的驱动了。。

于是重新回过头来研究arduino吧,看看到底能不能修好。最终发现原来是某些烧写配置不对, 重新配置后,烧写测试通过。关于烧写A8M的配置就放在了gist,https://gist.github.com/ety001/d44bd7c770b2d2937cfb

最终就是树莓派通过arduino来读取采集器的数据,并走wifi把数据上报,达到阈值就发微信提醒。 下面的链接就是采集的湿度数据了:

http://www.yeelink.net/devices/343089/#sensor_380664

今天开始就关停这套设备了,因为插入土壤的探测部分,真心的不耐腐蚀。 所以现在经过实验后来看,当下淘宝上卖的类似这样的土壤湿度检测元件, 也就是进行下实验而已,想要长时间使用则是不行的。

长时间使用的话,就像下图的样子了:

长时间使用的土壤检测装置被腐蚀

可以看到PCB板上的金属多部分都已经被腐蚀了,这也是导致有段时间的数据一直为零的原因。 由于我设置了当湿度低于40%就进行微信提醒,每天至多提醒一次,所以那段时间天天都有微信报警。。。 当时还纳闷,是什么原因导致的,后来一个周末,把上图的那个装置从土里拔出来,才知道原来是这样。

于是又更换了新的探测装置——不锈钢小条,结果稳定使用3个月后,又被腐蚀了,

不锈钢都被腐蚀了

可以看到有一根被腐蚀断了。我观察到断的位置是这根不锈钢条插在土里面时,土壤与空气交界的地方以上的部位。 这就引发了新的思考,为啥一根完好无损,另一根就被腐蚀的很严重呢。刚开始以为可能是土壤的问题, 但是后来看了最早的那个原装的探测装置的腐蚀情况,发现腐蚀也是不对称的。

一阳一阴,一正一负,突然间就想到了原来化学课上学过的电解。如果用电解的思路来考虑的话, 就能解释为什么只有一根腐蚀严重了,土壤应该只是提供了潮湿的环境和土壤中的离子,也就是土壤充当了电解质。 由于arduino的电流很微弱,所以化学反应进行的很缓慢。另外腐蚀严重的一端应该就是正极, 这个在拆下来的时候也没有仔细看看。。

总之,就当做是做了个实验吧。

这两天再更换博客的主题,顺便把博客内的文章分类重新整理下。

由于有一部分的tag的更改具有重复性,为了省力气,就用sed来完成批量替换。 进入_post文件件后执行下面的命令,遇到了invalid command的错误,

➜  _posts git:(new_theme) sed -i "s/categories/tags/g" `grep "categories" -rl ./`

sed: 1: ".//2010-11-19-16-days-r ...": invalid command code .

对命令修改了好几个样子,都是报invalid command code,最后在stackoverflow找到了答案, http://stackoverflow.com/a/7573438/2086146,原来是需要再增加个参数来选择是否备份源文件。

即命令可以修改成下面的样子:

➜  _posts git:(new_theme) sed -i.back "s/categories/tags/g" `grep "categories" -rl ./`

这样,sed命令会把源文件备份出一个后缀为.back的文件,然后在源文件里进行修改。 如果想直接替换源文件,可以修改成下面的样子:

➜  _posts git:(new_theme) sed '' -i "s/categories/tags/g" `grep "categories" -rl ./`

最后打印了下sedhelp,的确是有个参数,不过没有写怎么用。。

➜  ety001.github.io git:(master) ✗ sed --help
sed: illegal option -- -
usage: sed script [-Ealn] [-i extension] [file ...]
       sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... [file ...]

昨天下午开始到今天上午,终于是把博客的主题换好,并对文章重新进行了分类整理。 从WordpressJekyll后,一直沿用Jekyll自带的主题,没有时间去更换, 文章也是用脚本从Wordpress搬过来的,所以导致分类也是乱糟糟的。

更换主题的起因是,原来自带的主题在手机下的访问体验很不好。为了能保证之后顺利的在 朋友圈分享自己博客的内容,所以就决定换一个对手机访问体验友好的主题。

另外,糟糕的分类也是不便于查找和阅读,因此几乎花了大半天的时间在这里整理自己之前的博文。

在整理的过程中,其实也在快速的review下之前的东西。

发现自己从记博客开始,很大的时间比例是花在服务器环境的搭建和操作系统的配置上面了。 感觉自己更像是网管,而不是程序员。如果按照自己原来想做一个架构师的目标来看, 方向还是偏离了很多。发生这个偏差的原因,我分析除了我自我的兴趣点比较多以外, 那就是在计算所的工作内容和工作环境了。

从时间角度来看,我2010年开始建立博客,那时候是大二,到2011年底去计算所开始实习, 这段时间更多的内容是转载。从2012年–2013年是高产的两年,更多的是因为项目推进需要新的知识, 以及项目中遇到了各种各样的问题。这也再次证明了,加入一个项目去动手实践才能推动自己的技术积累。

从质量角度来看,转载的比例过大。虽然在2014年开始已经开始注意减少转载, 但是自己动手写的东西,更多的还是像流水账,像是备忘录。行文组织乱,文笔缺少亮点, 这应该得慢慢的去练,最终形成一个自己风格的文体。

从生活角度来看,由于最初对于博客的定位是技术笔记,但是慢慢的发现,我们的生活是丰富多彩的, 作为个人博客,还是应该把自己的一些所思所想记录下来,让博客看上去更有生气,而不是一堆堆的代码。

注重生活,注重思考,注重总结应该是下个阶段的目标。

春节假期快结束的时候,终于是找到了些时间来埋一埋去年的坑。经过2.2.0到2.2.6几个版本,终于把新版完成了。

在去年年中的时候,我开发了一款chrome应用,目的是为了方便自己整理自己的书签栏。想法很简单,就是利用零碎的时间去review自己的书签栏,没有用的就可以删除掉了。毕竟,单独拿出时间去整理书签栏,是个很累人的活,把这个活分散成零碎的时间去完成,倒也惬意。

这个想法其实是四年前的,只不过一直没去做罢了。每当自己的书签栏迫切需要整理的时候,就会想起来这个想法。终于在去年7月左右开始动工了。

不过开发进展不是很顺利,毕竟自己不是个专业前端,英语水平也一般,看chrome的文档就耗费了很多精力。先是把整个的chrome的文档页面的结构理顺了一下。真的是很想吐槽下chrome开发的文档组织的很糟糕,Api接口的列表的进入放在了一个三级的目录中,几乎每次要找一个Api接口的时候,都要翻好久,主要是找一级菜单就要花好久。

后来习惯后,也就习惯了。。。

最初的计划是能够每次打开新标签页的时候,自动提醒一次,提醒的数据是随机从书签栏里获取,使用 Chrome 的 Notification 接口显示书签名和地址,并提供打开和删除按钮。(原始想法,雏形)

但是在开发的过程中,首先发现的问题是,随机获取一个书签并不是像自己想的那样。 本来计划是扩展安装的时候,自动把书签一次性读入到html5的本地存储中去,然后从本地存储中随机获取。但是这里面涉及到几个点:

1、使用何种本地存储能方便的检索数据?
2、用户变动书签信息(增加、删除)的时候,还需要同步到本地存储中。

考虑到后期可能会迁移到 Firefox 和 Safari,于是选择本地存储的时候,我除了考虑数据的获取外,还参考过兼容列表。最终觉得还是先不要想那么远了,先把chrome版本的做好再说其他的。于是选择了IndexedDB。

然后的问题就是如何随机。在考虑这个问题的时候,我最先想到的就是获取本地存储中的书签列表的索引范围,然后写个方法来从这个索引范围中随机一个数。但是后来觉得这样不是很妥,如果随机性不是很好的话,那么可能某些书签被随机到的概率很大,那么效果就不理想了,或者是某个书签连续几次都被随机到,那么用户体验也是不好的。

那么能不能加个访问量的字段,然后把这个字段纳入到随机数的计算中呢?倒是可以,不过貌似这样程序就复杂了太多了,我也不知道最后做出来的效果是否满意,所以最后就放弃了随机一条书签的计划,改成顺次提取一条书签了。实验证明,这个方案至少我自己是满意的。

另外的就是找到书签的监听接口,在用户操作书签的时候,能把数据同步到本地存储中。不过这里当时为了赶时间尽快做出来看效果,就省掉了数据同步,而是每次打开新标签页获取一条书签的时候,都会读一遍全部的书签列表,然后把索引记录在本地存储中,以及这次访问的索引值存储在本地存储中。

第一版差不多就这样勉强的上线了。

上线后,发现还是有不少人来安装,真的是很感谢这些初期的用户。但是貌似我没有具体的运营数据。于是又研究了下 Google Analytics,在扩展中加入了一些操作事件的记录,依次来看一下,现在有多少人在用,提醒了多少次书签,删除了多少次书签。依次来判断我的扩展的价值。

之后,有用户开始反馈。反馈的主要问题就是弹出框和不再提醒机制。

弹出框的第一个问题,主要就是各个操作系统的 notification 差异性导致的。在 Win 下,notification 是在右下角弹出,而 Mac 和 Linux 下是在右上角。我的开发环境是 Mac,所以最初在右上角弹出,我觉得可以,就没有多留意。后来 Win 用户提出来能不能把提醒从右下角放到右上角,我才发现了这个问题。

弹出框第二个问题,右上角弹出的时候,有时候可能正好挡住了标签页的关闭按钮(在标签页打开了很多的时候),这样进行关闭标签页的操作时,要先关闭 notification ,才能点击标签页的关闭,显得很不方便。

弹出框的第三个问题,chrome升级某个版本后,notification 不再自动关闭了,只能手动关闭了。

弹出框的第四个问题,chrome 的 notification 只支持添加最多两个按钮,而当前已经有『打开标签页』和『删除』两个了,想再增加『不再提醒』按钮是不可能了。

关于『不再提醒』功能,是用户提出来的,希望能够把一些书签设置为『不再提醒』。

针对用户提出来的这些问题,我一直都很想处理,最后还是拖到了年后。

年后第一版v2.2.0,重构了本地存储部分,把书签存储在了 localStorage 中,并且完成了用户变动书签后,自动同步到 localStorage 中,这样每次取数据的时候,只需要从 localStorage 中获取 bookmark_id ,然后再调用 Api 取详细信息即可。这样也便于以后向 Firefox 和 Safari 迁移。

v2.2.0 – v2.2.2 还弃用了 notification 接口,使用替换『新标签页』的方式,我自己写了一个 html 页面,可以显示书签标题和网址,带 iframe 预览功能,带『新标签页打开』,『删除』,『不再提醒』等按钮。

上线后,好几个用户反馈能不能不替换新标签页。其实我最初也是不想替换的,但是无奈 chrome 应该处于安全考虑,不允许向 chrome://newtab/ 插入js代码,所以我也是不得已为之啊。

不过经过思考,觉得没必要非要在『新标签页』中进行提醒呀。于是开始开发迷你模式,即把弹层放到了正常的网页中去,也就是现在 v2.2.6 版本大家所看到的。

到此,这个扩展应该基本上就完成了。估计短时间内是不需要增加或者修改什么功能了。

总结一下,开发扩展基本上就跟开发传统软件是一样的了,应该要遵循传统的流程。平时自己写 PHP 网站写习惯了,遇到问题随时修改随时上线。现在扩展出个bug,至少要60分钟才能发布完毕,等用户升级到新版本还不知道什么时间。我在开发的时候,经常遇到的就是这个问题,某个版本发布前已经测试的很不错了,结果在商店点击完发布了,又用了几次就发现新问题了,导致自己不得不增加版本号,重新上传修复bug后的版本进行发布。

另外就是需要加强与用户的沟通和交流,现在感觉做的最不足的就是这一点。其次就是交流后,用户反馈的哪些该采纳,哪些该舍弃,还是个很让我迷惑的问题。这个还需要再思考思考。

最后,附上扩展地址和反馈地址:

http://bm.to0l.cn/

https://gitter.im/ety001/bookmark-extension