NoSQL不是一个工具，而是由多个免费而相互竞争的工具所形成的生态圈。那些被称为NoSQL的工具为保存数据提供了除了基于SQL的关系型数据之外的另一个选择。要了解NoSQL，我们必须要了解每个可用的工具，看看它们的怎样设计数据存储的。
如果你考虑要使用一个NoSQL存储系统，你需要首先理解NoSQL系统所横跨的广阔的选择空间。NoSQL远离了传统的关系型数据库的舒适区，以前被封装隐藏在系统边界之后的数据库现在留给了系统设计人员。这要求设计人员在某种程度上扮演了系统架构师的角色，这要求设计人员对NoSQL系统是怎样构建的有更深的了解。
到现在为止，我们已经了解了Jitsi是怎样处理协议、发送和接收消息以及进行通话的。但是，Jitsi是由真人使用的应用程序，因此其很重要的一个方面就是用户界面。大多数情况下，用户界面使用Jitsi的其他的bundle提供的服务。但是有些情况下情况有些不同。
插件就是第一种情况。Jitsi中的插件通常需要和用户进行交互。这意味着它们需要打开、关闭和移动窗口，或者在用户界面已经存在的窗口中添加组件。这就是我们为什么需要UIService的原因。UIService允许对Jitsi的的主窗口进行基本的操作，这也是Mac OS X的dock和Windows的通知区域让用户控制应用程序的方式。
除了简单的展示联系人列表之外，插件还能够扩展联系人列表。在Jitsi中实现聊天加密（OTR）的插件就是一个很好的例子。ORT bundle需要在用户界面的不同部分注册多个GUI组件。它会在聊天窗口添加一个扣锁的按钮，并且在所有的联系人的右键菜单中添加一个子区域。
要实现这些只需要调用几个方法。OTR bundle的OSGi activator — OtrActivator中包含以下的几个方法： 继续阅读
在Jitsi中，ProtocalProviderService定义了所有的协议实现工作的方式。当其他的bundle（例如用户界面）需要发送和接收消息、进行通话、或者通过网络分享文件的时候就会调用该接口。
这个服务接口放置在net.java.sip.communicator.service.protocol包中。这个接口有多个实现，每个实现支持一种协议。所有的实现都是被放置在net.java.sip.communicator.impl.protocal.protocal_name包下。
让我们先看看service.protocal目录。这个目录下最重要的部分就是ProtocalProviderService接口。无论什么时候，如果需要执行协议相关的任务，都需要在BundelContext下查找这个service的一个实现。这个service及其实现运行Jitsi连接到任何其支持的网络，获取连接状态和细节，最重要的是获取实现了实际的通信任务（如聊天或通话）的类。 继续阅读
周一晚上，熬夜赶一份客户急需的文档，到凌晨4点才睡觉。虽然到11点才起床，但是整个白天还是觉得昏昏沉沉，没有精神。想起十几年前能够连续熬两个通宵依然精神抖擞，不得不说年岁不饶人，不服不行啊。
很多做IT的人都有熬夜的经历或者习惯。年轻的时候不觉得有什么，仗着年轻，身体好，常常半夜2、3点才睡觉。有一句话叫“傻小子睡凉炕，全凭火力壮”。实际上熬夜对人体有很大的损害，任何试图强行扭曲生物钟的做法都会对健康产生危害。 继续阅读
Jitsi是一个使得人们可以进行视频与语音通话、共享桌面、交换文件和消息的应用程序。最重要的是它使得人们能够以不同的协议进行这些活动，包括标准的XMPP（Extensible Messaging and Presence Protocal）和SIP（Session Initiation Protocal），甚至是向Yahoo!和MSN专有的协议。它能够在Microsoft Windows、Apple Mac OS X、Linux和FreeBSD上运行。Jitsi基本上是使用Java编写的，只有很少的一部分是使用本地代码编写的。这里，我们会来看看Jitsi的基于OSGi的架构，看看它是怎样实现和管理协议的，并且看看我们从Jitsi中能够学习到一些什么。 继续阅读
通过Pony-Build的验证，我们在将来的持续集成系统中希望看到下面的一些功能：
Buildbot和CDash选择了相反的架构，并且实现了由重复但是不同的功能集。下面我们会逐个的看看这些功能集并讨论选择不同的架构怎样使得功能能够易于或难以实现。
图2： Buildbot的架构
持续集成（CI）系统是定期的自动构建和测试软件的系统。虽然他们的主要的好处是避免了两次构建和运行测试之间间隔太长的时间，但是CI系统还能够简化和自动的执行很多繁琐的任务。这些任务包括跨平台的测试、定期运行速度慢的、数据密集型的任务，或者难以配置的测试，验证遗留系统是否有合适的性能、检测很少失败的测试、以及定期的生成最新的产品版本。而且，因为自动的构建和测试是实现持续集成的必需步骤，CI也常常是迈向持续部署框架（这样的框架中软件的更新在被测试之后能够快速的部署到在线系统中）的第一步。
持续集成式一个很时髦的话题，不仅仅是因为它在敏捷开发方法中的重要性。这些年针对不同的语言有了很多开源的CI工具，在不同的架构模式的环境中实现了很多的功能。我们这里主要是要讨论在持续集成系统中实现的最常见的一组功能，讨论可用的架构选择，并且讨论在给定的架构选择下哪些功能是易于实现的，哪些功能是难以实现的。
一个软件开发团队能否在项目中获得最大限度的成功，重要的因素之一就是团队中的成员是否能够形成技术性一致意见。
技术性一致意见是指充分吸取团队中每个成员的技巧和经验之后形成的大家都认同的意见，其目的是为了开发出更好的软件。
但是要注意，技术性一致意见并不是折衷，两者有着很大的区别。
Yahoo的大型的HDFS集群包含大约4000个节点。一个典型的集群节点有2个4核的Xeon处理器，主频为2.5G，有4-12个直接连接的SATA驱动器（每个有2TB空间），24G的内存，1G的以太网连接。70%的磁盘空间是分配给HDFS的。其他的磁盘空间是为操作系统（Red Hat Linux），日志以及map task的输出（MapReduce的中间数据时不保存在HDFS上的）保留的。
一个机架上的40个节点共享一个IP交换机。这些机架的交换机被连接到8个核心的交换机。核心交换机提供了机架之间的连接，同时还提供了到集群外的资源的连接。对于每个集群，NameNode和BackupNode主机配置的是64G内存，应用程序任务用户不会分配给这些主机。这个拥有4000个节点的集群加起来有11 PB(1PB = 1000TB)的可用存储空间，由于每个block要复制3次，因此对于应用程序来说有3.7PB的净存储空间。经过这么多年的HDFS的时候，选择的主机也受益于不动发展的技术。新的集群节点总是使用的更快的处理器、更大的硬盘和内存。速度较慢的、硬盘和内存较小的节点要么是退休了，要么是退居到了另外一个为开发和测试Hadoop所保留的集群中。 继续阅读