本周项目:Dat
本周的特色项目是 Dat,这是一个受资助的、开源的、用于分发数据集的去中心化工具。Dat 由一个地理分布的团队构建和维护,其中许多人都参与了这篇文章的撰写。
首先,Dat 是什么?
我们希望将点对点和分布式系统的优点带入数据共享。我们从科学数据共享开始,然后扩展到研究机构、政府、公共服务和开源团队。
另一种理解方式是,它是一个类似于 Dropbox 或 BitTorrent Sync 的同步和上传应用程序,不同之处在于 Dat 是开源的。我们的目标是成为一个强大、开源、非营利的数据共享软件,适用于大、中、小型以及小批量和大批量数据。
要使用 dat
命令行工具,您只需输入
dat share path/to/my/folder
然后 dat 会创建一个链接,您可以用来将该文件夹发送给其他人——没有中央服务器或第三方能够访问您的数据。与 BitTorrent 不同,它也无法嗅探谁在分享什么(详情请参见 Dat Paper 草稿)。
现在我们知道了 Dat 是什么。Dat Desktop 是如何融入的?
Dat Desktop 是一种让不习惯或不愿使用命令行的用户也能使用 Dat 的方式。您可以在自己的机器上托管多个 dat,并通过网络提供数据。
能分享一些很酷的用例吗?
DataRefuge + Svalbard 项目
我们正在开发一个代号为Svalbard 项目的东西,它与DataRefuge 相关,DataRefuge 是一个致力于备份面临消失风险的政府气候数据的团体。Svalbard 以北极的斯瓦尔巴全球种子库命名,该种子库拥有庞大的地下植物 DNA 备份库。我们的版本是一个大型的、受版本控制的公共科学数据集集合。一旦我们了解并信任元数据,我们就可以构建其他很酷的项目,例如分布式志愿者数据存储网络。
加州公民数据联盟
CACivicData 是一个开源档案库,提供来自 CAL-ACCESS 的每日下载,CAL-ACCESS 是加州追踪政治资金的数据库。他们进行每日发布,这意味着他们的 zip 文件中托管了大量重复数据。我们正在努力将他们的数据托管为 Dat 仓库,这将减少引用特定版本或更新到新版本所需的麻烦和带宽。
Electron 更新
这个想法尚未具体实现,但我们认为一个有趣的用例是将编译好的 Electron 应用程序放入 Dat 仓库,然后在 Electron 中使用 Dat 客户端拉取构建好的应用程序二进制文件的最新增量,这样可以节省下载时间,同时也可以降低服务器的带宽成本。
谁应该使用 Dat Desktop?
任何希望通过 P2P 网络共享和更新数据的人都可以使用。数据科学家、开放数据黑客、研究人员、开发人员。如果有人想到我们尚未考虑到的酷炫用例,我们非常乐意听取反馈。您可以访问我们的 Gitter 聊天室并提出任何问题!
Dat 和 Dat Desktop 的下一步计划是什么?
用户账户和元数据发布。我们正在开发一个 Dat 注册表 Web 应用程序,将部署在 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,或订阅我们的电子邮件通讯。