体验手机写博客
今天部门开年终大会,目前我正在现场听领导演讲,突然有一个念头:尝试用手机写博。我用的是摩托罗拉A780,支持手写,比较适合写文章。加上上周移动公司发来短信说第一季度每月赠送50Mgprs流量,遂开始了体验。由于手机屏幕毕竟很小,所以操作起来还不十分适应,不过感觉不错哟,以后在旅途中有什么想法可以直接发到博客上来。
体验到此结束:)
一个程序员的心路历程
今天部门开年终大会,目前我正在现场听领导演讲,突然有一个念头:尝试用手机写博。我用的是摩托罗拉A780,支持手写,比较适合写文章。加上上周移动公司发来短信说第一季度每月赠送50Mgprs流量,遂开始了体验。由于手机屏幕毕竟很小,所以操作起来还不十分适应,不过感觉不错哟,以后在旅途中有什么想法可以直接发到博客上来。
体验到此结束:)
昨天凌晨,突然接到云南移动哥们的电话,说他们正在进行的全网割接出现了问题,当时只有我们的产品遇到这样的问题,其他省的其他厂商的产品都已经顺利通过测试了。迷迷糊糊的我无奈的起床,开机,查找问题,这也让我体会到了这几天北方的夜晚的冷啊。
花了一段时间对底层的协议包进行了分析,发现我们产品发出去的消息包的那个域后面的确随机的分布着一些乱码字符。譬如我们的消息发送的目的地址是1069999333(Google的短信搜索),经过分析发现我们产品发出去的包中的这个域是这样的:3130 3639 3939 3933 3333 00f9 42 9678 0000 ….,一共是21个字节。粗略判断是我们协议栈发送功能实现的问题,但是又转念一想,虽说这个数据由瑕疵,但是数据接收方也是应该可以正确处理的啊,他们居然一反常态的校验出来其中的垃圾数据。之所以认为对方可是正常处理是因为对于这样的域,我们一般在业务层都会按字符串进行处理,大家都知道C语言中字符串是以''结尾的字符数组,那么对于上面例子中的那串数据,如果使用C中相应的字符串处理函数的话,是可以得到正确的信息:1069999333的,后面的垃圾数据会被最后一个3后面的''所隔开。
显然对方做了更加严格的校验了。也许当初实现我们的协议接口的同事太'单纯'了,没有想到对方'下手'会这么狠。开个玩笑罢了,其实归根结底还是我们自己实现的不完美导致的。早上上班来到部门,将事情和大家mail沟通了一下,居然另外一个项目组(其产品和我们属一类)发来邮件说这个问题他们早已经发现并修正了,但是忘记通知我们了。真是晕倒啊:),这也说明了及时的沟通与交流多么必要啊!
评论