在苏宁买东西

在亲身经历过之后,才能感受到苏宁的购物体验是有多么的支离破碎。

作为一名普通消费者,贪便宜才是理性的体现,团购就很对胃口,所以就团购了一把。某大件电器,限购 3台。好吧,我下个单要两台。一切都很顺利,除了必须得绑定一下手机!我最讨厌绑定手机了,不过为了便宜,绑了一个。支付的时候选择了在线支付,如果没有什么特别理由或者提醒说这里最好别这么做的话,一般都会是在线支付。

问题开始来了,网银有金额限制。要跟超过70家银行合作快捷支付,可能真的没有那么多精力来为网银交易限额做个提示吧。好吧,我能理解给个提示真的工作量超大,那么先看看有没有什么办法可以改支付方式。没有!-_-! 退而求其次,先取消这个单,然后下个新单改为到门店支付。

然后,下不了单!打电话给客服,答复是,即使取消了订单,资格还是占着的,建议我用其它账号重新下单。这个逻辑本身就很有问题。谁设计的系统,取消了订单还占着资格?不知道是系统的 bug 还是设计的时候就没考虑周全。

苏宁限购的bug

新建一个用户,找了另外一个手机号绑定(连续两次干最讨厌的事,忍耐力是不是很好?),下单,支付方式为门店支付。

===== 华丽的分割线 – 场景瞬间切换至苏宁门店 =====

收银台的工作人员说没找到我的单号!?
苏宁订单错误

再次致电客服,说了一堆类似于我能明白你的意思的话,确认了团购的是不能在门店支付的,最后给出的解决办法是找门店导购员重新下单,改为货到付款。

团购的不能在门店支付?毫无提示。害我白跑一趟了。从这个点上可以隐约感觉到,苏宁其实不是一个整体,里面山头林立。

导购员不知道是没听明白我想要的方案还是怎么回事,一阵忙碌,跑来跑去,说是门店里做不了那个价格,要打报告,让我等。30分钟过去了,导购员回来说方案有了,可以做,就是步骤有点复杂。

先要搞张门店的会员卡,以较高的价格先买一台,然后得到返卷,买第二台的时候用返卷抵扣,最终价钱一样。操作起来也很复杂很费时间,来来回回打单,额外搞张会员卡,付款也要付两次。

中间我故意客气一点,表现得情绪稳定,但无意中导购员一句,“不麻烦,我也有提成的”,很真情流露的一句话,让我深深的感觉到 “服务是苏宁唯一的产品,顾客满意是苏宁服务的终极目标” 全是狗屁。

我相信绝对是有可以让顾客满意的办法,不过前提是得站在顾客的角度去思考。

整个过程有多处细节都可以避免最终的悲剧,包括:在选择网上支付的时候,给出足够清晰的提示网银限额,是否有其它方式来突破这个限额;在选择门店支付的时候,给出足够的提示,团购是不能在门店支付的,或者允许团购在门店支付;允许客户修改订单的支付方式;订单取消之后,对于有限购的项目归还占用的资格;门店线下的下单操作应该兼容线上的操作方式,不用那么迂回曲折的办法来实现和网上价格同步。

线上账户对于用户来说是个重要的入口,那么轻易地建议顾客再开一个账户或者使用他人账户的行为是不可取的。引导顾客使用正常流程,确保正常流程的可用性是评价一个系统成熟度的重要考量。

门店导购员的服务也显得很生硬,让客人等待超过半小时,商品不会推介,一杯水也没有。还有让人好奇的是比较热衷于劝顾客开会员卡,对其他顾客声称能做得比网上更低价。

这个 Frozen 不太冷

Frozen 海报
传说这是一部本来打算在 2000年上演的动画片,回炉了13年之后,再来个破茧而出。还好它选择的是一个很经典的主题,突破束缚,突破自己。经典的主题就该配经典的效果,那些冰雪魔法、那座屹立峰巅的冰晶宫殿,还穿插一些经典的梗,比如那根胡萝卜。

有些人可能期待王子或者哪个卖冰的来英雄救美一下,结果被震住了。男主角都只不过是陪伴一下,不显得那么寂寞空虚冷而已。

因为女王内心的不安,造成全城冰雪覆盖,以为自己迁一下都,躲起来就没事,但只要还要有人牵挂,想落得个耳根清净是不可能的。有些事情是早面对的好,方针一错,会错过好多时间,而且纠正起来特别麻烦,比如需要冰镇一下妹妹。

看到有很多讨论主题曲 《Let It Go》,不过我倒没有太多印象,可能因为整个电影里面都很迪士尼地在很多环节开唱,虽然比直接说对白要带感很多,不过也会冲淡了主题曲的感觉。对比起埃及王子的主题曲,这个就略为逊色。

总体来说,片子还是老少咸宜,值得重播的。

茂名螃(P)蟹(X)事件

please
事件的始末可以参考百科:3·30茂名反芳烃项目游行示威,其实这个更详细,就是需要翻下墙。

表达一下诉求是应该的,但是暴力就不应该了。用政府的话来说就是“群众们太不了解PX项目”,“操之过急的宣传”,事实是这样么?

在被引导的舆论当中,问题都被转移到 PX 是剧毒还是低毒刑事事件,对网络流传的消息进行辟谣上去了,官方的“正言”又开始继续,但是就是不谈论这个事情本身,仿佛是毫无意义的闹剧。

“如果不发生厦门这些事情,茂名PX项目的建设肯定不是现在这种情况。”茂名市环保局法规宣教科科长陈炎辉接受华夏时报记者采访时表示。不知道他是指如果没有厦门PX事件,就不会有茂名这次事件,还是指如果没有厦门PX事件,会导致更严重的冲突?对事件本身的理解的不同是可以得出完全不同的结论的。

如果说这次事件是由于操之过急的宣传引发的,那么怎样的速度才算是合适的呢?特别是其实在2008年8月,茂名已经表示要争取 PX 项目,花了接近 6 年时间终于进入到科普阶段,然后在一场推广会之后,就硬生生出来一个抗议事件?

冰冻三尺非一日之寒。

政府的反应迟缓,面对抗议演变成暴力冲突,然后警察与抗议民众发生“擦碰”(这个词一般是用于汽车事故的吧,反正我是想像不出来到底怎么回事),几天后在茂名新闻网发布了《全体市民书》(现在已经 404,不仅仅是这个,大量的有关消息都被删除了,掩耳盗铃也只能骗骗领导而已,难道他们不知道可以 百度 或者 Google)。

缺乏公信力,即使是再密集再强大的PX宣传攻势,也只是黄婆卖瓜。签订什么承诺书更加是没画蛇添足,是不了解群众心理,管理思维严重落后的表现。群众的眼睛是雪亮的,但是群众的想法却不一定是科学的,理性的。妄想群众能科学地理性地去了解PX和判断项目是否合适,这本身就是不科学的。

昨天 4月 8日微软宣布 13岁 XP 正式退休,而我国可能是 XP 保有量最大的国家。我经常会碰到的事情是电脑是近几年买的,装的 XP,还有更奇葩的会因为各种原因卸载了更为先进的操作系统改装 XP。硬件大家都能很快的跟进换代了,唯独是软件依然停滞不前,电脑用个老系统也许大多数时候也就是个个人问题,但如果整个社会的“软件”也停滞不前,恐怕就影响深远了。

Zeco CX6 投影仪刷固件

我一直以为刷固件离我很远,昨晚 CX6 开机之后就一直停在了开机画面,重启数遍无效,找到客服,说要刷固件,当时哪个场合太囧了!第一次拿到别人家里放,N 双眼睛等着看新玩意,结果告诉我要!刷!固!件!

好吧,那就现场刷一下吧,又遇到一件囧事,CX6 背后的 micro USB 插口深不见底啊,普通 5mm 长的嘴插进去就掉了,好吧,那就用手按着吧,根据说明一步一步,结果还是不停显示出错了,出错了…… 打电话问技术支持,当时是晚上 10:10,得到的消息是插头不够长,建议我削掉一点胶。

明显是又一个很不合理的设计,我找了 N 根 micro USB 的线,全部都是最近一两年的机型配的原装数据线,嘴都是 5mm 的,CX6 的要至少 6mm 长的才行,问题是都知道自己的特殊一点,就配一条 6mm 的嘛。虽然技术支持说可以邮一根过来,但是时间就太长了。

好,扯远了。准备好工具之后,就开始动手削!可能要牺牲一根华为的线了。

削线需要的工具

先把头部的胶削掉 0.5mm ,试了一下,还真不行,再削 0.5mm,都见到里面的“骨头”了,已经不能削更多了。上天保佑终于可以了。

露出 6mm

刷固件就难在,要先拿个牙签桶住 RESET 按钮不妨再开机,如果你习惯用右手的话,最好用左手去桶,不解释了。然后就没有什么难度,打开软件,选择一下固件来源,跟着都自动完成。

左手桶 RESET 键

烧录完成

至于为什么 CX6 会变砖,跟马航事件一样目前没有定论,不过最大的嫌疑是 App 更新造成的。App 自己都提示更新是修复已知问题,架构上是应该不会影响到系统无法启动的,关于这一点,得到的建议是不要点 App 自己的更新,呃…… 有骗小白的嫌疑。

这不说软件在稳定性上完全跟不上了,说说外观设计。同样是插头,HDMI / VGA 的就比较浅,至少外面就能看到,OTG 接口就不能再伸出来一点点么?同样的 TF-CARD 的,卡已经够小了,手指粗的人能塞卡进去,但是如果想取出来,你得有长指甲,注意是要长指甲,刚剪过的会够不着。底部的进风口距离固定点太近,三脚架的快装板多少会遮住一点。我认为,接口少一点其实更加好,可以更加专注提升软件质量,做接口其实还要考虑接口做工的可用性,至少用来急救刷固件的接口要确保场合适应性。

一点都不好笑

广东人说今天3度好冷!
山东人(傲慢地)笑了:我们这零下3度!
北京人也(非常傲慢地)笑了:我们这零下13度!
东北人听到(失去控制的)哈哈大笑:我们这零下30度。
广东人听完冷笑一声:我说的是室内温度…
山东人-_-?,北京人-o-!!,东北人-O-!!!

===== 极尽华丽之分割线 =====

当前就是在颤抖中留下这篇 blog。

思维的陷阱

前阵子遇到个问题,是在 Joomla 里升级组件的时候出现 “Failed to copy file” 的错误。我已经习惯了先 google 解决方案,跟随头几个方案,都说是文件或文件夹权限的问题,我满心欢喜地以为已经接近真相了。

几小时过去,哪几个文件夹,包括父文件夹都已经变成 777 了,还是一样报错。然后,开始想是不是姿势不对,还有几个可疑的地方,包括是不是应该先删除旧的组件,然后新安装;不要用上传 zip 包的方式,而改用直接用服务器上的文件进行安装;改用 ftp 的方式进行安装等等。多得有 git ,每次尝试完一种办法不可行之后,所有文件都可以恢复到初始状态。不过多次尝试未果之后,隐约觉得有点浪费生命了。

几天过去了,中间也重复过之前的尝试,每次都有一点点变化,希望找到突破口,也向身边的同行咨询,尝试过各种跟权限有关的方法,依然是未有进展。

事情开始变得吊诡起来。

又几天过去,浪费生命也得有个谱,思维才开始跳出这是一个权限问题的框框,立刻动手写了个小脚本,放在同一位置,用最简单的 API,对同样的文件进行操作,结果是令人震惊的,毫无权限问题。然后开始跟踪代码,系统比较大,对源码结构不是很熟悉,花了点时间才最终确认,由于一个程序配置的问题,导致文件复制的步骤总是返回失败。触摸真相的感觉依然是让人兴奋的。

回头再想,如果早一点开始翻查源码,会不会就能早点发现事实呢?

但问题是,为什么不早一点。

是因为这个陷阱太完美了么?还是因为自己的思维出现固定模式,感觉到同样的问题一定已经有不少人遇到了,而且很可能都已经解决了,只是还没有搜索到而已。源代码与搜索引擎这两个工具,我潜意识会更多地使用的是搜索引擎而不是源代码。也许是因为搜索引擎很多时候能更快的给出答案,不需要太多的思考,而阅读源代码注定要花比较多时间,要记忆流程思考其中的逻辑。问题不在于工具本身,而在于人在什么位置出发思考问题。

还有另外一个因素是时间,急于解决问题,于是求助于通常能快速解决问题的搜索引擎,越是急,越会优先选择快速方案而不是思考正确的方案。

Google Webmaster 索引历史丢失 (已解决)

刚刚发现一个奇怪的事情,下午的时候,Google Webmaster 里一个站点的索引历史好好的,还给别人看索引趋势,刚才再去观察的时候就全都没了。

被吓得赶紧用 site: 指令搜索一下,还好索引还在。只是历史丢了,也没收到什么警告邮件之类的。难道只是一时的数据丢失?

希望这些数据认得路回家。

===== 华丽的分割线 =====

Update: 睡了一觉之后,重新进入 Webmaster 里查看,站点地图里的编入索引数量和历史已经回来了,但是索引状态那里却依然是一条直直的线。

如下图↯
Google 索引显示为 0

Update: 经过一周之后,终于看见索引历史的曲线了。这个数据的更新周期大约是一周至二周,所以频繁的去观察这个数据是没有多大意义的。只要 sitemap 里索引数量正常就可以了。

有种自愿叫做被逼

昨日(7月14日)早上,因为担心政府出尔反尔,大批民众继续聚集,从东湖广场,“散步”到江门市府门口并停留。

如果说前两天的“散步”是为了表达诉求,那么今天的“散步”又是在表达什么呢?

回到核燃料项目本身,也许真的是很安全,而且经济效益极高,鹤山址山抢到这个项目也许就是中大奖一样的幸运。然而,民众在公示出现之后,反对声音由小变大,一波接一波,各种消息(知识)经由网络的高速传播,终于在公示的最后一天爆发了。(我自己观察是周二周三左右首次见到下周一起散步的微博,所以我感觉是提早爆发了)

据闻,公示最后一天晚上本来准备了个庆祝项目开工的活动。结果被早上的“散步”给枪毙了。

公示期间,我了解到的官方只是出了一个八问的统一答复,而且语气带点轻佻的感觉。也许就是这个八问统一答复进一步激发民情的也说不定。面对这样一个重大项目(鹤山 2012 年 GDP 在 200+亿,这一个项目 370 亿,大家感受一下),在面向大众进行宣传,进行科普说明,与民众沟通反馈等工作上面似乎都不愿意花更多的时间和精力。轻轻的签了约,收了地,带一小部分人去在役设施实地考察,还建了个气象观测塔(网友的说法是未立项先动工)。应该注意到一个细节,已经同意的案例里,其一开始也是不同意的,要经过一系列动作才慢慢接受的。这个几近于本能的反应,也是大家遇到这个话题的时候首先最容易表现出来的反应。在这个反应的基础上,再加上一系列的有扩大恐惧的疑问浮现:3月已经签约,征地不知道什么时候已经完成了,还已经动工了,公示期才10天,想咨询也不知道该往哪里咨询,想表达意见,哪个破热线一天打20次都打不进去,还不需要涉及到什么核燃料安全问题,核泄漏应急预案等技术性问题,在那么短的时间里面,传播得足够快的,只有恐惧,已经抛离理性好几圈了。

7月12日晚,鹤山方面新闻发布会,宣布延长公示10天。第二天早上,江门市长发表电视讲话,表示在没有达成共识之前,绝不立项,绝不建设。从这个讲话人们实在太容易理解出更多的意思了,疑似伏笔。随后 10点,鹤山市府再搞发布会,宣布不予立项申请。回应市民诉求也还真是挺快的。这个消息一出,起到很好的冷却作用。当日下午,网络上面平静了许多。这个时候就有些谣言冒出来了,诸如取消立项是烟幕弹,散步当中有无间道,秋后算账等等。这类谣言还是很好判断的。然而,暗涌开始出现,线索应该就是江门市长那疑似伏笔的讲话。第三天的“散步”在取消项目的消息已经上过头条之后继续进行,原因是担忧政府出尔反尔。

什么时候会出现这样一种情况?两小孩 A,B 一起做约定,然后 A 再三地向 B 确认关于约定的事。假设 A,B 都没有精神问题,那么显然,就是 B 曾经做得不够,导致 A 不放心。

我们知道就算是核电这样的高危项目,管理控制得好也是很安全的,就看谁来操刀了。我要怎样才能知道自己的利益不会遭受损害?我要怎样知道政府已经做好的充分的准备,而且能做的事情都做到最好了?

用邓卫东局长的话说:我们无法去做外围城市的工作。

这已经暴露了政府在处理大项目时的不成熟,而且缺乏思考。难得有一次超大规模的项目,而且是充满各种恐怖词汇的超大项目,难道就只需要做辖区内的工作?就不考虑周边的意见,不需要周边的配合?

我们不会无缘无故的相信一群人,更加不会在亲历了多次让人愤怒或者痛苦的体验之后选择继续相信。给出机会已经是最大的宽容了。当然机会是留给愿意思考的人。

担心,让很多人担心,是令民众上街的理由。有种自愿叫做被逼。

项目被取消,不是因为核燃料加工科学知识不足,而是群众心理学认识的肤浅。

这次的事件,有媒体用民意的胜利来做标题。的确,很吸引眼球,但我觉得那不是事实。事实是并没有赢家。民众不得不出来”散步“,政府不得不响应民意取消项目,这就是胜利了吗?民意要胜利,需要的是一个知识型的政府,它做足了充分的准备动作,能做的都已经做到最好,民众已经普遍理解是怎么一回事,有充分畅通的渠道表示支持或者反对。

jQuery SelectAll Plugin

这是一个处理 全部选中/不选 的插件。

这个插件节省不了你太多代码,但是能帮助你分离处理逻辑。通过在改变选择项时,向 controller 发送一个 “change:select” 事件(还附带 selected 和 total)来实现。这样你就可以灵活地选择在什么地方处理这个事件。

controller 不一定是 jQuery 对象,也可以是 Backbone.Events 的派生对象。

jquery-selectAll.js

Gitlab-shell 1.1.0 的 SSH 访问异常

GitLab 4.2 升级到 5.0,虽然 步骤 有点儿繁琐,但还算是一路绿灯,但最终却遇到了不能以 ssh 方式访问库的问题。搞了几个小时,找了所有能想到的地方,都搞不清楚究竟哪里错了,于是在 github 上给提了个 issue 3578

问题的情况简单来说就是,ssh -T 成功,但是 git clone/pull/push 却意外失败,另外 http 的方式是成功的,说明应该还是连接的问题。

唯一有可能存在疑问的地方,应该是 gitlab-shell 的版本。检查的时候会报告说需要 1.1.0,而事实根据升级指引中的操作结果是 1.2.0 的。但从 另一个 issue 的说明 看来,可以通过修改 check.rake 来实现“瞒天过海”。

暂停了 gitlab service,然后切换 gitlab-shell 的版本到 1.1.0

> cd /home/git/gitlab-shell
> git checkout v1.1.0
> git checkout -b v1.1.0

# 配置文件不需要改
> ./bin/install

重启 gitlab 后再试试 ssh -T git@mygitlab.com

结果却出错了!

/usr/local/lib/ruby/1.9.1/json/common.rb:148:in `parse': 743: unexpected token at '<html> (JSON::ParserError)
<html>
<head>
<title>Welcome to nginx!</title>
</head>
<body bgcolor="white" text="black">
<center><h1>Welcome to nginx!</h1></center>
</body>
</html>
'
     from /usr/local/lib/ruby/1.9.1/json/common.rb:148:in `parse'
     from /home/git/gitlab-shell/lib/gitlab_net.rb:24:in `discover'
     from /home/git/gitlab-shell/lib/gitlab_shell.rb:28:in `exec'
     from /home/git/gitlab-shell/bin/gitlab-shell:16:in `<main>'

为什么会出现这个错误,我没什么头绪,google 了一轮也没什么对症的答案。

要出现默认的 Nginx 页面,应该还是跟 Nginx 的配置有关,而哪个配置文件是从网上下载的,唯一就是指定了 IP 以及域名。就算直接用 IP 访问,也是可以看见 GitLab 的页面的,但是不会看见 Nginx 的默认页面。

这时,我想起之前曾经改过 /etc/hosts

127.0.0.1   mygitlab.com

如果在服务器端访问 http://mygitlab.com 的时候才会看见 Nginx 的默认页面。果断去掉这个 host 设定,然后再试,一切都正常了。

嗯嗯,具体什么原因要加这个 host 设定,不太清楚了,装 4.2 的时候的事情了。反正 gitlab-shell 1.1.0 跟它有冲突。不过应该算是 gitlab-shell 的问题,它不应该解析出域名的 IP 后直接用 IP 去访问,因为有可能一个 IP 上会挂好多个站点,默认的不一定就是 gitlab。

有时候指定 hosts 能解决一些问题,也有像这种帮倒忙的情况,能不加还是不加吧。

PS: mygitlab.com 不是一个真实的域名。

Update 17 Apr: Issue 3384: Gitlab can’t clone or push