Jack Ma: Blog

Today's posts mainly go into a new category "Notes". I'm thinking that, I should have a habit to collect and archive some goodies for later reference purpose.

Hope my readers also can find something making sense for them.

Why Model?

Tue, 29 Jul 2008 10:23:10 GMT

Why do engineers build models? Why do aerospace engineers build models of aircraft? Why do structural engineers build models of bridges? What purposes do these models serve?

These engineers build models to find out whether their designs will work. Aerospace engineers build models of aircraft and then put them into wind tunnels to see whether they will fly. Structural engineers build models of bridges to see whether they will stand. Architects build models of buildings to see whether their clients will like the way they look. Models are built to find out whether something will work.

This implies that models must be testable. It does no good to build a model if you cannot apply criteria to that model in order to test it. If you can't evaluate the model, the model has no value.

Why don't aerospace engineers simply build the plane and try to fly it? Why don't structural engineers simply build the bridge and then see whether it stands? Very simply, airplanes and bridges are a lot more expensive than the models. We investigate designs with models when the models are much cheaper than the real thing we are building.

Why Build Models of Software?

Can a UML diagram be tested? Is it much cheaper to create and test than the software it represents? In both cases, the answer is nowhere near as clear as it is for aerospace engineers and structural engineers. There are no firm criteria for testing a UML diagram. We can look at it, evaluate it, and apply principles and patterns to it, but in the end, the evaluation is still subjective. UML diagrams are less expensive to draw than software is to write but not by a huge factor. Indeed, there are times when it's easier to change source code than it is to change a diagram. So when does it make sense to use UML?

I wouldn't be writing some of these chapters if UML didn't make sense to use. However, UML is also easy to misuse. We make use of UML when we have something definitive we need to test and when using UML to test it is cheaper than using code to test it. For example, let's say that I have an idea for a certain design. I need to test whether the other developers on my team think that it is a good idea. So I write a UML diagram on the whiteboard and ask my teammates for their feedback.

Should We Build Comprehensive Designs Before Coding?

Why do architects, aerospace engineers, and structural engineers all draw blueprints. The reason is that one person can draw the blueprints for a home that will require five or more people to build. A few dozen aerospace engineers can draw blueprints for an airplane that will require thousands of people to build. Blueprints can be drawn without digging foundations, pouring concrete, or hanging windows. In short, it is much cheaper to plan a building up front than to try to build it without a plan. It doesn't cost much to throw away a faulty blueprint, but it costs a lot to tear down a faulty building.

Once again, things are not so clear-cut in software. It is not at all clear that drawing UML diagrams is much cheaper than writing code. Indeed, many project teams have spent more on their diagrams than they have on the code itself. It is also not clear that throwing away a diagram is much cheaper than throwing away code. Therefore, it is not at all clear that creating a comprehensive UML design before writing code is a cost-effective option.

Principles behind the Agile Manifesto

Tue, 29 Jul 2008 10:12:17 GMT

The values in the Manifesto for Agile Software Development inspired the following 12 principles. These principles are the characteristics that differentiate a set of agile practices from a heavyweight process.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. The MIT Sloan Management Review published an analysis of software development practices that help companies build high-quality products.^[1] The article found a number of practices that had a significant impact on the quality of the final system. One was a strong correlation between quality and the early delivery of a partially functioning system. The article reported that the less functional the initial delivery, the higher the quality in the final delivery. The article also found a strong correlation between final quality and frequent deliveries of increasing functionality. The more frequent the deliveries, the higher the final quality.

^[1] "Product-Development Practices That Work: How Internet Companies Build Software," MIT Sloan Management Review, Winter 2001, reprint number 4226.

An agile set of practices delivers early and often. We strive to deliver a rudimentary system within the first few weeks of the start of the project. Thereafter, we strive to continue to deliver systems of increasing functionality every few weeks. Customers may choose to put these systems into production if they think that they are functional enough. Or, they may choose simply to review the existing functionality and report on changes they want made.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. This is a statement of attitude. The participants in an agile process are not afraid of change. They view changes to the requirements as good things, because those changes mean that the team has learned more about what it will take to satisfy the customer.
An agile team works very hard to keep the structure of its software flexible, so that when requirements change, the impact to the system is minimal. Later in this book, we discuss the object-oriented design principles, patterns, and practices that help us to maintain this kind of flexibility.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. We deliver working software, and we deliver it early and often. We are not content with delivering bundles of documents or plans. We don't count those as true deliveries. Our eye is on the goal of delivering software that satisfies the customer's needs.
Businesspeople and developers must work together daily throughout the project. In order for a project to be agile, customers, developers, and stakeholders must have significant and frequent interaction. A software project is not like a fire-and-forget weapon. A software project must be continuously guided.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. People are the most important success factor. All other factorsprocess, environment, management, and so onare second-order factors and are subject to change if they are having an adverse effect on the people.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. In an agile project, people talk to one another. The primary mode of communication is human interaction. Written documents are created and updated incrementally on the same schedule as the software and only as needed.
Working software is the primary measure of progress. Agile projects measure their progress by measuring the amount of software that is currently meeting the customer's need. They don't measure their progress in terms of the phase they are in or by the volume of documentation that has been produced or by the amount of infrastructure code they have created. They are 30 percent done when 30 percent of the necessary functionality is working.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. An agile project is not run like a 50-yard dash; it is run like a marathon. The team does not take off at full speed and try to maintain that speed for the duration. Rather, it runs at a fast but sustainable pace.
Running too fast leads to burnout, shortcuts, and debacle. Agile teams pace themselves. They don't allow themselves to get too tired. They don't borrow tomorrow's energy to get a bit more done today. They work at a rate that allows them to maintain the highest-quality standards for the duration of the project.
Continuous attention to technical excellence and good design enhances agility. High quality is the key to high speed. The way to go fast is to keep the software as clean and robust as possible. Thus, all agile team members are committed to producing only the highest quality code they can. They do not make messes and then tell themselves that they'll clean them up when they have more time. They clean any messes as they are made.
Simplicitythe art of maximizing the amount of work not doneis essential. Agile teams do not try to build the grand system in the sky. Rather, they always take the simplest path that is consistent with their goals. They don't put a lot of importance on anticipating tomorrow's problems; nor do they try to defend against all of them today. Rather, they do the simplest and highest quality work today, confident that it will be easy to change if and when tomorrow's problems arise.
The best architectures, requirements, and designs emerge from self-organizing teams. An agile team is a self-organizing team. Responsibilities are not handed to individual team members from the outside but rather are communicated to the team as a whole. The team determines the best way to fulfill those responsibilities.
Agile team members work together on all aspects of the project. Each member is allowed input into the whole. No single team member is solely responsible for the architecture or the requirements or the tests. The team shares those responsibilities, and each team member has influence over them.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. An agile team continually adjusts its organization, rules, conventions, relationships, and so on. An agile team knows that its environment is continuously changing and knows that it must change with that environment to remain agile.

Manifesto for Agile Software Development

Tue, 29 Jul 2008 10:05:40 GMT

http://agilemanifesto.org/

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler

James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick

Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

ABeam Core Value

Tue, 29 Jul 2008 09:53:14 GMT

Client Passion

We focus on our clients, always thinking in terms of what is best for each client. We offer only solutions that are workable, pragmatic and prudent—solutions that add value and become an intrinsic part of a client’s business.

Professional Excellence

Our solutions come from industry-specific knowledge, best practices and accumulated expertise. As a true industry leader, we constantly explore new services and expand our knowledge and skill sets. We invest in people who are passionate about achieving excellence, and who are measured by tangible results and client satisfaction.

Power of Diversity

As a global organization, we are diverse by definition. We share a culture of mutual respect for each individual’s capabilities, achievements, and heritage. We recognize how diversity adds value to our clients – and to each other – by amassing individuals’ capabilities into a unique collection of knowledge.

Collaboration and Collegiality

We work as a team, both enterprise-wide and at the engagement level, with our clients and with each other. We overcome complex challenges together, and welcome new challenges.

Global Perspective

We absorb best practices from around the world as our own, while respecting local value systems and cultures. This worldwide network enables us to deliver benefits that are specific to each client’s industry, objectives, and geography.

UML diagrams

Tue, 29 Jul 2008 09:48:40 GMT

http://en.wikipedia.org/wiki/Unified_Modeling_Language#Diagrams

UML 2.0 has 13 types of diagrams that can be categorized hierarchically as shown in the following Class diagram:

Structure diagrams emphasize what things must be in the system being modeled:

Class diagram
Component diagram
Composite structure diagram (added in UML 2.x)
Deployment diagram
Object diagram
Package diagram

Behavior diagrams emphasize what must happen in the system being modeled:

Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:

Communication diagram
Interaction overview diagram (added in UML 2.x)
Sequence diagram
Timing diagram (added in UML 2.x)

The Protocol State Machine is a sub-variant of the State Machine. It may be used to model network communication protocols.

UML does not restrict UML element types to a certain diagram type. In general, every UML element may appear on almost all types of diagrams. This flexibility has been partially restricted in UML 2.0.

In keeping with the tradition of engineering drawings, a comment or note explaining usage, constraint, or intent is always allowed in a UML diagram.

无题

Tue, 29 Jul 2008 07:43:30 GMT

去年请搬家公司搬家的时候，我和同学的电脑各被搬运工拔了一条内存条。我还记得当时，因为看那几位工人为了帮我们搬东西而汗流浃背，我和同学基本上加入了他们的工作，帮他们一起搬。没成想他们居然有这手。被人卖了还帮人数钱？苦笑。

前几天，发现住处附近的好德便利里面的阿姨，总是时不时地出错多收你两三块钱。一开始还以为他们是不小心出错，连续留心了两天后，发现那彻彻底底就是计划预谋好了的。我靠。

。。。

我这两天莫名地超级工作效率低下。姑且，将脑子里的脏东西往外倒一倒打发一下时间。

。。。

想不出题目，就叫无题吧。

MSF Principles

Tue, 22 Jul 2008 13:55:13 GMT

Foster open communication
Work toward a shared vision
Empower team members
Establish clear accountability and shared responsibility
Focus on delivering business value
Stay agile, expect change
Invest in quality
Learn from all experiences

Just for a note...

which version are you?

Fri, 27 Jun 2008 11:41:52 GMT

http://geekswithblogs.net/leesblog/archive/2008/06/22/developer-versioning-which-version-are-you.aspx

good point

Wed, 25 Jun 2008 05:16:21 GMT

http://www.infoq.com/news/2008/06/new-user-story-format

Life is just a process

Mon, 23 Jun 2008 16:42:15 GMT

Life is just a process between birth and death.

Relaxed or plodding, YOU choose.

Links 2008/06/17

Tue, 17 Jun 2008 02:04:03 GMT

MVC

http://aviadezra.blogspot.com/2007/07/twisting-mvp-triad-say-hello-to-mvpc.html

http://dotnetslackers.com/articles/aspnet/AnArchitecturalViewOfTheASPNETMVCFramework.aspx

http://ctrl-shift-b.blogspot.com/2007/08/interactive-application-architecture.html

NHibernate

http://devlicio.us/blogs/billy_mccafferty/archive/2008/06/16/performing-join-queries-with-nhibernate-createalias.aspx

勉强不是一件什么好事

Mon, 16 Jun 2008 17:41:15 GMT

如题。

总有一天会实在勉强不下去吧，我期待着这一天。

Installing ASP.NET 1.1 with IIS7 on Vista and Windows 2008 - BillS IIS Blog

Tue, 03 Jun 2008 01:30:25 GMT

Nice article for guys work on vista but need to write asp 1.1 applications.

Installing ASP.NET 1.1 with IIS7 on Vista and Windows 2008 - BillS IIS Blog

C# .NET: Convert System.Drawing.Color to HTML color

Wed, 28 May 2008 11:02:22 GMT

Nice!

ColorTranslator

C# .NET: Convert System.Drawing.Color to HTML color

Open Command Here in Vista

Thu, 22 May 2008 06:25:23 GMT

If you shift-right-click on a folder in an explorer window, you will see two incredibly useful menu items added to the menu:

Open Command Window Here...
Copy as Path

This is awesome! I mean, in XP, you have to install something like "Open Command Window Here" power toy. Sweet!

感同身受

Wed, 21 May 2008 13:51:44 GMT

Lu Yue-ting 5.19 博客上的几句话，让我有流泪的感觉。

晚上回家，偶尔抬头看天空，发现月亮很圆的挂在那里
心想，该是１５了吧，唉．．．回家一查，果然是
在这月圆之时，多少人散已发生。

今天我要说两件事

Wed, 21 May 2008 10:02:37 GMT

一、坚决戒除数据收集强迫倾向

事实上，我已经基本没这个倾向了，不过为了彻底戒除这个倾向，不妨还是写下来提醒一下自己。

最早开始患上这个倾向，应该是从早期网络极不发达，装软件几乎全靠买盗版光盘算起。那时候，为了找到自己想用的软件，经常要四处寻觅。也难怪有好东西就要收集一下的习惯养成了。于是乎，光盘包鼓鼓囊囊开始了。

再后来，宽带网起来了，光盘少了，然后收集好东西的习惯仍然存在，于是，硬盘开始被数据疯狂占据，经常性地出现容量不足的情况，再大的硬盘也都有塞满的时候。

喜欢收集数据本无所谓，恶劣的是，还喜欢整理。当面对那些自从收集起来就再也没动过的数据海洋时，差不多可以疯了。于是，在带宽达到差不多 2M 的时候，我开始养成了不收藏（这个词合适一点）东西的习惯。几个 M 的小东西直接从网上安装，稍微大一点的载到临时目录，装了即删。我现在只收藏三样东西。超大的，几个 G 的那种（估计总有一天不需要再收藏这些个东西了）。超小的，不容易找到的（比如 keygen，crack，汗～）。绝对精华的（往往指文章，ppt 一类，保存前自问有无必要 5 遍以上），这一类是我处理得还不够好的，还需努力戒除。

二、国产的新软件或软件新版本让我失望

谷歌金山词霸。满怀兴致地载好安装，用了几天发现极度地无法忍受。性能拙劣。太多地方的词根本捕捉不到。卸了。本打算安装老版本，想到那几百 MB 的大小，算了，还是装个只有不到 3M 的 lingoes 吧。

FlashGet，快车。2.0。失望透顶。耗掉我 CPU 的 50%，就 http 载个小东西而已，至于嘛。FlashGet 被收购的消息一出来的时候我就担心这个，果不其然，出来一个比迅雷更恶心（其实还是没有迅雷恶心，不过迅雷似乎性能稍微好那么一点）的版本。卸了。装回 1.9。

为什么这两款我用了这么长时间的软件这次集体让我失望？

都是互联网赚钱的目标惹得祸。金山开始思考他们打败微软的空头目标了，开始实际了，于是看上了互联网。跟谷歌合作。无奈过于冲动了点。FlashGet 就不说了，这个新版本简直就是彻底地向互联网盈利投怀送报。

互联网这东西不好玩。我是深深体验过的。尤其在我们国内。当然，也有很多人会说，虽然互联网不好玩，但一旦玩好了就发了呀。你说的对啊，但问题是，怎么样才能玩好呢？

我看呢，还是要利润第二得好。特别是软件一线的人，不要满脑子里想着赚钱，要首先想到用户，想到你的这个软件怎么造福广大网民。离开了这个前提，恐怕失败者众。

reading list

Thu, 15 May 2008 06:22:47 GMT

http://www.visitmix.com/university/stories/default.htm

http://www.visitmix.com/University/

http://sessions.visitmix.com/

基于可公度方法的川滇地区地震趋势研究

Wed, 14 May 2008 09:09:25 GMT

龙小霞，延军平，孙虎，王祖正

（陕西师范大学旅游与环境学院，陕西西安710062）

摘要：川滇地区为我国大陆最显著的强震活动区域，地震活动频繁。在对川滇地区强震灾害数据分析的基础上，应用三元、四元、五元可公度法分别预测了该地区下（几）次可能发生强震的趋势，以便能更好地配合防震减灾工作。

关键词：川滇地区；地震；可公度；趋势预测

中图分类号：P315175　　文献标识码：A 　　文章编号：10002811X （2006） 0320081204

　　川滇地区位于青藏高原东南缘，区内主要发育有北西向的鲜水河—安宁河—小江断裂、金沙江—红河断裂、怒江—澜沧江断裂和北东向的龙门山— 锦屏山— 玉龙雪山断裂等大型断裂带[ 1 ]。该区新构造活动剧烈，地震活动与活动断裂密切相关，绝大多数属构造地震，地震活动频度高、强度大，是中国大陆最显著的强震活动区域。川滇地区地震活动地域广、烈度高、破坏性大，地震灾害的频频发生严重威胁了该地区人民的财产和人身安全，也给该地区带来严重的生态、经济损失。本文采用“可公度法”对川滇地区的强烈地震的发生趋势进行推算与预测[ 2 ] ，以期该地区今后在防御重大地震灾害时，处于积极主动的状态，尽可能的减少生态、经济等诸方面的损失。

1　已有地震的统计分析

川滇地区块体构造是联系在一起的，由于欧亚板块和印度板块的碰撞，川滇块体向东南运动，滇缅断块向东北运动，形成边界断裂走滑位错和块体内部断层错动。边界断裂成为强烈地震孕育发生的构造带，而617 级以上地震大多发生在边界断裂带附近[ 3 ] ，反映出强烈地震与构造活动的密切关系。川滇地区地震活动频繁，有悠久的历史记载。特别是20 世纪以来，中强地震及强烈地震记录较全，成为统计研究的基础。据中国地震局整编的《中国历史强震目录》、《中国近代强震目录》以及1991 年至2005 年《中国地震年鉴》，20 世纪以来川滇地区617级以上地震发生的次数共37 次，其中710 级以上地震发生了21 次，占总数的57% ，617～ 710 级地震有16 次，占总数的43% （表1） [ 4～ 6 ]。图1 为20 世纪以
来川滇地区强震分布格局图。

图1　川滇地区20 世纪以来强震分布格局图

从表1 中可以看出，20 世纪以来川滇地区发生≥617 级地震的年份为25 年，分别为：1913 年、1917年、1923 年、1925 年、1933 年、1936 年、1941 年、1942 年、1948 年、1950 年、1952 年、1955 年、1960年、1967 年、1970 年、1971 年、1973 年、1974 年、1976 年、1979 年、1981 年、1988 年、1989 年、1995年、1996 年。如果将这25 年的年份作为一组数列，那么在其中我们可以找出几组以19 年为公差的子数列，如“1917、1936、1955、1974”、“1923、1941、1960、1979”、“1913、1933、1952、1971”以及“1950、1970、1989”等（部分年份的误差在正负一年以内），如图2 所示。

图2　20 世纪以来川滇地区发生≥617 级地震的部分年份关系图

　　由图2 可知，除1913、1923、1950 这三个年份有正负一年以内的误差外，其余年份皆严格符合19年公差的规律，由此我们可以依据上述计算得出的统计规律，对今后可能发生地震的年份进行推测,1989+ 19= 2008，因此可以看出，2008 年有强烈的
地震灾害信号。

2　地震趋势的可公度法预测

可公度性源于天文学，表示自然界事物之间的一种秩序，是自然现象周期性的一种客观外在反映,所以是一种信息系。这种信息系不仅在天文学研究领域中有明显的表现，而且在其他领域中也广泛的存在，因此可以以它作为对自然现象进行预测研究的依据和方法。翁文波院士首先将可公度性预测方法应用到了预测科学中来，并曾利用可公度信息系对1976 年唐山地震、1982 年华北干旱、1991 年长江流域洪水、1992 年美国加州地震等自然灾害现象作过成功的预测[ 7 ]。本文根据20 世纪以来川滇地区≥617 级地震的25 个发生年份，依据可公度法的原理和方法，对未来川滇地区≥617 级地震的发生年份进行预测。

211　三元可公度法预测

由三元可公度法计算如下：
设X 1= 1913；X 2= 1917；X 3= 1923；X 4= 1925;

X 5= 1933；X 6= 1936；X 7= 1941；X 8= 1942;

X 9= 1948；X 10= 1950；X 11= 1952；X 12= 1955;

X 13= 1960；X 14= 1967；X 15= 1970；X 16= 1971;

X 17= 1973；X 18= 1974；X 19= 1976；X 20= 1979;

X 21= 1981；X 22= 1988；X 23= 1989；X 24= 1995;

X 25= 1996

则计算结果见表2:

通过计算可以看出，得出的结果与实际的年份一致，且每一个结果都能写出三组以上的三元可公度式子，由此说明，川滇地区的强震表现出了极好的可公度特征。由此可以推算出下（几）次地震的可能发生年份
X 26和X 27:X 26‘= 2007　　X 22+ X 6— X 2= 2007

X 24+ X 14— X 12= 2007　　X 22+ X 7— X 3= 2006

X 27‘= 2008　　X 24+ X 6— X 3= 2008

X 25+ X 14— X 12= 2008　　X 23+ X 6— X 2= 2008

212　四元可公度法预测

由四元可公度法计算如下:

设X 1= 1913；X 2= 1917；X 3= 1923；X 4= 1925;

X 5= 1933；X 6= 1936；X 7= 1941；X 8= 1942;

X 9= 1948；X 10= 1950；X 11= 1952；X 12= 1955;

X 13= 1960；X 14= 1967；X 15= 1970；X 16= 1971;

X 17= 1973；X 18= 1974；X 19= 1976；X 20= 1979;

X 21= 1981；X 22= 1988；X 23= 1989；X 24= 1995;

X 25= 1996

则计算结果为:

X 16+ X 5— X 20— X 1= 12　X 15+ X 5— X 18— X 2= 12

X 14+ X 6— X 18— X 2= 12　X 15+ X 7— X 19— X 3= 12

四元可公度法预测结果：1996+ 12= 2008

213　五元可公度法预测

由五元可公度法计算如下:

设X 1= 1913；X 2= 1917；X 3= 1923；X 4= 1925;
X 5= 1933；X 6= 1936；X 7= 1941；X 8= 1942;

X 9= 1948；X 10= 1950；X 11= 1952；X 12= 1955;

X 13= 1960；X 14= 1967；X 15= 1970；X 16= 1971;

X 17= 1973；X 18= 1974；X 19= 1976；X 20= 1979;

X 21= 1981；X 22= 1988；X 23= 1989；X 24= 1995;

X 25= 1996

则计算结果为:

X 23+ X 15+ X 1— X 3— X 7= 2008

X 23+ X 20+ X 12— X 18— X 7= 2008

X 24+ X 21+ X 8— X 18— X 6= 2008

X 25+ X 15+ X 7— X 19— X 3= 2008

X 22+ X 15+ X 5— X 13— X 3= 2008

X 21+ X 11+ X 9— X 13— X 1= 2008

总结以上几种预测结果，可以看出从灾害信息来讲，2007 年和2008 年的灾害信号比较强，尤其是2008 年更符合已有地震资料的统计规律，因此川滇地区下（几）次可能发生≥617 级地震的年份为2008年。

3　结论与建议

从以上所进行的推算与预测结果看，在2008 年左右，川滇地区有可能发生≥617 级强烈地震。为了更好地配合防震减灾活动，笔者提出以下建议。

（1）完善预防措施　实行“预防为主、防御与救助相结合”的方针，切实加强地震监测预报、震灾预防、紧急救援三大工作体系建设，加强针对性专题研究，确定重点防震区域，依靠全社会力量，不断提高防震减灾综合能力。

（2）加强抗震能力建设　各级政府应高度重视防震减灾工作，加强领导和管理，切实加强抗震设防及地震安全性评价工作，加强对重大建设工程和一般民用建设工程的抗震设防监督管理工作，坚决做好抗震设防和地震安全性评价管理工作，提高城市和农村的防震抗震能力。

（3）健全紧急救援系统建设，以提高地震应急反应能力　依法制定地震应急预案，加强地震应急系统指挥建设，明确紧急救援队伍，加强宣传教育,提高各级领导和广大群众的避震应急、自救互救知识技能。

（4）广泛宣传动员，普及防震抗震知识。川滇地区的破坏性地震以往主要集中于农村，而缺乏防震减灾意识和经济滞后等原因又导致农村民居普遍抗震性能差[ 8 ] ，因此，应该加强防震抗震知识的宣传和普及，把防震抗震知识宣传普及到乡（镇）、村及农户，努力提高农村民居防震抗震能力。

（5）加强地震监测网络建设　川滇地区断裂多,地域广，地震灾害频发。在如此广大的区域内，确定地震规律及确切的发生地点仍然有许多科学问题，有待于进一步深入研究，尤其应采用切实措施不断完善和加强地震监测网络建设。

参考文献：
[ 1 ]　苏有锦，秦嘉政. 川滇地区强地震活动与区域新构造运动的关系[J ]. 中国地震，2001，17 （1）：24234.

[ 2 ]　邢东兴，孙虎，延军平. 陕西省大旱年发生概率及可能发生的年份预测[J ]. 灾害学，2004，19 （1）：69272.

[ 3 ]　黄子波. 川滇地区强烈地震预报研究. 四川地震，1994，（1）：9213.

[ 4 ]　中国地震局.《中国历史强震目录》（公元前23 世纪～公元1911年） [M ]. 北京：地震出版社，1995.

[ 5 ]　中国地震局.《中国近代地震目录》（公元1912 年～ 1990 年）[M ]. 北京：中国科学技术出版社，1999.

[ 6 ]　《中国地震年鉴》编辑部. 中国地震年鉴1991～ 2005[Z]. 北京:地震出版社，1991～ 2005. [ 7 ]翁文波. 预测论基础[M ]. 北京:石油出版社，1984.

[ 8 ]　陈，等.“十一•五”期间中国重大地震灾害预测预警和防治对策[J ]. 灾害学，2005，20 （1）：1214.

Study on Earthquake Tendency in Sichuan—Yunnan Reg ion Ba sed on Commen surabil ity
LON G Xiao2x ia，YAN Jun2p ing，SUN Hu andWAN G Zu2zheng
（T he Colleg e of T ou rism and E nv ironm ent，S haanx i N orm al U niversity ，X i‘an 710062，Ch ina）
Abs tra c t：Sichuan2Yunnan region is p rone to st rong and h igh f requen t earthquakes. Based on the data
analysis of earthquake disasters in Sichuan2Yunnan region，the tendency of the nex t st rong earthquake
（ s） is p redicted by comm en su rab ility of ternary，quatern ion and qu in tup le，fo r the pu rpo se of disaster p re2
ven t ion and reduct ion.
Ke y w o rds：Sichuan2Yunnan region；earthquake disaster；comm en su rab ility；tendency p redict ion

地震在美国的话军队估计当天就能空降进去了。 KDS宽带山 PChome社区

Wed, 14 May 2008 04:40:41 GMT

值得一看。

地震在美国的话军队估计当天就能空降进去了。 KDS宽带山 PChome社区

DefaultDotAspx.com

Wed, 14 May 2008 02:42:29 GMT

Nice tutorial sites, good for interviews.

DefaultDotAspx.com

Scott Hanselman's Computer Zen - What Great .NET Developers Ought To Know (More .NET Interview Questions)

Mon, 12 May 2008 06:01:12 GMT

Well, this is a relatively old post, however, it is still a very realistic list for all of the .NET programmers to check.

Scott Hanselman's Computer Zen - What Great .NET Developers Ought To Know (More .NET Interview Questions)

微软开发部门似乎又重新开始习惯性 delay 了

Mon, 05 May 2008 14:55:35 GMT

过去两三年，微软开发部门给人的感觉，怎一个“敏捷”了得。推陈出新的东西一个接一个，令人目不暇接。vs 2005，vs 2008，基本上都是超前推出。这当中的许多扩展性功能，基本上也是快速跟进，很少出现跳票现象。

不过 2008 年开始，感觉这帮子人的速度明显慢了，或者说，明显比他们喊出来的速度慢了。xp sp3 拖了（不过也有人说是故意拖延，让等不及的人都去买 vista）。p & p 的 EntLib 4.0 拖了。ASP.NET MVC 距离真正的成熟还遥遥无期。

为什么？

我在想，或许他们战线拉得太长了吧。

生活项目化

Mon, 28 Apr 2008 09:38:51 GMT

继续读阿兰-拉金的《如何掌控自己的时间和生活》，发现和 pmp 有很多相似的地方。

Alan Lakein 强调了目标，计划，活动的重要性。同样的原则也出现在 pmp 中。项目管理四件事中的前两件基本上就是谈目标。首先要识别需求，然后是制定明确可达的目标。Alan 随后强调了为了完成目标而明确所需的活动并对活动进行排序的行为。而项目管理中呢？更加明确化了。项目管理中的规划过程中，明确地提出了制定工作分解结构（WBS），定义活动，排序活动，为活动决定资源，时间这些东西。除了这些，计划的执行和监控自然也都是这两个事物提到并强调的。

生活项目化，值得思考。

Foundations - Karl Seguin

Mon, 28 Apr 2008 02:34:04 GMT

Many of us think programming is becoming easier and easier. From perspectives of the tools, methodologies, I think, it is. However, on the other hand, I do think programming is becoming more and more complex, too, and the result is for many of the newbies, it is hard to quickly create a clear path or roadmap for the actual knowledge crunching. Karl wrote a series to help newbies and even many of the "sophisticated" developers among us to quickly pick some of the most important foundations of programming skills. Read it.

Foundations - Karl Seguin

ReSharper Horizons: Varification -- Using Implicitly Typed Locals

Thu, 24 Apr 2008 02:37:11 GMT

"var" keyword is new in c# 3.0, it is not a pretty new concept but just some enhancements for the c# compiler. To use it or not, many people are arguing about this topic. I prefer to use it and here are some thoughts you maybe find interesting. Just read on.

ReSharper Horizons: Varification -- Using Implicitly Typed Locals

Tips.Net: Creating a Shortcut Key for Strikethrough Formatting

Thu, 10 Apr 2008 02:58:15 GMT

Hey, I never found this trick for Microsoft office. Pretty cool! Why I try to look for a shortcut for the strikethrough operation? Generally speaking, I make a get things done list (actually a to-do list) everyday, and when I finish one of the items in the list, I used strikethough it to mark it as completed.

And here is another trick I never thought MS will provide till these days, it is about the text editor in Visual Studio, the rectangle select. I used to do this select in the asp times with editplus. This operation is pretty useful when your code aligned well, for example, by the equation sign. VS also support this, just hold alt key when you drag your mouse. Otherwise, if you don't want to use mouse drag, just press ctrl+alt, and then press any arrow key.

Tips.Net: Creating a Shortcut Key for Strikethrough Formatting

大风

Wed, 09 Apr 2008 13:21:02 GMT

今天风很大，不过在到达公寓楼下之前，我没意识到这个风究竟有多大。

从来，只有两种东西会给我有敬畏的感觉。一是大规模人造建筑，一是琢磨不定的自然。

因为如上的原因，我讨厌高楼，一切的高楼。选公寓，我会坚决拒绝超过十层的住宅楼，找工作，我会首选张江软件园类似的园区，因为那里不仅没有高楼，而且低矮的小楼都会错落有致。我想，这大概可以用恐高来解释。年前去名古屋时，发誓要去乘据说亚洲最高的过山车，但当真正到了那高耸的塔架下时，我晕了。还好那天风大，人家关闭了这个项目，总算在众人面前保留了脸面。

和风细雨让人怡然自得。然而，老天爷却不见得总是心情好如是。巨大的闪电，要撕裂所有一般的雷鸣，我恐惧。我还记得几年前的一个夏日中午，突然狂风大作，电闪雷鸣。写字间里的我，竟然被一个巨大的雷声惊得尖叫了一声。旁边是面不改色心不跳的几位女同事。丢脸。不过，我是真的怕。

刚刚经过公寓楼下，我的恐惧感几乎是瞬间爆发。因为在接近二十层的楼下，大风几乎要把我向断线的风筝一样吹走。我的天。今天的风好大。

……

How to get control of your time and your life

Mon, 07 Apr 2008 13:10:43 GMT

如何掌控自己的时间和生活

勤奋不一定有好报，要聪明地工作
更多地享受生活、不要过于追求“井井有条”
要少干活，多得结果
不会计划就是计划失败

Work smarter, and work harder...

在如何应用时间这件事情上，做出正确的选择要比更快更好地完成手头的工作更加重要
平衡是一种最理想的状态
过于讲求条理的人做事效率往往很低
真正的决定者是你自己
一味地空想，“要是我能再年轻些……要是我有足够的钱……要是我比现在更穷……要是我能更聪明一些……要是我能比现在更成功一些……”毫无任何意义
把规划的结果“写”下来要比一味地“想”效果好得多

The NHibernate FAQ

Mon, 07 Apr 2008 05:23:14 GMT

This site is definitely what you need even if you are already a so called nhibernate expert.

The NHibernate FAQ

The Differences Between Thick, Thin & Smart

Thu, 03 Apr 2008 06:07:51 GMT

Well, these are really not new concepts and maybe everybody who work in IT area should laugh at this post. However, I want put this link here and keep updating this link in the future. Why?

There are many concepts you think you are familiar most time, but sometimes it is not easy to give out a business definition. Think about your audience, he is not a developer and does not even heard about these things.

You need to use the shortest definition to give out the sell point to your audience.

Think about more concepts like web services, MOSS 2007, BizTalk, is it still easy for you?

The Differences Between Thick, Thin & Smart

Here is another subtopic, Ajax vs. Silverlight and .NET.