ROS catkin 和 catkin_make 在 overlay 上的区别

TL;DRW

catkin_make 先造的轮子,catkin 后造的轮子(看得到那个 shell 界面优化得也是出神入化了)。

overlay 是个啥?当你想把多个 workspace 同时使用的时候(通常是有一些底层的库被魔改的情况),就需要一层一层地 overlay,其中最底层是 /opt/ros/kinetic,然后就是一层一层的 workspace 了。

今天下午一不小心拿(MoveIt! 推荐的) catkin 做 underlay 的底层 workspace,后面一层的 catkin_make 就死活识别不到 overlay 了。最终两层 workspace 都用 catkin_make,成功。

查了下 catkin 的 issues,似乎是已经修复了 overlay 异常的问题(刚仔细看了下好像是读 underlay 有问题,还不大一样)?然而我用的 ROS Kinetic 下自带的依然有问题啊。

本科走进最后三个月,后知后觉的一点牢骚

人有一点和其他动物没差:是自私的。诸如我写下一篇东西,看起来是免费“分享经验”、“学习交流”,实际上可能只是我有些话想找人说,却不想打扰别人,最后就把这些想法变成了互联网上的十几个千字节数据,自私的是满足自己的一点表达欲、一点存在感、一种说出来的痛快。

突然发现了这一点,再加上发现大家都很忙,并不是多么关心鸡毛蒜皮的事情,自己也突然变忙了,我就好久没写博客了。然而心里总是有话想说的嘛,所以下面这些东西,我也不知道自己在写啥。 继续阅读“本科走进最后三个月,后知后觉的一点牢骚”

Manual work after WordPress auto update failed

WordPress 版本都到 4.9 了,全球 CMS 占有量也早过三分之一了,自动更新居然还是全量下载,连个增量更新都不做(光做 no-content.zip 有啥用拜托?)。虚拟主机下载 WordPress 的包速度又很慢,结果总是超时(虚拟主机控制的那种超时断开),更新失败。

网上搜了一圈,居然官方建议是“绝对是你的主机有问题,请手动更新”。网差一点还被说是主机不行?那就只能自己来呗。

My WordPress auto update always failed because of slow download speed. Just don't know why WordPress doesn't implement a incremental upgrade mechanism (maybe I should search for a ticket?). Whatever, I have to solve it manually, in a smart way.

P.S. 写完这篇之后,看到更新的 API 了,的确是有增量更新的,但他们不用。They actually have incremental upgrade implemented, but they hardly use it.

继续阅读“Manual work after WordPress auto update failed”

php-fpm + Apache 的长时间 reading headers

最近为了降低下网络运行成本,在 AWS 上用教育折扣开了服务器,搬了些托管业务过去。兼容为本,自然是 LAMP,不过因为这些年 Apache 2.4 的 event MPM 也算能用了(SetHandler + If 块判断文件存在,完美),加上 http2 不支持 Prefork MPM,就开了 PHP-fpm。

都配完了,没事看 PHP-fpm 的状态页面,总是会看到有进程在 reading header 的状态,而且显示持续时间很长。我以为是什么异常情况,PHP 自动停进程失败了,于是就设置了超 1 分钟强退进程,结果 php-fpm 的日志很快就被这些强退错误占满了。 继续阅读“php-fpm + Apache 的长时间 reading headers”

从头开始摘树莓 - Day 2

等待树莓派 IP 的那一刻

昨天配置的 WiFi 热点,按我一直以来的操作,是用电脑开一个热点来凑合。我的电脑是 Windows 8.1,很方便,先打开一个有管理员权限的命令行,然后:

netsh wlan set hostednetwork mode=allow ssid=SSID key=PASSWORD
netsh wlan start hostednetwork
arp -a | findstr -i 192.168. | findstr /V 255

这时候是中午,我接着给树莓派上电,等了好久都没看到 IP,这就很气了。重复了几次,我开始怀疑是系统没正常启动,就查了查网上对树莓派指示灯的介绍。再仔细一看树莓派,居然红的电源灯会闪,这就不大对头了。于是我拿来手机充电器接上 USB 线,没过一会树莓派的 IP 就出现在电脑的 ARP 表里了。

哎,谜团终于揭开,但我已经把卡重做了,也只能硬着头皮从头来过。赶紧先用默认密码(pi:raspberry)连上树莓派的 SSH 再说(我用的是 Bitvise SSH Client,没遇到坑很好用),果然能上,全新的系统哈哈哈。

继续阅读“从头开始摘树莓 - Day 2”

从头开始摘树莓 - Day 1

这是个什么鬼?

还记得许多月前的春天,为了一个项目买了树莓派,折腾 Linux。当时隔壁宿舍的项目也是折腾 Linux 装 ROS,因为校园网下系统太慢,土豪们居然买了手机流量日租包用来没日没夜地下载,每天在机电科协早出晚归的。而我在 headless 的模式下折腾了一两周,也总算是把环境搭起来了。

这几天为了参加比赛,在改代码。改着改着,随手 apt-get upgrade 升级了下系统,结果第二次重启的时候就连不上树莓派了。下午拿到玉神实验室的显示器上看,一切似乎都正常,我正准备看 WiFi 连接情况,突然显示就花了,完全不知道是哪里故障了。

于是,只能从头开始摘树莓了。我先把树莓派上的 Micro SD 卡的内容借着 Paragon extFS 全拷了出来(提示,不要用 ext2fs,我试着在 Windows 8.1 上加载的时候程序永远会崩溃),然后开始重装系统。虽然第二天发现是电源的问题,但因为我备份的时候 Windows 把太长路径的文件丢了一些,拷回去文件权限还不一定对,所以还是只能乖乖重新做一次系统了。

突发奇想,觉得还是记录一下这个操作过程比较好,否则要是后人再重新配置一次,真是太痛苦了。 继续阅读“从头开始摘树莓 - Day 1”

小探网页支付网关的架构设计与体验优化

开题

现在网络支付方式越来越发达,已经不可避免地开始与各类 IT 系统集成。在财务制度比较规范的地方,这类入账自然需要统一管理,资金不能随意流动。如果由各个业务系统自己去申请对接网络支付接口,自然是很难实现统一管理的,而且也麻烦。

因此,就需要一个统一的企业级支付平台作为中间层,来负责各业务系统与网络支付的对接。这样,不仅方便了财务数据的统一提取、账户对账,也使企业支付平台可以代表所有的业务系统与网络支付接口进行交互,业务系统不会接触到企业的网络支付总密钥,较为安全可控。

这样的例子其实我们天天见。例如 12306 的车票支付教育部考试中心的考试费支付,都采用了中间层,来接入多个网络支付平台。

此时,企业级支付平台的角色可以认为是一个代理,协助业务系统完成支付流,并保存相关数据。目前这类“代理”的架构并没有标准,所以实现起来会各有小差别。如何去定义企业级支付平台(下称企业层)和业务系统各自的角色,就会决定架构的实现方式,相应就会影响到支付业务的实现情况。 继续阅读“小探网页支付网关的架构设计与体验优化”

Make Service Fault Transparent

This article is an English one, because I really need to work on the language. Sorry if it is not easy to understand.

A Summary to What's Happening Recently

Recently in my campus, IT service is very unstable.

  • In March, many people posted on forums that they tried to top up campus Internet account by WeChat, but more money (maybe 100x) than they paid were topped up.
    • Later WeChat top-up service were disabled. Because most people were not aware of the existing offline top-up-by-card service, many of them became arrearage.
    • Several days later, campus Internet's charging system was disabled, which means you can use it for free. Later the charging system was resumed, but only charging at the monthly fee (not counting flux fee).
    • An unnoticeable statement was published then, indicating that it was caused by a bug from the software company.
  • On March 20th, campus card users who used their cards to drink hot water or eat breakfast, found their card locked. (Those lazy guys were not affected at all)
    • In the morning nobody knows whether the issue was being solved, until at around 11 (lunchtime) my school's instructor sent an announcement that "there will be unlock service in canteens, please keep order and don't panic at the scene". At canteens announcements by canteens' administrator is put up. Unlocking was quick and easy, but most people still went to canteens where Alipay is accepted.
    • Later that afternoon public statement by card administrator was out: It was a service fault (on BITUnion some said that it's a bug hidden for 14 years). IT staffs explained on BITUnion that they tried to work out solutions and mitigate the issue before they drafted public statements.
  • In these months campus Internet is unstable: During peak hours it became very slow or even unavailable. Maybe it's around 2%'s downtime (in a 24-hour aspect), looking not that much, but users surely could experience that.
    • The causes seem very complex. In my view, new DNS servers, old cache servers, new firewall systems, new upstream link providers and upstream link issue all can cause problems. And of course those new facilities all need to be fine-tuned, which takes time.
    • Currently no authentic statement is published. But in the IT service monthly report (which most people are not aware of), it said "Issue fully fixed, during peak hours upstream links can work in full bandwidth now". One of the reasons they mentioned was "DDoS attack causing network core server CPU instant usage up to 99% (usually ~20%)".
    • However, as student representatives meeting will be held, many representatives will raise the heated Internet issue onto the meeting. But I believe most of they will never get the point why this is happening.

继续阅读“Make Service Fault Transparent”