本週專案：Dat
本週的精選專案是 Dat，這是一個獲得補助的開源分散式工具，用於發佈資料集。Dat 由一個地理分散的團隊建置和維護，其中許多人協助撰寫了這篇文章。
首先，Dat 是什麼？
我們希望將點對點和分散式系統的最佳部分帶入資料分享。我們從科學資料分享開始，然後開始擴展到研究機構、政府、公共服務和開源團隊。
另一種思考方式是像 Dropbox 或 BitTorrent Sync 一樣的同步和上傳應用程式，但 Dat 是開源的。我們的目標是成為一個強大、開源、非營利的資料分享軟體，適用於大型、小型、中型、小批量和大批量資料。
要使用 dat CLI 工具，您只需輸入
dat share path/to/my/folder
而 dat 會建立一個連結，您可以使用該連結將該資料夾傳送給其他人 — 沒有中央伺服器或第三方可以存取您的資料。與 BitTorrent 不同的是，也不可能嗅探誰在分享什麼（請參閱 Dat 論文草稿以瞭解更多詳細資訊）。
現在我們知道 Dat 是什麼了。Dat Desktop 如何融入？
Dat Desktop 是一種讓無法或不想使用命令列的人可以存取 Dat 的方式。您可以在您的電腦上託管多個 dat 並透過您的網路提供資料。
您可以分享一些很棒的用例嗎？
DataRefuge + Svalbard 專案
我們正在研究一個代號為Svalbard 專案的專案，它與DataRefuge有關，該群體致力於備份可能消失的政府氣候資料。斯瓦爾巴群島以北極地區的斯瓦爾巴全球種子庫命名，該種子庫有一個大型的地下植物 DNA 備份程式庫。我們的版本是一個大型的、版本控制的公共科學資料集集合。一旦我們知道並可以信任元資料，我們就可以建置其他很棒的專案，例如分散式志願者資料儲存網路。
加州公民資料聯盟
CACivicData 是一個開源檔案，每天提供來自 CAL-ACCESS 的下載，CAL-ACCESS 是加州追蹤政治資金的資料庫。他們會每天發佈，這意味著在其 zip 檔案中託管大量重複資料。我們正在努力將其資料託管為 Dat 儲存庫，這將減少引用特定版本或更新到較新版本所需的麻煩和頻寬。
Electron 更新
這個還沒有具體定案，但我們認為一個有趣的用例是將已編譯的 Electron 應用程式放入 Dat 儲存庫中，然後在 Electron 中使用 Dat 用戶端提取已建置應用程式二進位檔的最新差異，以節省下載時間，同時降低伺服器的頻寬成本。
誰應該使用 Dat Desktop？
任何想要透過 p2p 網路分享和更新資料的人。資料科學家、開放資料駭客、研究人員、開發人員。如果任何人有我們尚未想到的很棒的用例，我們都非常樂意收到回饋。您可以加入我們的Gitter 聊天室並隨時提問！
Dat 和 Dat Desktop 的下一步是什麼？
使用者帳號與元數據發布。我們正在開發一個 Dat 註冊表網頁應用程式，將部署於 datproject.org，基本上會是一個「資料集的 NPM」，但需要注意的是，我們只會是一個元數據目錄，而資料可以存放在網路上的任何地方（不像 NPM 或 GitHub 所有資料都集中託管，因為原始碼夠小，可以全部放在一個系統中）。由於許多資料集都非常龐大，我們需要一個聯合註冊表（類似 BitTorrent 追蹤器的工作方式）。我們希望讓使用者可以輕鬆地從 Dat Desktop 中尋找或發布資料集到註冊表，以使資料分享過程順暢無阻。
另一個功能是多寫入者／協作資料夾。我們有很大的計畫來實現協作工作流程，也許會包含分支，類似於 git，但設計會圍繞資料集協作。不過我們目前仍在努力確保整體穩定性並標準化我們的協定！
你們為什麼選擇使用 Electron 來建構 Dat Desktop？
Dat 是使用 Node.js 建構的，因此它是我們整合的自然選擇。除此之外，我們的使用者使用各種不同的機器，因為科學家、研究人員和政府官員可能被迫使用他們機構的特定設定——這表示我們需要能夠針對 Windows、Linux 以及 Mac。Dat Desktop 可以輕鬆地滿足我們的需求。
你們在建構 Dat 和 Dat Desktop 時遇到哪些挑戰？
弄清楚人們想要什麼。我們從表格資料集開始，但我們意識到這是一個有點複雜的問題，而且大多數人都不使用資料庫。因此，在專案進行到一半時，我們從頭開始重新設計所有內容，改為使用檔案系統，並且沒有回頭。
我們也遇到一些通用的 Electron 基礎設施問題，包括：
- 遙測 - 如何收集匿名使用統計資料
- 更新 - 設定自動更新有點零散且像魔法般
- 發布 - XCode 簽署、在 Travis 上建構發布版本、進行 Beta 版本，這些都是挑戰。
我們也在 Dat Desktop 的「前端」程式碼中使用 Browserify 和一些酷炫的 Browserify Transforms（這有點奇怪，因為即使我們有原生的 require，我們仍然會進行捆綁——但這是因為我們需要 Transforms）。為了更好地管理我們的 CSS，我們從 Sass 切換到使用 sheetify。它極大地幫助我們模組化我們的 CSS，並讓我們更容易將 UI 移至具有共享相依性的元件導向架構。例如，dat-colors 包含我們所有的顏色，並在我們所有專案之間共享。
我們一直以來都是標準和最小抽象的忠實粉絲。我們整個介面都是使用一般的 DOM 節點和幾個輔助函式庫建構的。我們已經開始將其中一些元件移至 base-elements，這是一個低階可重複使用元件的函式庫。與我們的大部分技術一樣，我們會不斷迭代它直到我們做對為止，但作為一個團隊，我們覺得我們正朝著正確的方向前進。
Electron 在哪些方面應該改進？
我們認為最大的痛點是原生模組。必須使用 npm 為 Electron 重建你的模組，這增加了工作流程的複雜性。我們的團隊開發了一個名為 prebuild 的模組，它可以處理預建二進制檔案，這對 Node 來說效果很好，但是 Electron 的工作流程仍然需要在安裝後執行一個自訂步驟，通常是 npm run rebuild。這很煩人。為了解決這個問題，我們最近切換到一種策略，將所有平台的所有已編譯二進制版本捆綁在 npm tarball 中。這表示 tarball 會變得更大（雖然可以使用 .so 檔案 - 共享函式庫進行優化），但這種方法可以避免執行安裝後腳本，也可以完全避免 npm run rebuild 模式。這表示 npm install 第一次就能為 Electron 執行正確的操作。
你們最喜歡 Electron 的哪些地方？
API 看起來經過深思熟慮，它相對穩定，並且在與上游 Node 版本保持同步方面做得很好，我們沒有太多其他可以要求的了！
有沒有任何對其他開發人員有用的 Electron 提示？
如果您使用原生模組，請試試看 prebuild！
追蹤 Dat 開發進度的最佳方式是什麼？
在 Twitter 上追蹤 @dat_project，或訂閱我們的電子郵件新聞通訊。