自定义博客皮肤VIP专享

*博客头图：

点击选择上传的图片

格式为PNG、JPG，宽度*高度大于1920*100像素，不超过2MB，主视觉建议放在右侧，请参照线上博客头图

请上传大于1920*100像素的图片！

博客底图：

点击选择上传的图片

图片格式为PNG、JPG，不超过1MB，可上下左右平铺至整个背景

栏目图：

点击选择上传的图片

图片格式为PNG、JPG，图片宽度*高度为300*38像素，不超过0.5MB

主标题颜色：

RGB颜色，例如：#AFAFAF

Hover：

RGB颜色，例如：#AFAFAF

副标题颜色：

RGB颜色，例如：#AFAFAF

预览取消提交

自定义博客皮肤

-+

上一步保存

kanji的专栏

Bridge SE World

04月

原创在外包开发中奋斗的中国人开发者的视点（オフショア開発で奮闘する中国人開発者の視点）

推荐一篇08年4月开始在日经BP上的新连载，作者是一位在日的中国籍SE。文章流畅易读，正在学日语的朋友不妨作为辅读资料参考一下。当然，更值得推荐的是文章的内容，作者谈了他这5年多来对日本项目，以及日本人SE的观察，在一些常见的，却往往被人忽略的细节上，再现出了一个个生动的“异文化交流”的场景，读来十分亲切有趣。kanji懒得很，N久没更新BLOG，原先计划中的外包统筹人系列，也由于内容的时效性

2008-04-23 13:28:00 1709 1

深入理解linux内核.pdf

【内容简介】本书将引导你畅游Linux内核中使用的最主要的数据结构、算法和编程技巧，讨论了具体的Intel平台的重要特点。但是本书涵盖的内容绝不限于代码所起的作用，它还阐明了Linux为什么如此运作的理论基础。本书涵盖Linux 2.4，集中讨论的内容有网络、内存管理、虚拟文件系统层和第二及第三扩展文件系统、进程创建及调度、信号、中断及对设备驱动程序的主要接口、定时、内核中的同步、进程间通信、程序执行等。本书将使读者熟悉Linux所有的内在工作机制，但本书不仅仅是一种学术训练，读者还将知道什么样的条件使Linux产生最好的性能，以及Linux在各种环境下对进程调度、文件访问及内存管理期间提出的快速响应要求如何得以满足。

2008-10-04

编程高手箴言（梁肇新）

书名：编程高手箴言作者：来源：电子工业出版社 ISBN： 7-5053-9141-0 页数： 416 开本： 16开出版时间： 2003年11月定价： 50元内容简介：本书是作者十余年编程生涯中的技术和经验的总结。内容涵盖了从认识CPU、Windows运行机理、编程语言的运行机理，到代码的规范和风格、分析方法、调试方法和内核优化，内有作者对许多问题的认知过程和透彻的分析，以及优秀和精彩的编程经验。

2008-10-04

RubyCourse_1.0-1.pdf

RUBY的入门教程。虽是英文版，但代码示例简明扼要，易读性较高。

2008-01-13

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

kanji CSDN认证博客专家 CSDN认证企业博客

码龄21年

IP 属地：日本

IP属地以运营商信息为准，境内显示到省（区、市），境外显示到国家（地区）

11: 原创

24万+: 周排名

81万+: 总排名

7万+: 访问

: 等级

1230: 积分

73: 粉丝

4: 获赞

218: 评论

2: 收藏

私信

关注

热门文章

分类专栏

对日外包 3篇
译文 12篇
随笔 2篇

最新评论

在外包开发中奋斗的中国人开发者的视点（オフショア開発で奮闘する中国人開発者の視点）
kanji: 找到一篇对作者的介绍，转一下先…… ブリッジSEの現実：：：引用：：： 1999年，一人の中国人が，上海から日本にやって来た。当時の改革開放政策で中国の若者達は皆，海外に出て世界を見るという夢を抱いていた。彼も，そうした“出国潮”にせきたてられるように，日本に渡った一人だ。　上海では，日系のソフトウエア開発会社に勤めていた。国有企業の就職を断って，日系企業を選んだのは，いずれ日本に行きたいと考えていたからだ。　その日系企業で仕事をしている間に，先輩たちは次々と日本での就職を決め，会社を辞めていく。自分のプロジェクト・リーダーもその1人だった。自分も世界に出たいと彼に相談したところ，東京のある派遣会社の社長を紹介してくれた。上海で面接に合格した後，ついに来日を果たした。　そして彼＝周翼さんは現在，システム設計支援ツール「JUDE/Professional」などで知られるチェンジビジョンで，オフショア先の中国ベンダーとの間に立つ，いわゆるブリッジSEとして働いている。先日，周さんとじっくり話をする機会があった。　彼の基本的な仕事は，日本側の要求（仕様設計，タスクの調整，不具合の修正など）を中国側に伝える。それに対して中国側からあがってきた質問を日本側に回答してもらい，自分の理解で中国側に回答する。もちろん，開発要員の一人として仕様設計や実装，テストにも参加する。　容易に想像できることだが，彼の立場はいろいろと苦労が多い。一番苦労するのは，やはり「日中双方の要求を理解すること」と言う。特に，複数のプロジェクトが並列に進行する場合，すべてのプロジェクトの仕様と状況を知り，それぞれの要求をきちんと処理しなければいけない。　国内の一般的なSEやプロジェクト・マネジャも，顧客と開発者の間，または外部の開発会社と内部チームとの間で，同じ様な悩みがあろう。周さんの場合はさらに，日本と中国のそれぞれの言葉や文化を理解したうえで双方の要求を理解/伝達し，プロジェクトを成功に導かねばならない。　「日本側の仕様設計と開発計画立案に参加して，中国側の開発を指揮し，最後に日本側に正しく実現できた仕様を見せられたときに，とても大きな喜びを感じる」と周さんは言う。「ただの伝達役ではなく，国際的な開発を指揮したという充実感が湧いてくるから」。　ほかにもいろいろとおもしろい体験談を聞くことができた。中国開発者から見た変な日本人リーダー，中国の求人サイトでは，どんな人材募集が人気があるか，中国開発者は，自分をどんな点で評価されていると考えているか，自分が経験した失敗例──など。ぜひそれをITproで連載してほしいとお願いしたところ，快く引き受けていただいた。まもなくITpro Developmentで連載を始める予定だ。興味がある方は，ぜひ読んでほしいと思う。　彼の話の中で興味深かったのは，自分の役割を「日中双方の状況を“見える化”すること」と認識しているという部分だ。　オフショア開発で難しいのは，品質や納期の管理だけでなく，人的要素（中国開発者のやる気や積極性）をどうコントロールするかにある。そこに言葉や文化/慣習の違いによって起因するズレが加わる
连载：Offshore时代的统筹人（6） -- 中国外包开发中生产效率与品质的平衡
bse: 呵呵人很多,去超市排队结账的时候无论怎么认真挑剔自己的队伍总是比旁边的慢也符合莫非定律吧
连载：Offshore时代的统筹人（6） -- 中国外包开发中生产效率与品质的平衡
laiwen: マーフィーの法則：墨菲定律(Murphy’s Law)缘于美国一位名叫墨菲的上尉。他认为他的某位同事是个倒霉蛋，不经意说了句笑话：“如果一件事情有可能被弄糟，让他去做就一定会弄糟。” 这句话迅速流传。经过多年，这一“定律”逐渐进入习语范畴，其内涵被赋予无穷的创意，出现了众多的变体，“如果坏事有可能发生，不管这种可能性多么小，它总会发生，并引起最大可能的损失”、“If anything can go wrong, it will.(会出错的，终将会出错)”、“笑一笑，明天未必比今天好。”“东西越好，越不中用”、“别试图教猪唱歌，这样不但不会有结果，还会惹猪不高兴!” 墨菲定律的原话是这样说的： If there are two or more ways to do something, and one of those ways can result in a catastrophe, then someone will do it.(如果有两种选择，其中一种将导致灾难，则必定有人会作出这种选择。) 根据“墨菲定律”: 一、任何事都没有表面看起来那么简单；二、所有的事都会比你预计的时间长；三、会出错的事总会出错；四，如果你担心某种情况发生，那么它就更有可能发生。我们都有这样的体会，如果在街上准备拦一辆车去赴一个时间紧迫的约会，你会发现街上所有的出租车不是有客就是根本不搭理你，而当你不需要租车的时候，却发现有很多空车在你周围游弋，只待你的一扬手，车随时就停在你的面前。如果一个月前在浴室打碎镜子，尽管仔细检查和冲刷，也不敢光着脚走路，等过了一段时间确定没有危险了，不幸的事还是照样发生，你还是被碎玻璃扎了脚。如果你把一片干面包掉在你的新地毯上，它两面都可能着地。但你把一片一面涂有果酱的面包掉在新地毯上，常常是有果酱的那面朝下。墨菲定律告诉我们，容易犯错误是人类与生俱来的弱点，不论科技多发达，事故都会发生。而且我们解决问题的手段越高明，面临的麻烦就越严重。所以，我们在事前应该是尽可能想得周到、全面一些，如果真的发生不幸或者损失，就笑着应对吧，关键在于总结所犯的错误，而不是企图掩盖它。 2003年美国“哥伦比亚”号航天飞机即将返回地面时，在美国得克萨斯州中部地区上空解体，机上6名美国宇航员以及首位进入太空的以色列宇航员拉蒙全部遇难。“哥伦比亚”号航天飞机失事也印证了墨菲定律。如此复杂的系统是一定要出事的，不是今天，就是明天，合情合理。一次事故之后，人们总是要积极寻找事故原因，以防止下一次事故，这是人的一般理性都能够理解的，否则，或者从此放弃航天事业，或者听任下一次事故再次发生，这都不是一个国家能够接受的结果。人永远也不可能成为上帝，当你妄自尊大时，“墨菲定律”会叫你知道厉害；相反，如果你承认自己的无知，“墨菲定律”会帮助你做得更严密些。这其实是概率在起作用，人算不如天算，如老话说的“上的山多终遇虎”。还有“祸不单行”。如彩票，连着几期没大奖，最后必定滚出一个千万大奖来，灾祸发生的概率虽然也很小，但累积到一定程度，也会从最薄弱环节爆发。所以关键是要平时清扫死角，消除不安全隐患，降低事故概率。怕什么来什么，好的状态是只想技术要领，忘掉自己。
日元汇率下跌与中国工资上涨 -- 苦于效益减少35%的中国企业
kanji: andyyuyue你好再次谢谢你让我分享你的感受。可能是看问题的角度不一样，谈谈kanji的一些想法吧。《关于效率》你提到的日方的工作效率问题，kanji也一直有些想法。面对一些本身并不成熟的日方客户，在与他们的合作中也会听到诸如“中国企业如何如何”的句式。这种情况下，kanji一般作这样的回应。なぜオフショア開発でうまくいかないのかと議論しはじめると、結局「中国的ＸＸ」「日本的XX」というラベルで語られてしまうと、突っ込みが浅いと思わざるをえない。伝統的なウォーターフォール型を前提した議論ならば、ウォーターフォール型の問題か、ロケーションが離れていた場合の問題か、それとも案件に絡んでいる人間のスキルレベルの問題なのかを混じってしまうと、結論的な部分は曖昧に文化的な差異・摩擦の問題へ収斂させてしまう恐れがある。日本国内的开发确实是靠高预算打造的，虽然也跟“日本”两个字有关，但前提和过程都跟kanji所提到的外包不同。究竟是软件开发固有的问题，还是日本人工作习惯的问题，还是所有参与项目中的人员合作上的问题？这些问题往往不是以国籍来区分比较就能找到答案的。 kanji知道，你所提到的问题在大部分日本工作的中国籍技术者都面临过的问题。这样的问题在外包开发的过程中通常也会延续。这种情况下，作为BSE的真正价值，就是确保这样的问题能及早被发现，避免距离和语言的因素导致问题被放大。当然，可能有些彼此“先天不足”的部分是没有有效的对策的，我们的目标就降低到如何让问题的影响停留在最小范围内。这是kanji在这里一直讨论“如何做外包”的初衷。不管怎么说，过多讨论谁是谁非的问题确实让人感到无聊。归根到底，人月神话依旧经典，外包开发更没有银弹。《关于敏捷开发》敏捷开发这样的话题，kanji知之不多。但总觉得口号多于实际。既然被提及，那就谈谈一些不成熟的想法。好比有栋大楼的住户要喝水，更多的情况下，我们只要买来“现成的水管”然后在“规划好的范围内”找水电工“施工”即可。要说敏捷不敏捷的问题，这似乎就是在给富豪盖别墅了。或许他们才会不顾房屋的结构要求“水管别这么直着铺，要绕过我的风水树”。“这个颜色太冲，X月X日之前给我换个颜色” 在数十年的积累过程中，商业应用程序趋于规范和标准，所用到的技术也基本定型。 kanji做了5年左右的外包，略有些心得。或许有朝一日也应该搞出个“敏捷外包”什么的来，呵呵。（玩笑）《关于咨询》确实属于高收入。根据kanji了解的情况，中国籍SE在日本搞SAP的话，30岁左右月薪基本80万日币以上。不好意思，又开始罗嗦了，就写这些吧。祝工作顺利。
日元汇率下跌与中国工资上涨 -- 苦于效益减少35%的中国企业
andyyuyue: 每次讨论类似问题，事后总会感觉意义不是很大，之所以这么说，因为一个企业的成长是众多因素决定的，比较现实的包括怎么留住人，怎样能使自己发展又不被抛离于社会的整个氛围之外，怎么在留人和效益之间平衡，等等，毕竟日本是好几十年的现代化发展了，中国才刚起步，却还得快速的融入世界，这就带来很多问题，能够具有持续力固然是好，但是对于一个快速发展的国家的一个刚起步只有几年的对日外包行业来说，想做好一个企业并不是一件容易的事。目前日本的这种开发方式，也是有利有弊，给我的感觉就是用钱和每个PG加班到11点的时间堆出来的。这种方式对于开发大型项目还是有好处的。关于是技术对于一个大型项目重要还是高超的管理水平对大型项目重要，我也不能量化，也没有具体的数据来支撑，也许管理和技术之间的平衡点能把握住至少就能保证大型的项目的成功了，毕竟多花点钱使项目成功比花了钱干了一个烂尾的活要好得多。但是就很多中小型项目来讲，高超的设计水平和好的开发人员才是使项目投入产出比达到最大化的最佳实践，当然高超的管理在这也不能忽视，总有人跳来跳去的项目肯定没法干。对于日本这种用钱和时间堆出来的成功，我不能苟同，但是目前高水平设计者和程序员很少的情况下也只能如此了吧。很早以前我就说这年头最赚钱的就是做咨询的，由一些在设计和技术领域都算是精英的人组成一个相对稳定的团队，来做上层设计和框架设计，只要这些东西做的好，然后就可以把项目包下去了，自己出几个人做管理，然后找很多楼主所说的合格的PG来开发，真是坐地生财啊。想想敏捷开发为什么在日本火不起来，是因为敏捷开发对技术的要求更高，只有项目组里储备了相当的技术力量，才能敏捷的起来啊。

最新文章

提示

确定要删除当前文章？

取消删除