\u0026#xd;\n\u0026#xd;\n將版本號直接提公升至1.0是非常艱難的選擇。一方面你希望1.0是乙個盡善盡美的版本，但是你又意識到沒有任何軟體可以盡善盡美，於是你又不得不使用其他的標準來幫助你做出決定。之所以這樣做，是因為我們認為1.0這個版本號意味著api已經趨於穩定。也就是說，使用者使用的公共api和外掛程式作者使用的「半公共」的api都不會做出任何修改。雖然2.0的api可能會加入一些新功能，但是使用1.0的api的**應該只需要在2.0發布的時候做一些細微的修改。當dm還是乙個新興專案的時候（大概兩年以前），api一直在不斷變化，但在最近的6到12個月，api已經趨於穩定，我們對此感到非常高興。
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n我想開發者們會發現很多激動人心的特性，但是，我想從大多數只有activerecord經驗的人關注的事情開始介紹，而且這也是dm如何自然表達的地方。在dm中，每乙個屬性和關係都是在模型中宣告，然後作為可信的**使用，而不是需要將這些屬性關係儲存到資料庫中。你需要指定某處的一些限制和行為，而且所有的東西都是從模型中反映，然後在遷移、驗證或者其他的行為的時候使用。下面是乙個簡單的例子：
\u0026#xd;\n
在 activerecord中，則要求你在不同的檔案中切換，而且要牢記讓資料在db和驗證器中保持同步。但是，很多情況下，開發者不僅僅厭煩了各種型別驗證，而且還認為他們的db只是乙個「愚蠢的」資料儲存裝置，而dm能夠減輕開發者的痛苦。我們鼓勵開發者利用好底層資料儲存的優勢，而不要將其認為只是資料的傾倒場所。
\u0026#xd;\n
我曾經在轉到dm之前使用過ar，結果我都幾乎忘掉了在我的db中有哪些字段，所以我不得不執行例如annotate_models來在我的模型頂部新增注釋，寫明當前的db schema。實際上我使用都是和dm差不多的功能，除了沒有享受到dm能夠提供的那些優點。我仍然需要寫明所有的驗證器和初始遷移。
\u0026#xd;\n
ruby on rails 2.x的流行以及完全重寫的rails 3發布的近在咫尺，於是我們將dm和rails專案的整合也提上了日程。任何開發者在考慮不走尋常路之前，需要仔細地衡量一下從activerecord 遷移的好處以及實現的難度。我們討論了將dm和rails整合使用，而且，試驗的結果非常積極和高效：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n我們非常高興地看到dm-rails是如何順利發展的，而且，在未來它的一些核心將會被提取出來，放置到乙個gem中間，這樣的話我們可以能夠在所有的 web框架上都保持一致的rake task，模型（重新）載入等功能。此特點允許dm能夠更簡單深入地和其他框架一起工作。
\u0026#xd;\n
決定在rails專案中使用dm而不是activerecord會產生一些疑問，例如對於開發者來說，適應另外一種orm的難度如何呢？我們希望能夠知道dm是否能夠完全在rails專案中替代activerecord，而不僅僅是乙個替代品：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n是的，沒錯。使用dm，你需要在你現有的類中引入乙個module。大多數ar finder都可以在dm中找到對應的存在，而且有些時候這些finder甚至要比ar中的簡單。我們同樣也支援所有的驗證器，而且有大概150個dm相關的gem可用。雖然在某些情況下，語法有點差異，但是，我非常自信地說，dm能夠做ar所有能夠滿足需要的事情，而且不需要外掛程式的幫助。
\u0026#xd;\n
dm中乙個非常有意思的特性是所有的屬性和關係都是在模型中宣告的。這樣的話，看起來將不再需要rails的遷移，但是，很快dan就意識到遷移必不可少：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n只是部分情況下不需要遷移，一旦你需要將你的程式投入生產應用中去，那麼遷移是仍然需要的，因為你已經告訴db如何修改以儲存資訊。而且，會有這樣一些情況，例如auto-migrations會是毀滅性的，因為它們會解除安裝所有的表，然後重新按照宣告的模型建立這些表，auto-upgrading新增新的表、列和索引，但是它不夠聰明，能夠做一些例如重新命名，刪除列以及將列分解成多列的操作。我並不完全相信它能夠非常聰明地完成這些事情，除非你能夠顯示地說明在遷移中你需要的事情。但是，如果需要將auto-upgrading加入到你的遷移過程，用它來處理額外的修改，以及使用顯示的遷移指令碼來處理可能會出現崩潰或者引起歧義的問題的話，那麼我認為遷移的過程確實應該被簡化。
\u0026#xd;\n
即便如此，我們仍需要考慮生成能夠簡化過程的遷移指令碼。它應該能夠分清模型之間的差異，最後能夠自動執行修改的遷移指令碼。開發者應該檢查遷移指令碼是否做了你希望做的事情，然後部署即可，但是編寫遷移指令碼並不是表示你可以做個甩手掌櫃，我們必須很清楚有一些額外情況需要處理，例如可能會出現崩潰或者引起歧義的問題。
\u0026#xd;\n
dm介紹了automigrations，這個工具能夠幫助開發者進行典型的rails遷移：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n對快速開發而言，這無疑是乙個巨大的勝利。具有tdd的能力和只需要在模型和規範之間快速切換來增加新的屬性，比在模型、遷移指令碼和規範之間不斷地切換要簡單很多，而且後者還會打斷你的遷移過程以及資料庫儲存。
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n這讓我能夠感受到dm沒有人談論過的乙個優點。每一種儲存引擎被加入到dm之後，就會有資訊被反饋到dm的核心開發團隊，最後將會反映在下乙個版本的介面卡api中。所以每乙個介面卡的建立，都意味著未來將能夠更容易地加入更多的介面卡，從而新增更多功能。例如，有乙個在mongodb介面卡的專案，它有一些功能不被dm支援，但是會影響未來dm的開發。這個外掛程式的開發者便幫助dm新增了對這些功能的支援。在mongo中內嵌資源等能夠使用內嵌值之類的來實現，而且能夠和現存的介面卡工作的很好。
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\ndm的目標使用者是這樣的開發者，儘管也許有的時候rdbms並不是那麼適合，但是他們能夠意識到，未來大多數應用程式將會和儲存結構資料的關聯式資料庫，以及儲存非結構化或者可變資料的nosql資料庫繫結在一起。現在關於rdbms和nosql孰優孰劣的爭論是非常愚蠢的。只有在某種特定的應用中才能知道哪個更好，而且大多數的應用程式都需要二者的結合；這不是乙個或此或彼的命題。
\u0026#xd;\n
檢視英文原文：
DataMapper 1 0里程碑將至
將版本號直接提公升至1.0是非常艱難的選擇。一方面你希望1.0是乙個盡善盡美的版本，但是你又意識到沒有任何軟體可以盡善盡美，於是你又不得不使用其他的標準來幫助你做出決定。之所以這樣做，是因為我們認為1.0這個版本號意味著api已經趨於穩定。也就是說，使用者使用的公共api和外掛程式作者使用的 半公共...
Scala 2 10 0里程碑3登陸
scala是jvm多正規化語言的最新里程碑，它使狂熱的粉絲瞥見了該語言即將面世的一些新花絮。儘管稱他們為花絮也許低估了發行版。在scala 2.9之後，針對scala 2.10.0的typesafe團隊已經制定了巨集偉的計畫，該團隊在ide和並行庫方面取得了進步。里程碑3顯示了在短時間內取得了多少進...
如何在 Project 裡設定 建立 里程碑
很簡單，建立乙個零工期的任務，project 會自動顯示為里程碑。更詳細內容可參考project幫助 在 檢視 選單上，單擊 甘特圖 在要更改的任務 任務 一種有開始日期和完成日期的操作。專案計畫由任務組成。的 工期 域中鍵入0。按 enter。當為任務輸入零工期 工期 完成任務所需的有效工作時間的...