Hippo notes

J ava 界里有许多实现日志功能的工具，最早得到广泛使用的是 log4j ，许多应用程序的日志部分都交给了 log4j，不过作为组件开发者，他们希望自己的组件不要紧紧依赖某一个工具，毕竟在同一个时候还有很多其他很多日志工具，假如一个应用程序用到了两个组件，恰好两个组件使用不同的日志工具，那么应用程序就会有两份日志输出了。 为了解决这个问题， Apache Commons Logging  （之前叫 Jakarta Commons Logging，JCL）粉墨登场，JCL 只提供 log 接口，具体的实现则在运行时动态寻找。这样一来组件开发者只需要针对 JCL 接口开发，而调用组件的应用程序则可以在运行时搭配自己喜好的日志实践工具。 所以即使到现在你仍会看到很多程序应用 JCL + log4j 这种搭配，不过当程序规模越来越庞大时，JCL的动态绑定并不是总能成功，具体原因大家可以 Google 一下，这里就不再赘述了。解决方法之一就是在程序部署时静态绑定指定的日志工具，这就是  SLF4J  产生的原因。 跟 JCL 一样，SLF4J 也是只提供 log 接口，具体的实现是在打包应用程序时所放入的 绑定器 （名字为 slf4j-XXX-version.jar）来决定，XXX 可以是 log4j12, jdk14, jcl, nop 等，他们实现了跟具体日志工具（比如 log4j）的绑定及代理工作。举个例子：如果一个程序希望用 log4j 日志工具，那么程序只需针对 slf4j-api 接口编程，然后在打包时再放入 slf4j-log4j12-version.jar 和 log4j.jar 就可以了。 现在还有一个问题，假如你正在开发应用程序所调用的组件当中已经使用了 JCL 的，还有一些组建可能直接调用了 java.util.logging，这时你需要一个 桥接器 （名字为 XXX-over-slf4j.jar）把他们的日志输出重定向到 SLF4J，所谓的桥接器就是一个假的日志实现工具，比如当你把 jcl-over-slf4j.jar 放到 CLASS_PATH 时，即使某个组件原本是通过 JCL 输出日志的，现在却会被 jcl-over-slf4j “骗到”SLF4J 里，然后 SLF4J 又会根据绑定器把日志交给具体的日志实现工具。过程如下

G it 是目前比较时髦的版本控制系统，虽然 linux 内核源码是使用它来管理的，但系统非常小巧而且使用简单，比起 svn （ subversion ） 系统，git 有一个明显的优势就是在不联网的情况下也可以查阅或者回滚历史版本，有时带着笔记本出外工作这个功能是非常有用的。下面介绍一下用 Git 管理个人电脑上的个人文档文件。( @ivarptr ) 这篇文章有几个假设前提： a、你从事的工作有很多文档需要书写或者整理，而且文档篇幅比较大需要经常修修改改，有时还可能需要回档（即恢复到历史的某个版本）。 b、你的文档具有关联性的，比如一个项目策划书，有多份文本文档、电子表格、图片，希望平时能整体记录一个版本（快照）。 c、你有多台工作用的电脑，为了简单起见，下文假设只有两台电脑。 d、你有一台能够在互联网上访问的服务器，最好是跑 linux 系统而且有 ssh 登录权限。 e、为了简明，省略了安全权限设置和Git最为突出的特性“分支”。 1、几个必须厘清的概念 a、svn只有一个远程仓库集中管理所有的版本，而Git分有“本地仓库”和“远程仓库”之分，在提交你的最新文档过程中，需要两层提交，一次是提交到本地仓库，然后才可以提交到远程仓库。 b、svn的远程仓库保存的总是全局最新的版本，各个支点（小组成员）必须对此仓库负责。而Git则没有集中远程仓库之说，理论上每个人的地位是平等的，同时每个人的本地仓库也可以配置为给他人访问的“远程仓库”。不过对于个人或者一个小团队来说，为了简便起见我们通常会协商好让某个远程服务器上的仓库保持最新并且集中管理，这点跟Svn类似。 c、svn的每次提交会产生一个递增的数字作为版本号码，而git每次提交会产生一个“快照”，快照不是用一个递增的数字作为名称的，而是一个hash值，当然用一个hash值来呼叫某一次提交也太累赘了，所以在实际应用过程中我们往往只用hash指的头4~6位就可以了（类似一个人的昵称）。 2、在服务器上创建 Git 仓库 关于在 linux 系统里如何安装 Git 程序可以参考这篇《 在CentOS 5.5里安装Git以及搭建Git服务器最简单教程 》，要记住 Git 程序是不区分服务端或客户端的。 首先我们要创建一个Git仓库，使用 ssh 登录到你的服务器，在用户home文件夹里