qcon_從倫敦QCon 2007中學到的重要知識點和教訓

qcon

在這篇文章中，我們介紹了主要的學習重點和經驗教訓，許多 部落格上 有關 QCon的與會者 都 看到了這 一點 。 随着新觀點的加入，我們将繼續監視部落格空間并更新本文。 通過人們認為值得寫部落格的所有觀點來體驗會議。 :)您還可以在Flickr上檢視超過320張QCon與會者拍攝的照片 。

倫敦QCon是InfoQ的首次會議，并取得了很大的成功。 該活動是與組織JAOO會議的人們合作制作的，吸引了大批群衆，上面印有550多個徽章，來自24個國家的與會者參加了會議。 盡管這是第一次活動，但在會議上進行了重大投資，這将是未來幾年倫敦不斷增長的年度活動。 您将在下面的QCon的83場會議上介紹83位演講者，并在QCon上讨論9個教程。 在我們參與過的所有會議中，我們從未見過如此多的人通過部落格釋出有關會議的如此詳細的内容！

本文按會議軌迹組織部落格作者的評論，并按會議會話分組。 單擊以轉到您最感興趣的部分： 案例研究 （亞馬遜，eBay，Yahoo！） Java ， 靈活 ， 靈活開放空間 ， 建築品質 ， Ajax和浏覽器應用程式 ， .NET ， Ruby ， SOA， 可用性 ， 銀行體系結構 ，然後總結參與者對QCon的總體看法 。

案例研究：您一直想知道的架構

eBay架構

馬丁·福勒（Martin Fowler） 對eBay.com運作無事務性消息的React是 ：“我對無事務性消息的直接跟進是詢問對應用程式程式員會産生什麼後果，特别是對無事務性的整體感覺。答複是一開始很奇怪，但最終沒什麼大不了的-比您想像的要少得多的問題。您必須注意送出的順序，首先獲得更重要的送出。在每次送出時都必須檢查它成功了，并決定失敗了該怎麼辦。這種程式設計風格吸引了我，但是由于我被悄悄地告知，是以我不會再廣泛讨論它了，因為丹·普裡切特 （ Dan Pritchett ）在QCon上發表了精彩演講本周有關eBay的架構，包括這方面。” 引用了丹（Dan）關于大型系統的電源需求的演講 ：“除了碳足迹，計算機技術的熱量以及空調的廢熱是當今大型安裝的主要開銷–實際上，據丹·普裡切特（Dan Pritchett，技術研究員， eBay Inc在馬路對面的QCon倫敦會議上發言），“在這種計算規模下，“電源和冷卻現在是增長的主要制約因素”，這僅僅是因為美國電網通常難以在一個地方提供電源當今最大的資料中心都需要它。從來沒有考慮到這麼多電源來設計單個建築物。” 費蘭·羅德納斯寫道 ：

（eBay技術研究員）讨論了eBay的一些有趣的體系結構功能，它們如何處理垂直DB分段（按功能區域劃分）和水準DB拆分（日期，位置等），以及如何不使用存儲過程，觸發器而且，也很棒，也沒有交易（Martin Fowler在他的《 Transactionless》中談到了這一點）。 這意味着所有業務邏輯都由應用程式執行（排序，聯接，參照完整性等）。 他們使用密集準備的語句和綁定變量（由資料源緩存）。 它們還使用重寫的連接配接池和内部開發的稱為DAL（資料通路層）的ORM解決方案進行擴充。 所有CRUD操作都通過此基礎結構執行。

安德斯還指出了功耗問題。

亞馬遜平台-Werner Vogels的主題演講

Ben提供了有關Amazon體系結構的重要摘要 ：“ 2001年，Amazon.com開始将其體系結構逐漸轉換為SOA，任務小組以各種方式專注于滿足服務規範。一些團隊使用Python，Java，Perl ，Smalltalk和Ruby ...總而言之，為了在Amazon.com的首頁上提供180多種不同的服務，其中一些服務提供資料，另一些将資料和頁面資訊聚合到表示層中。完全面向服務的架構允許Amazon.com進入服務提供的新領域4個主要出發點 ：

• 要擴充：不再直接通路資料庫。 相反，資料通路通過穩定的公共接口封裝在服務（代碼和資料在一起）中。
• 分離：服務可以與其他服務或非常“瘦”的Web應用程式聚合在一起，進而允許将不同的服務組合在一起，并省去了您不需要的内容，進而支援許多不同的應用程式和用途。
• 一個小團隊在所有方面擁有一項服務。 這具有使團隊負責服務功能的優勢，同時使它可以自由地執行服務并使其正常工作。
• 稍後擴充。 很難正确地做到這一點，有時沒有理由為此付出努力。 或将其交給擁有專有技術并已經做到的人，例如Amazon（記住S3-虛拟磁盤等）。

雅虎！ Mark Nottingham的後端和SOA政策

摘錄自Stefan Tilkov的精彩文章 ：

每天有40億的頁面浏覽量... Yahoo!不同“屬性”的整合噩夢... Yahoo規模是另一個問題-Yahoo首頁上的連結将觸發他們自己的Slashdot效果版本...每個媒體資源都在重塑一直運轉，直到有人意識到重用元件才有意義...對新體系結構的要求：巨大的可伸縮性，靈活的部署，高度動态，關注點分離-結果。 轉向面向服務的體系結構。 PHP在Yahoo!上更為常見。 比Java。 可伸縮性，簡單性，重用性，互操作性-決定：使用HTTP，而不是WS-*...。前端框通過緩存向後端API伺服器送出請求，所有這些都通過HTTP。 屬性：真理的單一來源。 緩存複制資料（拉模型與推模型）

Redmonk分析師James Governor是案例研究的主持人，并撰寫了他的簡介：

馬丁曾談到過需要在IT和業務之間架起打哈欠的裂縫的橋梁。 我試圖争取在傳統企業體系結構和更多Web /輕量級方法之間架起一座跨越鴻溝的橋梁。 如果我們有更好的“故事”（在靈活意義上）來支撐我們所謂的“規模”的含義，那麼雙方都可以互相學習。

Java

Java在QCon上有兩個軌道，即Java in Action軌道和Java新興技術軌道 ，所有注釋都合并在這裡：

Guilluame Laforge在Grails上

Jiri Lundak 總結了示範的主要資訊 ：

• 即使是簡單的事情，使用Java架構也很難完成（ORM持久性難以實作，許多層和配置檔案導緻混亂，UI內建混亂）
• Grails是一個基于MVC動作的Web架構
• 原則：約定優于配置（CoC），不要重複自己（DRY）
• Grails建立在可靠的元件之上：Spring，Hibernate，Groovy，SiteMesh，AJAX

彼得·克裡恩 （ Peter Krien）的總結（部落格Qcon，但總結了一本書）：“ Grails的關鍵是它使用許多約定來最小化必須要做的編碼。代碼生成器使用約定來建立大多數樣闆代碼，在企業軟體中如此流行。我已經看過這本書，但還沒有玩過它，是以，當我真正開始使用它時，我可能會感到失望。但是到目前為止，它看起來很有希望。”

使用OpenTerracotta進行JVM叢集

凱文·海豹寫道 ：

...而不是提供用于在節點之間共享資料的API，Terracotta對堆透明地工作。 這使它更像是在VM之間共享記憶體，對于許多群集要求來說，這聽起來像是一個白手起家……作為一個命題，這很有趣：VM是否共享記憶體（或更準确地說，透明地模拟共享記憶體，甚至向下） （對于鎖定的語義），這使開發人員不必擔心許多發行問題。 實際上，它允許利用在過程中采用的非常簡單的範例（例如鎖定和瑣碎的對象辨別），而不管目标環境如何。

Rob Harrop關于JRuby的演講

Jiri Lundak寫道 ：“示範者...以指令行方式從jirb（JRuby解釋器）開始...他...實際上是直接在解釋器中直接建立了一個小型Swing應用程式... Ruby與Java的內建不是無縫的。相反，您必須使用特殊的內建類将其綁定到……Ruby在建立新的特定于域的語言（DSL）方面顯示出優勢。”：

加文·金（Gavin King）介紹SEAM

吉裡隆達的外賣店：

Seam為Web應用程式生成架構，其中包含一些簡單的測試代碼。 您可以像在Grails中一樣修改應用程式的代碼...“我們不需要功能單元測試。 任何一名程式員都可以毫無錯誤地編寫這些簡單的POJO。 當您與班級合作者一起測試一堂課時，問題就來了。”……Seam帶來了什麼：

• JSF，ESB，EJB等的單一元件模型
• 沒有動作
• 持久性：沒有DAO，而是将通過JPA / Hibernate通路資料庫的元件直接綁定到視圖
• 更改資料庫結構後，需要重新啟動Web伺服器。

Spring2及以後-Rod Johnson

西蒙·布朗的訣竅 ：

在Spring配置檔案中使用自定義名稱空間是一種為其他供應商/架構提供無縫內建的機制的巧妙方法，并且是通過使用更多抽象定義來降低與那些檔案相關聯的複雜性的支援者。 例如，您可以使用單個事務XML标記來訓示Spring在任何帶有

@Transactional

注釋的類上編織事務魔術。 将此與在Spring 1.x中必須編寫的樣闆XML進行比較，您将看到好處。

彼得·克裡恩斯（Peter Kriens） ：“ OSGi技術在其中扮演了非常重要的角色。他甚至以新成員的身份跟随OSGi市場營銷代表，解釋說OSGi聯盟否認它們與網關有關。當然，結果是他正在向大多數聽衆介紹我們曾經與網關有關的事實！”

聯合創始人Cedric Beust和Alexandru Popescu提出的TestNG

塞德裡克總結了自己演講中的關鍵主題 ：

• 可測試性設計有時可能與公認的軟體工程實踐（例如某些設計模式和極端封裝）背道而馳。 您需要準備好質疑自己的信念。
• 您應該避免使用靜态變量，并且有一些非常有價值的架構可以簡化這一過程（Guice和Spring，僅舉兩個）。
• 測試驅動開發不一定會導緻代碼設計得更好，并且最好用于使初級程式員接觸測試。

西蒙·布朗寫道 ：“從我的角度來看，TestNG似乎對您使用JUnit可以得到的功能進行了非常不錯的增強，并且由于使用了注釋，它并沒有像JUnit那樣限制您。我問到它有多麼容易它是從JUnit“更新”到TestNG的，并且提供了工具來幫助實作此過程的自動化。聽起來，我一定會在有機會的時候進行研究。” Piotr Gabryanczyk受啟發從Eclipse中的JUnit + JMock切換為使用TestNG：

使用TestNG IntelliJ插件非常簡單，該插件具有“将JUnit測試轉換為TestNG意圖”的功能。JMock和TestNG的內建非常簡單：

-測試類需要擴充MockObjectTestCase

-確定調用了超類中的setUp（）和tearDown（）方法。 是以，您需要在測試類中覆寫它們，并使用@ BeforeMethod，@ AfterMethod進行注釋。

Joe Walker談Java趨勢

Joe在新興技術領域的介紹非常關注封閉。 Joe在他的部落格上寫了一篇關于它的教程 ：“您可以将閉包視為可以傳遞給執行的代碼塊。您可以将它們視為内部類的文法糖。我認為完全閉包背後蘊藏着強大的力量。隻是從這些角度看他們會錯過。”

Rod Johnson與企業中的AOP

西蒙·布朗寫道 ：

Rod的會議讨論了Spring和AspectJ中的AOP支援。毫無疑問，這在我看來是非常有趣的，尤其是當您考慮到方面可以真正用來簡化跨領域關注點（例如安全性，業務邏輯）的開發時驗證，甚至是架構一緻性。...但是對于大多數開發人員而言，肯定存在進入的障礙。

彼得·克林斯（Peter Kriens）： “有趣的是，Spring如何使您無需真正使用AspectJ編譯器就可以使用許多AspectJ功能。Spring的內建功能非常強大，隻是它們使用XML有點令人反感。”

Scott Delap概述桌面Java技術

西蒙·布朗的外賣 ：

Scott提出的主要觀點之一是，如果您想通過Internet（例如，使用WebStart）将該應用程式釋出給公衆，則Swing應用程式的部署隻是初學者。 原因是什麼？ 簡而言之，您不能保證最終使用者将安裝Java。 為了獲得最大的應用範圍，您需要使用Adobe Flex之類的東西，因為它使用的Flash播放器無處不在。 您上次看到大型網站（例如YouTube）何時使用Java小程式公開釋出其功能？ 這是一個很好的觀點，使您思考Flex是否将成為更主流的事物的開始。

帶有Linda DeMichiel的Java Persistence和EJB 3（EJB規範負責人）

西蒙再次寫道：

我真的很喜歡JPA，并且認為它可能會吸引人們的注意力和精力再次在其項目中使用EJB。 沒錯，我對EJB 3所做的工作非常酷，特别是因為您可以通過幾個注釋将任何POJO變成EJB。 隻是人們過去曾經被EJB燒死了，可能對傳回并不十分熱心。一旦人們看到JPA，他們也可能會看看其餘的規範。

靈活

QCon上的靈活分為三個軌道： 靈活基金會 ， 靈活掌握和與掌握軌道同時進行的特殊靈活開放空間事件。

主題演講：馬丁·福勒（Martin Fowler）和丹·諾斯（Dan North）出席“毀滅的偏航”

蒂姆·安德森（Tim Anderson） 總結了主題演講 ：

厄運的打呵欠裂縫 ; 這是指那些開發軟體的人傾向于不與軟體的受益者（使用者，業務人員等）進行通信。這使我了解大多數軟體故障不是由技術問題引起的，而是由通信問題引起的。發現這是對我從供應商那裡獲得的PR的有益糾正，它暗示他們的工具可以防止項目失敗。 他們喜歡引用Standish Group的數字， 這些數字聲稱大多數軟體項目都失敗了。

芒果跳舞馬克寫道：

他們的中心主題是客戶/最終使用者/消費者/企業與開發人員/ IT之間的通信。 馬丁作了一個很好的類比。 您是否希望兩個“側面”之間的交流像渡船或橋梁。 馬丁和丹談論的橋梁的一部分是人種學研究的使用-在自然環境中觀察使用者，并以情節提要/線框/低保真度原型觀察使用者，進而以書面要求永遠無法做到的方式清晰表達要求。 例如，擁護我熱衷的東西，以及ThoughtWorks所做的工作都能成功完成項目。

Rachel Davies的使用者故事和釋出計劃

約翰娜·亨特（Johanna hunt）寫道 ：

Rachel提出了一個非常有趣的觀點，即傳統的需求文檔是基于傳統的知識轉移模型的，該模型在授課中的教學中得到了示範，專家可以将知識直接傳遞給學生（由學生保留知識）。 認為可以将知識傾倒，捕獲，記錄，然後毫無損失地傳遞給其他人。 這種觀點已經改變，随着越來越多的教育活動側重于反思，小組活動和隐性知識。 從需求捕獲到使用者案例的轉變中可以看到相同的變化

Ben繼續說 ：“ Rachel還介紹了計劃釋出，例如每5 個疊代部署一次，而沒有部署每個疊代不會使您陷入困境。她還在每次疊代結束時着重回顧，包括審查釋出計劃”。

靈活架構不是脆弱的架構

詹·諾林斯（Jen Norins）寫道： “在Kevlin Henney和Jim Coplien之間的舞台上的争戰……他們倆都堅信，架構太重要了，不能被“我們靈活，架構不是，是以我們不這樣做”。 “。TDD再次受到Jim的質疑，例如“如果您不設計任何體系結構，您如何知道編寫哪個單元測試？”，“如果我們沒有一個簡短的設計階段，那麼在什麼情況下，建築是從哪裡來的？”，“ TDD會建立什麼設計工件？”。有趣的觀點。” 埃卡（Mikael Essle）寫道：“靈活人是開始這樣做了嗎？聽起來，即使靈活人也認為沒有地圖和目标行駛100英裡是一個壞主意。我什至聽說過靈活人在談論“盜夢空間”。這個詞多麼不靈活；）Jim Coplien和Kevlin Henney進行了有趣的談話，他們提到RUFD（粗糙前端設計）是靈活項目的良好開端。對我來說，這聽起來像是一個好主意。在開始開發項目之前要三思。”

Steve Freeman和Nat Pryce-測試驅動開發

約翰娜·亨特（Johanna Hunt）寫道 ：

那麼，為什麼要使用TDD？ -可以說是因為您最終隻能得到一半的缺陷，但生産率卻差不多。 它有助于使您有信心完成工作，而您不必擔心副作用……測試最好以它們将為我們做的事情而不是它們正在測試的方法來命名。重構通過消除重複并幫助表達意圖來支援設計方面。

本總結

史蒂夫（Steve）談到了“測試驅動開發”（Test Driven Development），展示了一些使用魔術公式驅動的示例：編寫測試，通過測試，重構...通常，人們認為TDD的工作量太大。 一些反對這一觀點的觀點是：

• 大部分時間都花在閱讀代碼上。
• 包括調試時間-如果您擅長于此，調試時間将大大減少。
• 可靠的代碼可讓品質檢查人員專注于更大的問題。
• 當您擴大規模時，它變得至關重要-它使您能夠廉價安全地進行規模擴大-特别是在團隊周圍。

羅伯特·戈弗雷（Robert Godfrey）的最愛：

特别喜歡将對象與之協作的對象的描述分為以下幾類：

• 依存關系
• 政策
• 部分
• 通知事項

以及構造函數真正隻需要接受依賴項作為參數來将對象設定為有效狀态的方式。 通常可以預設政策，部件和通知。

戴夫·托馬斯（Dave Thomas）談發展專長：放牧賽馬，賽馬

費蘭·羅德納斯寫道 ：

戴夫·托馬斯（Dave Thomas）在講話中宣稱，流程改進需要人員改進（他建議閱讀Capers Jones評估和基準）。 他使用Dreyfus技能擷取模型，以有趣的方式描述了不同階段（新手，進階初學者，勝任，熟練，專家）人員的特征。 他表示，絕大多數開發人員都在第二階段，我們需要提高标準。 他主張使用Dreyfus來固定公司并固定我們的職業，并學習和應用财務管理來開展我們的日常工作（制定計劃，多元化，尋求價值，積極主動……）。

Mikael Essle的外賣是：

戴夫·托馬斯（Dave Thomas）對Dreyfus模型進行了精彩的演講，該模型描述了一個人的不同技能。 從新手到專家，新手都是初學者，而對于這種人來說，最好的事情是在指導下應用事物并實作簡單的目标（而不是從大量的文檔開始）...在項目期間，他/她可能會開始索要可以提供更多了解的文檔，屆時他也将對資訊更加開放。

戴夫·托馬斯本人寫道 ：

我認為有些方法可以掌握，您可以說“現在我已經知道了”。 我不相信靈活在那個陣營中。 對我來說，靈活就是旅程的全部。 一路上，我們總是在路上遇到叉子。 靈活原則幫助我們決定采取哪種方法。 我們繼續前進，享受旅途，并在旅途中盡力而為。

維德尼斯寫道 ：

Dave提到格言是那些已達到第四階段技能的人所使用的教學工具。 這引起了我的共鳴，非常适合我的經驗。 例如，職業顧問馬庫斯·白金漢（Markus Buckingham）運用格言來發揮巨大作用 。

Ben寫道： “使用Dreyfus模型作為了解Dave的一種方法，他談到了……具有不同知識水準的人們的水準和習慣。為新手設定目标，規則和界限的重要性，實作專家直覺的重要性通過不問為什麼，而隻是相信他們。

Google的經驗教訓-Jeff Sutherland

詹恩·諾林斯（Jen Norins）在跑步國家的Scrum上說 ：“當然，當談到Google的經驗教訓時，主要動力傑夫·薩瑟蘭（Jeff Sutherland）吸引了一大群人。他的演講幾乎就像是複興主義者的會議，你無法避免被吸進去。他的表現确實很棒，後來你得到了Scrum可用于管理國家和解決世界貧困的感覺。實際上，您可能可以使用Scrum成功地管理一個國家。盡管如此，它需要大量的Scrum。:) “ Jiri Lundak寫道 ：”在Google，Adwords項目是大約一年前，他們開始使用Scrum在2006年初将公司的Scrum實踐（如發行積壓）引入公司。最初在2001年，Google決定他們不需要任何經理，因為他們沒有為Google增值。公司，是以他們取消了所有管理職位。從那時起，項目就有機地發展了。當​​Google變得越來越大，軟體（以Adwords為例） ze（500'000 LOC，并且仍在快速增長），該項目的項目經理看到了對結構化方法的需求，這不會破壞目前的工作方式的有機本質，因為這被認為是一種好東西 “ 馬克·舞蹈芒果寫 小号 ：

傑夫·薩瑟蘭（Jeff Sutherland）談到了他們如何在Google進行績效評估。 相反，每個人都有個人的“三個月目标”，并張貼在自己的部落格上（Google的新員工顯然要做的第一件事就是建立個人網頁）。 這樣，人們可以與更廣泛的組織共享他們在做什麼。 與谷歌搜尋專家和他們的知識可以很容易地找到。 向組織宣傳您的​​目标驅動績效的效率遠比人力資源部門釋出的不定期季度報告有效。

約瑟夫·佩林（Joseph Pelrine）：當靈活撞牆時-處理靈活采用的組織挑戰

吉裡·倫達克（Jiri Lundak）寫道：

約瑟夫将快速采用與靈活采用與下坡運作進行了比較-如果您放手，您會加速并加速，直到您自己踩到快速而跌跌撞撞...是以解決任何問題的第一步是了解問題所在并掌握組織内部的力量。 通常對“因果關系”的了解會發生沖突。 管理層和靈活團隊通常生活在兩個不同的世界中。 管理常常停留在牛頓世界觀中，而靈活團隊則采用基于複雜性科學的方法。 這些彼此不相容。

Boris Gloger-心跳回顧，以提高團隊效率

約翰娜·亨特（Johanna Hunt）寫道：

為什麼要回顧？ 我們希望改進過去所做的工作。 對期望的失望停止了學習。 活動結束後需要進行回顧，以鼓勵學習。...心跳回顧可以持續10到90分鐘... 6個步驟：1）安全第一，收集事實，問：進展如何？，問：可以改進什麼？ ，誰來控制？，優先安排活動。

LSC還對這6個步驟中的每個步驟進行了更深入的研究。 “城市”寫道 ：

我對這次會議的主要印象是，靈活社群開始意識到1）過于“靈活”并不總是一個好主意，2）即使您使用的是靈活方法（Scrum，XP等），您也可能會運作陷入軟體開發項目中的問題。

靈活掌握 開放空間

Sadek Drobi 對開放空間進行了漂亮的圖檔浏覽 ，并記下了其工作原理：

qcon Wiki上的開放空間會議筆記 ：

• 所有這些人的東西真的很難，我們不能隻買闆球拍嗎？
• 靈活合同：您如何定義不強制初始瀑布的合同？
• 測試驅動開發：我們如何使TDD起作用，這對它有什麼好處？

Sadek Drobi在部落格上發表了一篇沒有登上Wiki的文章： 如何處理困難的團隊成員

品質 建築軌迹

本專題介紹了體系結構中的具體操作品質：

Martin Fowler-可修改性

蒂姆·安德森（Tim Anderson）寫道 ：“這是關于靈活與混亂之間的差別；福勒（Fowler）引用了他給肯特·貝克（Kent Beck）的一句話，即最簡單的東西（好的）和最愚蠢的東西（...）之間的差別。講得很清楚：最注意那些不可逆轉的決策...。我也喜歡測試驅動開發的評論，并指出TDD的附帶好處是它可以執行子產品化設計，因為沒有子產品化設計您無法輕松建立測試。”

性能和可伸縮性-Cameron Purdy

Jiri Lundak 注意到一個有趣的沖突 ：“與Werner Vogels的主題演講相比，Cameron提出了一些沖突的聲明：性能和可擴充性的架構師，因為在以後的版本中花費太多的精力那麼，誰是對的呢？當我嘗試合并這兩個話題的總體資訊時，我得出以下結論：在您的體系結構初稿中包含有關性能和可伸縮性的想法，但是準備對其進行修訂和優化。稍後，當您知道a。）有關系統實際需求的更多資訊時，以及b。）當您能夠用自己的眼睛（或确定）看到有效瓶頸時，便會知道。”

可用性和一緻性-亞馬遜的Werner Vogels

吉姆·韋伯評論：

他提出了一個從根本上正确的觀點，他希望開發人員能夠顯式地處理分布式系統的僞像，以便他們可以優雅地顯式地處理故障，而不是将此類故障隐藏在基礎結構中，并希望像地獄一樣不會發生太嚴重的事情。 這不是違反直覺的，而是建構可靠的分布式系統的成本-對于任何錯誤地考慮通過WSDL公開EJB的人來說，這都是極好的建議！

馬克·麥克尼爾（Marc McNeil） 對亞馬遜團隊組織的評論 ：

我之前曾寫過關于孤立的組織的博文，但Werner談到了如何隔離内部IT組織。 有關您的資料庫團隊如何獨善其身的一些知識集中在一緻性上。 他們願意出于有效的技術原因而犧牲可用性。 但是，需要從更大的角度看待資料庫，而不是IT組織的範圍。 它需要支援客戶體驗。 這意味着客戶必須始終能夠将物品放入購物車。 期。 我想的主要收獲是圍繞客戶體驗建構您的體系結構。 分解經驗來做到這一點...做出相應的技術決策，而不是一刀切的決策。

易用性

本教程的目的是使開發人員意識到使用者界面在軟體産品中的至關重要性，對使用者環境進行良好分析的重要性以及使用合适的軟體結構來支援界面的重要性。

Jim Coplien從設計實踐到代碼

延斯·諾林（Jens Norin）寫道：

當他挑戰一些靈活實踐時，他激怒了很多人。 特别是測試驅動開發（TDD）受到了他的攻擊。 他的觀點是，如果開發是測試驅動的，那麼您應該自然而然地定義驗收測試。 但是他的問題是，如何不進行設計就從驗收測試到單元測試。 我絕對明白他的觀點，在許多情況下，您必須先進行簡短的設計階段，然後再進行TDD。 他的建議是完全跳過TDD，但是我認為TDD可以是一個很好的工具，特别是對于具有衆所周知的架構模式的系統以及有經驗的程式員而言。

Jiri Lundak 在由Jim Coplien上司的可用性教程中發表了評論 ：

Larry提倡以使用為中心的UI設計方法，而不是以使用者為中心的方法。 不同之處在于，以使用為中心的方法側重于要完成的工作并對其進行優化，而主要是使使用者放心而忽略了手頭問題的有效解決方案。 是以，他的座右銘是： “将好的工具放在使用者手中，這樣他就可以創造性地解決日常工作中的問題。” ……讓我感到震驚的是，拉裡說： “我是可用性專家，是以我隻需要讓使用者參與一點，是以我知道他想要什麼，但是我決定如何獲得它。” 。

主題演講：Larry Constantine應對可用性挑戰

蒂姆·安德森（Tim Anderson）寫道 ：

他的大想法是，開發人員不應依賴使用者的意見，回報和測試來确定應用程式的使用者界面和功能集。 您最終會擁有太多功能，并且會複制過去的錯誤。 他提出了一些好的觀點，但是這次會議給我留下了深刻的印象。 大部分時間都花在嘲笑其他人的UI錯誤上，這給康斯坦丁提出的解決方案（活動模組化）留下了很少的空間。

基于Ajax和浏覽器的應用程式

Ajax和設計模式：我們需要客戶層嗎？

羅伯特·戈弗雷（Robert Godfrey）的會議筆記介紹了戴夫·克蘭（Dave Crane）提出的兩種模式 ： MVC ：

• 在用戶端中維護的模型（可能是XML或JSON資料結構 ）
• 使用控制器注冊為模型偵聽器的多個視圖
• 檢視通路模型狀态
• 控制器調用視圖回調函數來更新有關模型更改事件的視圖
• Javascript允許按函數名稱動态反映回調函數，即，如果控制器可以在偵聽器上找到具有名稱的函數，則将調用該函數。

戰略：

• 由于功能可以引用為變量并傳遞，是以政策實作可以實作為帶有閉包的功能。
• Javascript中的函數對象有點像Java中的匿名内部類。
• 例如，當一個人早上上班時使用封閉物預先登記午餐活動（吞吃三明治，用鉛筆擦幹淨耳朵等），并與其他物體進行互動（例如三明治）。

Google Web工具包：什麼，為什麼以及如何-Bruce Johnson

Ajax Patterns的作者Dave Crane最初表示懷疑， 但在談話結束時，他想嘗試一下GWT ，因為：

• 因為整個代碼庫都是用嚴格類型的語言（Java）編寫的，是以與試圖從松散類型的語言推斷意圖時相比，可以進行更嚴格的全局優化。 作為手動編寫代碼的人，我仍然更喜歡腳本語言，但是我可以看到，在自動生成代碼時，所有安全工具都可以提供幫助。
• GWT并不采用指令'n'征服的方法，但可以與手寫Web UI很好地配合使用。 您可以在代碼中使用Javascript（重載本機keyord-太可愛了！），和/或将GWT定位在手寫頁面中的特定元素上
• 網絡性能，緩存以及所有重要但繁瑣的管道細節都受益于全局優化方法。

，他的會議記錄 ：

• 托管模式的客戶浏覽器無需打開IE / firefox，即可進行UI的 Java調試
• 小部件使用CSS設定樣式
• 曆史支援實施得很好
• RPC支援允許對用戶端和伺服器代碼進行Java 重構
• 閱讀“使GWT更好”文檔
• 不支援反射/類加載。 折衷是為了在編譯器中進行積極的性能優化。
• 本機javascript可以嵌入Java源代碼中
• GWT可以內建到現有應用中
• 使用托管浏覽器的自動測試支援的幾個選項。

帶有Flex和Apollo的Rich Internet Apps

羅伯特·戈弗雷（Robert Godfrey）的筆記：

Flash應用程式絕對可以勝任 “哇”的賭注，使用Flex建構的示範應用程式看起來非常漂亮……很高興看到spring內建開箱即用。 其他有趣的事情包括：

• 性能測試，比較flex與xml和javascript。 在表格網格中呈現20000條記錄時，Flex的性能比XML / Javascript高出10倍（3秒對30秒）。
• 實時表資料編輯
• 實時協作示範顯示了通過伺服器保持2個用戶端會話同步的情況，即在一個會話中進行更新，這些示範在第二個會話中顯示。

Ruby

James Cox撰寫了整個過程的簡短總結，并總結道：“很高興看到Ruby與其他面向企業的軌道共享一個平台，支援該語言在全球市場中日益成熟和強大。”

Rich Kilmer談Ruby和DSL的藝術

Stefan Tilkov總結 ：Rich Kilmer展示了他在Ruby中建構的内部DSL的多個示例，具有廣泛的不同領域。 他花了最多時間的第一個示例是從空軍場景開始的-領域是排程和管理空中飛機加油的規則。 我認為他很好地證明了自己的DSL（在與領域專家交談時實際上是在現場設計的）如何幫助他快速了解了該領域（并使他能夠更快地解決實際問題）。 Java調試協定是一個很酷的例子：他為Ruby建構了一個庫，該庫可以通路正在運作的JVM，并在Ruby DSL中指定了該協定，然後該協定用于生成實際上通過網絡發送正确資料包的代碼。 。 非常簡潔—顯然，一些Scheme人士使用他的可執行定義來為Scheme生成協定實作。

雜種，2500條線和經濟學

Stefan 也參加了Mongrel的演講 ：

Ruby Web伺服器Mongrel大約需要2500行代碼，需要6個月的工作時間。 它是用Ruby，C和ragel編寫的。 例如，DHH向他承認，使用FastCGI時，他每天在37signals下重新開機約400次； 這些問題都消失了...他想出了這個名字是因為他讨厭Tomcat ... Mongrel不做活的原因是因為它通常位于例如Apache HTTPD的後面... Apple送出了一個更新檔，隻是希望他包括這就是他所說的“拳法”态度。

.NET

主題演講：Erik Meijer在新的Web開發平台上

摘自Stefan Tilkov的意識流 ：“ LINQ是Haskell的Monad了解，以C＃和VB實作。任何程式設計語言都可以使用LINQ（就像VB和C＃一樣）... SQL和XQuery兩者都是資料模型+查詢文法，緊密相關對于OO來說，同樣可以做到。LINQ =對任意資料的任意集合的查詢....最終報價：程式設計語言理論是相關的， 但是它需要至少20年的耐心和成熟。 蒂姆·安德森（Tim Anderson）總結道： “起點是無論在什麼平台或裝置上，使用者都希望在任何地方都具有相同的體驗。梅傑的想法是程式員應該能夠為最簡單的情況編寫代碼，這是一種直接在用戶端上運作的應用程式，并且能夠在幾乎不更改代碼的情況下将其轉換為跨平台的多層應用程式.... Meijer将相同的思想應用于并發程式設計；開發人員應該能夠通過簡單的屬性來做到這一點，而不必為同步而苦惱語句等類似的邏輯适用于狀态處理：Meijer認為程式員應該能夠有狀态地進行程式設計，并具有處理問題的基礎結構。”

我們應該給程式員一種幻想，即他們的伺服器是有狀态的，而我們可以以某種可擴充的方式實作它。 應該這樣做一次，而不是所有程式員都試圖解決該問題。

安德斯寫道 ：

他重點介紹了在實際需要做出決定之前必須如何在應用程式中做出決定。 在開發系統和實施業務規則時，您不必考慮正在使用哪個用戶端（網絡/厚等）。 如果您正在做網絡，也不必考慮并發或後退按鈕。 他們正在LINQ 2.0中建構類似的東西，這确實可以簡化開發。 那是如果它真的很好。 我與之交談的很多人（包括我在内）都對這将如何真正發揮作用和擴充表示懷疑。

邁克爾·漢格（Michael Hunger）的要點 ：

• XML的語言內建
• 查詢語言内的語言
• 資料源不限于關系資料庫
• 內建語言及其生成的動态類的編譯器安全性
• 層重構将單層方法拆分為多層（例如，用戶端-伺服器）
• 自動為各種環境和虛拟機（Windows，Flash，JavaScript等，利用用戶端的現有基礎架構）生成用戶端代碼

我認為這根本不适用于企業應用程式。 它們的複雜方式由單層重構和同步程式流處理。 對Microsoft基礎架構的關注也不是很樂觀。

Oakleafsystems還在維護有關Erik主題演講的評論的連結部落格條目 。

Windows Communication Foundation

蒂姆評論道 ：“我了解到，在進階微軟平台開發人員的市場之外，很少有人知道WCF是什麼。”

SOA：橋接業務和技術

田徑主持人Stefan Tilkov 寫了整個曲目的快速摘要 ：

安妮·托馬斯·曼内斯 （ Anne Thomas Manes）進行了很好的演講，特别是談到了如何将SOA“出售”給管理層的問題。 Paul Downey也非常出色-他非常直覺的示範為Web即服務平台提供了很好的案例。 史蒂夫·瓊斯（Steve Jones）有一個截然不同的關注點，他摒棄了技術，專注于業務方面，這是另一個很好的話題。 保羅·弗裡曼特爾（Paul Fremantle）談論了很多不同的事情，但也談到了REST-vs.-WS- *問題。 Jim Webber的講話是一個很好的結論（非常有趣），如果我不戴RESTafarian帽子，Jim的觀點就非常符合我的個人信念。

吉姆·韋伯（Jim Webber）對SOA軌道中的REST進行了評論：

我真正感到啟發的是RESTafarians坦率和誠實地承認REST不一定簡單。 實際上，要獲得适當的魯棒內建，您必須對HTTP有相當詳細的了解。 所有這些對于那些仍然将REST和POX混淆的人們來說應該是一個警報-REST聖戰者正在為您開槍:-)

銀行架構

QCon全面了解銀行體系結構。 IASA建築師Matt Deacon 參加了其中的一次演講并發表了評論：

技術是銀行業的主要業務驅動力。” 克雷格·海馬克（Craig Heimark）在今天的QCon會議上說，并不是業務真的意識到，他們所看到的隻是競争格局的變化。 但是，正如他所說的那樣，這種變化是由傳播的巨大挑戰所驅動的（盡管啟用啟用可能是一個更好的詞），并迫使從集中式垂直模型到由單一價值專家組成的分散式模型重新配置。 其結果是以犧牲利潤為代價為消費者創造了增值； 音量越高，邊際利潤越低。 這導緻大規模定制，并最終導緻由消費者需求驅動的服務捆綁。

阿德裡安·特雷曼 （ Adrian Treneman）撰寫了各種演講：

看到這些東西之間的相關性，這是加倍的收獲：AMQP現在是一個熱門話題，并且能夠将AMQP簡單地配置到純Java JAX-WS用戶端或服務中的功能真的很棒。 同樣，正如Travelex的Sailesh Panchal渴望在他的演講中指出的那樣，在産生真正可重用的服務，同時支援REST和SOA體系結構方面，在多種傳輸上支援XML和SOAP負載的能力非常重要。

普通的留言：

• “ [Erik Meijer]不喜歡AOP ，不相信事後再添加可能會破壞現有代碼不變性的内容。将部分方法作為替代。是以與原始代碼的作者AOP相比，說其他人可以在其中編織自己的東西。”
• TheRegister評論了建築師的本質 ：“馬丁·福勒（Martin Fowler）在本周的QCon會議上發表了一條有趣的評論：“有時，我們在Thoughtworks遇到“建築師”一詞的麻煩，主要是因為我們遇到了一些自稱是建築師的人。”還提到了活動中可用的書籍 。
• 在Qcon上聽到的有趣的說法是 ：
• • Ted Neward-VB使經理能夠編寫程式。 問題是他們确實做到了！
  • 奧比·費爾南德斯（Obie Fernandez）-露比（Ruby）有太多繩子可以挂掉整個團隊。
  • 歸因于敬虔:-)
  • QCon上的ThoughtWorks和FowlBots ：“說明您的名稱”。 “我是馬丁的七歲。”
• Stefan Tilkov寫道 ：QCon 2008我需要記住兩個規則：
• • 不要在Martin Fowler周圍提及MDA。 這使他很早就離開了聚會。
  • 不要與Eric Meijer，Patrick Linskey和Cedric Beust讨論程式設計語言理論。 尤其不要在淩晨2點30分之後飲用過多的酒精飲料;-)

關于Qcon本身的觀點：

• 這是我有史以來第一次參加會議，我相信這是一個很棒的會議！ 我的意思是，你怎麼能出錯，音箱就像Martin Fowler的 ， 戴夫·托馬斯 ， 傑夫·薩瑟蘭和詹姆斯Coplien，隻是僅舉幾例- 城市 。
• 感謝您制作的QCon。 并感謝您與InfoQ的良好合作。 做得好，非常有益的内容。 -吉裡·倫達克（Jiri Lundak）
• 總而言之，這是一個很棒的安排，我帶着很多靈感和動力回到了我的身邊，這将使我持續很長時間。 謝謝！ - 詹斯·諾林 （ Jens Norin）
• “純粹的想法和有趣的戰争故事的數量僅與所消費啤酒的數量相比對”- 吉姆·韋伯
• “這次會議提供的新思想和強化的舊思想證明了每投入一歐元是合理的！” -從LuismiCavallé的部落格翻譯成西班牙語。
• “對于這次會議，我感到非常高興：這裡的位置絕對很棒，能夠參加非Java的曲目來進行更改真是太好了。向Floyd，Alexandru和其他從業人員緻敬一流的會議！” - 塞德裡克·貝斯特
• 周五的QCon很有趣，有很多好的想法和讨論-Dave Crane
• 我認為這是一次很棒的會議，從我收集到的回報來看，大多數人都同意...我度過了愉快的時光-我進行了很多有趣的對話，其中一些對話是我在網上認識多年的，直到現在，我和在那兒認識的人都親自見面，光是這一次就值得參加。 - 斯蒂芬·蒂爾科夫 （ Stefan Tilkov）
• QCon感覺像一個“适當的”會議。 這可能是首屆活動，但确實感覺像是一個小型JavaOne風格的會議。 說到Java，Sun幾乎在QEII會議中心（QCon所在的地方）的隔壁舉行了技術日活動，我遇到了一些印象深刻的人。 實際上，我認識的幾個人實際上遇到了，并在門上購買了會議通行證。 - 西蒙·布朗
• 與我，項目經理/技術架構師/團隊負責人/開發人員一樣的許多人參加了該教程。 -本
• 第一次QCon昨天結束了，很高興能參與其中。 - 埃卡 （ Mikael Essle）
• 昨天的總體情況非常好，并提供了許多重要的建議。 - 安德斯
• 我在周五參加了QCon ，并留下了深刻的印象。 内容非常好，幾乎看不到銷售毛病。 - 羅伯特·戈弗雷

結論

QCon取得了巨大的成功，我們為能夠舉辦這樣的會議而感到自豪，而InfoQ甚至還沒有到成立一周年。 這将成為倫敦的年度盛會，下一屆QCon将于明年同一時間舉行。 我們還将最終每年将QCon引入美國，并可能将InfoQ引入其他地區。 謝謝大家的光臨，我們明年見！！！！！

翻譯自: https://www.infoq.com/articles/qcon-2007-bloggers-summary/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

qcon