怼周刊_v1
~ 17.4.15 20:20 发布
[定场诗]
莫等莫盼 自先动手
自怼自学 才好嗯哼
玻璃花园 怼友相互
据汝行径 才知前路
释名
~ via -> [TASK]42hDebugUself拼写错误
DebugUself ,而不是 yourself
, 部分原因:
- 读的出来
- U -> You 是惯常的替代法, 比如说 2 -> to, 4 -> for
- Uself 比 Yourself 少近一倍字母, 读音又相同
- de+bug + you + self 原先想用 DebUself 的, 但是,缺少了关键的 bug, 才 -> DebugUself 的
- 另外 UgU 也样一个累碎了,流鼻涕的人脸
- 即,在 编程中, 为了增加趣味 减少输入 unique ID, 各种常见的生造词方式是 hacker 变化的一部分
- DebugUself 已经配置到所有相关的资源中了
综上 DebugUself(DU) 本身就是不现有单词的简单拼接, 而是为我们的 怼圈 设计的一个专有词 ;-)
怼圈
的价值判定:
有用 -> 是否解决具体问题?
有趣 -> 是否有能帮助其它人的输出?并包含足够的能技素
有种 -> 是否有足够的挑战性?
~ via [DUW]72h一周入圈小感:期限是最重要的 · Issue #29
进度
~ 记录当周关键事件日期+证据链接
- 170412 大妈吐糟 4 连发:
- 170411-mind-coding
- 编程思维? 好象没这货
- du170412-1-it-all-text
- It’s all text 安利以及小任务
- du170412-2-3value
- 怼圈行为价值观
- du170412-3-big-image
- 怼的大图景
- 170411-mind-coding
- 170402 [DU:init. re-start]在线收听_Zoom.Quiet_荔枝FM 正式开怼
- 170401 关闭报表和入密
任务
~ 记述关键共怼任务 (如果没有, 留空)
- 截止 17.4.15 11:11
- 34 位怼员, 22 名有尝试,最近一天有更新的 8 人
- 文件名始终错误的一人
- 12 名超过 1⁄3 的怼友没有推进任务
- 任务最终交付物:
自怼帐单
- 无人提前起草逐日增补
- 最终也没有人正式提交, 6806bf0 ~ 有尝试, 也自行删除了
- [ASK] 有靠谱的时间记录工具否? 是原本最应该第一个产出的关联成果, 也没有见成品
如果这是一次 MOOC 课程的话, 相比业界 <5% 的完成率, 我们算是高的… 但是,对于已经受过一轮 开智编程入门班 训练的大家, 就不够班了
自怼的仪态
- 170413 创建
- 170416 计划草案发布
进展
~ 整体上圈内部活跃指标情况
- 作业: S01E01
- 提交: 22 人, 不到 2⁄3
- 引发的作品:
- …
- 状态:
当周 Commits (17.4.8 15:21 ~ 17.4.14 23:01,
共 19 人
)次数排名:
GitHub ID | Times |
---|---|
ZoomQuiet | 12 |
zoejane | 10 |
Zxlon | 9 |
xpgeng | 8 |
sunoonlee | 7 |
… | … |
当周 Comments (含 Issue 创建/回复, 以及代码点评 17.4.8 13:50 ~ 17.4.14 22:34,
共 14 人
)次数排名:
GitHub ID | Times |
---|---|
ZoomQuiet | 102 |
zhangshiyinrunwithcc | 45 |
zoejane | 14 |
NBR-hugh | 14 |
13416136446 | 11 |
… | … |
所有 Comments (含 Issue 创建/回复, 以及代码点评 ~ 17.4.14 22:34,
共 16 人
)次数排名:
GitHub ID | Times |
---|---|
ZoomQuiet | 173 |
zhangshiyinrunwithcc | 64 |
NBR-hugh | 32 |
zoejane | 21 |
bambooom | 18 |
… | … |
所有 Commits (~ 17.4.14 22:55,
共 23 人
)次数排名:
GitHub ID | Times |
---|---|
NBR-hugh | 22 |
xpgeng | 18 |
Zxlon | 18 |
ZoomQuiet | 17 |
zoejane | 16 |
… | … |
成果
~ 各种成品/半成品 内部知识作品
- [WIKI]合理迁入实验指南 · Issue #23
- [LOG]知.时管理
- <– 摘要相关时间管理的技巧部分
- 42h[DUW]仓库故事还原追查法
- 应该尽力变成所有怼友可以上手享受的高效搜索技术
- 37signals -> basecamp -> RoR -> …
- 搜索 -> 辨别 -> 收集 -> 整理 -> 再搜索 -> 产出….
是也乎
<– 即, 如何判定当前资料可用/最好/足够? 待留大家思考总结
- [LOG]首次快速获取远程仓库分支数据
- 有什么方案?各怎么来? 最简洁的是什么? 为什么?
- 以下 DAMA 操作记要示范
:
git clone ... as A
cp -rv A B
cp -rv A C
cd B
git br -a
git co B
git branch --set-upstream-to=origin/B B
git st
cd ../C
git co C
git br -a
git branch --set-upstream-to=origin/C C
...
是也乎
<– 目测以上方案,并没有被大家发现, 所以, 待留发现.
故事
~ 收集各自无法雷同的怼圈真人故事…
完全复制主分支
~ via -> 13416136446 created branch 13416136446 at DebugUself/du4proto
@李广鹤 : 想交表,怕污染 master,先建一个分支上传后再合并,看来这种做法是不对的。 还没有合并到主干,现在删除应该不会对 master 有影响吧? 大家都是直接在 master 上提交作业的么?在没确定这个行为会不会对大家造成影响前,我应该先研究,发 issue 的。 目的是上传一个文件到 code
一小时后, 被小密圈怼, 得以删除…
原作未能按时完成内心剖析…
自怼的授权
~ via -> [LOG]知.时管理 · Issue #34
- 始未: 怼友的公开记要 -> 发现小遗憾 -> 支招 -> 偏离诱发大妈 -> 诘问 <- 请求授权
- 分析:
DebugUself
一开始就点明了, 这儿的所有行为对象是U -> you
- 不是 We, 不是 My, 不是 She/He …
- 为什么?
- 因为 我 -> 排除了旁观
- 我们 -> 排除了独立
- 只有
你
先有行动, 教练们, 才知道是否对, 为什么错 - 就象乒乓球, 你不发球, 一直吼, 我要学打乒乓, 那真心永远学不到的
- 问题可能在 教练们输出的又快又多, 以至大家误解这是军营…
- 寄语:
是也乎,( ̄▽ ̄)
- 这儿是
自怼圈
又不是集中营, 大家是平等的, 都是积极自学者, - 其它人的建议, 认同就去尝试, 得到自己第一体验后,
- 再回怼, 凡事儿只是不涉及 情感和财务, 都不应该需要谁的授权的,
- 当然, 是否去嗯哼, 一直有基本的判定:
- 是否侵害怼员们的成果? 造成 丢失/删除/覆盖/… 其它人的目录/分支/仓库/…
- 是否有益自己? 足以产生
3有
(有用有趣有种) 输出? - 是否有益怼友们的自学?
- 这儿是
以上…
输出残酷之新奥义
~ via -> [LOG2w 项目进展提交处 · Issue #39 · DebugUself/du4proto
始末: OMlalala 提交自己的探索记录 -> NBR-hugh 给出观点:觉得探索过程不宜发布 -> 大妈给出反对意见,说明[记录/技术档案要点][输出的残酷新奥义][原始记录才是正义] -> NBR-hugh 被说服,并反思自己记录的问题
现场:
@大妈
是也乎,( ̄▽ ̄)
觉得探索过程不宜发布
<– 反对! 原因也早已说过:
输出是更加残酷的输入
- 探索过程有发布的压力时,才能更好的记录
- 有了足够清晰/结构化的记录后,第一读者是自己
- 有助第一时间看清楚自己的思路和行为是否统一
- 有助形成学习/实践/输出的节奏:
- 是的, 如果折腾完再来记录, 经常回忆不起, 而且又没有合理的工具来维护这种行为序列
- 是的, 这又是一个 MVP 的落地点
- 思考 -> 什么节奏/时间长度,对自己最合适?可以解决一个最小问题?
- 以及什么是最小问题?
- 怎么定义/预测/规划, 最小问题序列 ?
写笔记时只想着自己要什么,没有想到读者要什么
教会他人才能证明自己真正会了
- 在没有具体的他人时, 半年前的自己就是 读者!
- 如果输出的文档, 连自己都看不明白, 那没有人可以看明白的
- 所以,
只想着自己要什么
<– 是对的- 嘦将时间线向前调节半年
- 就能判定出要写什么记录什么,以及劝说什么了…
不发布 不等于不记录
- 错, 不发布的记录等于没有记录
- 因为, 你放弃了直接的 debug 渠道
- 同时也给自己的心理给了一个足够偷懒的空间,危险
作品更偏向是教程,指南的清晰具体
- 错, 记录就是记录, 不用风格化为其它什么东西
- 教程/指南 原本就是记录:
- 真实的可复现的操作指令序列
- 夹一些提醒自己容易出错的说明
- 只是后来出版社为了绩效乱加了那些我们以为是好的风格化的玩意儿
半年前的自己也很陌生
- 错, 不是陌生, 只是陌视而已
- 人的记忆其实非常扎实的, 只是长期记忆的提取要有特殊技能
- 这里的半年,是借用义务学制中的学年概念, 半年就是期中考试, 也就是半途止损点
- 我们要求/需要/期待的是可用文档, 不是出去卖銭的成品图书
- 所以, 嫑合自己太多完全不必要的假设写作要求
- 技术文档/记要只有一个唯一指标:
- 可用
- 即,根据你的文档可以解决对应问题
- 所以, 设想读者想看什么根本是方向反了
- 而是, 自己重新再解决同一问题时,如何能更加简易/不出错?
当时的记录与后来的反思修改的区别 … 探索过程记录未结构化,保证可读性时,不宜直接发布
- 错, 原始记录才是正义, 其它的都是表演
- 又错, 为什么记录时,就不能直接结构化了?
- 学习使用 md 不就是为了将结构化最简洁的进行?
- 以及, 所有程序输出/调试打印, 不都是为了自己可读?
- 如果记录的一定是不可读的,只能证明记录错东西了..
- <– 输出是更加残酷的输入
- 又一层含义就在这儿
- 为了输出的记录, 才是对的,可用的
- 否则, 你记录的根本对解决问题无帮助的…
@倪必荣
错, 不发布的记录等于没有记录 因为, 你放弃了直接的 debug 渠道 同时也给自己的心理给了一个足够偷懒的空间,危险
- 是了,发布不发布在我的心智中是无差别的
- 所以我从来不曾以
发布
的压力来修正我的记录 重读一遍笔记,细查我看不下原因:
- 太多心情化的用语,影响问题思路进行
- 执行代码与结果代码未区分,增添的认知负担让我难受
- 想起 github help 与赖神的笔记就是只给操作代码
- 想起 github help 与赖神的笔记就是只给操作代码
我就在这个
足够偷懒的空间
危险地呆了三个月- 时间利用效率就低了
- 思考的有效性就低了
- 拖拖拖…..
这也是我
回复慢,任务处理慢
的一个重要原因- 后面可以再修改,所以
足够偷懒的空间
就出来了 - 如何挤压偷懒空间?
- 定时,时间的压力
- 能否看一次就提取所信息要点?
- 能否再提笔前就想好自己说的要点?
- 能否一次完成,绝不返工?
- 唯一的途径就是练习
- 自怼圈的提问/思考任务都是良好的锻炼机会
- 所有行为取向剑指思考质量与节奏
- 下笔即是发布,及时反馈
- 刚开始会不适应/难过,但是坚持如此有意识的训练
- 必然可以达到–>又快又好
- 这也是大妈强调知识快速流通节奏的价值所在
- 后面可以再修改,所以
我心他心天下心适合写故事,但不适合写清晰的文档
记录 = 教程/指南 = 真实可复现操作命令序列 + 错误提示说明
错, 原始记录才是正义, 其它的都是表演
- 原来原始数据的使用/改进,心智调整磨炼比后期修改调整更有效
- 这在于
- 时间的有限性
- 精力的有限性
- 所以必须
- 从源头解决问题
- 即你的意识,你的行为,你的心.
后记
~ 怼周刊是什么以及为什么和能怎么…
大妈曰过: 参差多态 才是生机
问题在 参差
的行为是无法形成团队的
Coming together is a beginning;
Keeping together is progress;
Working together is success!
- 所以, 有了 大妈 随见随怼的持续嗯哼…
- 但是, 想象一年后, 回想几十周前自己作的那些
图样图森破
- 却没现成的资料来出示给后进来嗯哼?
- 不科学, 值得记录的, 就应当有个形式固定下来
- 所以,有了这个
怼周刊
(DUWeekly)