第一场 GitChat 总结

在 GitChat 做了一次分享,总结一下他们家和 SF 的差异。简单来说,GC 的文章式共享方便检索,SF 的视频在交流效率上更占优势。另外,GC 的钱实时到帐,很舒服。

旭川动物园看出去

开始之前,先做广告吧。

GitChat 分享 《JavaScript 异步开发全攻略》

为解决异步函数的回调陷阱,开发社区不断摸索,终于折腾出 Promise/A+。它不增加新的语法,可以适配几乎所有浏览器;以队列的形式组织代码,易读好改;捕获异常方案也基本可用。这套方案在迭代中逐步完善,最终被吸收进 ES2015。不仅如此,ES2017 中还增加了 Await/Async,可以用顺序的方式书写异步代码,甚至可以正常抛出捕获错误,维护同一个栈。可以说彻底解决了异步回调的问题。 现在大部分浏览器和 Node.js 都已原生支持 Promise,很多类库也开始返回 Promise 对象,更有各种降级适配策略。Node.js 7+ 则实装了 Await/Async。如果您现在还不会使用,那么我建议您尽快学习一下。

下次直播分享 前端面试攻略:JavaScript 排序与搜索

从事前端开发的同学很多从页面仔入门,比如说我,自学比例很大,有些时候会无意中忽视一些基础,比如算法、数据结构。这些欠缺在某些时候就会显得很致命,比如说面试,或者处理大量数据的场景。所以希望这样的一场分享能够帮助大家夯实原本不太扎实的基础,将来的开发之路更加顺畅。

目前早鸟票发送中,7月13日前门票5折,19日前75折,开播当日恢复全价。


现在做内容创业的真多,花样百出。前几日在 GitChat 也搞了一次分享,这里总结一下。

模式

GitChat 的模式是这样的:

  1. 分享者发一个题目
  2. 围观者根据题目和介绍,选择是否付费购买
  3. 发起一周后,如果人数超过25人,则题目成立;否则,题目不成立,所有预付款退回
  4. 成立后分享者开始写文章,理论上有两周时间,实际上站方会要求尽快写完
  5. 两周后的晚上,是答疑交流时间,交流开始前两天,会再有一波宣传
  6. 交流在微信群里通过文字交流,持续1个半小时,即8:30到10:00
  7. 交流结束后,微信群解散,同时报名费立刻转账到分享者账上
  8. 次日,站方会出一篇《交流实录》,同时分享的文章变为公开,可以从 GitChat 的首页看到,一元看全文

整个经历了一遍之后,感觉设计的有优有劣,主要跟 SegmentFault 对比。

GitChat 的优势

1. 分享者有的放矢

分享者更加有的放矢,因为文章是先买后写,买的人不够可以不写,所以相对来说,前期准备的风险比较低。从预购者的角度来说,反正买的人不够也会退款,无所谓,就当投票了。

2. 文章有利于检索

与 SegmentFault 的视频直播不同,文字利于检索,文章编辑器几乎都是现成的,所以 GitChat 的开发成本不高,并且可以最大限度的利用现在的网络资源。

相较来说,SF 现在都还没实现视频的检索、时间轴的标记,更不要提弹幕、字幕、交流内容的抓取,等等。所以就目前来看,SF 的视频基本就一锤子买卖,直播时可以有限的互动,结束后很难方便的检索。

3. 基于微信群互动

GitChat 一开始就没打算自己做社区,所有东西都放在微信上,所以至少我进入的时候,工作人员就会主动帮忙建立读者群,分类的读者群之类的场所,方便讲师和读者互动。相对来说,SF 差不多运行了几个月才开始这么做,当然他们本身就是社区,所以不太想让自己的用户在别的场所互动吧。

GitChat 的劣势

当然 GitChat 也有很多不良设计,有些是主观的有些是先天不足。

1. 文字交流效率太低

文字交流效率之低简直令人发指,昨天1个小时时间我只回答了6个问题,其中两个还是我自己提的不需要思考。大部分时间大家都在等我打字,让我恍惚间回到当年山口山里 Raid MC 的场景。相对来说,视频直播就太方便了,语言能解决语言解决,语言解决不了直接跑代码,咔咔咔几分钟搞定一个问题。

2. 准备周期太长

这次做的题目还是异步开发相关,基本上60%的内容可以取材于 Promise 的 N 种用法,已经是现成的,但是我仍然花了差不多4天时间在准备上,因为内容太多了,最终成文3万字,相当于我把视频里口述的内容,全都打字打了出来。这也是文字类另外的问题:你想把问题说清楚,就需要大量打字。

相对来说,我在 SF 做一场直播差不多2、3天就准备好了,包括 Slide,代码,至少一次试讲。两边效率比较起来,还是直播高。

3. 一些分享者水平欠奉,观众群气氛很差

一部分分享者是运营请来的,还有一些是自发的。自发分享的同学,甚至还有在校学生……当然不是说分享不好,也不是说在校学生就不好,只是看到他们的分享内容,和交流时的说法……我觉得至少,跟那些大牛混在一起做分享,不太合适。

昨天加了交流群,今天上午有人问了问题,本来很普通的一个问题,结果愣是引发一场不小的争执。原因说白了很简单,有个同学想装B,或者说想炫技,然而他的经验不足见识不足,语气又很难听,搞得大家几乎没法正常交流。这在 SF 是完全不可想象的,作为技术社区,SF 的隐性入门门槛更高,帮助分享者屏蔽掉了不少类似的人,分享的心情好很多。

4. [2017-07-16 更新]不支持文章修改

不知道他们的设计思路是什么,反正发布后就无法修改文章,只能把全文发给运营,由运营人工修改。

昨天在 SF 里回答了一个 Vuex 相关的问题,我突然发现它也在异步开发的范畴内,就想更新文章,才发现这么麻烦。既然如此干脆做一本小书好了,今天早上试了一下,gitbook.com 不需翻墙也可以访问。


好了,第一次做完,不知道下次什么时候做。无论如何,即便看在钱实时到账的份儿上,也希望 GitChat 越办越好。