The publication of VS 2015

C drive is red
Once it was blue
Install VS
And so are yours

其来有自的音乐库（11）

我的音乐库已经有好久没收入新的专辑，这个系列，包括这个博客。但这个坑我还是认的，总会填完的。我的iTunes升级过后怎么连专辑排序都乱了，我只好把以前没写过的写进来。

使用adb及fastboot进行刷机及安装程序

这周尝试着把Nexus 5刷了个Android M预览版来玩，结果刷好后10个App有9个都不能用。赶紧下了个5.1.1的工厂镜像想要刷回来——但是失败了。刷完后一直处于“更新应用程序——重启”的死循环中，无奈又重刷了一回。因为我想保留应用数据，所以7个镜像文件中userdata.img和cache.img没有刷。我后来分析这应该就是祸根的所在。于是我把脚本改了改，除了system.img没刷，其余6个都刷进去了（system较大，偷懒不想等太久）。这下可好，直接卡在开机的"Google"界面了。进入recovery mode双清也是相当慢，我一度认为双清也卡死，无法完成。

Javascript正则表达式笔记

由于最近项目需要从字符串中提取字串，具体地说是匹配实数集R（严格的说是有理数集Q）中的元素。网上找了一圈没一个能用的，不知道是不是我使用正则表达式的方法有问题。而且网上似乎转来转去的都是那么几篇文章，无奈只能自己来写。

由于不能预见字串会有几位小数，正负也不一定，所以下面的正则表达式匹配的是一切实数（严格的说是有理数）：

var str1 = "transform(-332.44,567)";
var str2 = "transform(0,-42)";

var regExp = str1.match("/0|-?\d+[.]?\d+/g");     // regExp=[-332.44, 567]
regExp = str2.match("/0|-?\d+[.]?\d+/g");       // regExp=[0, -42]

看到几乎所有的文章都只记录了表达式，而没有告诉读者表达式是如何写出来的，读者往往只能知其然而不知其所以然。这里再说一下这个正则表达式书写的过程。其实只要根据实数（严格的说是有理数）的判据就容易得到：

• 0
• 可能有一个负号（负数），或者没有（正数）
• 可能有一个小数点（小数），或者没有（整数）

所以，表达式中，第一部分将0提出来，单独作为一个可能即“0|”；第二部分，即整数部分，为1~n位数字，即”[0-9]{1,}“，可简写为“[0-9]+”，进而继续简写为“\d+”；第三部分，即小数点，可能存在也可能不存在，故写为“[.]?”；小数部分同整数部分；最后，再加上js的正则表达式搜索指令g表示是一个贪心模式，即可匹配出全部的数字。

浅尝油猴脚本

好久不写博客，以前Blogger上配置的CSS都忘了是哪些了，想了半天才记起来≶p>里的内容有首行缩进。由于种种原因，翻墙是越来越难了，这也给我偷懒带来了理由。上网的时候经常会遇到一些不便，比如：该帖子回复后可见、下载链接缺头少尾等等。于是产生了改造网页的想法。先后尝试了Chrome插件和油猴脚本，最终还是觉得油猴脚本更适合干这活儿——简单、直接。目前写了两个简单的脚本，一个用来解决回复后可见，一个用来搞定下载链接的。我将逐一解释其应用场景。

秦时明月，何时可掇

下午去电影院看了《秦时明月之龙腾万里》。我并不是该系列的爱好者，此前也从未涉猎过该系列任何形式的作品。看这部电影是应高中同学的邀请，本着“不看电影也可以见见同学”的心情走进电影院的。从《秦时明月》整个系列的评价以及本次观影的感受来说，这部影片在国内动画市场堪称翘楚，但也只能是关上门在国内玩，跟美式3D动画或是日式剧场版动画还有相当差距。

其来有自的音乐库（10）

差不多2个月没写博客了，明天又有一门很难的考试，今天却没心思复习，来填坑吧。

其来有自的音乐库（9）

又到了批量结课、交论文的时节，目前暂时只有一篇论文有头绪。

CC2530 2.5.1a 协议栈研究笔记（1） —— LED及按键驱动修改

ZStack协议栈为CC2530编写了一套操作系统并规定了数据收发的协议。这个片上系统工作的大致流程是：初始化各种板上硬件资源（LED、按键、串口、其他外设），初始化网络状态，根据设备类型进行组网或加入网络，最后正式开始运行这个系统——进入一个死循环不断轮询各种片上资源和设备，一旦其状态有所改变即在事件处理过程中执行相应的事件回调函数。

CC2530开发板基础实验（5）—— JoyStick

CC2530上有一个5向（上\下\左\右\中心）摇杆(Joystick)。而5个方向的输入并不是靠5个独立的IO口，而是用ADC采集P0_6口的电压值来判断的。这样做的好处是可以节省4个IO口。对摇杆的方向采集同样有轮询和中断两种方式，在ZigBee协议栈中使用的是轮询方式。我在试过两种方式后发现采用中断的效果并不好，想必这也是TI在协议栈中使用轮询的原因。这个问题先不展开，先来看看如何采集摇杆的方向。