Sleven's Tech Thing

Ibatis中，可以用selectKey

1. <insert id="insert" parameterMap="pm_user_without_id">    
2.         <![CDATA[   
3.             INSERT INTO t_user    
4.                 (username,password,emplName,visible)    
5.             VALUES (?,?,?,?)   
6.         ]]>    
7.         <selectKey resultClass="int">    
8.             <![CDATA[   
9.                 SELECT SCOPE_IDENTITY()  AS ID   
10.             ]]>    
11.         </selectKey>    
12.    </insert>  

针对不同数据库的写法如下： 

Cloudscape  VALUES IDENTITY_VAL_LOCAL() 
DB2         VALUES IDENTITY_VAL_LOCAL() 
Derby       VALUES IDENTITY_VAL_LOCAL() 
HSQLDB      CALL IDENTITY() 
MySql       SELECT LAST_INSERT_ID() 
SqlServer   SELECT SCOPE_IDENTITY() 
SYBASE      SELECT @@IDENTITY 
ORACLE      SELECT CUSTOM_SQL.NEXTVAL AS ID FROM DUAL 

 

英文原文： http://www.readwriteweb.com/archives/top_10_software_engineer_traits.php

中文翻译：http://www.jobbole.com/entry.php/344

如今，每家公司都似乎成了科技公司。从软件创业公司到投机性投资公司、制药巨头和媒体巨头，它们都越来越多地加入到软件业务行列。

　　代码质量不仅成为了一个必需品，更成为了一个竞争优势。因为众多公司围绕软件而竞争，开发软件的人——软件工程师正显得越发重要。但是，你该如何发现那种百里挑一的程序员呢？在本文中，我们简明扼要地列出了明星开发人员的10种特质。

• 1. 热爱编程
• 2. 完成事情
• 3. 持续重构代码
• 4. 使用设计模式
• 5. 编写测试
• 6. 善用现有代码
• 7. 专注可用性
• 8. 编写可维护的代码
• 9. 能用任何语言编程
• 10. 知晓基本的计算机科学

　　1. 热爱编程

　　编程是一种为了满足兴趣而心甘情愿去做的劳动（Programming is a labor of love）。和其他任何职业一样，唯有真正的热情，才能完成真正的伟大事情。这里有个误解，认为编写代码是机械化并纯科学性的。事实上，最优秀的软件工程师是工匠，他们能把能量、独创性和创造力融入到每一行代码中。伟大的工程师知道何时该把代码雕琢至完美，知道何时把大型系统像拼图一样组装到一块。热爱编程的工程师从构建软件中获得满足，就好比一位作曲家在完成一部交响乐后而欣喜若狂。正是兴奋感和成就感，才造就了喜爱编程的明星工程师。


　　2. 完成事情

　　有很多技术人员只谈论软件而不编写代码（只说不做型）。而伟大软件工程师会真正去编码，这也是他们最为重要的品质之一。他们是实际做事的人。聪明人都知道，解决问题的最佳途径是直面问题，而不是花上数周来设计复杂又不必要的架构和函数库。优秀工程师应当会问：解决手头问题的最简单方法是什么？最近的软件开发方法——敏捷实践，正是专注那个。它的思想是，把复杂的项目拆分为短小的迭代，每个迭代只关注一小部分的增量功能。因为每个迭代对应的编码只需要数周，所以功能易于管理并简单。


　　3. 持续重构代码

　　编码很像雕刻。要像艺术家一样不断完善自己的作品，软件工程师也要通过可能的最佳方式来持续完善自己的代码，以达到目标。重新塑造代码的原则称为“重构”，Martin Fowler在他的创意书中有相应描述。重构背后的原始思想是：改善代码而不改变其功能，移动调整部分代码以确保系统不腐，还有确保系统完成基于当前需求该完成的事。持续重构可以让开发人员解决另一个著名的问题——“黑盒遗留代码”（这个问题基本无人想触及）。

　　几十年的软件开发文化要求我们，不应该去改变正常工作的东西。然而，随着时间推移，问题是我们成为了老旧代码的奴隶，老旧代码变得不稳定和不兼容。而重构正好可以改变这一状况，因为我们是代码的主人，不是它的奴隶。重构在工程师和代码之间建立起持续的“对话”，并带来所有权、确定性、自信心和系统的稳定性。

　　千万不要成为老旧代码的奴隶。如果代码是他人所写，或许你可以轻易推脱责任。但大多数时候，那些代码是自己所写，要拿得起放得下，旧代码该埋时，就把它埋了！


　　4. 使用设计模式

　　自从所谓的“四人帮”（Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides）发表他们的著作——《设计模式》后，全世界的软件工程师一直都在讨论模式。在我们所处世界，不管是自然界还是人类行为，模式无处不在。软件工程自然也不例外。模式就是不断重现的跨语言跨系统的场景和机制。一位优秀的工程师通常能识别并利用模式，而不是受制于模式。工程师不应（强制）让系统去适应某种模式，而需发现在系统中使用模式的时机（恰当使用模式）。在使用模式来确保正确性时，应借鉴利用前人的智慧结晶，使用以前能正当解决特定工程问题的方法。但请切记：模式不是万灵药；不要为了使用设计模式而使用设计模式。


　　5. 编写测试

　　曾有段时间，软件工程师们认为测试不值得他们去做。然而，如果你不做测试，你怎么能确保代码就能正常工作呢？敏捷实践中的“单元测试”已获得普遍认可，因为它注重编写测试来反映代码是否有效。随着系统增大，测试也随之增大。有经验的工程师知道并了解测试的价值所在，因为测试的目的就是创建一个能正常运作的系统。优秀的工程师通常会确保出现过一次的Bug不会再出现第二次。但优秀的工程师也知道，不应该浪费时间写那些琐碎或多余的测试，而需要专注测试各个组件中的核心部分。


　　6. 善用现有代码 

　　“重新发明轮子”一直是软件行业中的巨大问题之一。从发明新语言到从写函数库，忽视并重写那些已经存在并已能工作的奇怪驱动力，已经造成大量软件开发的失败案例。一位明星工程师会专注三种基本类型的重用：第一，内部基础架构的重用，相应代码是他自己或同事编写的；第二，使用第三方的函数库，比如JDK。最后，研究使用某些大型网络服务商提供的相应服务，比如Amazon。总之，正确善用现有的代码，使得软件工程师能真正专注于最为重要的事情上——应用程序本身。


　　7. 专注可用性 

　　优秀的工程师通常都专注于用户。无论用户是企业还是个人，无论是为消费型的软件公司还是投资银行，需要关注的都是可用性。用户如何和系统交互？系统是否提供一种简单、直接和平稳的操作体验？有种说法，因为软件工程师是技术人员，他/她和“用户如何与系统交互”没有关联，这种说法严重错误。优秀工程师努力工作是为了什么？不正是让系统简单并易于使用。他们无时无刻都会想到用户，不会尝试去发明那些令人费解，只有极客才能理解并欣赏的东西。

　　有些时候，一些软件工程师过于投入，反而忘记所编写的程序/软件，是供他人使用，不是做给自己看的“艺术品”。所以，在软件开发过程中，一直要把“用户”放在心中。


　　8. 编写可维护的代码

　　软件开发界的另外一个小秘密是：编写优秀代码和糟糕代码所花费的时间是一样多。一位训练有素的工程师，他/她会从第一行代码开始就考虑可维护性和代码的演化。没有任何理由编写“丑陋”的代码、长达数页的函数，或是稀奇古怪的变量名。优秀的工程师编写代码会遵循命名惯例，代码编写紧凑、简单和不过度炫耀聪明。代码的每一行，都应恰如其分地展现出其原有目的。在给不便理解的代码（块）合理注释时，别忘了命名规则。清晰明了的函数名和变量名可以让代码不言而明。

　　在编码时，有些程序员会有这种心态：过一会儿再来修改或完善某部分代码或某条语句。但谁知这一“过一会”竟然是“一天”、“一周”、“一个月”或“一年”，甚至以后根本就没机会再回头修改。所以，尽量别妥协写出暂时堪用的代码。否则，不仅不会节省开发时间，也可以阻碍整个进程。当然也不利于后续维护人员的工作。


　　9. 能用任何语言编程

　　优秀的软件工程师活血有自己一门特别钟爱的编程语言，但从不会执迷于当中。如今已有很多优秀的编程语言，也就是说，如果你只会使用其中一门语言，说明你缺乏多样性。你可以用Java、C#或C++编写任何现代软件，可以用PHP、Perl或Ruby编写任何网站的后台。简而言之，编程所用语言，远远没有语言相应的函数库重要。优秀的工程师能够认知到这一点，并愿意去学习新语言、新函数库和构建系统的新方法。


　　10. 知晓基本的计算机科学知识

　　最后，但肯定不是优秀工程师最不重要的特质就是：扎实的基础。优秀的工程师或许并没有计算机科学的学位，但他/她必须知道基础——数据结构和算法。如果不知道哈希表，或者不知道链表和数组之间的差别，你如何构建一款大型的软件？。这些都是每位从事软件开发的开发人员应当知道的。算法也同样重要，从二分查找到各种排序，到图形遍历，一位明星工程师必须知道并内在消化这些基础东西。因为这些基础就是你在构建任何现代软件中做抉择时的必备品。


　　结束语

　　以上就是区分伟大软件工程师的诸多特质。其中讨论的“热情”，是非常重要的。代码重用、设计模式、基础数据结构和算法都是必须知道的，而敏捷实践中的重构和单元测试则有助于工程师应对复杂的软件。尤为重要的是，明星工程师相信简洁和常识。也正是这些信念，帮助他们成功构建当今世界所需的看似不可能又错综复杂的系统。

 

DB2删除大数据量表格时，会发生log溢出的问题。解决方案之一是关闭log后作删除操作：

在Command下可以执行以下操作：

1   UPDATE COMMAND OPTIONS USING C OFF            //turn off the auto-commit in the command editor

需要注意，2、3句要在同一个transaction中，1和5就是关闭了auto-commit。

      

参考：DB2如何将数据库表解锁

几个基本命令：

list applications: 列出所有DB链接进程(application)

force application (n): 关闭application（进程号）

force application all: 关闭所有进程

DB2重启命令： 1. terminate ->2. db2stop force ->3.db2start

如果DB2在Window上，则可以使用“控制中心”->实例->右键“应用程序”，可以看到当前的锁定情况，并且可以强行关闭某个进程，也可以显示“锁定链”。

 

简单的例子就是头目效果，也就是filter="alpha(opacity=x)".

其他滤镜可以参考这里。

更多关于alpha滤镜，IE支持alpha滤镜，要实现在FF下的alpha滤镜，可以写成：

STYLE="filter:alpha(opacity=50);-moz-opacity:0.5;opacity: 0.5;"

参考这里，还有这里，更多方案参考这里。当然还有讨论IE8中滤镜的。还有比较IE和FF的。

 

这个是我在Firefox（3.0）看Feed的时候发现的：FF能够讲RFC3339的时间自动转化为本地时间。

时区是从操作系统里取得的（至少windows下是如此），自己可以测试一下：修改系统时区，然后重启FF。

看到这篇写得很有条理。转载于这里。

在Java语言中，您可以通过java.util.Calendar类取得一个本地时间或者指定时区的时间实例，如下：
取得本地时间：

java.util.Calendar cal = java.util.Calendar.getInstance();

取得指定时区的时间：

java.util.TimeZone zone = java.util.TimeZone.getTimeZone("GMT-8:00"); java.util.Calendar cal = java.util.Calendar.getInstance(zone);

或者：

java.util.Calendar cal = java.util.Calendar.getInstance(java.util.Locale.CHINA);

甚至您可以取得GMT 0的本地时间，但是又如何取得标准（相对于Java而言）的时间呢？

由我上一篇的有关时间与区域的文章可以得到如下的方法：
1、取得本地时间：

java.util.Calendar cal = java.util.Calendar.getInstance();

2、取得时间偏移量：

int zoneOffset = cal.get(java.util.Calendar.ZONE_OFFSET);

3、取得夏令时差：

int dstOffset = cal.get(java.util.Calendar.DST_OFFSET);

4、从本地时间里扣除这些差量，即可以取得UTC时间：

cal.add(java.util.Calendar.MILLISECOND, -(zoneOffset + dstOffset));

之后，您再通过调用cal.get(int x)或cal.getTimeInMillis()方法所取得的时间即是UTC标准时间。

————————————————————————————————————————————

还有一种方法，似乎更为简练：

 

java.util.Calendar cal = java.util.Calendar.getInstance();

cal.setTimeInMillis(d.getTime()- java.util.TimeZone.getDefault().getRawOffset());

————————————————————————————————————————————

SimpleDateFormat parse出来的Date是本地时间，例如所在地是中国(东8区，GSC）。如果parse的时间为：

"2009-10-18T12:00:00+06:00"（东6区的时间），则时间结果为：

2009-10-18 14:00:00 GSC，其余UTC时间6：00其实为同一时刻。通过java.util.TimeZone.setDefault()可以设置系统时区，但因为似乎全局性的，所以需要慎重使用。

以上两个方法，其实是改变了时间，在时区未发生变化的情况下。

 

看到这篇写得很有条理。转载于这里。

在Java语言中，您可以通过java.util.Calendar类取得一个本地时间或者指定时区的时间实例，如下：
取得本地时间：

java.util.Calendar cal = java.util.Calendar.getInstance();

取得指定时区的时间：

java.util.TimeZone zone = java.util.TimeZone.getTimeZone("GMT-8:00"); java.util.Calendar cal = java.util.Calendar.getInstance(zone);

或者：

java.util.Calendar cal = java.util.Calendar.getInstance(java.util.Locale.CHINA);

甚至您可以取得GMT 0的本地时间，但是又如何取得标准（相对于Java而言）的时间呢？

由我上一篇的有关时间与区域的文章可以得到如下的方法：
1、取得本地时间：

java.util.Calendar cal = java.util.Calendar.getInstance();

2、取得时间偏移量：

int zoneOffset = cal.get(java.util.Calendar.ZONE_OFFSET);

3、取得夏令时差：

int dstOffset = cal.get(java.util.Calendar.DST_OFFSET);

4、从本地时间里扣除这些差量，即可以取得UTC时间：

cal.add(java.util.Calendar.MILLISECOND, -(zoneOffset + dstOffset));

之后，您再通过调用cal.get(int x)或cal.getTimeInMillis()方法所取得的时间即是UTC标准时间。

[本日志已设置加密]

循环检测是目的，需要定期检测某个全局的值（hash值），以根据状态变化做出反应。

I.

基本的思路是用setTimeout实现类似于Java中的Thread.sleep功能，但也有少许差异，先来看setTimeout的用法：

• setTimeout的原型是这样的：

iTimerID = window.setTimeout(vCode, iMilliSeconds [, sLanguage])

• setTimeout有两种调用形式

setTimeout(code,interval)  //其中code是一个字符串，为表达式，如“foo()"

setTimeout(func,interval,args) //func是一个函数, 指定具体函数，如foo

*不能写成foo(args)这种形式！

II.

轮回查询的方式是用递归的方法

唯一需要concern的问题是，当再次进入circle之后，this对象会变为window（因为线程是附属在这个类上），需要有某种机制记录包含function的类。

提供一种最基本的解决思路，可以将this放在eventList里面:

[1]Sleep in JavaScript

[2]Javascript中暂停功能(sleep)的实现

[3]setTimeout()在js类中的使用方法

[4]在Javascript中用command模式模拟多线程

先贴几个link，之后再写。

Javascript跨域和Ajax跨域解决方案

AJAX 跨域访问 — 方法大全

当执行transaction的时候，数据库都会对表或者行进行加锁，commit之后解锁。

在做一个项目的时候，发现不能update某张表，被锁住了。应该是程序的某处执行了死锁。后发现原来是程序没有考虑数据库初始化的异常状态。

查询锁的系统表是syscs_diag.lock_table，事物的进程是syscs_diag.transaction_table。当然这个是不能修改的，但是能让用户查询锁的状态。如果要手动解开锁，只有重启derby。

但我解锁之后，表内并没有锁。而update这张表却被锁住了，怀疑可能是因为之前有请求排在队列之中，并未完全清除。所以就删除表并且重建。(最后证明，锁住的原因是因为java程序并没有真正停止，只是停止了web application，但是jvm中的进程还在执行)好在这张表里只有一行记录状态，如果是记录数据的，那么就会很麻烦了。

所以要尽量在程序中避免死锁！

——————————————————————————————————————————————

锁表的命令是：

1. LOCK TABLE table_name IN {SHARE|EXCLUSIVE} MODE

share mode: 用于读表(read)

exclusive mode： 用于更新(update)

2.只要上锁了，之后的事物（transaction）只能申请表以上的锁，而不是行锁（After a table is locked in either mode, a transaction does not acquire any subsequent row-level locks on a table.）

3. 如果锁的级别超过行（row)锁的级别，则自动升级（escalation）表锁。参见这里。

[1] Java Client 关于锁的文档。

[2] derby 的其他一些命令演示。

[3] derby 官方手册。

2G内存的笔记本电脑终于有些快扛不住了，特别是在build整个项目的时候。

开机后内存大概已经有1G已经用完了，以下是工作状态下应用的内存消耗：

Notes: 160M

RAD(Rational Application Developer): 270M

WAS(WebSphere Application Server): 580M

FlexBuilder: 200M

SameTime: 140M

Chrome: 260M

MSN: 90M

金山词霸： 110M

Google Desktop: 90M

这9个应用就消耗了1.9G的内存，够可怕的了吧。准备去买根心的内存条咯。

http://www.earthcam.com/uk/england/london/?cam=leicester_wmv

http://www.opentopia.com/hiddencam.php?seewhat=newest&country=Germany&showmode=standard&screen=1

这样2个网站，很有意思。其实大概早在4、5年前，王建硕就做过类似的事情，我也设想过建设类似的网站。

好玩是好玩，但是成本太高，商业模式也无法确立。

但无论如何，现在已经 有这样的网站出来了。

忙碌得发慌

突然很想念twitter、饭否、叽歪……

http://zhidao.baidu.com/question/93073790.html

前提是有豆瓣账号，然后在“我的设置”里，有一个添加blog地址就可以了。 

进一步的话就是进行博客认证，验证该博客归你所有。在自己博客发篇验证码，然后豆瓣验证通过就成了。
具体：
去“九点”，点击“我的订阅”，在顶部点击“添加订阅”，输入正确的博客或rss地址，即可将博客添加到九点里。 

添加订阅成功后，再在订阅页面找到该博客所在的九点页面，在页面顶部可以看到">认领这个博客"的按钮，根据提示（在自己博客里发篇含验证码的博文，验证码可以复制过去），即可认领这个博客了。 

认领成功后，最近更新的博客文章会显示在个人豆瓣页面。 

-----------------------------------------------------------------------------------————————————————

真的好麻烦啊，不知道有多少人会玩这个，学习成本太高了。

不想把标题起得太小愤青了，因为毕竟愤怒和超越理智是解决不了问题的。

公司组织羽毛球比赛，组织者规定：每个一线manager下面都要有一只队伍，每支队伍3男3女（男双、女双、混双）。为了这个事情我和组织者交流过，大概意思是以下几点：

1. 比赛这个事情，要以大家自愿为主，天气那么热，你不能为了你搞这么一个活动，就强行拉人家去比赛。

2. 在一个IT公司，你要找到男女数量上的平衡是有困难的。基于第一条原则，应该合理地调整男女比例。

3. 强行规定一线经理的组一个队伍不利于人员灵活调整。一个一线经理下面的人数参差不齐，且并非多数人员都对羽毛球比赛感兴趣。往往会出现有些manager下面人员过多，不得不删除，而有些manager下面根本就没人对比赛感兴趣，被强迫去比赛。

组织者是如此回答我的问题的：

1. 鼓励大家都能参加比赛。

2. 基于鼓励原则，所以应该特别鼓励女生参加（目的是全民健身？）。

3. 参与意义大于竞赛意义。

4. 一线经理的参赛结构有利于比赛公平性

我的点评是：

1. 说是鼓励，更多具有强迫性质。如果是没有组织经验的人，往往差距不到两者的区别。作为一个多元化的公司，你不能强迫别人做任何事情。

2. 鼓励员工健康地平衡工作和生活，积极参与体育锻炼，这是一件好事情。但是鼓励和强制是有区别的，每个人都有选择自己生活方式的自由，哪怕是不健康的，比如宅。如果你不是在精神上有这种认同，你是无法鼓励就能让人改变自己的选择的。

3. 既然参与意义大于竞赛意义，就无法过多地腔调“公平性”。所谓过多，就是很刚性的规定，而且无法改变。组织者所说的3、4两点显然内在含义是矛盾的。真的要鼓励参与，那么就打循环赛。

4. 一线经理参赛结构的问题是讨论的焦点。
“公平性”的理由是站不住脚的，因为一线经理下面的人数过少，你无法保证大家对于比赛的认识是处于同一水平。你不能拿十几个人和国家参与的奥运会想提并论公平性。
作为负责基层的组织者，我当然理解这种结构是方便组织管理的一种方式。不过这并非唯一的解决方案。去年的比赛这种结构已经暴露出了许多弊端，负责人换了，于是就要重蹈覆辙。主要的矛盾就是前面所述的“有的同事参赛积极性高，却不能参加；而有的同事显然不感兴趣，却被迫参加比赛。”

我曾经提议过一个方案：以二线经理为基础（几时到几百人），随便申报几个队伍参加；每个队伍自行选择人员，向经理申请资金（或者自筹）。这种方案不仅能够解决比赛的关键性问题（结构、资金），更多地能够避免积极性问题，更多地具有自发性（也带有鼓励性质），提高了效率。

最后，组织者否定了这种方案。显然她是觉得这个方案过于“自由”，具有“隐性风险”（某种程度，我是承认的）。

既然最后已经决定，我想我不会在组织过程中再提出什么异议。不过，显然我们两个对于管理理念上，是存在很大的断层的（Gap）。如果要总结我对于那位组织者的管理方式，我大概会用“官僚式的”、“自上而下的”、“刚性的”；而我的方式则是“自由主义式的”、“自发性的”、“松散的”。

这是两种迥然不同风格的交锋。前者更为陈旧稳重，而后者则是先锋派。虽然不仅存在于中国，但官僚气氛浓重的确是这个人口大国很大的特色（官僚和人数存在这某种必然的联系）。可能在某种人数的层次（例如每个一线manager下），自上而下的管理是有效率的。但一旦人数开始上升，过于强调管理者自身的意愿，只能带来结构的僵化和效率的低下。并且这种情况很容易演变成上下矛盾：在下者对于管理者过多地控制不满，而管理者基于来自下面的challenge，对于权力有更大的依赖性（保护自己），又演变成刚愎自用。

在中国，的确这种例子并不少见。

http://www.eweek.com/c/a/Application-Development/25-Things-You-Might-Not-Know-About-IBM-656232/?kc=EWKNLEDP07162009A

从此可以看出，IBM也是，或曾经是一个有着世界级梦想的公司，如同现在的google。

关于利润与梦想的争论，其实一直在这片土地上发生着。

显示loading的图标有各种各样，这个是一个重要的UE的标志。

浏览器下载网页一般也会显示laoding的状态，例如IE的进度条。Chrom的在Tab网页名称的前方的放置Loading图标。

这并不稀奇，但是如果更细心一点会发现：发送请求的时候（例如上传文件），图标是逆时针转的，而等待请求（下载）的时候，图标是顺时针转的。

getLocalAddr()是ServletRequest里面的一个方法，JavaDoc上的解释是：

“Returns the Internet Protocol (IP) port number of the interface on which the request was received.”

输入http://xx.xx.xx.xx这样的IP地址时，返回的是这个IP地址；而输入http://localhost 这样的域名，返回的将是127.0.0.1，原因是localhost当从网卡发出数据包的时候，其IP地址被替换成了127.0.0.1（hosts文件中定义），所以走得也是这个interface。

Case：

1. 有2个Web应用A和B，装在一台机器M1上（域名D1，地址IP1）

2. 从另外一台机器（M2）上访问应用A，应用A会调用应用B的资源，应用B取得LocalAddr（为了下一步调用）

3. 调用发生在前台Browser端，使用HttpRequest（Ajax），且规则是：如果发现B的资源在和A不同的域名下，则选择用应用A中AjaxProxy调用(d1)（为了跨域cross domain）；否则浏览器直接调用(d2)B的资源

问题描述：

1. 为了模拟生产环境(production envrionment)，M1的IP分别人为地设置了DNS匹配（修改hosts文件）：在M2上：D1->IP1;M1上：D1->127.0.0.1；在这样的条件下M2能访问应用A，并调用应用B的资源，应用B能获得IP1。

2. 而在另外一台未设置IP mapping的机器M3上，应用B不能获得IP1。

原因解释：

1. 根绝条件3，M2上调用应用B采用直接调用(d2)的方式，URI为：http://D1/B

    而因为在机器M2上D1被map为IP1，所以数据包在interface上是以IP1的形式发出去的

    所以在应用B中，LocalAddr为IP1

2. 在M3上，采用AjaxProxy的方式调用（d1),URI为：http://D1/A/ajaxProxy/http/D1/B

    所以其实是在A中（机器M1）调用了B；

    而在M1上D1被map为127.0.0.1，所以在B应用中，LocalAddr为127.0.0.1

解决方案：

在M2上的hosts中，将D1匹配到IP1，而不是127.0.0.1

 

wikipedia成名已久。早在几年前，因为没有GFW，访问wikipedia似乎成为了一种习惯。google自然好用，但wikipedia传递是更直接的知识，就算没事翻翻也能张不少见识。就像很多人一样，我认为wikipedia是人类知识共享的一个里程碑。

在《未来是湿的》里面Clay Shirky把wikipedia的成功更多地归结于协同（collaboration）的成功——指的当然是wikipedia的运作方面。shirky把social software的功能分为三类：共享（share），协同和合作，其关系是前者分别是后者的基础，由底而上逐次演进。

wikipedia的成功有很多因素，最重要的可能是群体性地参与。正如Shirky所言，如果不是人们大量地不及效率地投入，知识才逐渐被积累，且日趋于完美。规则的制定，保证了参加活动的可能性。每个人都能贡献出自己的一份小小的力量，而长尾却是最终影响结果的关键。

wikipedia带给我们的是一个完美的知识共享体系，一个成功的典型。这让许多人痴迷研究wikipedia的秘密，以及去模仿。但很容易发现，之后出现的知识系统，无论是“百度知道”这样的答问式系统，还是其他的wiki系统，都无法达到wikipedia的高度。

很多企业也建立了自己内部的wiki，试图建立一个知识共享的基地。但是我们往往发现，多数page永远都只是创建者自己在编辑。原因很简单，这些page的建立往往是作为任务去编写的。只有极少数的人会关心这些页面：创建者和部分需要查询的成员。问题并不在于其功能性的定位，wikipedia最终也是成为人们查询专业知识的地方。可关键是：如果才能鼓励人们去share他们的知识呢？

Shirky喜欢将wikipedia贡献的动力归结为“爱”，这个词我不是很满意。不过，Shirky也介绍了这种爱的内部深层含义：人们乐意留下一些改变世界的记号。而这种纯兴趣的动力，是讲究效应的，而不是效率。公司的内部体制觉得了效率更为重要。这就是社会软件与企业的内在矛盾。如果要产生有用的企业社会软件（Enterprise Social Software），需要在这方面做出努力。

讲究效率的企业，往往缺乏足够的开放性。这也是人民没有足够意愿参与社会软件贡献的原因之一。但这不应该意味着企业社会软件一定走向陌路，要看它是如何发展的。就如上文所言，虽然缺乏开放性、讲究效率等原因，是的企业社会软件缺乏开发性社会软件（Public Social Software)所具备的先天条件，但是只要有足够的动机，公司成员还是会乐于奉献出自己的信息。

改变文化、改变机制、改变技术，这三样东西同等重要。模仿不能解决问题，不如先问一下：企业里面的员工究竟需要的是什么？

不知道多少人看到这个标题产生了不健康的联想，反正我承认我一开始看到标题想法是蛮俗的。

看了方军的推荐，才拿起来读。奇思乱想不断地蹦出来。

一本伟大的书并不仅是传递知识的，而更应该是能够令人感到启发的（inspire）。这本书的确做到了，之后应该会陆续写一点关于由读这本书产生的想法。

 

其余还买了三本书：

  

哎，书架上要堆满书了……

工作关系，发现一个不错的第三方Poll 和Survey的SP。

可以访问www.polldaddy.com

名字虽然俗套，但用起来挺方便的，只是现在显示中文还有些小。他的Poll是通过JS嵌入网页的，而Survey则提供了网页和Popup JS两种方式。

Poll：

Survey：

工作中，有效的沟通是非常重要的。人人都知道这点，可是却不是每个人都能做到。

昨天，Manager让我负责一个活动，作为focal point。由另外一个负责联系我。

然后那个人转给我一封email，告知我活动的背景。在了解了大概情况后，我和他谈了一次。

但显然，谈话并没有达到预期的效果。在谈话结束之后，我仍然不知道我在其中担任的角色，或者说我的职责是什么。他只是告诉我一些schedule，但是我并不知道，哪些是硬性的，哪些是我可以调整控制的。于是，我在接下去的工作中碰到了许多问题。并非问题本身难倒了我，而是我不知道我的解决方案在多大范围内是可以被接受的。

我想，开诚布公大概真的是交流中很重要的技巧。特别是在一开始的时候，就告知对方的职责范围。我在问他一些问题的时候，也明显感觉到他其实也是处于中间的一环，答案中包含了大量的“高层”“senior”等模糊概念的词。但得不到具体答案。或许这也是一种做事风格，但是我的确是不喜欢如此。

今天看了一份不算有趣的报告，主要谈到了Social Software在中国用户群中的体验。

提到了几点：

1. 中国用户喜欢匿名登陆，但却更倾向于向别人暴露自己的真是信息。

   是的，每次我查看某个bbs，需要注册都让我非常火大。但是鉴于现实，有时又不得不注册。其实，虽然中国的网站很多支持匿名登陆，但总会鼓励用户去注册。尽管可以理解网站为了保持用户的流量，总是要做些什么。可是一想到随便搜索一个信息就要登陆，我就觉得这种资源的浪费简直到了白痴的程度。

   另外中国人不重视自己的隐私也是大家都知道的现实了，现在大家都说提高保护自己的隐私，但也不会有人说怎么尊重别人的隐私。我不理解，我上某个网站为什么和我的生日、地址有什么关系？国家都没正式出台什么政策，你网站像哈巴狗一样献殷勤干嘛？其实，这些信息无论怎么看，多网站都是有益无害的，只能让用户自己火大。

2. 中国用户喜欢虚拟积分

    不知多少人为了q币闹得不可开交。报告说是因为中国人对于自我认同的需要（在这样一个人口大国之中），我的理解非常简单——一切由于我们的教育系统。小时候是唯分数，大了就是唯GDP，这些都是一脉相承的。

3. 中国用户更依赖推荐的东西

   这点我也是感同身受。有时一打开某个网页，不知道往哪里点，总怕错过些什么。很希望有人能指点一下。这个是否也和我们从小收到的教育有关呢？从小就是听从别人的教导：什么是好的，什么是坏的，应该如何，不应该如何。无论如何，我们也可以说：站在巨人的肩膀上，可以少走很多弯路。众多门户网站的爆炸式主页应该是这种文化现象的产物了。

4. 中国用户更适应等级管理的制度

   就是我们平时所说的版主、群主之类的。是不是展示中国人对于权力的欲望？不置可否。不过，等级的管理，比起毫无管理而言，可能的确是更有效的。

今天心情有些down，三周前post出去的presentation被committee给拒掉了。

大概所有刚开始职业生涯的人都会对应聘时的拒绝心有余悸。说实话，我应聘失败的概率不高。当时信心满满，但反而是进了公司才发现，自己还是那么嫩，无论在选择还是在执行上，都有很多不足。

我显然没有像当初招聘我的经理预期的那样，快速地成长起来。逐渐感觉自己变得默默无闻，但是我希望还是能够坚持一些东西。

我相信我自己，presentation得到了一个技术人员的支持，我相信他也是投了我们一票的人员之一。我很为自己完成的东西感到自豪，不过，的确还不够。

不够的东西很多，如何成为senior的人，无论是technical还是管理方面。淘汰一个新手，对公司来说再也正常不过了，某种程度我也必须接受这样的训练。只是，内心仍感觉一丝不爽。他们的反对票不说明一切，但的确引来一阵不快。

在中国这个越来越物质化的地方，很少有人会相信所谓的理性和完美。成功才是唯一的价值标准，或者简单地总结为财富。知道这是错的，但却无法改变。

继续工作吧，我不知道这样的结果是会让我消沉，还是让我振作。

刚刚参加了一个study group，主要研究产品针对中国地区用户的特殊点，特别是Web application。

觉得应该是一个很有趣的topic。IT一直是以美国为技术龙头，欧洲以资本取胜，而日本较为独立自成一体。

除了极少数用户，在中国twitter、facebook（当然现在还有校内）、blogger都是玩得人不多的。一直说google中国战略不太成功，其实相对于其他的应用，google已经算是国外企业里有所建树的了。不可否认，中国人更喜欢用qq，天涯，百度，校内，开心……

当然，市场是一个原因，技术可能都不是最为关键的。很多时候，产品的成功和文化、历史都有一系列的关系。比如twitter，中国人翻译叫微博客，其实我很早就说过：这个就是中国人天天在改的签名档。能不能热起来，真的就不好说了。

如论将来如何，今天都会成为IT界不同的一天。

“Oracle（甲骨文）收购了Sun” 这条新闻铺满了所以IT新闻的首要内容。

其实，无论是谁收购了Sun，都会影响到整个业界的格局，毕竟Sun已经太庞大，太重要了。

席卷其中的，不仅仅是进行交易的两家公司。IBM、HP、SAP、MicroSoft都成为了受到影响的公司，更不用提那些处在产业各个环节的小公司们。IBM可能首当其冲，毕竟它是曾经拥有“优先收购权”，现在花落旁家，而且原因很可能是其主动放弃。

从IBM的角度分析，如果收购Sun，将进一步拉大与竞争对手的差距，但却可能面临被反垄断调查的危险。我不知道IBM的决策者们是否考虑过Sun被其他公司收购的可能性（毕竟当时来看，IBM不出手，也的确是可能发生的），或许唯一想不到的是发生的那么快，而且收购者是Oracle。（其实，仅从影响上来说，HP如果成为收购者，IBM也好受不到哪里去，尽管HP显然不会收购，以及收购的具体影响是不同的。）

从某种角度看，IBM的退出与Sun的出手是一种必然。在经济危机之中（IBM第一季度财报，利润下滑1%，营收下跌11%），谁都会谨慎面对收购Sun这样的公司。其实，就算经济好的时候，这种大动作还是存在风险的，就如当年HP收购Compaq就被许多人诟病：产业合并整合、人员动荡协调、外部关系清理、资产清算、战略规划、文化融合，没有人否认这种风险的可怕，就如同没有人否认收购后带来的巨大影响。IBM作为一个巨无霸公司，收购Sun是作为他的一种战略选择；而Oracel的收购，则是将自己变成了另一个IBM。这种结局让人回味无穷。

IBM是保守的，Oracel是进攻型的。从Oracel的角度出发，收购也是一种赌博，输赢概率只能说是对半分。如果赢了，对Oracel而言，将是脱胎换骨的一次转型；如果失败，可能。。。谁都说不清。这样一个时刻，许多人都在观望，看着Oracel是否能消化掉Sun。如同赢者通吃的原则一样，结果是没有中间状态的（个人臆测是因为现代公司太过于复杂）；只要Oracel不倒退，巨大的机会就一直存在。

大家都感觉到了威胁，但是从另一个角度看问题，貌似强大的时候往往是隐患缠身的时刻（而且还是大家都看得到的隐患），有谁能在这个时刻痛击Oracel呢？从个人感情的角度考虑，我是乐意见到的，哈哈。

今天加一个好友时发现，博客本身是不能comment的。

所谓对博客本身的comment，有许多形式出现：比如说留言、给某个人作tag、对某人的评述。

comment和私人留言最大的不同是：它是以public的形式出现的，而后者可以通个站内的短消息实现。

一个变通的方法是：留言在某篇日志之后。但如果碰到对方还一篇都没有写，那么就会变成一个bug（功能缺失）了，（恰好我的那个朋友就是这种情况）。

我不知道可以到哪里去提这个意见，不过虽然功能很小，如果blogbus要在SNS有所作为，总还是要注意的。

今天写了一篇书评，发现在blogbus里写日志时能够自动插入豆瓣的一段代码（即插入书籍）。

突然对这个功能很有感觉，这的确给那些书虫们提供了一个很诱人的服务。

其实，仔细看一下那段豆瓣的嵌入代码，发现其实所谓的插入书籍，只是给个图片的链接，然后点开可以到达豆瓣上相应的页面。我不得不说，这个idea真的是很绝妙！仅从技术上来讲，这个服务的实现，几乎就不需要花任何多余的effort，因为这本来就是任何网站都可以做到的事情。

以前就听说，豆瓣刚推出的时候，仅仅在一台server上跑，程序的逻辑都写得非常高效的，完全是高手中的高手之创作。从一开始豆瓣都不是那种站在浪尖上的，我们不知道它拉到了多少钱，不知道它能赚多少钱，也很少听到别人有议论它是多么地赚钱。但也几乎是从一开始，它就是以某种目标去经营——一种近乎理想的东西，所以它能带给用户的永远是最贴心的服务，你不会觉得它有任何傲慢的地方。从它简洁但强大的界面，到许多意想不到的小惊喜。

个人来讲，真的很偏爱豆瓣。我或许不会每天都上，或许不会真的用它的新功能，但是像许多其他人一样，如果要说什么读书的网站，大概第一个会想起的就是豆瓣。关于书的网站，很多人在做：卓越、当当是以物流为生；开心、校内只是将其作为一种补充性的服务（估计现在都快没了）；豆瓣却始终以一种服务去坚持着。

说实话，很想豆瓣继续坚持下去，因为从中看到了某种热情（一种在中国市场上几乎绝种的热情）；但同时，也会为其担心害怕，毕竟在网络泡沫已经破灭的今天，网站的赢利始终是纠在任何相关人士心里的一个结。豆瓣从未以暴发户的形象出现在用户面前，我们也只能希望它一路走好。因为，心中始终相信：那些有理想的东西，必然会在将来的某一天被实现。