豆知识:Toxic Leader

最近thedailywtf频繁发文婊那些不懂装懂的经典例子——虽然之前他们也发过不少——但最近两周的文章内似乎除了CodeSOD和Error’d外就是婊傲慢自大。婊过了同僚终端用户甲方之后,自然要轮到Boss或leader咯:The Tye That Binds。事实上之前那篇也是,但文笔、长度和欢乐程度都没昨天这篇好。

如果你打开链接后就想回复”TL;DR”或者“20字谢谢”的话,那么这里我缩写一下:

主人公Aargle负责某系统的开发。他的经理Tye说系统太慢了,让他处理一下——让他照着自己心目中的方案处理一下——将整个服务器备份后格式化硬盘再恢复,就像对付普通PC那样进行磁盘整理和重装系统。Aargle数次解释这样做不对,应该从程序入手而无果之后被告知“要么照我说的干,要么我找其他人来”。

无奈中他只好查找手册开始备份恢复工作,却看到手册上提到磁盘占用率到90%前系统会确保文件扇区内容连续,不需要手动介入进行调整。在确认当前服务器磁盘占用远小于阈值的情况下,他激动万分地给Tye看手册内容,然后被吼回来“你是要用这个违逆我吗?”。

作为有气节的程序员,Aargle到底还是没有按照Tye说的去做,但她监督Aargle的直接领导者Mack完全按照自己想法开始“提升服务器性能”。与此同时Aargle从SVN签出了代码查看到底哪里出了性能问题,发现有个叫做C.Pirouline写了烂到爆的排序程序。Tye(自豪地)说这位C.Pirouline是公司内的系统分析专家,时薪80刀,专门被请过来“仅仅用了一个月时间就搞定了这个整个系统需要依赖的部分”。但Aargle确定这堆烂代码远花不了一个月时间。

这个故事里面的Tye就是典型的Toxic leader:傲慢、刚愎自用且滥用职权。通常来讲这类人还会在因为自己的原因出现问题后将责任推卸到下属那里,就算是下属一直在帮他/她尽力避免和弥补错误也是一样。就像故事中的Aargle,恐怕之后因为服务器在备份/恢复后出现问题而塞到手里一口大黑锅。但现在还不知道,因为这篇文章可以说是难得在thedailywtf上一见的连载文,毕竟那是the DAILY wtf不是吗。顺带一提,已经有来自未来的高端用户帮我们发掘出了part 2的页面(目前还是空空如也)真正的part 2页面。,留言中网友Lorne Kates毫不留情地吐槽“I guess I know who got WTF’d today. :| ”。

虽然可能程度上不同,但社会人或多或少都会碰到一些这类头头。我也不例外,但幸运的是是以第三视角看到的其他人的上司:对于别人的成果占有脸不红心不跳,无时无刻不在展现自己的权威带着大家把船往冰山上撞。下属们似乎已经习惯了这种形式,甚至已经形成了一套应对方法,让上司开心但又不影响工作效率,如果能亲眼看到的话,恐怕你也会对人类的适应能力感到佩服,同时觉得The theory of evolution翻译成“进化论”不是“天演论”还挺合适。

有关这个话题,或者想进一步了解有关Toxic leader,那么可参考的著作包括这本The Allure of Toxic Leaders: Why We Follow Destructive Bosses and Corrupt Politicians–and How We Can Survive Them,这里是它的摘要和介绍。值得一看的还有amazon上关于这本书的差评一则。很多人羡慕老外能在购书网站上发表长篇大论,将自己的读后感和看法供大家分享,以便后来人更好地选择读物。但考虑到我们有豆瓣,而且由于它的存在几乎导致各大网上书店的评论区已经变得没什么作用,多花一点时间移步豆瓣查看信息也不是坏事——当然,对于很多人来说选择书籍时候豆瓣才是起点。另外注意水军出没,上次刚有一例被广大人民群众给予了无情打击

了解了一下“村上町屋再生计划”

看《全能住宅改造王》(大改造!!劇的ビフォーアフター)发现了一个有趣的东西:日本新泻县村上市的“村上町屋再生计划”(むらかみ町屋再生プロジェクト)。从名字可以读出来,“町屋”(まちや)应该是是村上市的传统建筑风格,借用维基百科的图片,就是下面这样的住居/商家:

町屋顾名思义,是町人的居所。作为江户幕府时期地位非常低的“町人”——也就是工商业者——他们凭借自己的技术争取到了生存的机会,并且创造出了自己的阶级文化。町屋就是其中代表性的产出。

作为曾经的村上藩内历史悠久的“下町”存在的村上市,便是町屋风格建筑盛行的代表地点之一。村上市自称“没有受到现代化波及”幸而保存了不少传统风格建筑。但随着旅游业的兴盛,很多商家开始改建为现代风格的外观,导致城市的历史逐渐流失,市中心的商店街区域尤为严重。所以村上市的市民自发组织了这个恢复原先町屋风格的活动。从他们的主页来看,这个活动从平成16年(2004年)开始,计划用十年时间募集1亿日元(每年1000万),逐年改造失去町屋风格的传统建筑,让他们恢复本色。

改造的内容包括恢复作为町屋风格核心的笼子式外观、暖帘、涂黑的外壁、木制凸窗等等。对于希望改造的商家,这个计划募集的市民基金会给予60%(最高80万)的补助。计划的主页上列出了例如「山上染物店」等成功范例,迄今为止,这样的店家已经有20家。前面提到过,这个计划的市民基金是募集而来的,有兴趣的人都可以出钱参与,每年3000到10000日元不等,就可以成为不同身份的会员。当然,光挂名是不太能吸引人加入计划的,所以作为会员投入了资金之后,可以享受各种服务,例如每年到村上市享受加盟店的休假服务或者9折购物券等等。

这种恢复古代建筑风格面貌,甚至整个行政区划内进行复古改造的行为在国内也有。比如北京前门大街从04年到08年间的改造,将很多老字号招了回去,从珠市口到大栅栏,建筑风格总体来说恢复得挺好,但功能上成功变成了除了南锣鼓巷之外最适合坑老外的旅游地点。可以说,在这类行动上,还是民间组织的行动力更高,效果更好。

一直以来,我都对这类市民自发组织的活动之发起、运作和宣传很感兴趣。当然,社会环境和相关法律法规的支持是关键——需要对于非盈利性机构友好的环境。其次,对于这类项目的精力投入,恐怕也不会产生什么经济效益,所以出现愿意为大家服务的活动组织者也是关键。最后,计划内行动和经济活动的监督、审核也是要事。日本在非政府组织的管理方面很值得学习。不仅是这种市民自发组织的活动不会受到阻碍,涉及商业行为的组织也有很多是NGO和NPO。例如进行电影审查的映伦、爱情动作片审查的映像伦以及电子游戏审查的CERO等,都是为了产业内为了更容易解决法律问题组成的法人机构。当然,至于CERO什么的是否是警视厅退休官员们的再就业幌子,展开说来就复杂了;而映伦、映像伦等等之间那些贵圈真乱的关系也是如此。

P.S:《大改造》也很喜欢搞町屋的改造,例如放送初期由西方建筑师进行改造的京都の町家2軒同時リフォームSP、耗费4000多万改造的番屋、最近的130年町家改造和这期等等。

三全食品新logo的既视感

优酷广告上看到了三全的饺子,和它的新logo:

图片来源

等等,这强烈的既视感是怎么回事?

P.S:其实这两个logo的相似度还一般般。老早前还发现过Slipgate Ironworks(嗯,就是John Romero创办,09年倒闭的那个)Logo主体和三联书店的几乎完全一致。

日文编码下反斜线是¥的一些考据

为什么?这个问题困扰很久,虽早就发现——以前玩日语游戏时候看到的——但一直不得其解。包括各种日语输入法,按反斜线键出来的是日元符号(yen sign)而不是反斜线。

那么查看一下Backslash的维基百科页面

In the Japanese encodings ISO 646 (a 7-bit code based on ASCII), JIS X 0201 (an 8-bit code), and Shift JIS (a multi-byte encoding which is 8-bit for ASCII), the code point 0x5C that would be used for backslash in ASCII is instead rendered as a yen mark (¥)…

困惑一下就解决了!简言之就是不同字符集下面的冲突,根据Windows Codepage: 932 (Japanese Shift-JIS)上的记录,很清楚可以看到在Shift JIS下0x005c被¥占据。因为当年的字符集位置比较紧张,或许是迫于无奈,日韩两国的默认编码系统不得不这样做。在Unicode中,0x5c还是U+005c,而日元符号¥则是U+00a5,平时我们用中文输入法打出来的¥则是U+FFE5。根据上面Backslash的维基页面所说,还能知道:

  • 虽然这是个问题,但由于历史悠久而影响过于广泛,目前来看改回来不太可能。甚至Windows的明朝体等日文系统默认字体会在Unicode下把U+005c也渲染成日元符号,以保持和之前一致。
  • 韩语系统下,则有类似的问题,反斜线被韩元符号₩代替。
    Windows Codepage: 949 (Korean)

反斜线一直被用于表示本地目录路径的分隔符,所以之前在看日本人写的开源项目时候也注意到这奇怪的不同点,同时也知道自己当时玩游戏时候看到的¥并非乱码。那么难道日韩两国人的广大人民群众们用着和其他国家人用不同的分隔符而不觉得别扭吗?根据
When is a backslash not a backslash?一文的考据,这两国的一般人不太关心这个,而IT行业的人虽然觉得别扭,但“怎么改呢。毕竟已经用了这么久,习惯了。”

实际上,这还不仅是使用习惯和视觉上适应与否的问题,试想一下如果在日韩编码的系统中如果确实要显示货币符号,而文件系统认为是反斜线又如何,比如AIX shows the Japanese Yen symbol as a backslash;而反过来说,希望显示反斜线而被渲染成了货币符号的问题也是存在的。解决办法只能是手动判断当前的字符编码类型,如果是Shift JIS或者其他什么会引起混淆的类型的话,再进行手动转换。而那个反斜线被错误渲染的问题,是Firefox当年(2004年)1.0版本RC前发现在utf-8编码网页中的,comment中有日本人现身说法(8楼),提到就算是日本人也对具体怎么处理存在分歧:

  • 永远不替换0x5c到U+a5
  • 在编码为Shift_JIS、EUC-JP和IS0-2022-JP情况下进行替换
  • 用户决定是否替换

最终的解决方案不在这三种内,而是限定了语言、替换选项和字符集非unicode时才进行替换(减少false positive)。在もじら組上,甚至有更早的Firefox相关问题报告,bug生存期超过7个月,讨论数100+。可以看到Firefox内处理这个问题的代码类似于:

818   if (mLanguageSpecificTransformType ==
819       eLanguageSpecificTransformType_Japanese) {
820     for (PRInt32 i = 0; i < aLen; i++) {
821       if (aText[i] == 0x5C) { // BACKSLASH
822         aText[i] = 0xA5; // YEN SIGN

正是由于有这样的转换存在,我们所使用的编程平台,在进行国际化编程时都会存在特定语言的Unicode勘误(collation)功能。所以对于现在的程序员而言这已并非什么大问题。当然,平时写代码时,也会时刻注意不自己硬编码,而使用系统决定字符:例如.net上是Path.PathSeparator或者用Path.Combine合并路径;Python中则用os.sep,等等。

对软件进行国际化和本地化是很多程序员经常忽视,却又是非常重要的一环。有空的话会把之前工作中见到的和亲身处理过的相关问题列一些出来,现在看看非常有趣但当时处理的时候棘手得很。

siwei.org指向了”siwei”个人站点目录

大约半年前收到一位陌生blogger的来信,说他发现基本所有siwei的域名都被注册光了,只好用http://siwei.info。信里还cc了另外一位拥有siwei.me站点的blogger。所以我就想到做一个个人站点目录,里面都是叫做siwei的blog或者个人主页。

页面其实早就做完了,但一直忘了改域名——当时siwei.org的控制面板因为没有认证信息所以进不去——后来也就彻底想不起来了。这两天突然想到,赶紧改了一下。现在可以直接访问http://www.siwei.org/看到这个页面。