Bestony 发布的文章

2019 年 8 月 17 - 18 日,我参加了心念已久的在台湾连续举办了 14 届的 COSCUP 2019,并在会后,进行了一系列的开源访谈,以期促进两岸的开源软件、开源社群、开源人的交流。

这次的台湾之行,也让我看到了两岸在开源之间的差异,因此,希望能够通过这一篇文章,让更多的大陆开源人,看到不同的世界,了解多元的开源世界。

源自长荣航空广告

Just For Fun 的开源事业

Linux 之父 Linus Torvalds 有一本书 《Just For Fun》,在中国大陆的书名是 《只是为了好玩》(也有译作《一生只为寻欢笑》),这一句话,在我看来,很好的表现出台湾开源人的精神风貌。

在台湾参会期间,令我印象最为深刻的,莫过于所有议程结束后的 Lighting Talk。

Lighting Talk,闪电演讲,每个人都只有 5 分钟完成自己的演讲,如果没有完成,就会被主持人拔掉电源,强制停止演讲。在这五分钟里,每一个演讲者都竭尽所能,将自己的演讲内容完成。

现在听起来似乎还很正常?但是当你看到演讲者的题目,就会觉得不那么正常了。

今年的 COSCUP 的 Lighting Talk 的主题是这样的

  • 聖家堂與軟體開發 by hlb
  • 開源與 COSCUP 起源圖文 by 唐唐
  • 不務正業工程師成長之路 by 聽風
  • How to get beer using Pinpoint by HyunGil Jeong
  • HackMD feat. XXX by 黃鈺凱
  • 如何(物理上的)延長你的工程師生涯 by LSChyi
  • 機房監控酷炫上手 by Haraguroicha Hsu
  • 我在Taipei Ethereum Meetup的跳坑滅頂全記錄 by Jerry Ho
  • 基於數據科學的房地產價格預測,做成Chat bot應用,最後如何被政府一句話終止開發 - 柯克
  • 如何才能做好自己的工作Side Project by 白宦成
  • 4分鐘看Free list的演進 by Julian
  • 報到 App - OPass 專案回顧及展望 by Denny Huang

你会看到,大家提供的议题并不像我们在大陆所提交的议题那样,高端大气上档次,反而是十分的接地气,大家在起标题时,选择的也是尽可能有意思的话题,并以此来吸引参会者来听。

或许你会想,只是一个 Lighting Talk,随意一点也正常,正式的议题肯定就很正经了,然而,并不是。

正式的议题是这样的:

  • 懶惰鬼的函數式爬蟲 ー 以 Tezos 應用需求為例
  • 當 Rails 遇上 Docker,環境部署原來是這樣!?
  • 開拓者們建立鐵道的辛酸血淚史
  • 前端開發的再次典範轉移 - 如何走出混亂並讓複雜變的可掌控
  • 你媽知道你在用 PostgreSQL 看 PTT 嗎?

是的,正式议题也并不那么正式,也带有一丝戏谑和玩笑。回过头来看我们的大会的议题,支撑亿级 XX 的 XX 平台架构实践XXX 面对亿级并发场景的组件体系设计,此类型的议题数不胜数。一场大会,从头到尾都是亿级流量,如今的架构师,如果没有扛过亿级流量,都没有资格上大会。

这种差异,使得两岸的开源会议的参与者完全不同。大陆的会议主题大多高端大气上档次,其门票也一样的高端大气上档次,使得大家根本提不起兴趣来自费参会,加上会议总是会在工作日举办,导致如果你想要自费参会,所要付出的成本是极高的。而台湾的会议主题则相对更加的接地气,门票一样接地气,针对开源贡献者,更是提供的免费的门票,让你可以开开心心参会。

台湾开源推崇的便是 “Just For Fun”,首先先要让开发者 Happy ,然后才是考虑产品的商业利益,让爱好,变为财富。首先学会快乐,再学会成功。

而大陆开源推崇的更多是“利益至上”,我如何让我的产品击败别人的产品?开发者先要考虑商业的利益,再去考虑自己的爱好。从一开始,便与利益挂钩,后续,便再也难于利益脱钩。

当然,我不能只是一味的说,台湾的开源更活泼、更有生机,我们也需要看到其后的原因,并提出相应的解决方案。

台湾之所以更活跃,首先应当是开源项目主要由个人及小企业主导。对于个人主导的开源项目来说,因为没有重重的 KPI,所以拥有更多的活力,开发者会大量投入自己的精力去完成、完善、推广一个项目。对于小企业主导的项目,则是希望帮助小企业在残酷的商业竞争中获取一定的竞争优势,有一个社区所认可的开源项目显然比没有要好。此外,这些小企业的团队领导人大多是从工程师起来的,所以对于开源社区、开源贡献是有认同感的,他们会思考,我的项目能够活下来,是得益于开源社区的贡献,因此,我需要也为社区做一些贡献。

而大陆的开源项目则更多是以企业主导,背负着特定的 KPI,大家做开源的动力难免不足。一方面,工作的压力使得不少人在工作之余,根本没有时间去做开源项目。另一方面,企业主导的开源项目因为也会背负一些从开源到业务引流的 KPI,也使得整个过程失去了快乐与活力。同时,大陆的企业领导者大多不是工程师,而是产品、商务等岗位,这会使得他们对于开源社区、开源软件没有认同感,他们也不会觉得,自己使用了开源软件,就需要为开源社区做出贡献。此外,大陆的开源教育也做的并不好,我们太过于看重成败,使得原本一些不错的项目,可能因为惧怕失败而放弃开源,如果我们不去看重成败,而是将更多的心思放在开源本身的价值,或许我们可以做的更好。

就像前面的长荣航空的广告中所言,在学会赢之前,先学会享受了玩的乐趣,也因此,才有了“乐在其中,才会无限精彩”。对于大陆的我们,或许需要找回自己最初的初心,享受生活、享受工作,让自己的工作不再是抑制成长的压力,而是推动我们前进的动力。

当然, Just For Fun 并非全然没有问题的,就如 Skywalking 的创始人吴晟老师所言,开源不能仅仅是 Just For Fun ,如果没有一个好的商业目标,一个好的开源项目可能随时因为创始人的离去而失去维护者。相比之下,一个好的商业目标虽然看起来与起初的目标相冲突,但是终归确保了开源项目的长期运转,也不失是一种贡献。

(题图来自:2019!開源久酒!

Logoly.Pro 是一个在线的 PornHub 风格 Logo 生成工具,可以帮助你快速生成类似 PornHub 风格的 Logo。

目前项目已经上线:https://logoly.pro/代码也已开源:https://github.com/bestony/logoly

欢迎各位前来试用 && 求 Star !


昨晚,我花了 5 个小时,在肝一个项目,如今,让它成功上线,我便向大家介绍一下它。

突发的灵感

我自己平时经常要做一些业余项目,在做业余项目的时候,就涉及到了要做 Logo ,但是作为一个没有设计感的程序员,在做 Logo 时总是会做出一些很丑的 Logo ,于是痛定思痛,想想有没有什么有用的工具可以帮助我生成好看的 Logo。对于我来说,也不需要太过复杂,能够满足我自己的要求就行。

那么这就要求这个 Logo 有一些特点

  1. 设计简单:很多带吉祥物的 Logo 就不适合我了,因为要去准备吉祥物的图片。
  2. 辨识度高:单纯的简单并没有太多的用处, Logo 需要让用户能够记住

经过一番筛选,PornHub 的 Logo 进入到我的视线。

设计产品

在开发之前,我先进行了产品方面的考虑,看看我需要做哪些功能,哪些不做,最终得到了这样一个清单:

要做的项目

  1. 项目使用 Vue 开发,因为可以快速上线
  2. 项目使用 Netlify 部署,这样就可以使用自己的域名,并使用 SSL,速度还要比 Github Pages 快一些。
  3. 项目应当支持自定义文字,这个是最基础的功能需求,必须要做的。
  4. 项目应当支持自定义颜色,毕竟可能有其他的方面,需要类似风格,但是不同的颜色的 Logo
  5. 项目应当支持自定义文字大小,毕竟我导出的是 PNG,如果不能自定义大小,大家可能会很困扰。
  6. 项目应当加入 Google Analytics,加入统计,就知道有多少人用过我的项目了,也是一种成就感。
  7. 项目应当加入我的个人信息,用来给我自己推广,顺便刷一波脸。
  8. 社会化分享,应当有个方便的分享方法,这样才能够更好的帮助项目在前期成长。

不做的项目

  1. 自定义字体:原汁原味的 PH 风格,怎能瞎改字体呢?
  2. 导出 JPG: 有了透明背景的 PNG,不透明的 JPG 的需求就没那么大了。

后续迭代实现的

  1. 其他简单的 Logo:比如 Youtube.

设计布局

在完成了产品的功能,我又进行了布局的设计,这次我用的是 Adobe XD,最近很喜欢用这个工具来设计产品的界面,非常的方便。最终设计完成的版本如下:

设计完成后,就要开始准备开始编码了。

找库

一开始,我考虑使用一些 UI 框架,不过,由于一开始没有引入 UI 框架,快写完了才发现基本不需要组件库,干脆将错就错,这样用了。

在完成了基本的界面后,就是涉及到的一些库的使用了,这里要感谢前端生态圈的繁荣,我从 PicasCarbon 的源码里找到了我想要用的库。

  • dom-to-image:将 Dom 元素转换成为图片,以备下载。
  • file-save:在 Vue 组件里调用系统的下载接口,下载图片

其他我用到的库还有

  • v-tooltips:用户提醒,之前用的 Vue-Tour,但是跳跃感太强了,所以弃用了。
  • vue-analytics:Vue 下的 Google Analytics 工具,可以很方便的调用 GA 进行统计。

上线

在完成了开发后,将代码上传到 Github,准备部署。

在前面提到,我考虑用 Netlify 进行部署,这里非常方便,在 Netlify 上直接创建项目,选择你的项目,然后填入命令即可。

并配置一下域名,将自己的域名设置为主域名:

稍等一会,就会自动为你的域名签注 Let’s Encrypt 的证书。

最后

关于这个项目的故事,我已经说完了所有我能想到的了,接下来,就是你的提问时间了,欢迎你针对项目对我提问,无论是产品、设计、编码,都可以~

希望大家能够给这个项目一个 Star: https://github.com/bestony/logoly

这篇文章将会教你如何在 10 分钟中内借助 WordPress 搭建一个支持 ERC20 通证的在线 B2C 商城。

在区块链及通证经济备受瞩目的今天,很多开源社区纷纷在探讨如何将开源社区与区块链技术和通证经济相结合,从而为开源社区和开源生态提供自主、自洽、发展的动力和支持。我们 “Linux 中国”就是这诸多探索的开源社区之一。可喜的是,我们已经迈出了第一步:发布社区通证,也迈出了第二步,使通证流通起来。这里,我们愿意分享我们的经验给各个社区伙伴,使更多的开源社区也可以投身于新的生态探索,避开一些我们遇到的陷阱,从而共同营造一个更繁荣的开源世界。

我们的通证商城是基于 WordPress 的 WooCommerce 商城构建的。

安装 WordPress

在开始配置商城前,你需要先安装 WordPress 。你需要购买一个支持 PHP + MySQL 的虚拟主机,或自行配置 VPS、云服务器的环境,以支持 WordPress 的运行。

当你安装好 WordPress 后,你可以看到一个这样的后台。

安装 WooCommerce

安装完 WordPress 后,接下来安装 WordPress 的商城插件 WooCommerce ,点击菜单栏中的“插件”-“安装插件”,访问到安装插件的界面,在界面右上角的搜索框内容输入“WooCommerce”,并按下回车,可以搜索到 WooCommerce 。

点击现在安装,来安装 WooCommerce。安装完成后,点击“启用”,启用插件。

启用插件后, WooCommerce 会引导你进行初始化配置,根据提示对插件进行配置。

必要时,可以允许线下支付,但是针对加密货币而言,目前看起来不需要线下支付场景:

并设置邮费:

插件安装时,取消 MailChimp 的安装,仅启用 StoreFront:

并视需要觉得是否安装还是跳过 JetPack :

当你看到如图所示的界面时,就说明完成了初始化的配置了。

点击访问控制面板,回到 WordPress 界面。

添加 ERC20 通证作为支付货币

为了原生支持 ERC20 通证来实现支付,从而免去汇率换算,我们需要添加一款自定义的货币。

打开“插件”-“安装插件”,在关键词中输入 “Woocommerce Customize ERC20 Currency”并回车。这是我们联合硬核区块链公司开发的一款用于给 WooCommerce 增加 ERC20 货币的插件,该插件已经开源于 GitHub

找到 “Woocommerce Customize ERC20 Currency” 插件,并安装。

安装,并启用 “Woocommerce Customize ERC20 Currency”。

启用插件后,点击左侧菜单中的“设置”-“WooCommerce ERC20 货币自定义”,进入到插件的设置界面。

在插件的设置界面,你可以设置需要添加的货币的名称和对应的符号。比如这里我设置为 “LCCN” 和 “Ⓛ”,并点击“保存”。

保存后,点击左侧菜单栏中的“WooCommerce”-“设置”,进入到 WooCommerce 设置界面,在常规选项中,拖动到最底部,可以看到币种选项。点击货币,找到你自己设置的货币后,点击“设置”,并“保存”设置。

此时,站点的商品便以你自己设定的 ERC20 通证作为支付货币进行交易了。

安装 ERC20 通证支付网关

接下来,我们来安装“Woocommerce ERC20 Payment Gateway” 来开启站点的 ERC20 Token 的支付支持。这也是我们联合硬核区块链公司开发的一款用于给 WooCommerce 提供 ERC20 货币支付支持的插件,该插件已经开源于 GitHub

点击左侧菜单栏中的“插件”-“安装插件”,在关键词中输入 “Woocommerce ERC20 Payment Gateway”,并回车,找到 “Woocommerce ERC20 Payment Gateway”并安装、启用。

安装,并启用完成后,点击插件后的“设置”,进入到设置页面。

在设置页面,启用 “使用 ERC 20 Token 支付”这一支付方式,并保存。

然后点击支付方式后面的“设置”,进入到插件的设置界面。

首先,设置一些支付方式的基础信息。

标题是支付方式的标题,将会展示在结账的页面,因此,你可以将其设置为诸如“使用 LCCN 支付费用”或其他内容,让顾客明白此支付方式为使用通证支付。

描述会展示在支付方式的下方,同样的,你可以设置为 “使用 LCCN 支付费用”,此外,还建议你在此引导顾客安装、并打开 Metask 插件,切换到主网络,确保后续支付。

支付方式图标则会展示在支付方式标题后,将其设置为你的通证的图标,以获得更明显的提醒效果。

三者具体的示意图如下

支付方式设置完成后,接下来设置与 ERC20 通证有关的内容。

钱包地址为顾客支付时转账的对象,将其设置为你自己的钱包地址即可。

合约 ABI 则可以在 etherscan 中找到,比如,LCCN 的合约地址为:https://etherscan.io/address/0x8f4f3b3c3a900d10e9cf74c30e16f5958d8fd339#code,由于 LCCN 公开了其合约源代码,其 ABI 可以在合约的界面找到(如未公开,请向你的 ERC20 合约开发人员索要 ABI),点击右侧 “Copy”,复制 ABI,并将其填入设置项目中去。

合约地址为你的合约在对应网络中的地址。切记,如果你是测试环境,就需要将其设置为对应测试网络下的合约地址,如果是生产环境,就设置为主网的合约地址。

Gas 提醒这里是用来提醒用户支付时选择较高的 Gas ,从而加快确认的速度。你可以根据自己的需要设置具体的内容,也可以使用默认的语句。

至此,插件就已经设置完成了。

测试支付

插件设置完成后,我们来新建一个产品,用于测试。点击顶栏中的“新建”-“产品”,进入到创建产品的界面。

在产品界面输入产品名称、描述、售价等信息:

然后点击发布,创建新的产品。并点击“查看产品”,进入到产品的主页。

将其加入购物车:

在购物车界面点击“结算”,进行结算。

输入账单地址(账单地址将作为收货地址显示在界面中),点击“使用 Token 完成支付”。

在结算页面,拖动到底部,可以看到支付按钮,点击支付按钮,会自动唤起浏览器的 Metamask 插件。

在弹出的窗口中确认支付:

支付完成后,页面会自动刷新,并看到支付完成的字样。

处理订单

用户支付完成后,如何确定订单已经支付完成了呢?进入后台“仪表盘”-“WooCommerce”-“订单”,可以看到用户所有的订单。

正在处理状态的订单为用户已经支付完成,还没有处理的订单。点击该订单,进入到订单详情,在右侧的“订单备注”中可以看到交易的 Tx 值 。你可以点击对应链接,查看交易是否完成。

至此,整个使用 ERC20 通证的交易流程就走通了,接下来你就可以创建商品,使用 ERC20 通证 来完成你的 ERC20 在线交易流程啦!

关于硬核区块链

硬核区块链是一个区块链技术服务提供商,我们为顾客提供全面的 ERC20 通证发行、安全审计、解决方案构建、流通流程设计、 空投解决方案等服务,为顾客提供咨询与支付服务。

相关链接

本文为 Grank(Github Rank)的简介及相关思路的介绍。

在深圳刚刚结束的 CosCon 2018 大会上发布了《中国开源调查报告》,Grank 作为其中数据篇的部分数据提供者,构建了一个 Github 项目活跃度、社区化的模型,并以 Python 实现。

项目地址: https://github.com/lctt/grank/

Grank 模型

我们认为,一个健康的开源项目应该体现为以下两个方面:

  • 项目的活跃度趋势
  • 项目的社区化(去中心化)程度

而这两个方面分别有多个因素组成:

活跃度和活跃度趋势

项目的活跃度,我们定义为项目的提交数、 拉取请求数和贡献者数(其它数据,如代码行数、文件数、issue 数、 fork 数、star 数,要么是权重相对低得多,要么是代表意义不够确定,此处忽略不计入模型)。

但是,对于不同的项目,其横向比较其活跃度,或有不同的活跃度形态,或不具备可比性。很难说一个项目比另外一个项目的提交数高,而拉取请求(PR)数低代表的确切含义。因此我们不认为对不同项目的这些数据进行绝对值的比较有太多的科学意义。

所以,我们认为一个项目本身的活跃度变化的趋势和幅度,会更有项目间比较的意义。

如果以三维空间来描述一个项目的活跃度,以提交数、拉取请求数、贡献者数为三维,可以确定在某个时间点某个项目的坐标,那么计算一段时间内,该坐标点的移动轨迹和速率,可以真实的反映该项目的活跃度趋势。

考虑到按周工作的作息时间的普遍影响,我们以一个工作周作为一个时间采样点,然后计算连续的几周内该坐标的移动速率。这反映了该项目的发展速度。

社区化程度

开源诞生于社区,繁荣于社区,根植于社区,虽然现在大型组织、商业公司也纷纷投身于开源生态,但是我们认为,开源项目的生命力仍然在于社区。我们并不否认机构、商业公司对开源的巨大贡献和影响力,但是如果一个开源项目变成了一家或几家大企业的私人游戏,其必然失去开源项目的生命力,它或许会在商业上取得成功,但是那个成功不是开源项目的成功模式。

因此,我们认为需要有一个评估开源项目的社区化(去中心化)程度的指标。项目(尤其是软件项目)的一个重要属性是开发人员的社区化身份,因此,我们以实际向项目贡献了代码的人员的社区化离散程度来评估项目的社区化程度。

每个参与项目开发的人员均有其身份属性,这个身份可能是企业雇佣身份,也可能是社区志愿者身份。我们通过对项目的提交中的提交者数据进行收集,然后根据开发人员的身份信息、邮件后缀等依优先级来判断其所属身份。然后对这些信息进行聚类,以一个离散评估模型来评估该数据集的离散程度。

虽然项目越中心化,其发展风险越高,但是,并不是社区化程度越高的项目就越健康,过于离散的项目也容易出现项目分裂、迭代缓慢等问题。这显然是存在一个适当的区域。

Grank 的结果长什么样子?

多项目活跃度:

多项目社区化:

单项目社区化及活跃度:

使用方法

  1. 使用 pip 安装项目 pip install grank
  2. 获取 Github 的 Personal Access Token
  3. 使用 grank login 设置 Token
  4. 使用 grank config 设置社区化企业关键词
  5. 使用 grank analy <owner> [<repository>] 来分析特定用户 /组织和项目,比如 grank analy lctt grank,分析结果可以在执行命令目录的 result 目录中找到。
  6. 使用命令行模式操作,如 grank --token=XXXX --start=2018-01-01 --stop=2018-05-21 --askrule=0 --rule=inc analy <owner> <repository> 其中 token 必须指定,其他可以使用缺省设置

Grank 是如何实现的?

Grank 使用 Github 的 GraphQL 来完成数据抓取的工作,抓取项目的所有提交和拉取请求来进行分析,并使用 Pandas、numpy、pandas 进行数据的分析,最终得出结果。

此外,Grank 目前为命令行工具,采用了 Click 来编写命令行的支持。

Grank 能够为你带来什么?

  1. 评估自己的项目情况
  2. 学习 Python 项目编写
  3. 了解 Click 的使用
  4. 了解 pytest 的使用。

项目地址:https://github.com/LCTT/Grank

Pypi 地址:https://pypi.org/project/Grank/

仓库被封禁

在 2018 年 2 月 20 日,我们的开源项目放在 GitHub 上的仓库由于收到了 DMCA Takedown 投诉被封禁,仓库处于不可访问状态。此时在 GitHub 上访问该仓库时,会显示一个公开消息,表明该仓库被封禁的原因。

按照 GitHub DMCA 的规则,GitHub 在确认投诉有效后,会给该仓库的管理员发送一封邮件,提示该仓库需要在 24 小时内清理被投诉的内容,并回复 GitHub 才行——否则,该仓库会被封禁,禁止任何访问和数据导出。

我们在收到该 Takedown 投诉后,会有 24 小时的时间来响应,但由于过年期间,仓库拥有者没有及时看到邮件,未能及时发现这么严重的通知。因此,在过了 24 小时后, Github 按照 DMCA 的规则,进行了仓库的封禁。

仓库被封禁后,我们发现无法访问。根据封禁消息的提示,发现原来之前仓库内的某个文件出了问题,侵犯了原作者的版权。原作者向 Github 发送了 DMCA 投诉。而由于我们的未及时处理,导致了仓库的最终被封。当我们发现被封时,已经是深夜了。

紧急商讨方案

在被封禁后,由于已经超过了 24 小时时限,在这个阶段下, GitHub 的文档中给出的解决方案仅有请求 GitHub 来删除该仓库并根据自己手里的仓库数据重建的方案。但对我们来说,这种方案是不可接受的,因为这种方案会导致丢失所有的 issue、PR、Wiki,以及你本地的仓库和远程的仓库之间的版本差异。

我们在群内先找了更新最全的 fork,找到了一个群友提供的,和上游只差 2 个提交的版本,并将其保存下来,作为最后的自救手段。

此外,在查询 DMCA 的过程中,我了解到 DMCA 除了有 DMCA Takedown 以外,还有一个 DMCA Counter Notice,用于反向解除 DMCA 封禁。

DMCA Counter Notice

DMCA Counter Notice 用于向服务商发起申诉,说明 DMCA Takedown 投诉为恶意投诉且并无版权问题。

延展阅读

https://www.plagiarismtoday.com/2010/06/03/7-common-questions-about-dmca-counter-notices/

https://help.github.com/articles/guide-to-submitting-a-dmca-counter-notice/

当时考虑到我们已经错过了窗口期,没办法删除 GitHub 上仓库中的特定文件,所以想通过 DMCA Counter Notice 来解除封禁。

为此,我通过 Github 发给我们的邮件,找到了那份侵权文件,并在他的网站中找到了版权拥有者的邮件,发送邮件说明情况,看看能否通过付费获得授权。但其是挪威人,存在时差,所以我们只能边等待,边想办法。

山重水复疑无路,柳暗花明又一村

在准备 DMCA Counter Notice 时,我们又向 Github 发送了邮件,说明了中国春节的特殊情况,导致我们没有来得及处理文件,请求给我们一个机会让我们处理这些文件。但是迟迟没有回应,无奈之下,多位成员又以成员身份向 GitHub 发送邮件,请求给予帮助。

令人惊奇的是,经过大约 9 个小时的等待,仓库拥有者的请求邮件似乎开小差了,而各位成员的请求邮件得到了响应。Github 回信给大家说,根据其规则,给出了额外的 24 小时窗口期,让我们处理这些文件(后来经过仔细查阅 GitHub 的 DMCA Takedown 规则,对这种错过了第一次窗口期的情况,可以给予第二个,也是最后一个窗口期)。但是这个开启额外的窗口期,需要仓库的拥有者向 GitHub 发送邮件请求。

然后,我们就以仓库拥有者的身份再次向 GitHub 发送了请求,可能是由于时差的原因,又是几个小时没有回应。

与此同时,我们也收到了版权拥有者的回复。很遗憾,原作者不愿意授权,也不打算收费。好在 Github 给的额外窗口期,让我们有了改正错误的机会。

还好,在焦急的等待之中,我们终于收到了 GitHub 的回复,并同时恢复了仓库的访问——宝贵的 24 小时窗口期。

使用 BFG 处理文件

得到了窗口期后,我们开始处理仓库内的文件。

首先,你得清除了现在还在仓库里面的文件,然后再使用下面的方面来清除提交历史中的数据。

推荐阅读

以下文章建议按顺序阅读

https://help.github.com/articles/removing-sensitive-data-from-a-repository/

https://rtyley.github.io/bfg-repo-cleaner/

删除 Git 仓库的历史数据有多种方法,一种是使用 git filter-branch来处理,但是速度极慢。另外一种就是使用 BFG 来处理,我们采用的是 BFG 来处理(BFG 是git filter-branch 首字母的逆转)。

BFG 需要 Java 的运行环境,如果无法运行,请检查你的本地 Java 环境是否安装,或高于 Java 7 。

Java 6 需要使用 bfg v1.12.3版本

BFG 的处理过程比较简单,首先,你需要下载 BFG。

wget http://repo1.maven.org/maven2/com/madgag/bfg/1.13.0/bfg-1.13.0.jar

然后克隆你的仓库到本地,比如 bestony/test

git clone --mirror  git://github.com/bestony/test.git

克隆时用不用 --mirror 模式都可以,但是后续命令上会有所差距,所以我还是推荐大家使用镜像模式,毕竟按照官方的文档走,出现了问题也好搜索。(镜像模式克隆的仓库和远程仓库完全一样,但是不能直接看到仓库里面的文件,而且也不能允许 git 的各种命令)

克隆到本地后,执行 BFG 命令来处理文件。

cd test.git
java -jar bfg.jar --delete-files "filename"

这里需要注意的是,filename 不支持目录路径,只能是文件名,而不能是 dir/filename 这样的形式,所以添加参数时你要注意这个。对于有同样名字的文件却想只删除某个目录的情况,可能就没有办法了。

此外,默认情况下, BFG 不会处理最新的提交,它认为你的最新提交应该是干净的(不包含需要删除的敏感数据),如果你要删除的文件是最新的提交(比如你最新的一个提交是删除那些敏感数据),可以加入--no-blob-protection参数来强制清除,也可以再添加一个提交,使包含了要被删除文件的提交不是最新的提交。

java -jar bfg.jar --delete-files "filename" --no-blob-protection

BFG 处理完成后,会提示你使用 git 命令进行垃圾回收,你需要执行如下命令来操作:

cd test.git # 进入目标目录
git reflog expire --expire=now --all && git gc --prune=now --aggressive # 垃圾回收
这里需要注意的是,如果你删除多个文件,每次删除后执行和多个文件都删除后效果一样,所以建议你删除多个文件后再进行垃圾回收,会更省时一些。

处理完成后,将数据推送到远端即可(需要关闭 GitHub 上仓库设置里面对强制推送的防护):

git push

执行完成后,就可以到远端上去看了,你的文件会被删除,相关的提交不会被删除,但是提交里面不包含该文件了。

在推送时,可能会提示你有些更改被拒绝了,这些更改如果是和 Pull Request 有关的,你可以不需要在意,这是 GitHub 自身的问题。Github 设定 Pull Request 是只读不可改的。所以我们无法修改这些信息。

具体可以参考 https://github.com/rtyley/bfg-repo-cleaner/issues/36

至此,我们将文件进行了删除处理,并清除了相关的数据。

后续处理

在完成文件及历史数据的删除后,我们将我们的删除结果回复了 Github ,等待 Github 的确认。GitHub 会在 24 小时收到该回复后,会通知投诉方进行确认。如果投诉方无异议,此事就此结束,不会再有下一步动作。如果有异议,则会重新进行此流程。

此外,由于 GitHub 存在垃圾缓存回收的时间差,所以你推送到 GitHub 上的数据虽然并无需要被删除的文件,但是依旧在一定时间内可以看到。这种缓存只能请 GitHub 自行操作删除。此外,与要删除的文件相关的 Pull Request 也需要 GitHub 来删除——因为用户是没有权限删除 Pull Request 的。这些请求也可以一并发给 GitHub 来操作(但似乎 GitHub 并不热衷执行这些请求,只要被投诉的文件访问不到即可,也就是说,如果没有被投诉历史数据,其实或许并不用大动干戈清理历史……)。

这种清除操作还有一个副作用就是,所有之前 fork 的仓库,由于主仓库被封禁而导致各个 fork 仓库的 remote 意外地变为另外一个仓库(该仓库是最早的一个 fork 仓库)。而主仓库恢复之后,我们并没有找到好的办法将 remote 恢复回原来的主仓库。因此,需要所有成员重新 fork 主仓库并从缓慢的 GitHub 克隆到本地。

余思

这个惊魂事件当中,我们首先要反思的是,我们对版权问题的认识不足,这是一切问题的根源。因此,这之后,我们对既有数据进行了排查。

其次,GitHub 在这种事件的处置上,我们认为也并不够好。这么严重的处置(整个库封禁),仅仅通过一份普通的邮件通知,而且仅仅给出 24 小时的时间窗口。而 GitHub 其实掌握了仓库拥有者的更可靠、更及时的联系方式,比如说手机短信,也完全可以在 GitHub 的网页界面上以显目的方式提醒。另外,虽然 DMCA 规则中提到了可以容情第二个时间窗口,但是似乎这个附加窗口期是后来才改变的政策,在前面的流程说明中并未提及,很容易忽视。

其三,由于封禁会导致对该仓库的所有访问均不可进行,这不仅包括了提交数据,也包括了并没有存在于 Git 仓库中的 issue、PR 和 Wiki 等数据,而 GitHub 不会让你在封禁的情况下有机会导出这些数据。所以,有机会的话,各种数据还是有个备份的好。

最后,感谢在这个事件中,所有不离不弃支持我们的成员,感谢小白进行的仓库清理工作。

相关阅读

Linux 中国一直以来都在运营着一些微信群,帮助大家找到组织,和有共同爱好的朋友一起讨论关于 Linux 、运维 、开发等等。但是长期以来,受限制于微信群二维码仅能在群成员少于 100 人时使用,超过 100 人就需要微信群管理员手动拉人,对管理员们造成了很大的困扰。同时,由于群里有很多人,平时管理员们也有自己的工作,导致无法让用户获得更好的体验。

出于解决上述两个问题的初衷,我们基于 @youfou 开源的 wxpy 库开发了微信机器人,来协助我们的管理员处理微信群的管理问题。

现在,我们的微信机器人已经正式接管了 Linux 中国的所有微信群管理,所以,在这里,我隆重为大家介绍这款机器人 —— LCBot

LCBot 是由 Linux 中国旗下翻译组 LCTT 的开发团队开发的一个为 Linux 中国服务的微信机器人,主要为 Linux 中国下的微信群做管理、维护等工作。

可以说,有了微信机器人,微信群的运营和管理会更加方便,目前我们已经支持的功能有:

  • 根据关键字自动发送加群邀请
  • 接受若干指定的管理员的指令踢出某些群成员

已经排期计划的功能:

  • 根据设定的规则,自动踢人功能(如刷图、长期潜水、红包小偷等)
  • 微信群将满时自动创建分群,自动分流新入群成员
  • 自动创建主题群
  • 自动创建临时群,如果不能达成长久存在条件,自动解散
  • 自动分享公众号推送内容
  • 被踢用户加入黑名单,视情况分别处于不同处罚:一次性踢出、永久踢出、全部群永久踢出
  • ……

开源

技术的红利不止我们需要享受,在这里我们也将这款产品介绍给您,希望 LCBot 可以帮助您更好的运营您的微信群!LCBot 的开源代码在: https://github.com/LCTT/LCBot ,欢迎大家拿去使用和提交 issue

在此,我们要感谢 @youfou 开源了好用的 wxpy 库!感谢 @youfou 在项目开发中对我们的支持!

如果您在使用后,觉得非常好用,不妨来给我们点个 Star ,支持我们的项目更好的发展。

体验

请扫描如下微信二维码,将我们的微信机器人“小二 » Linux中国”(微信号“linux\_cn”)添加为好友:

验证信息输入下述关键字,或给机器人发送如下关键字,即可获得加群邀请。

已支持关键词

关键词对应群关键词对应群
运维Linux 中国 ◆ 运维群DBALinux 中国 ◆ DBA交流群
开发Linux 中国 ◆ 开发群PHPLinux 中国 ◆ PHP 交流群
云计算Linux 中国 ◆ 云计算群GolangLinux 中国 ◆ Golang 交流群
学生Linux 中国 ◆ 学生群DockerLinux 中国 ◆ Docker 交流群
安全Linux 中国 ◆ 网络安全群LFSLinux 中国 ◆ LFS 交流群
机器人Linux 中国 ◆ 微信机器人群
嵌入式Linux ◆ 嵌入式群
运维密码“运维密码” 用户体验群

效果

和机器人对话

参与项目开发

目前我们的项目正在不断的迭代中,欢迎参与项目开发,提交 issue、 pull request 。

欢迎大家在 issue 中提交合理的需求,我们将排期开发!

如果您在使用中有问题,也欢迎你加入“Linux 中国 ◆ 微信机器人群”,参与到我们的讨论中来。