又开始写博客了
在此之前已经弃了两个坑，希望这次能踏下心来记录些东西；就以此篇开始吧。
常用 LaTex 数学符号表
Greek Letters
| 符号 | 命令 | 符号 | 命令 | 符号 | 命令 | 符号 | 命令 |
|---|---|---|---|---|---|---|---|
| (alpha) | alpha | (beta) | beta | (gamma) | gamma | (delta) | delta |
| (epsilon) | epsilon | (zeta) | zeta | (eta) | eta | (theta) | theta |
| (iota) | iota | (kappa) | kappa | (lambda) | lambda | (mu) | mu |
| (nu) | nu | (xi) | xi | (omicron) | omicron | (pi) | pi |
| (rho) | rho | (sigma) | sigma | (tau) | tau | (upsilon) | upsilon |
| (phi) | phi | (chi) | chi | (psi) | psi | (omega) | omega |
| (Gamma) | Gamma | (Lambda) | Lambda | (Sigma) | Sigma | (Psi) | Psi |
| (Delta) | Delta | (Xi) | Xi | (Upsilon) | Upsilon | (Omega) | Omega |
| (Theta) | Theta | (Pi) | Pi | (Phi) | Phi |
Binary Operation Symbols
| 符号 | 命令 | 符号 | 命令 | 符号 | 命令 | 符号 | 命令 |
|---|---|---|---|---|---|---|---|
| (pm) | pm | (cap) | cap | (diamond) | diamond | (oplus) | oplus |
| (mp) | mp | (cup) | cup | (bigtriangleup) | bigtriangleup | (ominus) | ominus |
| (times) | times | (uplus) | uplus | (bigtriangledown) | bigtriangledown | (otimes) | otimes |
| (div) | div | (sqcap) | sqcap | (triangleleft) | triangleleft | (oslash) | oslash |
| (ast) | ast | (sqcup) | sqcup | (triangleright) | triangleright | (odot) | odot |
| (star) | star | (vee) | vee | (+) | + | (bigcirc) | bigcirc |
| (circ) | circ | (wedge) | wedge | (-) | - | (dagger) | dagger |
| (bullet) | bullet | (setminus) | setminus | (amalg) | amalg | (ddagger) | ddagger |
| (cdot) | cdot | (wr) | wr |
Java Callable 与 FutureTask
Callable与FutureTask简介
先说一下java.lang.Runnable吧，它是一个接口，在它里面只声明了一个run()方法：
public interface Runnable {
public abstract void run();
}由于run()方法返回值为void类型，所以在执行完任务之后无法返回任何结果。
Callable位于java.util.concurrent包下，它也是一个接口，在它里面也只声明了一个方法，只不过这个方法叫做call()：
public interface Callable<V> {
/**
* Computes a result, or throws an exception if unable to do so.
*
* @return computed result
* @throws Exception if unable to compute a result
*/
V call() throws Exception;
}可以看到，这是一个泛型接口，call()函数返回的类型就是传递进来的V类型。
[译]Git分支管理的最佳实践
原文地址：http://nvie.com/posts/a-successful-git-branching-model/
注：该文章由作者Vincent Driessen写于2010年1月
在这篇文章中，我将介绍一个开发的模式；早在一年前，我就将它引入我的所有项目（工作和私人），它已经被证明是非常成功的。我早就打算写一篇关于它的文章，但是直到现在才找到时间去完整地介绍它。我不会讨论任何项目细节，只是讨论分支策略和发布管理。
它重点围绕我们所有源码的版本控制工具，Git。
为什么是Git？
在网上，有很多关于Git与其他源代码版本控制工具的优劣的透彻分析。在这里存在激烈的争论。作为一个开发者，与其他源代码版本控制相比，我更喜欢今天讨论的Git。Git真正地改变了开发者关于合并与分支的思维模式。我也经历过经典的CVS/Subversion时期，合并与分支总是被认为有点吓人（当心合并冲突，它们会咬你！）并且在一段时间里，你只能每隔一段时间做一些事。
但是，使用Git后这些动作会变得廉价和简单，它们被认为是你的日常工作流的核心部分之一。例如，在有关CVS/Subversion的书中，分支与合并时在后面的章节中首先讨论的（针对高级用户），而在每一本Git书 中，它已经被包含在第三章了（基础知识部分）。