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 允許逐漸增加的采用，以符合各個部門單獨的開發時間表。