Adobe Kuler是一个在线颜色配色方案管理工具，位于http://kuler.adobe.com/。
它也可通过AIR运行在桌面，下载地址：Download the Kuler desktop
其主界面应该是一个 Flex应用：
在其中你可以查询下载别人创建的配色，并进行评价。或者创建自己的配色方案。
创建新的配色界面：
可以根据颜色空间创建，也可以根据现有的图像创建。并且可选择预设的风格或者定制自己的风格。
根据图像创建
奥运会场馆规则出台，其中明文规定“禁止裸奔”。呵呵，觉得非常之好，非常有必要！！
在火炬传递的时候，我给一个担任开道车任务的公安朋友说，我要去裸奔。他说，得了吧，就你那点东西，别丢人现眼了。人家老外还可以拿出来亮亮相。
我哈哈大笑说，也是，大大有道理。我放弃....
其实，现在社会，有许许多多就恰似“裸奔”的现象和行为，人们就当没看见。比如，薪水只有千多元的公务员，每天抽的都是中华之类的，再比如.....
算了，懒得说
OLPC基金会的廉价电脑随着全球性物价上涨的浪潮，可谓路途多艰。意大利一家命名为V12 Design的公司设计的双屏笔记本则非常之Cool。其实看起来，液晶或者其他显示介质的发展，键盘已经成为完全可以虚拟的东西。当然，这样更加依赖于软件和系统了。IPhone和HTC的Diamond都非常的Cool。
这款笔记本也非常的惹人流口水：
对于看大量电子书的我，这样看起来多安逸阿，尤其是可以在上面乱写乱画，就像在纸张上一样。
Web 2 时代的Meshup 应用有两种极端，简约模式 和 丰富模式。前者 遵循简洁的界面更个和简单的UI体验，所谓 显式设计，业务上遵循独特简单的模型。 后者则是RIA宣扬的丰富如桌面的Web应用，并且开始用Web占领桌面，如AIR，SilverLight之类。
地图和位置则是一个很好的调味剂，凡位置相关者应用均可混入。公共Map应用不多，主要有：
Google Map
Yahoo Map
MS Map
国内还是51ditu （灵图）做的较好，国内地图比较详细，但不能提供卫星地图。
使用条款
google
就使用条款来说，Google地图的主要条款有几条值得注意：
““服务”只能用于一般情况下无需收费即可访问的服务。”这个一般情况下是什么意思？
诸如合法性、知识产权的部分无需多说，不得将“服务”用于：(a) 用作或与实时路线指南一起使用（包括但不限于线路规划指南和其他可通过传感器接受的路线指导），或 (b) 用作或与任何系统或功能一起使用来实施对自动或自主驾驶行为的控制。
还有一个限制就是流量问题，地址解析请求。每天每个地图 API Key 可发出最多 5 万个地址解析请求。相当于大约每 5.76 秒发送一个。如果当天超过这个限制，您可能暂时无法使用地图 API 地址解析。如果继续违反此限制，可能会造成此后您对地图 API 地址解析的访问被永久拦截。
大体来看，还是比较宽松的。
Yahoo
而yahoo地图几乎是明文限制商业使用的。而且中国的地图数据几乎没什么用。至于Yahoo中国搞的地图，好像是Map2China提供的，也基本上没更新。
MS
Ms的地图属于Live系列，引擎为Wirtual earth. 英文为 map.live.com,支持3D。中文为 ditu.live.com，2D地图。地图还算比较详细，即时性不够。
live Map的API 称为 interactive SDK，开发中心位于 http://dev.live.com/virtualearth/。看来 是live 平台的一部分。
51ditu
除了地图比较详尽即时外，还提供应用API。但速度不太快。API提供免费服务，也提供商业服务，根据流量收费。详见http://api.51ditu.com/special/vip/index.html。
Oracle公司的网站现在基本上出于打不开的状态，都持续数月了。真不知道是怎么回事，难道是收购BEA了之后还在重组中，不过这种现象好像是在收购事件发生之前哦。
1 驱动程序:
微软官方驱动:
http://www.microsoft.com/downloads/details.aspx?FamilyID=6d483869-816a-44cb-9787-a866235efc7c&DisplayLang=en
2 连接
设置 SQL Service的服务引擎和客户端均开启TCP/IP连接，通常TCP端口为1433默认。注意IP All的端口设置也须设置为1433,否则会出现 Connection Refused错误。
3 设置认证方式。
SQL EXPRESS Management Studio中好像无法修改认证方式，可以直接修改注册表
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Mi crosoft SQL Server\MSSQL.1\MSSQLServer LoginMode
1 为Windows Only
2 Mixed
否则，如果为1，出现user not associated with a trusted sql server connection
从偶然架构到一个全球规模的统一的集成基础设施可能是像一个使人畏缩的任务。 把一切都准备就绪，然后再象扳动一下开关那样将所有的应用都一下子转移到新的基础设施之上是不现实的。这已经是组织为什么老是要不断添加偶然架构方案作为权益解决之计的一个主要的理由，甚至他们确实知道这样使相关的问题永垂不朽也是如此。
ESB 提供了能力来帮助减轻所介绍的痛苦。 第 9 章将通过一个案例来介绍如何远离一个完全建立在 FTP 和每夜批处理作业之上的早以存在的集成解决方案。
让我们现在重新回到对偶然架构的讨论。 在图 2-6中，实线、虚线、点划线代表用于集成的不同类型的连接技术和通信协议。注意其中有一个用集成Broker表达的已存在的 “集成孤岛”，以及POS应用和财务应用之间的连接是使用FTP 文件传输。在POS应用和ERP应用之间先前已经升级来使用HTTP 之上的SOAP协议，正如销售自动化应用 (SFA) 和客户关系管理 (CRM) 之间的联结。
图表 2‑6 使用SOAP通信、 FTP 、手工插座（Socket）、而且包括一个集成Broker的代表性的偶然架构
ESB 可以在一个部门级的层次或在一个项目的基础上被引入。 在项目层次采用 ESB 允许你能够习惯于使用 ESB 服务容器进行基于标准的集成，并且完全可以坚信该项目能够集成到一个更大的集成网络之中，并且与企业级的公司的集成策略目标相一致。
我们采用ESB的例子中的第一个步骤是要集成前端应用（FrontOffice）。在图 2-7 中，前端的CRM、财务和SFA 通过“服务容器”连接到ESB 之中。这些容器是 ESB 架构的主要组件，我们将在第 6 章详细解释。 经过 ESB 服务容器进行的集成的特性可能会不同。 容器和应用之间的接口可以通过使用第三方的应用适配器来完成；容器可以暴露使用WSDL描述的XML数据；或者它可能被实现为完全用户定制的代码。
图表 2‑7 ESB 可以在不打破原有点对点路径的前提下，在单个项目基础上采用
但是也许更有趣的不是那些已经集成到ESB 之内的东西，而是还没有集成进去的东西。图 2-7 表示了已有的 FTP 和SOAP协议之间的通信线，原来是连接到前端应用的，现在直接连接到那些特别配制来使用那些协议进行通信的ESB组件。应用仍然处于总线“之外”，Pos应用和伙伴CRM应用可以与集成到ESB总线“之内”的前端应用进行通信而不需要做任何修改，对他们如何参与ESB基础设施也不需要知道任何东西。注意，现在POS应用是连接到ESB 上的一个 FTP 桥接器，而且伙伴CRM应用则是连接到配置为总线的一部分的Web Services端点。
ESB 已经被引入了，但是对这些配备了ESB能力的应用以前所连接的点对点通信组合区没有产生任何影响。被插入总线的应用如今转而使用连接到ESB 集成容器的一个单一接口， 而且已经省却了对它们先前所有其他类型的通信连接的管理和维护。
我们将会在第 9 章中看到，即使是总线域中最新集成的应用也可以就地将他们转移到完全的ESB方式，并且与它们各自的项目开发时间线相一致。
在我们的ESB采用的例子得下一阶段中，POS应用将在每一个远端实现ESB能力，并且去除对不可靠的 FTP 联结上的依赖。 这可能会简单如在每一个远端安装一个ESB容器，并且插入到总部的ESB之中，或者涉及到在每一个远端的多个应用之间的一个“迷你”的集成环境。那么二个 ESB节点就可以通过一个基于可靠消息的安全连接进行通信(图 2-8)
图表 2‑8 在各个地点分立安装的ESB可以安全和可靠地连接在一起
此外，远端位置仍然可以在他们自己的分离集成环境里面运行，并且可以按照需要有选择地共享数据。例如，远端位置可以独立地拥有并且运作一个属于集体特许经营的零售店铺。它们没有必须共享关于它们的日常运作的信息，但是的确需要共享诸如价格更新和库存信息之类的数据。远程ESB 节点可以连接到位于总部的 ESB 网络，有选择地暴露消息通道以共享价格变动之类的数据。
我们的ESB 采用示例项目的第三阶段涉及到桥接进进一个已经部分地与一个集线器-和-插头 EAI Broker集成在一起的部门。我们先前提醒过，采用 ESB 不是一个全有或全无的概念。如图 2-9 所示， ESB 允许IT部门通过将一个已存在的 EAI Broker桥接到ESB之内来保护它里面的IT资产。
图表 2‑9 “保留-和-分层”方式允许将ESB桥接到EAI Broker安装之内
桥接 EAI Broker可以一多种方式进行。比如，它可以通过使用一个Web Services接口来完成，或者绑定到下层的消息通道。依赖于ESB和 EAI Broker 的实现，ESB 更加可以建立在EAI Broker下面的消息队列基础设施之上，因此部分地替换EAI Broker的功能仍然可以保留较低层的、消息通道。
我们的 ESB 采用示例项目的最后步骤是解决和业务伙伴集成的问题。如图 2-10 所示，这可能包括原样保留SOAP联结，以及在每个伙伴端安装一个 ESB 节点。决定采用哪一种方法完全依赖于你的组织和伙伴之间的关系，以及业务伙伴是否允许你在其地点安装软件，或者他们已经有能够连接到你的ESB之上的ESB。
图表 2‑10 ESB 可以个别地管理与业务伙伴的SOAP联结, 或者可以连接到另一个地点的ESB节点
插入到一个 ESB 扩展的分层的服务能够管理对伙伴的连接的后勤保障。例如，一个特殊的伙伴经理者服务可以在每一个伙伴的基础上管理与伙伴之间的正在进行的协作的细节。这些细节可能包括正在使用哪一个更高层次的业务协议(比如， ebXML、RosettaNet 等)、以及对话的状态，比如消息交换的当前状态、是否收到一个期望的应答消息、以及从业务伙伴接收到一个业务响应所能够接受多长的时延。
本章包含下列主题：
- 对更广泛的、更通用的集成基础设施的需要的各种驱动因素
- 偶然架构是今天所使用的主要集成设计。 在这种系统中，当前的企业完全没有很好地联通的。
- 只有 10% 的应用被联接。
- 而这些之中，只有 15%的使用了某种类型中间件。
- 到目前为止，分布式计算技术加重了，而不是解决了，偶然架构的问题。
- 集线器-和- 插头EAI Broker已经有了一定程度的成功。然而，它们:
- 大部分是专有技术
- 没有为组织提供一个标准化的、可以在企业内通用使用的集成平台。
- ESB 借鉴了在 EAI Broker技术方面学习的经验的价值。
- 集成作为是一个部门层面和公司文化的问题，和它作为一个技术上问题同样重要。
- ESB 允许逐渐增加的采用，以符合各个部门单独的开发时间表。