【草案】Go 夜读重大调整(请每个人都来说说你的看法和意见）
yangwenmai opened this issue · 35 comments
目标
我想让每个人都参与进来，（包括初中高级 Go 工程师），只有层次相当的人才有可能有思维的碰撞和交流，这样最终的产出也尽可能的高质量。
坚持做。
基本流程
收集-->人员准备-->制定计划-->准备分享材料（多次质量优化）-->对分享话题进行审核-->线上分享。
- issue 上收集大家想要研究的主题、源码库或源码模块。
- 必须得到至少两个人的参与，该分享才会进入准备阶段。
- 由参与的人选出主导人，然后参与者讨论确定分享计划（包括分工，耗时，预计时间，划定分享受众范围等）
- 参与者准备分享材料；
- 分享主题的审核；
- 线上分享；
分享选题
- 入门级；
- 实操级；
- 架构设计级；
- 学习方法、习惯培养等；
- 效率效能提升等；
分享方法
- 各小组确定分享者和准备提问者（可提前收集问题，也可引导参与者提问题）；
- 分享组给分享时会参与的人设置参与准入门槛；
其他
分享主题如果是一个系列，则分享的时间尽量都挨到一起进行。
回答模板：
- Go 夜读现在带给你的有哪些？
- 你希望从 Go 夜读收获些什么？
- 你希望 Go 夜读怎么改进？
我现在属于学习的进阶阶段，想了解一些 大家用go的实际业务使用场景，以及实践经验
初步学习go后，有什么好实战的简单项目入门？
同 属于学习的进阶阶段, 现在想找个稍微有点内容的小项目练练手, 但是go除了web之外的小项目都很少
偏向于服务端的golang的项目实践资料好像很少 针对各种包的综合运用更是少的可怜 希望就实际应用场景针对golang一些包的一些可操作性的实践能够分享
愿意分享的人可能比较少。。。
- Go 夜读现在带给你的有哪些？
蠻好的一個平台，讓我可以認識一些有心想學習 Go 的小夥伴並且進行討論。
- 你希望从 Go 夜读收获些什么？
提升自己的能力，並對社群做出貢獻。
- 你希望 Go 夜读怎么改进？
目前社群裡面各種程度的人都有，尤其初學者最多。直接講解源代碼太過於高深。
根據程度分級選取題目/項目，讓不同程度的人可以一起做研究。有問題可以在 Issue 上發問，讓懂的人指點。使知識能夠傳承。
- 超級初心者 -> 選取書/文章的內容討論
- 入門者 -> 實作項目討論
- 中高階 -> 源碼解析/架構
可能的問題:
- 題目/項目選擇
- 人員的多寡配置 (個人覺得一組不要太多人，不然就會只有幾個人在做。但可以有很多組)
- ...
感觉可以多请从事golang开发的程序员分享下golang的实际应用，讲源代码固然好
如果我讲nsq的使用以及源代码分析，有人想听吗？
其实直接听源码很生涩，最好是结合项目一起讲，或者直接讲go在项目中的一些经验。
其实除了源码之外，一些best practice分享一下应该也挺好的，包括知名库背后相对high level的架构原理
初步学习go后，有什么好实战的简单项目入门？
首先你得开一个 issue，然后找到志同道合的人一起，目前已经有 gin 开发组了。
其实除了源码之外，一些best practice分享一下应该也挺好的，包括知名库背后相对high level的架构原理
这个大家可以去 issue 创建你想要的，然后再按照最上面的流程来准备和执行。
其实直接听源码很生涩，最好是结合项目一起讲，或者直接讲go在项目中的一些经验。
如果你没有参与，其实分享的经验可能对你帮助不是很大，至少你要有具体的什么项目感兴趣再去听，可能效果才好一些吧。
感觉可以多请从事golang开发的程序员分享下golang的实际应用，讲源代码固然好
如果我讲nsq的使用以及源代码分析，有人想听吗？
欢迎你开 issue，然后以 nsq 讲解实战。
感觉大家都好实在啊，就我想听一些狂拽炫酷的东西么。
我提议分享一些 ast reflect 的东西，搞点好玩的东西不是很开心的事情么~
（当然工程中有多大用的问题可以先保留）
感觉可以多请从事golang开发的程序员分享下golang的实际应用，讲源代码固然好
如果我讲nsq的使用以及源代码分析，有人想听吗？
想听，想深入研究的，能看懂部分，但更多的是不理解为什么要那样写，如果能讲出来为什么那样做就好了
感觉大家都好实在啊，就我想听一些狂拽炫酷的东西么。
我提议分享一些 ast reflect 的东西，搞点好玩的东西不是很开心的事情么~
（当然工程中有多大用的问题可以先保留）
cool!
请你先建立 issue，以便于主题分类收集，也才好按照流程来进行准备分享。
一些想法
-
讲代码有价值吗？老实说讲代码并没有什么可讲的，代码产生的背景是非常复杂的，是一个人某个阶段思维过程的展现，这个思维过程在不同的阶段会存在不同的认识。落实到源码这类阅读，一般是需要自己花时间硬肯下来的，在阅读过程中伴随着资料查询、深思熟虑，直接讲给别人可能面临听众的理解问题（没有具备理解的相关背景）、分享者的表述问题（没有适当介绍相关背景）等缺陷，分享者需要对演讲具有一定经验，直接对着代码讲非常费时间还抓不住重点；
-
那么不讲代码讲核心原理吗？这个本质上来说原理性的分享干货比较多，但是这需要提前准备好分享的内容，也要对相关背景比较熟悉，可惜这类主题有限，大学课本上早就有更详尽的介绍，和语言本身相关的主题说来说去也就只有那些，这类分享在可预见的未来能够被穷举；
-
有必要讲框架吗？表面上一些热门的框架可能存在价值，但很难形成积累性的知识，一方面原因是在没有应用背景下学习一个框架是毫无意义的，一旦需要学起来不过也就一两个小时的事儿，另一方面是一个框架可能很快被替代（"代码营销"）；
-
有哪些值得被分享的、听众也愿意听的内容？个人观点，工程性的内容几个方面：
- 归纳地：实践总结在某个领域实践中获得的心得，俗称最佳实践
- 增量地：在某个特定问题领域，发现了方案 B 做某个被广泛使用方案 A 更加优秀，俗称项目经验
- 开创地：针对某个现有问题提出的全新新的见解，讨论了更多可供实践探索的方向，俗称研究
TLDR: 倒是可以组织每月看一次跟 Go 有关的研究论文: https://github.com/golang/go/wiki/ResearchPapers
大致看了上面的回答。每个人站的角度都不一样。
大致分：
- 实用型：能对自己的工作有帮助的。
- 学习型：能多学知识、技巧。
- 研究型：提出的新的见解等
我的看法是分享什么都好。
关键点在于：
-
1、有人愿意来分享以及分享者对分享主题已经有较高的认识，能给听的人带来价值或者叫启发吧就够了。其他演讲技巧等先不要做太多要求。
-
2、持之以恒下去，阻力还是大的，毕竟大家都挺忙，分享者自身也需要积累。
最后，我给分享者提下我的想法，先从自己的工作或者平时的自己做的项目中总结作为分享切入，可能好入门（分享）一点。
一些想法
- 讲代码有价值吗？老实说讲代码并没有什么可讲的，代码产生的背景是非常复杂的，是一个人某个阶段思维过程的展现，这个思维过程在不同的阶段会存在不同的认识。落实到源码这类阅读，一般是需要自己花时间硬肯下来的，在阅读过程中伴随着资料查询、深思熟虑，直接讲给别人可能面临听众的理解问题（没有具备理解的相关背景）、分享者的表述问题（没有适当介绍相关背景）等缺陷，分享者需要对演讲具有一定经验，直接对着代码讲非常费时间还抓不住重点；
- 那么不讲代码讲核心原理吗？这个本质上来说原理性的分享干货比较多，但是这需要提前准备好分享的内容，也要对相关背景比较熟悉，可惜这类主题有限，大学课本上早就有更详尽的介绍，和语言本身相关的主题说来说去也就只有那些，这类分享在可预见的未来能够被穷举；
- 有必要讲框架吗？表面上一些热门的框架可能存在价值，但很难形成积累性的知识，一方面原因是在没有应用背景下学习一个框架是毫无意义的，一旦需要学起来不过也就一两个小时的事儿，另一方面是一个框架可能很快被替代（"代码营销"）；
- 有哪些值得被分享的、听众也愿意听的内容？个人观点，工程性的内容几个方面：
- 归纳地：实践总结在某个领域实践中获得的心得，俗称最佳实践
- 增量地：在某个特定问题领域，发现了方案 B 做某个被广泛使用方案 A 更加优秀，俗称项目经验
- 开创地：针对某个现有问题提出的全新新的见解，讨论了更多可供实践探索的方向，俗称研究
TLDR: 倒是可以组织每月看一次跟 Go 有关的研究论文: https://github.com/golang/go/wiki/ResearchPapers
- 讲代码有价值吗？
- 读代码前, 应该有业务场景, 架构设想, 技术评估与选型, 以及落地实现----落实到代码组织以及重点代码段 ----------> 这个是非常有价值的, 工程实践相关的分享
- 事实上, 网上很多阅读/转载/翻译的高质量文章, 都是在具体项目中的一些痛点的思考, 评估, 与解决, 这就是最佳实践类的好分享
- 请注意, 这些文章, 对业务场景的描述, 以及痛点分析, 是体现价值的基础所在
- 有必要讲框架吗？
- 框架是给两类人准备的
- 一是初学者/进阶者, 从一些成熟的框架中, 可以学习借鉴到优秀的**
- 二是 start-up 类型的开发者, 借用他人的框架或有商业应用的成熟框架, 快速启动或优化一些中小型的项目实施
- 框架, 是对某一类型业务形态的解决方案汇总, 是套路
- 实际在商用项目实施中, 很多"套路" ---也就是框架, 只占技术实施中的很小一部分, 甚至被定制, 修改
- 而更多的是, 与其他 "套路" 结合在一起, 才真正去触及 "问题终结" 这一技术目标
- 换个方式说, 问题是根本 , 解决问题是目标 , 解决问题中使用的套路/技术, 是附带的外在表现, 而很多分享都流于套路/技术的解读( 这有益于学习开发语言的"新手"), 但对实际项目中带着问题来的朋友们, 没什么帮助
- 再换个方式说, 部分分享, 听了就听了, 想用到实践商用项目中去解决问题, 还有很长的路要走------> 既然有这可能, 为什么不是提出商用中的 issue, 大家就某一典型 issue 来谈解决?
看看 go 的 web 框架, 以及 javascript 的新框架, 层出不穷, 个个都号称, 轻量, 最快, 功能超全, 插件式, 全家桶....... 有几个架框能稳定维护几年并稳定用在商用项目中, 半数以上是试手项目, 没太多学习价值
其他, 分享, 不容易, 我认为, 应该有一些通用的业务场景, 比如 web 中的用户鉴权,会话管理 , 以及一些通用的技术, 比如 gRPC 在游戏/ IM 中的应用, 这样, 主讲人, 以及想参考的朋友, 提前去了解业务场景, 相关技术, 再进行交流, 价值更大一些
最后, 表达很重要.
附, 我对 goim 的三篇文章( 持续改写中)
可以发起一个新 issue，找志同道合的人一起深入探讨研究。 @tsingson
就是针对你写的 goim 的三篇文章发起一个《goim 深入研讨》这个话题，提供一些资料，有人报名参与，就一起交流讨论，然后定一个时间一起分享交流。
@tsingson 老哥你的想法不错，你可以开issue，然后从基础到实践开始一点点的讲起，估计有很多人会感兴趣，目前我和max还有另外一个伙伴在做gin的一些东西，我们三在一个群里，每天至少关于go的东西要交流会，每周都会对做的gin的项目进行交流，遇到不是很理解或者不好做的地方一起在讨论中，最近收获比之前一个人单打独斗的时候收获更多。也谢谢老哥的付出，如果您愿意分享，我愿意当您第一个听众
就是针对你写的 goim 的三篇文章发起一个《goim 深入研讨》这个话题，提供一些资料，有人报名参与，就一起交流讨论，然后定一个时间一起分享交流。
@yangwenmai 这个啊, 倒是可以, 只是, 这玩意是个工程原型, 就不知道有什么朋友交流, 要侧重哪些方面了.
单独开 issue 讨论吧
@tsingson 老哥你的想法不错，你可以开issue，然后从基础到实践开始一点点的讲起，估计有很多人会感兴趣，目前我和max还有另外一个伙伴在做gin的一些东西，我们三在一个群里，每天至少关于go的东西要交流会，每周都会对做的gin的项目进行交流，遇到不是很理解或者不好做的地方一起在讨论中，最近收获比之前一个人单打独斗的时候收获更多。也谢谢老哥的付出，如果您愿意分享，我愿意当您第一个听众
@xhochipe gin 那个讨论组, 相关讨论我看过一些, 太具体了太细节了, 会忘记"目标", 哈
@yangwenmai 仔细想了一下, 其实 < goim 深入研讨 > 不会有多少人参与, 原因如下:
- goim 是个工程原型, 算不上复杂, 但也有一定要求, 比如, gRPC , tcp 长连接服务, 自定义的协议, websocket , 一定的 go 语言实操经验, 外部网元涉及 kafka / discovery ( 或替代)
- goim 的业务场景很简单, 但商用环境就很复杂, 一般情况下比较难模拟出来
- goim 客户端暂时没有全功能成型的代码库
所以, 我认为:
- 对业务场景感兴趣的, 不会多, 就算有, 也多数已经研究过 goim 了( 网上同类文章不少, 甚至还有收费的网课)
- 对 goim 中有些问题, 要拆得容易懂, 得花不少时间, 而平时可能用不上
-
我还是一个大学生， 正式开始接触golang 是在实习的时候，自从学习golang 后就觉得写起来真的很舒服。
-
现在已经学习完了go的基础语法，正在学习一些框架，等等来提升，go夜读是个很不错的国内组织。
-
我希望go夜读也不仅仅停留在读官方源码上，也可以去读一些优秀的第三方包的源码。
赞, 队伍壮大了.
有兴趣的话, 可以开启一个共同的项目, 在共同开发过程中( 这是实践) , 分享用到的一些优秀的库( 这是读).
目前 reading-go 中已经有 gin 开发了，你有兴趣的话，可以开启。
https://github.com/developer-learning/reading-go/tree/master/examples
gin 项目, 能独立一个 repo 不?
暂时不开新的 repo ，毕竟都是练手的项目。
申请 reading-go 练手项目
repo 在https://github.com/tsingson/go-ums
有朋友说, 让写一个用户管理原型, 给他们作为基础, 所以, 项目目标改变, 加了适合他们对接的东西.
但文档还是按练手来写的, 边写文档边加代码, 看 git 日志会有趣一些.
比较需要一些**上的提升，比如说高并发量的缓存如何设计，然后源代码方面的讲解如果之前没有预习的话是比较难听懂和看懂，如果能直接讲下原理就好了。
比较需要一些**上的提升，比如说高并发量的缓存如何设计，然后源代码方面的讲解如果之前没有预习的话是比较难听懂和看懂，如果能直接讲下原理就好了。
预习工作本身就要做啊，与其听别人讲给你，不如好好预习自己预先掌握参与讨论