Feeling

　　Spark简介

　　Spark是整个BDAS的核心组件，是一个大数据分布式编程框架，不仅实现了MapReduce的算子map 函数和reduce函数及计算模型，还提供更为丰富的算子，如filter、join、groupByKey等。是一个用来实现快速而同用的集群计算的平台。

　　Spark将分布式数据抽象为弹性分布式数据集（RDD），实现了应用任务调度、RPC、序列化和压缩，并为运行在其上的上层组件提供API。其底层采用Scala这种函数式语言书写而成，并且所提供的API深度借鉴Scala函数式的编程思想，提供与Scala类似的编程接口

　　Sparkon Yarn

　　从用户提交作业到作业运行结束整个运行期间的过程分析。

　　一、客户端进行操作

1. 根据yarnConf来初始化yarnClient，并启动yarnClient

2. 创建客户端Application，并获取Application的ID，进一步判断集群中的资源是否满足executor和ApplicationMaster申请的资源，如果不满足则抛出IllegalArgumentException；

3. 设置资源、环境变量：其中包括了设置Application的Staging目录、准备本地资源（jar文件、log4j.properties）、设置Application其中的环境变量、创建Container启动的Context等；

4. 设置Application提交的Context，包括设置应用的名字、队列、AM的申请的Container、标记该作业的类型为Spark；

5. 申请Memory，并最终通过yarnClient.submitApplication向ResourceManager提交该Application。

　　当作业提交到YARN上之后，客户端就没事了，甚至在终端关掉那个进程也没事，因为整个作业运行在YARN集群上进行，运行的结果将会保存到HDFS或者日志中。

　　二、提交到YARN集群，YARN操作

1. 运行ApplicationMaster的run方法；

2. 设置好相关的环境变量。

3. 创建amClient，并启动；

4. 在Spark UI启动之前设置Spark UI的AmIpFilter；

5. 在startUserClass函数专门启动了一个线程（名称为Driver的线程）来启动用户提交的Application，也就是启动了Driver。在Driver中将会初始化SparkContext；

6. 等待SparkContext初始化完成，最多等待spark.yarn.applicationMaster.waitTries次数（默认为10），如果等待了的次数超过了配置的，程序将会退出；否则用SparkContext初始化yarnAllocator；

7. 当SparkContext、Driver初始化完成的时候，通过amClient向ResourceManager注册ApplicationMaster

8. 分配并启动Executeors。在启动Executeors之前，先要通过yarnAllocator获取到numExecutors个Container，然后在Container中启动Executeors。

   　　那么这个Application将失败，将Application Status标明为FAILED，并将关闭SparkContext。其实，启动Executeors是通过ExecutorRunnable实现的，而ExecutorRunnable内部是启动CoarseGrainedExecutorBackend的。

9. 最后，Task将在CoarseGrainedExecutorBackend里面运行，然后运行状况会通过Akka通知CoarseGrainedScheduler，直到作业运行完成。

　　Spark节点的概念

　　一、Spark驱动器是执行程序中的main()方法的进程。它执行用户编写的用来创建SparkContext(初始化)、创建RDD，以及运行RDD的转化操作和行动操作的代码。

　　驱动器节点driver的职责：

1. 把用户程序转为任务task(driver)

   　　Spark驱动器程序负责把用户程序转化为多个物理执行单元，这些单元也被称之为任务task(详解见备注)

2. 为执行器节点调度任务(executor)

   　　有了物理计划之后，Spark驱动器在各个执行器节点进程间协调任务的调度。Spark驱动器程序会根据当前的执行器节点，把所有任务基于数据所在位置分配给合适的执行器进程。当执行任务时，执行器进程会把缓存的数据存储起来，而驱动器进程同样会跟踪这些缓存数据的位置，并利用这些位置信息来调度以后的任务，以尽量减少数据的网络传输。（就是所谓的移动计算，而不移动数据)。

　　二、执行器节点

　　作用：

1. 负责运行组成Spark应用的任务，并将结果返回给驱动器进程；

2. 通过自身的块管理器(blockManager)为用户程序中要求缓存的RDD提供内存式存储。RDD是直接缓存在执行器进程内的，因此任务可以在运行时充分利用缓存数据加快运算。

　　驱动器的职责：

　　所有的Spark程序都遵循同样的结构：程序从输入数据创建一系列RDD，再使用转化操作派生成新的RDD，最后使用行动操作手机或存储结果RDD，Spark程序其实是隐式地创建出了一个由操作组成的逻辑上的有向无环图DAG。当驱动器程序执行时，它会把这个逻辑图转为物理执行计划。

　　这样 Spark就把逻辑计划转为一系列步骤(stage)，而每个步骤又由多个任务组成。这些任务会被打包送到集群中。

　　Spark初始化

1. 每个Spark应用都由一个驱动器程序来发起集群上的各种并行操作。驱动器程序包含应用的main函数，并且定义了集群上的分布式数据集，以及对该分布式数据集应用了相关操作。

2. 驱动器程序通过一个SparkContext对象来访问spark,这个对象代表对计算集群的一个连接。（比如在sparkshell启动时已经自动创建了一个SparkContext对象，是一个叫做SC的变量。(下图，查看变量sc)

   　　

3. 一旦创建了sparkContext，就可以用它来创建RDD。比如调用sc.textFile()来创建一个代表文本中各行文本的RDD。（比如vallinesRDD = sc.textFile(“yangsy.text”),val spark = linesRDD.filter(line=>line.contains(“spark”),spark.count()）

   　　执行这些操作，驱动器程序一般要管理多个执行器,就是我们所说的executor节点。

4. 在初始化SparkContext的同时，加载sparkConf对象来加载集群的配置，从而创建sparkContext对象。

   　　从源码中可以看到，在启动thriftserver时，调用了spark- daemon.sh文件，该文件源码如左图，加载spark_home下的conf中的文件。

   　　

   　　（在执行后台代码时，需要首先创建conf对象，加载相应参数， val sparkConf = newSparkConf().setMaster("local").setAppName("cocapp").set("spark.executor.memory","1g"), val sc: SparkContext = new SparkContext(sparkConf))

　　RDD工作原理：

　　RDD(Resilient DistributedDatasets)[1] ,弹性分布式数据集，是分布式内存的一个抽象概念，RDD提供了一种高度受限的共享内存模型，即RDD是只读的记录分区的集合，只能通过在其他RDD执行确定的转换操作（如map、join和group by）而创建，然而这些限制使得实现容错的开销很低。对开发者而言，RDD可以看作是Spark的一个对象，它本身运行于内存中，如读文件是一个RDD，对文件计算是一个RDD，结果集也是一个RDD ，不同的分片、数据之间的依赖、key-value类型的map数据都可以看做RDD。

　　主要分为三部分：创建RDD对象，DAG调度器创建执行计划，Task调度器分配任务并调度Worker开始运行。

　　SparkContext(RDD相关操作)→通过(提交作业)→(遍历RDD拆分stage→生成作业)DAGScheduler→通过（提交任务集）→任务调度管理(TaskScheduler)→通过（按照资源获取任务)→任务调度管理(TaskSetManager)

　　Transformation返回值还是一个RDD。它使用了链式调用的设计模式，对一个RDD进行计算后，变换成另外一个RDD，然后这个RDD又可以进行另外一次转换。这个过程是分布式的。

　　Action返回值不是一个RDD。它要么是一个Scala的普通集合，要么是一个值，要么是空，最终或返回到Driver程序，或把RDD写入到文件系统中

　　转换(Transformations)(如：map, filter, groupBy, join等)，Transformations操作是Lazy的，也就是说从一个RDD转换生成另一个RDD的操作不是马上执行，Spark在遇到Transformations操作时只会记录需要这样的操作，并不会去执行，需要等到有Actions操作的时候才会真正启动计算过程进行计算。

　　操作(Actions)(如：count, collect, save等)，Actions操作会返回结果或把RDD数据写到存储系统中。Actions是触发Spark启动计算的动因。

　　它们本质区别是：Transformation返回值还是一个RDD。它使用了链式调用的设计模式，对一个RDD进行计算后，变换成另外一个RDD，然后这个RDD又可以进行另外一次转换。这个过程是分布式的。Action返回值不是一个RDD。它要么是一个Scala的普通集合，要么是一个值，要么是空，最终或返回到Driver程序，或把RDD写入到文件系统中。关于这两个动作，在Spark开发指南中会有就进一步的详细介绍，它们是基于Spark开发的核心。

　　RDD基础

1. Spark中的RDD就是一个不可变的分布式对象集合。每个RDD都被分为多个分区，这些分区运行在集群的不同节点上。创建RDD的方法有两种：一种是读取一个外部数据集；一种是在群东程序里分发驱动器程序中的对象集合，不如刚才的示例，读取文本文件作为一个字符串的RDD的示例。

2. 创建出来后，RDD支持两种类型的操作:转化操作和行动操作

   　　转化操作会由一个RDD生成一个新的RDD。（比如刚才的根据谓词筛选）

   　　行动操作会对RDD计算出一个结果，并把结果返回到驱动器程序中，或把结果存储到外部存储系统（比如HDFS）中。比如first()操作就是一个行动操作，会返回RDD的第一个元素。

   　　注：转化操作与行动操作的区别在于Spark计算RDD的方式不同。虽然你可以在任何时候定义一个新的RDD，但Spark只会惰性计算这些RDD。它们只有第一个在一个行动操作中用到时，才会真正的计算。之所以这样设计，是因为比如刚才调用sc.textFile(...)时就把文件中的所有行都读取并存储起来，就会消耗很多存储空间，而我们马上又要筛选掉其中的很多数据。

   　　这里还需要注意的一点是，spark会在你每次对它们进行行动操作时重新计算。如果想在多个行动操作中重用同一个RDD，那么可以使用RDD.persist()或RDD.collect()让Spark把这个RDD缓存下来。（可以是内存，也可以是磁盘)

3. Spark会使用谱系图来记录这些不同RDD之间的依赖关系，Spark需要用这些信息来按需计算每个RDD，也可以依靠谱系图在持久化的RDD丢失部分数据时用来恢复所丢失的数据。(如下图，过滤errorsRDD与warningsRDD,最终调用union()函数)

   　　

　　RDD计算方式

　　RDD的宽窄依赖

　　窄依赖 (narrowdependencies) 和宽依赖 (widedependencies) 。窄依赖是指 父 RDD 的每个分区都只被子 RDD 的一个分区所使用 。相应的，那么宽依赖就是指父 RDD 的分区被多个子 RDD 的分区所依赖。例如， map 就是一种窄依赖，而 join 则会导致宽依赖

　　这种划分有两个用处。首先，窄依赖支持在一个结点上管道化执行。例如基于一对一的关系，可以在 filter 之后执行 map 。其次，窄依赖支持更高效的故障还原。因为对于窄依赖，只有丢失的父 RDD 的分区需要重新计算。而对于宽依赖，一个结点的故障可能导致来自所有父 RDD 的分区丢失，因此就需要完全重新执行。因此对于宽依赖，Spark 会在持有各个父分区的结点上，将中间数据持久化来简化故障还原，就像 MapReduce 会持久化 map 的输出一样。

　　SparkExample

　　步骤 1 ：创建 RDD 。上面的例子除去最后一个 collect 是个动作，不会创建 RDD 之外，前面四个转换都会创建出新的 RDD 。因此第一步就是创建好所有 RDD( 内部的五项信息 ) 。

　　步骤 2 ：创建执行计划。Spark 会尽可能地管道化，并基于是否要重新组织数据来划分 阶段 (stage) ，例如本例中的 groupBy() 转换就会将整个执行计划划分成两阶段执行。最终会产生一个 DAG(directedacyclic graph ，有向无环图 ) 作为逻辑执行计划。

　　步骤 3 ：调度任务。 将各阶段划分成不同的 任务 (task) ，每个任务都是数据和计算的合体。在进行下一阶段前，当前阶段的所有任务都要执行完成。因为下一阶段的第一个转换一定是重新组织数据的，所以必须等当前阶段所有结果数据都计算出来了才能继续。

　　假设本例中的 hdfs://names 下有四个文件块，那么 HadoopRDD 中 partitions 就会有四个分区对应这四个块数据，同时 preferedLocations 会指明这四个块的最佳位置。现在，就可以创建出四个任务，并调度到合适的集群结点上。

　　Spark数据分区

1. Spark的特性是对数据集在节点间的分区进行控制。在分布式系统中，通讯的代价是巨大的，控制数据分布以获得最少的网络传输可以极大地提升整体性能。Spark程序可以通过控制RDD分区方式来减少通讯的开销。

2. Spark中所有的键值对RDD都可以进行分区。确保同一组的键出现在同一个节点上。比如，使用哈希分区将一个RDD分成了100个分区，此时键的哈希值对100取模的结果相同的记录会被放在一个节点上。

   　　（可使用partitionBy(newHashPartitioner(100)).persist()来构造100个分区)

3. Spark中的许多操作都引入了将数据根据键跨界点进行混洗的过程。(比如：join(),leftOuterJoin(),groupByKey(),reducebyKey()等)对于像reduceByKey()这样只作用于单个RDD的操作，运行在未分区的RDD上的时候会导致每个键的所有对应值都在每台机器上进行本地计算。

　　SparkSQL的shuffle过程

　　Spark SQL的核心是把已有的RDD，带上Schema信息，然后注册成类似sql里的”Table”，对其进行sql查询。这里面主要分两部分，一是生成SchemaRD，二是执行查询。

　　如果是spark-hive项目，那么读取metadata信息作为Schema、读取hdfs上数据的过程交给Hive完成，然后根据这俩部分生成SchemaRDD，在HiveContext下进行hql()查询。

　　SparkSQL结构化数据

1. 首先说一下ApacheHive，Hive可以在HDFS内或者在其他存储系统上存储多种格式的表。SparkSQL可以读取Hive支持的任何表。要把Spark SQL连接已有的hive上，需要提供Hive的配置文件。hive-site.xml文件复制到spark的conf文件夹下。再创建出HiveContext对象(sparksql的入口)，然后就可以使用HQL来对表进行查询，并以由行足证的RDD的形式拿到返回的数据。

2. 创建Hivecontext并查询数据

   　　importorg.apache.spark.sql.hive.HiveContext

   　　valhiveCtx = new org.apache.spark.sql.hive.HiveContext(sc)

   　　valrows = hiveCtx.sql(“SELECT name,age FROM users”)

   　　valfitstRow – rows.first()

   　　println(fitstRow.getSgtring(0)) //字段0是name字段

3. 通过jdbc连接外部数据源更新与加载

   　　Class.forName("com.mysql.jdbc.Driver")

   　　val conn =DriverManager.getConnection(mySQLUrl)

   　　val stat1 =conn.createStatement()

   　　stat1.execute("UPDATE CI_LABEL_INFO set DATA_STATUS_ID = 2 , DATA_DATE ='" + dataDate +"' where LABEL_ID in ("+allCreatedLabels.mkString(",")+")")

   　　stat1.close()

   　　//加载外部数据源数据到内存

   　　valDIM_COC_INDEX_MODEL_TABLE_CONF =sqlContext.jdbc(mySQLUrl,"DIM_COC_INDEX_MODEL_TABLE_CONF").cache()

   　　val targets =DIM_COC_INDEX_MODEL_TABLE_CONF.filter("TABLE_DATA_CYCLE ="+TABLE_DATA_CYCLE).collect

　　SparkSQL解析

　　首先说下传统数据库的解析，传统数据库的解析过程是按Rusult、Data Source、Operation的次序来解析的。传统数据库先将读入的SQL语句进行解析，分辨出SQL语句中哪些词是关键字（如select,from,where)，哪些是表达式，哪些是Projection，哪些是Data Source等等。进一步判断SQL语句是否规范，不规范就报错，规范则按照下一步过程绑定（Bind)。过程绑定是将SQL语句和数据库的数据字典(列,表,视图等）进行绑定，如果相关的Projection、Data Source等都存在，就表示这个SQL语句是可以执行的。在执行过程中，有时候甚至不需要读取物理表就可以返回结果，比如重新运行刚运行过的SQL语句，直接从数据库的缓冲池中获取返回结果。在数据库解析的过程中SQL语句时，将会把SQL语句转化成一个树形结构来进行处理，会形成一个或含有多个节点(TreeNode)的Tree,然后再后续的处理政对该Tree进行一系列的操作。

　　Spark SQL对SQL语句的处理和关系数据库对SQL语句的解析采用了类似的方法，首先会将SQL语句进行解析，然后形成一个Tree，后续如绑定、优化等处理过程都是对Tree的操作，而操作方法是采用Rule,通过模式匹配，对不同类型的节点采用不同的操作。SparkSQL有两个分支，sqlContext和hiveContext。sqlContext现在只支持SQL语法解析器（Catalyst)，hiveContext支持SQL语法和HiveContext语法解析器。

原文地址：http://mt.sohu.com/20160522/n450849016.shtml

spark中有partition的概念（和slice是同一个概念，在spark1.2中官网已经做出了说明），一般每个partition对应一个task。在我的测试过程中，如果没有设置spark.default.parallelism参数，spark计算出来的partition非常巨大，与我的cores非常不搭。我在两台机器上（8cores *2 +6g * 2）上，spark计算出来的partition达到2.8万个，也就是2.9万个tasks，每个task完成时间都是几毫秒或者零点几毫秒，执行起来非常缓慢。在我尝试设置了 spark.default.parallelism 后，任务数减少到10，执行一次计算过程从minute降到20second。

参数可以通过spark_home/conf/spark-default.conf配置文件设置。

eg.

spark.master                  spark://master:7077 

spark.default.parallelism     10 

spark.driver.memory           2g 

spark.serializer              org.apache.spark.serializer.KryoSerializer 

spark.sql.shuffle.partitions  50

下面是官网的相关描述：

from:http://spark.apache.org/docs/latest/configuration.html

from:http://spark.apache.org/docs/latest/tuning.html

Level of Parallelism

Clusters will not be fully utilized unless you set the level of parallelism for each operation high enough. Spark automatically sets the number of “map” tasks to run on each file according to its size (though you can control it through optional parameters to SparkContext.textFile, etc), and for distributed “reduce” operations, such as groupByKey and reduceByKey, it uses the largest parent RDD’s number of partitions. You can pass the level of parallelism as a second argument (see the spark.PairRDDFunctions documentation), or set the config propertyspark.default.parallelism to change the default. In general, we recommend 2-3 tasks per CPU core in your cluster.


原文地址：http://www.cnblogs.com/wrencai/p/4231966.html

1 归并排序（MergeSort）

归并排序最差运行时间是O(nlogn)，它是利用递归设计程序的典型例子。

归并排序的最基础的操作就是合并两个已经排好序的序列。

假设我们有一个没有排好序的序列，那么首先我们使用分割的办法将这个序列分割成一个一个已经排好序的子序列。然后再利用归并的方法将一个个的子序列合并成排序好的序列。分割和归并的过程可以看下面的图例。



从上图可以看出，我们首先把一个未排序的序列从中间分割成2部分，再把2部分分成4部分，依次分割下去，直到分割成一个一个的数据，再把这些数据两两归并到一起，使之有序，不停的归并，最后成为一个排好序的序列。

如何把两个已经排序好的子序列归并成一个排好序的序列呢？可以参看下面的方法。

假设我们有两个已经排序好的子序列。
序列A：1 23 34 65
序列B：2 13 14 87
那么可以按照下面的步骤将它们归并到一个序列中。

（1）首先设定一个新的数列C[8]。
（2）A[0]和B[0]比较，A[0] = 1，B[0] = 2，A[0] < B[0]，那么C[0] = 1
（3）A[1]和B[0]比较，A[1] = 23，B[0] = 2，A[1] > B[0]，那么C[1] = 2
（4）A[1]和B[1]比较，A[1] = 23，B[1] = 13，A[1] > B[1]，那么C[2] = 13
（5）A[1]和B[2]比较，A[1] = 23，B[2] = 14，A[1] > B[2]，那么C[3] = 14
（6）A[1]和B[3]比较，A[1] = 23，B[3] = 87，A[1] < B[3]，那么C[4] = 23
（7）A[2]和B[3]比较，A[2] = 34，B[3] = 87，A[2] < B[3]，那么C[5] = 34
（8）A[3]和B[3]比较，A[3] = 65，B[3] = 87，A[3] < B[3]，那么C[6] = 65
（9）最后将B[3]复制到C中，那么C[7] = 87。归并完成。

如果我们清楚了上面的分割和归并过程，那么我们就可以用递归的方法得到归并算法的实现。

归并排序算法是一种O(nlogn)的算法。它的最差，平均，最好时间都是O(nlogn)。但是它需要额外的存储空间，这在某些内存紧张的机器上会受到限制。

归并算法是又分割和归并两部分组成的。对于分割部分，如果我们使用二分查找的话，时间是O(logn)，在最后归并的时候，时间是O(n)，所以总的时间是O(nlogn)。

2 堆排序（HeapSort）

堆排序属于百万俱乐部的成员。它特别适合超大数据量（百万条记录以上）的排序。因为它并不使用递归（因为超大数据量的递归可能会导致堆栈溢出），而且它的时间也是O(nlogn)。还有它并不需要大量的额外存储空间。

堆排序的思路是:

(1)将原始未排序的数据建成一个堆。
(2)建成堆以后，最大值在堆顶，也就是第0个元素，这时候将第零个元素和最后一个元素交换。
(3)这时候将从0到倒数第二个元素的所有数据当成一个新的序列，建一个新的堆，再次交换第一个和最后一个元素，依次类推，就可以将所有元素排序完毕。

建立堆的过程如下面的图所示:


堆排序的具体算法如下：

Eclipse 是一个集成开发环境，同时又是一个产品平台。这样有时候我们就会碰到一个问题，在开发Debug项目的时候没有问题，打包发布的时候就有问题了，这可如何是好？由于Debug时候和发布后plugin的ClassLoader机制不尽相同，出现这个问题的几率还有会有的。

Java 在这一点上为我们提供了方法，那就是远程Debug。远程Debug一般用于Web开发，或者客户端无法负载大规模的应用时才会运用到，所以Desktop developer 很少会涉及到这个概念。不过Eclipse 的产品平台却让我再次体会到了Java的强大。

关于Eclipse Remote Debug的文章，大家可以从此处学习：

http://www.ibm.com/developerworks/cn/opensource/os-eclipse-javadebug/index.html

Remote Debug 需要2方面的设置，一个是产品平台JVM启动参数的设置，需要让平台以远程Debug的模式启动。然后是在开发端监听产品平台的运行状态。当产品平台运行到断点代码时，Eclipse开发端就会进入Debug界面，像普通debug一样正常debug了。

网上关于Eclipse Fragment的资料比较少，引用Eclipse Wiki的一段话：

An Eclipse Fragment is a way of putting your own classes into the "class loader" of another package (basically, it's as though your class was actually in the other package). If you combine this ability of a Fragment with the notion of a plugin's classpath ordering, then you can force your class to load before a like-named class in the original package.

简而言之，Fragment可以利用Eclipse平台的ClassLoader机制替换原有Plugin的某些文件，以便实现自己的功能。如果仅仅是因为Plugin扩展，而需要替换自己项目的某些Plugin，可以参考文章：

http://wiki.eclipse.org/Steps_to_use_Fragments_to_patch_a_plug-in  （来之不易，感兴趣的可以收藏下）

读完这篇文章，你大概就应该能够了解到Fragment的实现分为两部分：Host 和 Patch。这两部分对应的plugin的manifest.mf文件都需要做特殊处理，对于Patch的build方式也要特殊处理，那就是build出来的plugin jar里放置的不是松散的class文件，而是一个特殊的jar文件，这个 jar 文件定义在Host plugin的manifest.mf 的classpath里面。

通常情况下，按照这篇文章的做法是没有问题的。但是在开发阶段，有一种情况可能无法实现class的替换。

我公司的项目是使用perforce进行项目版本控制的，但是perforce比较傻，有些重要的功能没有实现，而又很关键，因此我想自己针对perforce的eclipse plugin做一个fragment，添加自己想要的功能。但是这个plugin没有source code，而我自己的hack也是反编译class文件进行的。所以在我的work space里，并没有Host plugin的 project。结果按照这篇文章的做法，始终不能在workbench debug的状态下，正确load我hack过的class。因为在代码模式下面是可以正确load的，而现在没有代码，在数次检验无果之后，只能针对ClassLoader去思考了。Host文件里要求一个jar文件，我就用PDE 将 fragment export出来，把Fragment plugin jar 包里包含的那个 jar 文件解压出来，放到 patch project 里，然后重新Debug， OK，这次果然没问题了。一个小小的Class Loader问题，真的能够要人命呀……这应当算是Eclipse的一个bug吧，除非是对一个Plugin进行hack，否则一般也不会碰到这种情况。普通的项目开发，肯定会包含Host Plugin的Project。

我的经历权且当做饭后谈资，不足为虑。我这儿想说的是Fragment机制非常好用，也易于Plugin扩展。比如你的项目分为Open Source 和 Commercial 2种的话， Commercial 部分也可以通过Fragment来实现，不一定需要走Extension Point路线。由于网上相关文章不多，还需要自己多多研究，了解其机制。

Have you tried running your application elevated? (Right Click->Run As Administrator) If this doesn't work try applying an XP SP2 Compatibility shim from the Compatibility Tab in the properties dialog. (Right Click->Properties | Compatibility).

Let me know if this works.

Thanks!

沉寂了一段时间，现在继续SWT Win32 Extension的开发，说实话，最近的进展挺失败的。Black Glossy效果我发现在某些机器上的显示效果非常的卡，我自己的机器却没有任何问题。另外就是我最近在XP下实现了Window Mixer API，用来管理系统声音。Win98，2000，XP都没有问题，结果Vista让我郁闷了，Vista居然取消了Mixer，我哭呀。以下是微软员工给出的答案：

That's because the mixer APIs are virtualized on Windows Vista - you don't get to see the real audio hardware by default, only a virtualized version.  We did this because the vast majority of applications that used the mixer APIs were using them to control their own volume, which is quite rude (it says "I own the box, no other sounds on the system matter").

 You have two choices.  The first is to run your application in XP compatibility mode, in which case you'll be able to access the real audio hardware (please note: you'll see exactly what the hardware provides, which may lead to surprising results).

 The other choice is to use the new Vista audio engine APIs.  either the IAudioEndpointVolume API which allows you access to the master volume for each of the audio endpoints on the machine.  If you really need to access the actual audio controls the IDeviceTopology interface will allow you direct access to the various controls on the audio hardware.

通过打开Birt透视图，然后Reset至缺省的Layout，我们能够看到基本的一些View和一个主要的报表可视化编辑器。

先来说一下View，Birt主要的View包含7块：

左上角包含3个视图，Palette，Data Explorer和Resource Explorer，Palette里放置了报表常用的可视化组件，直接将这些组件拖到报表设计器的时候，这些组件并没有作特殊的初始化处理，而从Data Explorer里向设计器拖入一个Dataset会自动生成一个Table，拖入一个Cube会生成一个Crosstab，拖入一个Dataset Column会生成一个DataItem。Data Explorer主要是用来管理和显示数据源。Resource Explorer 老版本里是Library Explorer，新版本则变更为了Resource Explorer，用来特别显示Library，CSS文件，其他文件则不进行特殊处理。

左下角有2个视图，包含Navigator视图和Online视图，Navigator视图是用来建立Birt项目用的，如果是Birt Rcp版本，我们则看不到这个视图，这是IDE版本专有的一个视图，在Rcp版本里没有Project这个概念，直接以文件的形式进行管理。Outline是Birt里较为重要的视图，所有的报表部件都会在这个View里显示并会随着报表的变化实时刷新。

右下角包含了Property Editor 和 Problems两个视图， Property Editor 用来编辑每个可视化报表元素的属性，一般比较常用的属性都会在前几个Tab页里，但是有些属性前几个Tab页里都没有，这时候需要选择Advanced这个Tab页，它里面包含了这个元素所有可用的属性，如果连这儿也没有，那么说明该元素不存在你想要的属性。Problems视图则用来显示报表收集到的一些问题，如果报表校验的时候发生错误，会在此处显示出来。

以上的那些视图属于缺省视图，但还有几个视图也比较有用，一个是Error log视图，一个是Example视图。Error log视图主要是开发用的，当你使用Birt进行二次开发的时候，难免会碰到一些bug，当你感觉有问题的时候，不妨打开error log视图，只要Birt捕捉到了异常，一般都会显示在这个视图里。而Example视图里提供了各种各样的视图，可以Open 和 Save， Open的时候会自动帮你在workspace里建立一个项目，以便你浏览该项目文件。Save则是把这个Example保存到本地某个目录。

说完视图，再来看看Birt可视化的报表设计器，这个设计器包含了五个部分：Layout，Master Page，Script，XML Source，Preview。

Layout为设计器的主要部分，只要通过可视化的拖拽，一个报表就会被自动生成出来，当然要想灵活运用报表设计器，就必须对各个组件的属性了如指掌，Birt提供了丰富灵活的属性供用户选择。MasterPage主要用来设置页眉页脚，以及打印显示之类的功能。Script页面，当你在Layout页面里选中一个元素之后，切换到Script页面，就可以对这个元素进行脚本编码，主要用来监听各种事件，使用Javascript，在采用Web显示里，这些脚本会生效。XML Source则是将这张报表背后的XML source显示出来，用户如果觉得自己对Birt很熟，可以直接在这儿手工修改代码。Preview则是预览Birt报表，Birt会启动Tomcat显示Web运行效果。

基本上Birt还是比较强大的，基本的功能一应俱全。可能你会发现缺少一些更高级花哨的功能，比如flash之类的，其实怎么说呢，不是Birt没有，而是开源版的没有，这个功能在Birt商业版里，可以在 http://www.actuatechina.com/download.php 下载专业版试用。如同IBM，这是这类公司特有的策略，免费上面做收费。喜欢的话，可以试一下专业版，呵呵，可惜网上找不到破解版。

Eclipse3.4马上就要Release了，相信Eclipse的fans都已经开始翘首以待，望穿秋水了。不过现在的RC版本用得很不爽呀，性能非常差，Eclipse的惯例就是最后一个月的工作基本上就是对性能做优化，以达到最佳使用效果。

随着Plugin的增多，Eclipse采用了特殊的策略，增加了一个子目录dropins，用来放用户新增加的plugin，而原有的plugins目录，则基本用于系统基本功能，2者的区别就是，前者可以任意添加删除，后者则基本上是一个ReadOnly的状态，添加了就不能再作修改了，Eclipse会将每一个添加的plugin记录下来，以后启动就不再检查这些plugin了。

不过对于我来说，我一直都习惯于使用plugins目录，下了一个插件直接解压，就直接覆盖安装到plugins目录了，而且有一些plugin不支持dropins目录，必须在plugins目录下才能正常工作。不过一旦插件安装失败，想再reset就比较麻烦了。Eclipse不会自动恢复到初始安装状态，经过测试，找到了一个解决方案，用原始的eclipse的文件替代2个目录：configuration和p2目录。plugins文件位置记录在configuration\org.eclipse.equinox.simpleconfigurator\bundles.info里，p2目录里则记录了更多的初始化信息。要想Reset Eclipse3.4，这两个目录必须被恢复到初始化状态，然后就可以正常使用了。

就我所知，目前把Java程序编译成本机可执行程序的方法有两种，一种是GCJ，免费的，一种是Excelsior JET，商业的。我已经很久没有碰过GCJ了，因为当初用起来实在是非常麻烦，现在的版本如何，我不太清楚。我自己使用的是Excelsior JET，版本为3.7。有一点要注意的的是，Excelsior JET的后续版本好像已经不支持这个功能了，3.7是我所知的最后一个版本，能支持当前所有的Win32平台和早期的Linux（当前比较流行的Ubuntu不支持，因为内核版本过高，不过企业版Redhat没有问题）。不过我是很久以前从0day当下来的，由于0day仓储只保留一年，故现在已经找不到了，我自己的机器上也没有安装包了（有一次大意之下，把整个Download目录全给删掉了，事后悔之晚矣）。

Excelsior JET无非就是用自己的Runtime来代替JRE，只是比JRE更加灵活，根据Java程序具体的依赖来生成对应的Runtime。其实这个Runtime也挺大的，通常10M左右，不过比起JRE，那要小很多了。SWT Extension上的那个例子只有6M，是因为我用ASPack把所有的DLL文件全部压缩过了，体积小了一半。

就我的感觉，Excelsior JET比GCJ更加灵活，也更好用，毕竟是商业版的东西，它的网站上曾经有例子将Eclipse 3.0编译成本机程序，不过我当初照着例子试了一遍，没有成功。Excelsior JET的编译过程极为耗时，我上大学的时候，当时机器只有128M内存，编译了一天JRE也没有完成，后来找同学借了根256的内存，这才得以完成。

把JAVA代码编译成本机程序的弊端也是有的，那意味着你将无法在线升级，GCJ也许可以，但是Excelsior JET是绝对不行的，这是因为它最后一步要对所有DLL进行链接，如果更换了DLL文件，它会检测出来并报错。

各位看官如果哪位有兴趣，可以自行在网上查找Excelsior JET3.7或其他版本。由于安装包我自己也没有，故无法提供下载，见谅。

The idea is from DotnetMagic, I copied its style, but different implement methods. DotnetMagic uses shell self message circulation, but I use swt event listener. I want to implement the custom style menu for all platforms initially, but it's impossible. It has to use a lot of advanced OS funcitions. If I use pure swt public functions, I can't implement  some features. For example, if I click the menu, the window shell will be deactivated, I click window shell's titlebar, swt event manager doesn't send messages to me. I must use WND Message hook to deal these messages. So I have to add the feature into SWT Win32 Extension, but not a independent project.

Some beautiful snapshots:

Office 2003 Style Menu


VS 2005 Style Menu

Project Download: http://www.swtui.cn/downloads/org.eclipse.swt.win32.extension.zip
JNLP Online Demo: http://www.swtui.cn/jws/example.jnlp

If you don't have installed Java Runtime, you can access it via http://www.swtui.cn/downloads/org.eclipse.swt.win32.extension.example.independence_native.zip

Eclipse Plugin Update Site URL: http://www.swtui.cn/update

Add Flash Control to SWT Win32 Extension, now you can check out the latest code from CVS and run it.

Project Main Page: http://www.swtui.cn

cvs -d:pserver:anonymous@feeling.cvs.sourceforge.net:/cvsroot/feeling login

Flash Control Listener   


Flash Control Hook Interceptor

窗口是一个应用程序的门面，有一个好看的窗口，用户的评价自然也会大大提高，经过几天的努力，终于在SWT Win32 Extension中加入了自定义的Window Theme，当然目前只完成了一些基本的实现，高级实现依然有待于研究。

Windows XP Theme


Custom Theme

  目前已完成了任意SWT Shell wrapper，系统菜单管理，不规则边框的切边等功能，尚未完成的功能还有很多，比如窗口菜单。未来准备加入用户自定义Theme的接口，只要符合规范都可以进行自动切换。由于功能仍然还有很多地方尚未完成，暂时还没有提供打包下载，有兴趣的话，可以从项目CVS上Checkout出来看看效果。

新增了4个Low Level Hook：Mouse_LL，Keyboard_LL, JournalRecord，JournalPlayback。由于是Low Level Hook，因此Hook是不依赖于dll，所以可以直接将HookProc在Java程序中编写。这四个钩子都是全局的，而且都很有用处。Mouse_LL，Keyboard_LL，自不必说，用来监听鼠标和键盘的。Journal的2个Hook则是所谓的日志钩子，WH_JOURNALPLAYBACK Hook使应用程序可以插入消息到系统消息队列。可以使用这个Hook回放通过使用WH_JOURNALRECORD Hook记录下来的连续的鼠标和键盘事件。只要WH_JOURNALPLAYBACK Hook已经安装，正常的鼠标和键盘事件就是无效的。WH_JOURNALPLAYBACK Hook是全局Hook，它不能象线程特定Hook一样使用。WH_JOURNALPLAYBACK Hook返回超时值，这个值告诉系统在处理来自回放Hook当前消息之前需要等待多长时间（毫秒）。这就使Hook可以控制实时事件的回放。

基本上现在用SWT-Extension来实现这四个Hook还是很容易的，做了一下简单的数据封装和事件封装，而且加入了结合体对象和JNI的handle互相转换的函数。用来做C++的一些事情还是比较得心应手的。最新版本的Example提供了一个简单的系统Record/Playback例子，可以记录和回放系统事件。

Since 19th century, human has been changing the earth continuously. They began to use various energies to server themselves. The most important application is electricity. If the electric power is cutted, wo even couldn't do anything. Air conditioner, fridge, wash matchine, computer and oven all need electric power. We use coal,water power,wind,biology and nuclear power to generate electric power. Generally, when we convert a power to another power, the efficiency is not perfect, we will lose some energy. Most of the lost energy is changed as hot energy. So when we touch the machine used electric power, we can feel it's hot.

Except electric power, we also use another kind of power, that is chemical power. We can get it by burning coal and oil. This power is used broadly. For example, the car, the plane and some other traffic tools. But when we generate the chemical power, there will cause lots of waste gas. Some kind gases in the waste gas can let earth become a greenhouse. Then we generate a mass of hot energy but these greenhouse gases prevent it to run away to the universe. The hot energy stays at our planet, and the temperature becomes high little by little.

Now the global warming is obvious, the ice of the south earth pole is melting little by little, the drought and the hurricane appears more and more. Each person can feel the earth is warming now.

Now the big energy countries start to decrease the greenhouse gas releasing and increase the efficiency of power conversion.For example, we use water power, wind, nuclear power to generate electric power as much as possible, but not use coal and oil. Each people has the responsibility to protect our home.

　　中新网7月13日电 综合报道，一名犯有重罪的罗马尼亚犯人近日向上帝提出控诉，地方法院12日对此予以驳回。

　　据悉，该名罗马尼亚犯人是2005年7月因受贿罪被捕的。他被判处入狱20年，在狱中更是抱怨上帝对他不公，在2006年甚至向地方法院控告上帝。

　　这名犯人说，早在他出生时在教堂受洗的时候就与上帝订立了契约，让他能够快乐生活，但现在“上帝打破了这份契约，因此有必要控告他”。

　　地方法院12日发布的判决书称，“由于无法获知上帝的家庭住址，因此无法向其传达法院的意见，”并最终对囚犯的要求予以驳回。

大概因为开发环境是英文的缘故吧，做了这么久时间的SWT-Extension，直到今天才发现存取中文都是乱码。不过显而易见的是Test Case做得太少了，毕竟是自己的开源项目，在上面投入的是兴趣，而不是精力。虽然一直在弄，但动辄就几个月没有commit，而且到现在也没有一个正式版发布。本来可以积累一点user的，现在估计也都跑光了。

下面这段代码用于JNI中jstring和Window char之间转换：

JNI 用起来实在太麻烦了，比我做Java开发效率实在低得太多，各种各样的类型转换，我头都晕了…… 另外JNI好像是SUN中国研究院搞的，怎么就没有提供一个好的中文解决方案？

Eclipse SWT Extension snapshot：

想真正领悟这首曲子感人的地方，就不能不去玩《英雄传说6》这个游戏。

星之所在口琴版（游戏中的音乐）：
 
下载地址：http://www.blogjava.net/Files/cnfree/xzszkqb.mp3

星之所在完整版：
 
下载地址：http://www.blogjava.net/Files/cnfree/xzszwzb.mp3

FC结局视频：

一个简单的Dataset Joint Example

一般来说，Eclipse插件开发用到GEF的机会并不是很多，大概也就是结构设计，数据管理，流程控制等应用罢了。看了一下网上的例子，大部分都是基于数据库管理的，我想这应该是因为数据库设计的Dataset Joint是程序开发最常见的吧。

GEF的一个简单Example可以参加GEF自带的例子Logic，功能非常强大，了解了Logic，就能够了解相应的GEF开发。在网上这方面的教程并不多，我也基本上没开，我个人始终认为看书不如看代码。当然我以前也没有接触过GEF，毕竟要完全掌握这个东西并非一日之功，要想在上面有所造诣不通过一个大型项目的加强是不可能的。上面的这个小东西也是我花了半个月，还请教了一些人帮忙debug才研究出来的，还是花费了相当功夫。

不过GEF是一套框架，上面的这个小东西，麻雀虽小，五脏俱全，而且基本上可以算一个不依赖于Eclipse平台的小应用程序。不过GEF(Ver 3.3)这个项目依赖于Eclipse OSGI，如果想完全独立于Eclipse，需要自己做一些小小的改变，也不算太麻烦。最后基本上SWT+JFACE+GEF基本上就可以自己做应用了。

独立于Eclipse的GEF简单教程可以参见：
http://www13.plala.or.jp/observe/GEF/GEF_StandAlone.html
http://www13.plala.or.jp/observe/GEF/GEF_Tool_StandAlone.html

日文写的，我看不懂，只看代码。

这里我只说几点：
1、如果面板需要滚动条，并且能够自由伸缩，显示的话，请选择ScrollingGraphicalViewer，相应的RootEditPart请选择ScalableFreeformRootEditPart。

2、GraphicalViewer是通过EditPartFactory拿到子EditPart的，有些类似于JFace TreeViewer的ContentProvider，根据特定的Element拿到对应的EditPart，不同于TreeViewer的是，GEF的getChildren方式是写在EditPart里的，每一个EditPart都要实现 protected List getModelChildren( ) 方法，而TreeViewer的getChilder是在ContentProvider内部实现的。因此EditPart更为灵活，因为EditPart还可以通过EditPartFactory拿到上下文环境，而TreeViewer ContentProvider脱离了Viewer本身，只能通过Model来取，这样当Model和Viewer不一致的时候，GEF游刃有余，而TreeViewer却举步维艰。

3、EditPart的FeedBack Figure的背景颜色是和它的背景取异或操作的，因次再拖动EditPart的时候，如果FeedBack Figure覆盖EditPart的时候，Figure的颜色很难看，解决这个问题的办法就是设置GraphicalViewer的背景颜色为白色。

4、希望EditPart能够拖动，需要实现getDragTracker( )方法：

5、刷新EditPart的显示需要覆写protected void refreshVisuals( )方法，当Model的模型改变，需要刷新View的时候可以通过事件监听来显示的调用该方法。

6、设置EditPart在父亲EditPart的位置调用( (GraphicalEditPart) getParent( ) ). setLayoutConstraint(EditPart arg0, IFigure arg1, Object arg2)方法。 

7、如果是XYLayoutEditPolicy，内部EditPart位置的改变会调用XYLayoutEditPolicy的protected Command createChangeConstraintCommand( EditPart child,
   Object constraint )方法，需要记录EditPart位置可以在这里进行。

8、EditPart的Selection事件需要注册SelectionEditPolicy，你可以针对不同的EditPart实现不同的SelectionEditPolicy。

9、内部有自由布局的EditPart需要注册LayoutEditPolicy的子类。而该EditPart的Figure需要设置对应的LayoutManager。

10、GraphicalViewer监听Key操作需要setKeyHandler(new KeyHandler(viewer))。

11、进行连接操作的源EditPart需要实现protected List getModelSourceConnections( )方法，目标EditPart需要实现protected List getModelTargetConnections( )方法，创建一个连接需要使用ConnectionDragCreationTool。连接图形的EditPart必须继承AbstractConnectionEditPart。实际上每个连接会被创建出2个EditPart，只有这2个EditPart的Model相等的时候，一个连接才会成立。

12、如果需要连接，需要注册GraphicalNodeEditPolicy，并且实现protected org.eclipse.gef.commands.Command getConnectionCompleteCommand(
   CreateConnectionRequest request )和protected org.eclipse.gef.commands.Command getConnectionCreateCommand(
   CreateConnectionRequest request )方法。注册代码：

 先写到这儿，慢慢再补。

Eclipse下的插件开发如果需要用到什么字体或其他的工具时，尽量避免使用AWT GraphicsEnvironment ，这会导致Vista Aero效果暂停工作。如果有需要得到Font字体列表的话，可以使用SWT的FontList拿到：

 1    public static String[] getSystemFontNames( Comparator comparator )
 2    {
 3        FontData[] fontDatas = (FontData [])Display.getCurrent( ).getFontList( null, false );
 4        SortedSet set = new TreeSet(comparator);
 5        for(int i=0;i<fontDatas.length;i++){
 6            set.add( fontDatas[i].getName( ) );
 7        }
 8        fontDatas = ( FontData [] )Display.getCurrent( ).getFontList( null, true );
 9        for(int i=0;i<fontDatas.length;i++){
10            set.add( fontDatas[i].getName( ));
11        }
12        String[] fonts = new String[set.size( )];
13        set.toArray( fonts );
14        return fonts;
15    }

/** *//**
 * Returns <code>FontData</code> objects which describe
 * the fonts that match the given arguments. If the
 * <code>faceName</code> is null, all fonts will be returned.
 *
 * @param faceName the name of the font to look for, or null
 * @param scalable if true only scalable fonts are returned, otherwise only non-scalable fonts are returned.
 * @return the matching font data
 *
 * @exception SWTException <ul>
 *    <li>ERROR_DEVICE_DISPOSED - if the receiver has been disposed</li>
 * </ul>
 */
public FontData [] getFontList (String faceName, boolean scalable)

Realease在即，而Mock-up却还在更新，这就是我目前的境况。要命的却是还有一个从来没有涉猎过的领域摆在我面前，那就是GEF，Eclilpse最复杂的框架之一。我一向推崇简单就是美，Java搞了这么多年，但是越搞越复杂，Eclipse也是如此。最令人推崇的Eclipse开发版本还是2.1.2，相对于2.1版本，3.2简直就是蜗牛。而我们却要无休止紧跟着Eclipse的脚步，它走一步，我们就要前进一步。我以前甚至不屑于使用JFace，更何况这个传说中的GEF，玩玩还可以，使用它那还不是要我的小命。

不过框架自有框架的好处，如果能够熟练使用，可以少写很多代码，因此能够使项目速成。我现在要做的是一个数据库表索引关联编辑器，功能其实不多，但是麻雀虽小，五脏俱全，一个完完整整地GEF应用。拖拉暂且不说，是GEF的基本应用，最麻烦的其实还是各个表初始化的布局，需要写一个自己的布局管理器。如果要自己从头写而不用GEF，估计一个月怎么也够呛。现在采用GEF，我想半个月就差不多了，不过学习成本昂贵呀。我得承认我严重低估了GEF的复杂度，到目前为止，我已经研究了三四天，才刚刚能够进行简单应用。看书，找资料，研究框架的构架，都是扯淡，看了八进制的文章，仍旧是一头雾水。看别人的容易，变成自己的就太难了，什么事情都还要靠自己领悟才行。

还好我是多条路并行采用了。虽然我眼下的项目可以称得上是最复杂的GEF应用之一（源代码打ZIP包都快30M了），但身边能用GEF开发的高手却屈指可数，Manager估计早就想让我搞这个玩意了。JFace我都是速成的，现在已经很熟练了。顺便说一下TreeViewer这个东西，它的显示逻辑全部都是通过Provider来实现的。显示的时候就会通过getChildren从上往下走，找一个节点的时候则是通过getParent从下往上走，现在就有一个问题了，如果我setInput的Model的内部逻辑和我要显示的外部逻辑相差比较大，那么如何实现？在这儿适配器是不能工作的，因为沟通是双方的，适配器则是单方的。如果用一个虚节点来代替Model实际上没有的显示逻辑，那么虚节点的儿子（一个Model实体）通过getParent是找不到那个虚节点的，它只知道自己的实体父亲。封装所有的Model也是不可取的，要不要Model干什么。我想TreeViewer碰到这样的应用就会无能为力了。

现在说一下框架速成大法：
1、问，自然是问高手了。高手会一针见血的把问题找出来，并能告诉你框架的整体结构，通过现场演示，能够让你的脑子对框架有一个整体的认识，这可比看文章接受的快多了。我同事已经被我折磨了一个礼拜了。在问和解答的过程中，大家都能够发现自己的不足，如果两个人在一起编码，又是一个结对编程的过程，这个时候2个人的脑子思维都会很清晰。
2、Debug，找一个和自己相近的应用。每一个框架，作者一般都会提供一些例子，而且这些例子虽然简单，却基本上包含了框架的方方面面。要想应用框架，最终是需要自己写代码的，代码在哪儿找，就是作者的例子里找。看看例子里有多少应用是自己需要的，找到合适的地方Debug一把，一步一步地跟下去，很快你就能够通过堆栈信息以及源码了解应用的整个步骤，然后用Copy大法，一个自己的应用就创建出来了。

当然第二点依赖于第一点，初学者是很难寻找合适的断点进行跟踪，所以需要找个高手过来，让他来跟，他演示的过程就是自己学习的过程。有了自己的第一桶金，后面的路就已经很平坦了。一个人对于未知领域的恐惧并不是怕自己不能掌握，而是不知道自己要花多长时间来掌握它。通过3天的速成，虽然对GEF的整体了解是管中窥豹，但我已经心里非常有底了。现在已经能够把Tabel以及里面的Column画出来，而且已经实现了布局，拖拽等基本事件，剩下需要研究的东西不会太多，够用就行。技术这个东西，不怕不了解，就怕不会学习，很多时候，等到要用到的时候再学也不会迟，关键是要掌握正确的学习方法。

传说中凤凰每隔500年要投入火中以求得新生。有一种恒星在其「临死亡」的剎那，将发生激烈的爆炸，如迴光返照般放出极耀眼的光芒。星球毁灭了自己，却也同时触发了新恒星的诞生。这就是超新星，天上的火凤凰。

在宇宙中，恒星的分类是按照它们的死亡的方式，一类象我们太阳这种，最终安静的成为白矮星，另一类是比太阳大8倍以上的恒星，它们的死亡是爆炸。恒星越大，寿命就急剧的缩短，质量差3倍，寿命就差750倍，也就是说，一个比我们的太阳大3倍的恒星，它的寿命就只有1300万年，所以，生命的进化是不可能托付给大恒星的。但是，宇宙的物质的丰富和流动，却全靠它们。

宇宙在过去有过一个非常单调的开端，只有氢元素和少量的氦元素，然而宇宙在成长，而成长的标志就是重元素的增加，这种增加使宇宙越来越丰富，宇宙的所有的奇迹，都是在有了完整的元素制造之后。而制造元素，就是把氢元素以不同的数目聚合，而要完成所有元素的聚合的场所，就是拥有巨大引力的大恒星。从丰富物质角度来说，大恒星是宇宙中的精品，它们不仅能生产所有的元素，而且由于恒星越大，寿命越短，因此周期也短，所以，恒星的巨无霸是宇宙制造元素效率最高的工厂。不过，宇宙中最大的恒星的质量极限是一百个太阳，如果再大，就会因为自身的核反应过猛而解体。

船底座海山二星(Eta Carinae)可能即将爆炸

引力制造元素，但也束缚元素，小恒星大约能制造出十来种元素，但这些元素最终不能在宇宙中流动。大恒星能制造更多的元素，一般超过太阳质量 8倍以上的恒星就能使聚变一往无前，其核心达到几十亿度的高温不断的创造不可思议的聚变，每次聚变所产生的能量都使恒星膨胀得更大一些，于是它就象洋葱一样形成令人吃惊的多层核聚变的巨大空间，这个空间可以达到一百亿公里，装下整个的太阳系。在聚变的深入的过程中，恒星变得越来越危险了，因为元素越重，聚变提供的能量越少，而巨大的恒星又必须靠不断释放的核能支撑。然而，当聚变到排列第26位的铁元素时，摇摇欲坠的恒星遭受到最致命的破坏──因为铁元素的结构极其稳定，它在聚变时不释放能量，于是，巨大而膨胀的恒星将会因核心失去支撑而倒塌。

因此而恒星粉碎性的爆炸，能量的狂飙扫荡天庭，这就是超新星爆发。此刻它的能量相当于正常恒星的一百亿倍，在这个超能量的瞬间，宇宙中所有的元素都被聚变出来了。象金银首饰这种重元素，就是在超新星的爆炸中诞生的，当我们佩戴它们时，要记住宇宙制造高档产品确实是代价很高，它需要报废一颗至少比太阳大8倍以上的恒星，才能使我们披金戴银。

超新星发生在一个恒星即将结束生命时，亦即在红巨星阶段，核心燃料快要消耗殆尽时，恒星会因为没有额外的燃料而自行崩溃。如果恒星的质量够大，恒星内部的内爆层会在接触核心时反弹，产生巨大的爆裂，爆炸所产生的震波会将恒星的所有物质射入太空中。

我们的太阳将会在50亿年后衰亡，因它内部提供予核融合的燃料终於消耗殆尽。到时太阳会变成一个主要由碳和氧组成、密度高而「寒冷」的白矮星。 另一方面，一颗比太阳更重的恒星的中心温度更高。这些巨大星体会在经过一次壮观的爆炸后灭亡，这过程称为「超新星爆炸」。爆炸释出的能量非常巨大，超新星爆炸的光度可能相当於1,000亿万颗恒星同时发出的光芒。

超新星的爆发是在约一秒钟之内完成的。由於高能辐射与爆炸拋射出来的恒星大气相互作用，使得超新星也可能有X射线等辐射。例如SN1987A在爆炸后100多天才被Ginga卫星所探测到它的X射线。而光学波段的突然增亮，首先是由膨胀大气引起的，后来则由Ni56等同位素的衰变提供能量，使得光度下降较为缓慢。图五中给出了典型的超新星光变曲线。超新星爆发的高速拋射物与周围介质相互作用形成的激波引发出电波辐射，而对星周尘埃的加热则可以产生红外辐射。但这些只有周围有稠密的星际物质的II型或Ib、Ic型超新星才能观测得到。

在不到一秒钟时间内释放出10⁵¹~10⁵³erg的能量（相当於90个太阳在其一生所释放能量之总和）的天体，它的前身星是什么？产生如此巨大能量的机制是什么？这些是天文学家首先面临的问题。

首先我们来看看Ia型超新星。在它的光谱中缺少氢谱线，而且根据统计它在不同类型的星系中都有可能出现。据此天文学家提出了Ia型超新星是密近双星演化到晚期的终极结果的想法。设想有一密近双星系统，其两个成员星的质量均小於8M¤ ，其中质量大的那一个演化得比较快，在其核心燃烧完氢后，接著燃烧氦，而变成中心为碳和氧的白矮星。这时初始质量较小的那颗成员星的物质就被它吸积。假如物质转移速度小於每年10^-8M¤ 的话，在白矮星周围形成氢壳，当它达到核融合点火的温度时，其表面就产生核融合点火爆发，这就是新星爆发的现象，其规模比超新星要小得多。

当转移速率在每年10^-6M¤ ~10^-8M¤ 之间的话，表面同样会产生核融合，而形成氦，氦形成碳，逐步使其碳核心质量增加，直到钱氏 (Chandrasekhar) 极限的1.4 M¤ 。其中心密度可达到3×10⁹g/cm³，而且中心达到碳点火的温度。碳被点燃，并且融合过程从中心往外迅速传播，在不到一秒钟之内传到白矮星的最外层。其爆炸将产生10⁵³erg的能量，而且爆炸规模巨大无比，以至於将这颗白矮星完全「炸飞」了。由於白矮星中的氢已经燃烧殆尽，所以它的光谱中没有氢线，同时因为它是一种「老年」的恒星，因此会出现在不同的星系之中。

II型的超新星则不同。它的光谱中以氢线为主，而且往往出现在螺旋星系的旋臂上，在那裡往往有恒星正在形成。一个目前被广泛接受的II型超新星爆炸的模型是：一个大质量的恒星（质量大过10M¤ ），在其最初的3000万年甚至更短的时间内，它的核心首先是氢融合为氦，然后氦变为碳和氧，碳变为氖和镁，氧和镁变为硅和硫，直到最终硅和硫融合为铁属元素。上述每种融合过程都释放出大量的能量，维持著恒星的「生命」，而且其核心变得愈来愈密，温度则愈来愈高，以致能够抵抗恒星引力的收缩。但到了核心变为铁心后，由於铁属元素的核束缚能最小，融合无法继续为恒星提供能量，反而要吸收能量。引力收缩就开始，中心的密度和温度继续增大，到 10¹⁰K和10¹⁰g/cm³时，电子就被压到原子核内而形成富含中子的同位素，而高能辐射又将原子核「撕」成a粒子。这两个过程都要吸收能量，使得重力塌缩变得更快。当中心密度超过2.7×10¹⁴g/cm³时，塌缩不能继续，产生反弹而引发超新星爆发。它将外层核融合的剩余物，包括最外层的氢向外拋，而留下一个核核心，也就是中子星。所以在光谱中有强的氢线，同时因为大质量恒星（寿命短；因此我们看到的都是不久前形成的）是和恒星形成区相关的，所以他们往往出现在螺旋星系的旋臂上。至於Ib和Ic型超新星，目前也认为是一种称为「沃夫─瑞叶星」 (Wolf-Rayet stars; W-R stars) 的大质量恒星演化到晚期的结果。由於W-R星有大规模的恒星风，质量流失很大，因此表层已失去了氢甚至氦，所以其光谱中没有氢线(或甚至於氦线)。

超新星1987A(1987年发现的第一个超新星)是近代爆炸的超新星中，最靠近地球的一个，位於169,000光年外(我们银河系的伴星系)的大麦哲伦星系。它也是自从克卜勒在1604年於银河系中观测到超新星以来最明亮的一个；同时是自1885年以来第一个肉眼看得见的超新星。那原来是一个蓝超巨星的位置，其质量约为太阳的20倍。天文学家相信这个星球先是膨胀成红超巨星，在吹开一部份的星球体后，经过收缩与再加热，成为一个蓝超巨星。之后，在短短不到一秒钟，整个星球的中心突然就崩垮了，一阵微中子将中心加热至100亿度。这个过程引爆出震波，将此星球炸散掉，并喷出大量的微中子到太空中。

直至1987年5月，国际紫外线探索号已在超新星的碎片中发现了许多化学元素，显示出这个始祖星球已经过了红巨星期，证实了原来的理论。到了7月，一个日本的人造卫星和德国的望远镜都侦测到从碎片中发射出来的X光线。自8月到11月，更有其他的研究团队侦测到高能的伽玛射线，这是在即将死去的星球中心出现核反应所产生的放射性元素，衰变时所放射出来的。此资料证实了大家所相信的理论，即超新星会产生组成地球大部分的重化学元素。

 
超新星1987A影像

哈伯太空望远镜先进巡天相机 (ACS) 所拍摄的超新星1987A影像，在其四周包围著一串如珍珠项链般的气体环，这些「珍珠」其实是超新星爆发所产生的冲击波，以超过每小时6千万公里的速度追撞上了“恒星在爆炸前数万年所喷出, 膨胀速度较慢的气体”。爆震波追上了这个环，由於碰撞作用，气体受到衝击，温度升高到了数百万至1千万度，因而发出了红外辐射。环中的尘埃是在星风中形成的，而不是在超新星爆发中形成的。光环直径约一光年，光环中央的长椭圆形黯淡星体就是超新星残骸，主要受超新星爆炸时所产生放射性元素鈦 44 衰变辐射加热而发光，未来数十年都还将持续发光。天文学家在 1996 年首次在 SN 1987A 的外圈发现一个亮点，现在则可看出数十个。天文学家推测，未来几年中还将陆续出现更多类似的光点，这些亮点的光会将周围照亮，天文学家届时将可推测超新星爆炸前是如何喷发物质至太空中。当震波逐渐往外移时，产生的紫外线和X射线辐射将加热更多周围过去所喷出的物质。就如同参与钱卓研究计画的科学家理查、麦克雷所说：「超新星1987A将会点亮它自己的过去」。

超新星的爆炸使物质摆脱了引力的束缚，但铁元素的核却坠入引力的深渊，巨大的塌方把电子都压进了质子，于是质子全变成了中子，而中子之间没有电磁力的排斥，原子核可以相互紧紧的挨在一起，这就形成了最致密的物质──中子星，它一立方厘米的质量能达到十亿吨，而它引力强大到让光都要成抛物线才能挣脱。把一个几百万公里直径的物体压缩成只有30公里的直径，就是中子星，而同时被压缩的还有磁场，这是一个匪夷所思的超高能核电站，它可以把表面附着的电子象高压水柱一样喷射出去，它们所具有强烈的方向性可以成为宇宙定位的灯塔。十几年前，人类寻访外星生命的一艘飞行器上所携带的人类的自我介绍，就是用多颗中子星为地球做定位。一些大的超新星爆炸之后，将会产生引力的奇迹──黑洞，巨大的引力把物质化为无形，因为连光都要被吸回它的表面，如果把地球压缩成一个核桃，就是黑洞，因为地球其实是一个强力和电磁力支撑的物体，如果把原子核都毁灭了，地球就将成为几厘米直径的浓缩引力的载体，黑洞的存在已经被证实。

超新星是宇宙中4种力配合的杰作，它们共同建造一个巨大的原子锅炉，然后以锅炉的崩溃所激发的能量完成所有元素的制造，并且在最后的瞬间把元素都彻底的抛洒出去，正因为有这种抛洒，物质才有可能演化，否则，就象有钱不去投资，再多的财富也将没有任何意义。恒星以自身的毁灭造就了宇宙中最伟大的新生。 在超新星的物质弥漫之后，引力将会再次把这些物质凝聚成天体，大的塌缩成恒星，小的形成行星，如果这颗恒星有较长的寿命，而它的周围有若干合适的行星围绕，那么这个长寿的核能和比较靠近它的行星上丰富的宇宙元素的光和热交流，就可能最终产生宇宙中最复杂的物质形态──生命。

1、  程序员不擅长交际，但擅长说服别人。

2、  要习惯阅读别人的代码。

3、  通过阅读程序员的代码，主管可以从中了解程序员的能力，工作是否出色。

4、  在软件维护的过程中，被阅读最多的代码往往不是最好的代码，而是最需要重构的代码。

5、  如果程序根本无法正常运转，对其效率，适应性以及生产成本的评价就毫无意义。

6、  什么是程序中的毛病，在很大程度上取决于人的观点。如果这种毛病出现在你的程序中，你几乎不可能会认为它是毛病。

7、  在考虑一系列的程序的开发工作效果时，需要衡量开发时间的方差，而不是只考虑平均值。一般的开发主管宁愿先做 12 个月的计划，然后花 12 个月完成，也不愿做 6 个月的计划，却花了 9 个月。真正困扰人们的并非预先估计的平均开发时间，而是实际消耗时间的标准偏差。大多数人愿意每天花 10 分钟坐车，也不愿 4 天花 1 分钟， 1 天花 26 分钟。尽管就平均时间而言，后者花费更少，只需要 6 分钟。但是由于某次无法预测的长时间等待而将计划打乱，这点好处无法弥补损失。

8、  Fisher 基本定理：一个系统对某个特定环境的适应性越强，它适应新环境的能力也就越弱。为保证程序的效率，就必须考虑要解决问题的特殊条件。过分追求效率，只会降低适应性。但通常我们还是在二者之间做一取舍。至少，具备一种优点，要比哪种都没有强。

9、  衡量程序的真正效率，并不总能用运行时间来衡量。

10、 作为一个好程序，有一些重要的因素：该程序在多大程度上满足功能要求；该程序的开发是否按照计划完成，和计划的偏差幅度有多大；当条件改变时，是否能够修改，修改的成本有多大；程序的效率如何，为了弥补某一方面的低效率，是否牺牲了另一方面的高效率。

11、 主管根据什么来奖励程序员？在你的标准中是否存在相互矛盾的现象 ? 即快又好，还要易与重构，容易修改？

12、 在你的项目中，修改或者重构是否属于一项主要开支？

13、 即使一个计划不可靠，只要它是完成进度的唯一希望（尽管可能根本无法完成），程序员还是会采用它，你知道为什么吗 ?

14、 在进行某个项目的时候，你的脑子是否有一些明确的准则？或者是依照上级主管的看法？在项目的进行过程中，这些准则有无更改，或者你是否有办法让你的准则不被动摇？

15、 在编写程序时，你曾经有多少次想到它可能在未来会被人修改？反过来，在修改别人的程序时，你又曾经咒骂过几次？

16、 你是否因为追求“效率”，而延误了工作进度？反过来，是否因为要“赶时间完成”，而没有做到尽善尽美？

17、 在软件质量管理的过程中，软件性能的偏差使一个极其重要的方面。

18、 许多主管希望得到所有的东西，却不知道更重要的是应该通过明智的权衡，得到自己可能得到的最佳成果。

19、 爱因斯坦的名言：重要的是不要停止怀疑。如果不去进行尝试，我们永远不肯能成功。

20、 霍桑效应：因受到他人关注而带来提高或进步。关注手下工作的领导，将会取得更好的成绩。很多负责软件开发的主管，就是不愿意与属下并肩工作。

21、 最优秀的程序员同时也是那些最善于自省的。如果他们发现做错了什么，他们会对导致这个结果的思维过程（或物理过程）进行检讨；然后，他们会采取一些相应的措施，对这个过程进行调整。这种方法称为“根源分析”。然而更多人仍然喜欢使用“过失追究分析”方法，这种方法恰恰相反，它会诱导人们把引发问题的根源隐藏起来。