怼周刊_v18

~ 预定 17.8.14 14:42 发布 Release time - 14:42, August 14th, 2017

See U See Me

看你看我看大家
怼文怼码怼思维
等他等她没止境
搞事搞完搞出彩
怕错怕囧怕不停
嫑猜嫑挫嫑脑补
动手动脑动车组
从今从严从输出
看你看我精进矣

See you, see me and see us
Debug writing, debug coding and debug thinking
There is no end to wait him or her
Keep doing, keep done and keep wonderful
Don't be afraid of error and embarrassed
Don't guess and don't imagine
Just thinking and doing
Keeping output from now on
See you, see me and see us
We can do better than before

进度 Timelines

~ 记录当周关键事件日期+证据链接

任务 Tasks

~ 记述关键共怼任务 (如果没有, 留空)

进展 Progress

~ 整体上圈内部活跃指标情况

<<<<<<< HEAD - 提交: 8 人 (比上周新增 2 人) - 小组 @zoomquiet 时间帐单:效能分析小队 - 成员: @zsy @liguanghe @simpleowen @mxclover - @heta 深度学习 - @liguanghe 域外生活录 - @OMlalala 投资学习 - @zsy 编程与写作 - @zoejane 日常节奏形成 ||||||| merged common ancestors - 提交: ?? 人, ======= - 提交: 8 人 (比上周新增 2 人) - 小组 @zoomquiet 时间帐单:效能分析小队 - 成员: @zsy @liguanghe @simpleowen @mxclover - @heta 深度学习 - @liguanghe 域外生活录 - @OMlalala 投资学习 - @zsy 编程与写作 - @zoejane 日常节奏形成

ee3dbef52ae794972c2c9733bace9b84d8a1c38e - 引发的作品: + NIL - 状态:

allcic Commit timesweekly Commit times
zoejane288 OMlalala8
ZoomQuiet273 liguanghe6
liguanghe176 ZoomQuiet2
mxclover121 mxclover1
bambooom116 zhangshiyinrunwithcc1
all Commit Comments timesweekly CommitComments times
ZoomQuiet139 ZoomQuiet1
all Issue Comments timesweekly IssueComments times
ZoomQuiet346 liguanghe43
liguanghe246 ZoomQuiet9
zhangshiyinrunwithcc217 zhangshiyinrunwithcc8
zoejane100 mxclover4
NBR-hugh63 livingworld2

<- 20170813 22:39

  • 在线(测试ing..):
    • curl du.zoomquiet.us
    • curl du.zoomquiet.us/v0/all/cic/rank/5/
    • curl du.zoomquiet.us/v0/all/cil/rank/5/
    • curl du.zoomquiet.us/v0/week/cic/rank/5/
    • curl du.zoomquiet.us/v0/week/cil/rank/5/

成果 Achievements

~ 各种成品/半成品 内部知识作品

<<<<<<< HEAD

完整编程手册1(作者: 李广鹤)

引言

视频(密码:p6i1)演示生成20行代码,按时间线记录800行笔记. 高手对小白讲解了自己从一个需求到一个功能,不断拆解, 调试, 实现想法, 最后实现功能的思维和行为过程. 笔记的笔记: 完成这个笔记的知行合一 issue: 20d[TASK]精学大妈现场编程 · Issue #176 · DebugUself/du4proto, 欢迎持续增补.

知识点

需求到功能, 想法如何拆解?

整个过程大概是这样的, 首先, 我有一个小想法,我想实现它, 于是我写一个 readme.md, 告诉我自己和同伴们, 我想实现这个功能. 前提是, 我要先告诉大家,我有什么. 我的环境是什么. 有什么, 要什么.

在这个项目里面, 大妈有人可读的时间记录数据列表, 想变成机可读的. 为了实现这个目的, 大家不断在 README.md 里修改.

写代码, 调试.

过程如下: 

思路 - 需求 - 原始数据 - 开始打代码 - 代码结构 - 代码行 - 读代码 - 注释
|  \                                       |
背景知识 提问                              优雅代码

下面这张表是按照上面的内容逐条对比小白和高手的区别

type 小白 高手 学到
思路 不知道先干哪一步,理解项目要完全依赖 README,自己拿到原始数据无从下手, 没有思路 看到问题瞬间有200多个方法, 但不知道哪个有效.用思维工具把思维速度降下来. 定义清楚需求.用纸和笔把目的写下来,由果到因往回回溯. 定义清楚需求, 写下思路.
清楚需求 要转换成什么不知道 知道所有的变成秒,知道最后输出的是什么样子 知道计算机输出内容的一般样子, 以及特殊项目中的阶段性样貌.
对待原始数据的态度 只想到前两步,看到番茄钟的, 会认为没有必要就删掉. 尽可能把有效数据全部转换出来,供下一步程序员使用. 除非确定无用, 否则都要清洗. 充分利用所有数据, 全局考虑项目和组员.
写什么代码 google 如何实现功能的代码, 学着写, 举例:16-20行,看到把时间转成秒, 我也来写个脚本转秒,关键词是"yy",在标准库里面找, 没有找到.google 里面找,看到又现成的 app, 再搜这个关键词,不懂 先看默认标准库和模块.看最常见的 demo. 尊重源头知识, 到源头拿现成和核心的知识.
? doc.python.org/ 下载到本地, 常用200个库, 经常看. 跟 time 有关的, 到默认库检索 time.(官方模块千锤百炼)
拆分功能在代码上的显现(代码结构) 用命令行一次打开一个脚本 用命令行下的管道, 把一件事情拆分成不同的步骤. 举例ls 的含义是把文件夹下面的文件打印出来, 加上条件,以 zq开头的参数,把每一行打印出来, 不用一个一个打. 用 python 处理.stdin0, 处理数据, 第二步处理 head, 第三步把时间转成秒, 第四部把番茄钟转换成秒. 拆分功能在代码上的显现, 不仅仅是脚本中不同的模块, 还包括管道串联. 脚本只解决一个小功能.
背景知识 没有常识, 不知道什么是良构. csv 没经历过, 就读官方文档 多看项目, 都看官方文档
提问 明知卡住了,不问, 搜索时间过长, 在 slack 上提问, 提问内容80%陈述猜想, 而不是事实 认真提问, 事实, 环境/现象/问题/分析/方案, 描述过程中会产生方案. 尝试方案, 走通, 走不通,都记下来.一个方案15分钟走不下去, 就停止. 走不下去的方案是因为问题没有描述清楚. 不知道自己要干什么, 别人也无法回答. 回归需求和功能. 所有的项目都严格限定在这两点之间.
代码行 写一坨代码后再逐行调试 目前只写了四行代码, 调试五次(在命令行下面运行), 知道现在干嘛. 不断调试,让计算机反馈结果 这里可见下面的三级标题: 需求到功能之间.
优雅代码 _s = l.split() print('{},{}'.format(_s[0],_s[1])) print (','.join(l.split())) 简洁
写注释 改了什么 目的是什么,在调什么,用时, 要完成什么功能/探索.可以在git log 里很快的知道你做了什么事情. 仍然指向功能
读代码 从头开始读, 不懂 [1] 再一次的强调了功能和需求

[1] 代码是完成态,是线性的, 但读的形式和运行的次序是不同的.代码给出所有的通道,但是每行从哪个通道走, 你要清楚.

  1. 搞清楚这个代码是为了解决什么问题, 这个问题有哪些子问题.
  2. 清楚代码结构.从大到小: 先调一类数据, 再调一类, 都好了以后调试全部. if else, 是代码里的分支, 每个分支是做什么的, 你要清楚. 根据理解一个分支, 其他的不处理. 代码每两三行解决一个问题.
  3. 以上代码结构里的大大小小组块解决了什么问题?
  4. 读的具体方法
    1. #print 方便他人读你的代码,这是在反复验证你当时是怎么想的,怎么实现的. 不懂哪一行, 就去掉#, print你不懂的地方.
    2. 可以把代码注释掉, 看不懂, 就注释掉它, 不让他运行, 看差别, 就知道代码是在做什么.这与查 bug的冷冻调试法和二分法是一样的.制造可控 bug 以理解改行代码的意义. 最终定位到行.

需求到功能之间

  • 拆解 -> 想法 -> 实现 -> 调试 -> 拆解 ... 最后实现整个功能.
  • 之前不断强调的 MVP, 输入 -> 处理 -> 输出.
   代码 -> print -> 结果 -> 符合 -> #print -> git ->  下一个小想法
     ~             |
     |             v
     <------------不符合

if else 是编程的本质, 让计算机在面临选择的时候, 知道怎么进行下去. 每个脚本里的最小样本: 

if xx():
    print ...
else:
    pass

不断调试好,被注释掉的 print:

if xx():
    #print ...
else:
    if yy():
    print ...
    else: 
        pass
        ...

这样不断增加 if else 的过程, 就是不断从小到大实现想法, 最终实现功能的过程.

eg.线性记录line 75 - 167

代码中 数字, 符号, 括号都是什么(待完成)

一切皆数字. 脚本中的基本元素: 数字, 符号, 字母.

Py101-004/basic element and grammer of python.ipynb at master · liguanghe/Py101-004

由它们组成基本元素和语法

know what
yes if else import string print 变量 缩进4个空格 def class for..in..
no . [] () 0 1 -1

eg. 脚本里的数字和符号

  • if 1! = len(sys.argv)
  • l = line[:-1]
  • isDATE = 0
  • (i[0])

  • 以下有什么区别? print (i[:-1]) print (i[-1]) print (i[0])

  • is head:\n\t{}'.format(l)

  • (','.join(l.split()))

心

这里,其实也是双关语呢, 小白到高手, 也是需求和功能啊. 一个小白, 最终的目的是成为高手. 所以, 你要知道最终呈现(高手的样子), 也要知道目前环境(自己的样子). 按照<集异璧>的写法, 这篇笔记跟那本书一样, 都是有双关语的. 我们以编程为例, 不断对比小白和高手的异同, 不断接近最终呈现. 这同时也是一个小白转变为高手的过程. 在这里统一了.

高手是我的需求, 我先把他转化成功能, 再把自己的现状转化成原始数据, 拆解功能, 逐个完成,不断趋近目标.

沉迷学习, 无法自拔. 发布文章时的快乐, 我想这叫正向反馈, 当然, 你也可以说是嘚瑟.

怼友反馈

  • (大妈)
小白 高手
每次都上网现查 本地化
不完整看官网 看官方的外链
不写教程 写教程的技巧[1]

[1] - 每个人都必须写教程, 把自己的思路串起来. - 知识是相同的, 大家最后达成也相同. - 每个人不同, 每人中间要翻越的概念重组次数(跨过认知障碍)也不相同. 举例, 小白要重建很多层概念. 要一一对应 python 的形式, 要完成编程意义的重构. 每人要跨过的认知障碍都不同. - 突破认知障碍之前和之后也都不同, - 通过私人笔记记录, 跨之前的状态,摸索途径, 跨过之后的状态. - 摸索途径是 MVP, 每个想法都有输入和输出佐证. 逻辑分支之后再打印出来, 才能明确代码是对还是错. 脚本语言可以随时打印出来. 编译就不同了, 要看运行期才能看, 调试更费力. 这些体验要自己尝试.

  • (珍教) 工整巧思完备的笔记作者问出如此基础的编程问题, 让人从根本上质疑这份笔记是否有用. 小鹤参加过 py103, 也在大妈项目组中两个月, 为什么连最基础的语法还不知道. 是哪里出了问题, 是学习方式有漏洞么?
    • (小鹤)在 py103 的时候初次接触编程, 被大量的官方文档吓住. 前三周的作业都是抄同学的代码, 勉强完成.第四周就完全做不出来了. 那时的心气不足, 也就是仍旧会假想困难, 拒绝面对, 不懂求助等等. 这些都是在怼圈慢慢矫正过来的. 真的如大妈所说, 每人要翻越的无门大山都不同. 对你很容易的编程基本知识, 恰好是我不想去查阅的, 因为我'假想'它会很难, 所以'不想'去查. 但是在怼圈里就不同了. 大妈会不断鼓励. 能明确感觉到大妈的黑客生活方式, 编程是其中的一部分, 但在不会编程具体语言之前, 能不能用黑客的思维生活呢? 我在怼圈的最大收获是, 即使截止目前为止, 我还不会一些基础的编程语法. 但是, 我已经有了以上笔记所体现出来的问题拆解思路, 需求到功能再到代码转换. 这篇笔记是很好的例子.
    • (大妈)很简单, 代码写的少. 不写代码纯粹玩概念, 大家都可以把事情说的很清楚, 上手写代码才知道自己什么都不会. 编程知易行难, 编程是要求实践. 编程语言和框架进步, 接近自然语言, 你可以通过代码来约定形式. 产品经理不会编程但可以做好的产品经理. 概念说的清, 与程序员聊的下去. 上手写就会发现很多问题. 自然语言再接近也不同, 机器语言无法忍受模糊和逻辑混乱, 是严格逻辑自洽的. 是非自然的思维情况. 多实践, 立刻写代码.
    • (诗颖)小问题, 查阅, 不知道函数意义, 就写个变量打印出来即可.
    • (明星)Python的字符串处理部分,"Python编程快速上手—让繁琐工作自动化"里有详细解答.
  • (大妈)每次怼周会的内容应出现在怼周刊,吸引大家参加怼周会.

其他资源

http://openmindclub.qiniucdn.com/res/tr/tr_MDP2py4w_1_w1cli_rebuild.html http://openmindclub.qiniucdn.com/res/tr/tr_MDP2py4w_1_w1cli_rebuild.html http://openmindclub.qiniucdn.com/res/tr/tr_MDP2py4w_1_w1cli_rebuild.html 相关的过程性习惯都包含在各种公开的代码规范文档中: The Pocoo Style Guide — Pocoo

小鹤怼圈分享笔记技能

背景

大妈在五道口现场演示编程, 小鹤无缘亲见,好在有视频可以学习, 故做笔记之. 诗颖提点笔记技能亦应分享, 现分享笔记技能. 以此为例: <- 13d[TASK]精学大妈现场编程 · Issue #176 · DebugUself/du4proto

活动

  • 形式: 直播/zoom
  • 时间: 2017-08-12 周六怼周会
  • 分享人: 李广鹤
  • 资源: 链接: http://pan.baidu.com/s/1jIDr7Si 密码: smee
    • zoom_0(1).mpr, 13:50 开始至结尾

大纲

笔记技能: 打字速度 - 文义理解 - 重点记录 - 不同角度整理 - 增加可读性, 从读者角度再不断整理. 案例: 12d[TASK]精学大妈现场编程 · Issue #176 · DebugUself/du4proto

  • 打字速度
    • 热爱工具: 我爱我的键盘和我的 Mac
    • 双拼: 超简单快速提升打字速度
    • Markdown
  • 文义理解
    • 熟悉的文档打起
    • 时间地点人物时间, 线性记录最简单
      • 完全记录案例: ZQCodingNote.md
      • 全文重点是小白和高手的区别, 有意识的做列表.
    • 结果操作
  • 重点记录
    • 原因结果
    • 理论行动
    • 找不同
  • 整理
    • 根据线性记录产生的大体思路, 找出知识点
    • 将单个知识点的内容全部复制出来, 梳理清楚
    • 找到各个知识点之间的逻辑联系, 按顺序排列,写出逻辑
      • e.g. 把线性记录中小白和高手的列表全部粘在一起, 前面加一列: 知识点. 后面加一列, 我学到什么. 再把前面列的知识点用逻辑排序, 这样可以清楚的发现内在逻辑.
    • 找到整片文章的主题
    • 写在内容之外: 反 元 空
  • 添加目录
    • 笔记的过程也要笔记
    • 不断修改的时间节点, 任务完成程度和阶段性成果记录
    • 全部完成后自然生成目录
  • 完善关联内容和致谢
    • 如果有完善的部分就可以读.
  • 添加 timelog

引申

  • 以做笔记这个项目为例, 演示如何用 github 的 issue 做项目
    • issue 是行为和知识结合点
    • issue 和 wiki 和仓库的结合形成完整项目

致谢

  • 大妈的 issue wiki 演示教育
  • 诗颖提醒我分享笔记技能
  • <集异璧>中关于递归和堆栈

怼友反馈

大妈:

  • 最简信息环 Home · DebugUself/du4proto Wiki, 里面有很多信息
  • 正确使用 issue 和 wiki 的方式
    • issue 正文反复在改.
    • github 本质是一个大的 wiki, 分解成了仓库, wiki 和 issue
    • issue 是 README 和 wiki 起草的地方.
    • 得到大家的及时反馈.
    • 时间限定有始有终.
    • 初级版本转化成代码/项目/wiki
    • 持续不断改进, 重开/新 issue 链接 wiki.
    • 信息闭环
    • git 全部关联.
      • 任务与 wiki 关联, wiki 与 issue 又关联等.网状链接, 万物相联, 是现实世界的方法.
      • 对比word, 大量割裂, 无法沟通和共同修改.
  • 环是最重要的
    • 有始有终
    • 协同关系
  • 大妈4年之内在啄木鸟 wiki 里维护了 19 万个页面, 才有这个经验.
  • 笔记优先自己读.

小鹤:

  • 做笔记尽量让别人懂, 在 blog 草稿写, 让自己知道写的东西都是要发出去给人看的.
  • 写笔记不设置特别记号, 这是知识的诅咒. 越聪明的人越容易知识的诅咒.
  • 但程序员就是这样, 不断用记号, 用尽量短的字符表达更多信息.
  • 一方面学习缩写表明信息, 一方面继续坚持别人可以懂的笔记.

||||||| merged common ancestors

完整编程手册1(作者: 李广鹤)

引言

视频(密码:p6i1)演示生成20行代码,按时间线记录800行笔记. 高手对小白讲解了自己从一个需求到一个功能,不断拆解, 调试, 实现想法, 最后实现功能的思维和行为过程. 笔记的笔记: 完成这个笔记的知行合一 issue: 20d[TASK]精学大妈现场编程 · Issue #176 · DebugUself/du4proto, 欢迎持续增补.

知识点

需求到功能, 想法如何拆解?

整个过程大概是这样的, 首先, 我有一个小想法,我想实现它, 于是我写一个 readme.md, 告诉我自己和同伴们, 我想实现这个功能. 前提是, 我要先告诉大家,我有什么. 我的环境是什么. 有什么, 要什么.

在这个项目里面, 大妈有人可读的时间记录数据列表, 想变成机可读的. 为了实现这个目的, 大家不断在 README.md 里修改.

写代码, 调试.

过程如下: 

思路 - 需求 - 原始数据 - 开始打代码 - 代码结构 - 代码行 - 读代码 - 注释
|  \                                       |
背景知识 提问                              优雅代码

下面这张表是按照上面的内容逐条对比小白和高手的区别

type 小白 高手 学到
思路 不知道先干哪一步,理解项目要完全依赖 README,自己拿到原始数据无从下手, 没有思路 看到问题瞬间有200多个方法, 但不知道哪个有效.用思维工具把思维速度降下来. 定义清楚需求.用纸和笔把目的写下来,由果到因往回回溯. 定义清楚需求, 写下思路.
清楚需求 要转换成什么不知道 知道所有的变成秒,知道最后输出的是什么样子 知道计算机输出内容的一般样子, 以及特殊项目中的阶段性样貌.
对待原始数据的态度 只想到前两步,看到番茄钟的, 会认为没有必要就删掉. 尽可能把有效数据全部转换出来,供下一步程序员使用. 除非确定无用, 否则都要清洗. 充分利用所有数据, 全局考虑项目和组员.
写什么代码 google 如何实现功能的代码, 学着写, 举例:16-20行,看到把时间转成秒, 我也来写个脚本转秒,关键词是"yy",在标准库里面找, 没有找到.google 里面找,看到又现成的 app, 再搜这个关键词,不懂 先看默认标准库和模块.看最常见的 demo. 尊重源头知识, 到源头拿现成和核心的知识.
? doc.python.org/ 下载到本地, 常用200个库, 经常看. 跟 time 有关的, 到默认库检索 time.(官方模块千锤百炼)
拆分功能在代码上的显现(代码结构) 用命令行一次打开一个脚本 用命令行下的管道, 把一件事情拆分成不同的步骤. 举例ls 的含义是把文件夹下面的文件打印出来, 加上条件,以 zq开头的参数,把每一行打印出来, 不用一个一个打. 用 python 处理.stdin0, 处理数据, 第二步处理 head, 第三步把时间转成秒, 第四部把番茄钟转换成秒. 拆分功能在代码上的显现, 不仅仅是脚本中不同的模块, 还包括管道串联. 脚本只解决一个小功能.
背景知识 没有常识, 不知道什么是良构. csv 没经历过, 就读官方文档 多看项目, 都看官方文档
提问 明知卡住了,不问, 搜索时间过长, 在 slack 上提问, 提问内容80%陈述猜想, 而不是事实 认真提问, 事实, 环境/现象/问题/分析/方案, 描述过程中会产生方案. 尝试方案, 走通, 走不通,都记下来.一个方案15分钟走不下去, 就停止. 走不下去的方案是因为问题没有描述清楚. 不知道自己要干什么, 别人也无法回答. 回归需求和功能. 所有的项目都严格限定在这两点之间.
代码行 写一坨代码后再逐行调试 目前只写了四行代码, 调试五次(在命令行下面运行), 知道现在干嘛. 不断调试,让计算机反馈结果 这里可见下面的三级标题: 需求到功能之间.
优雅代码 _s = l.split() print('{},{}'.format(_s[0],_s[1])) print (','.join(l.split())) 简洁
写注释 改了什么 目的是什么,在调什么,用时, 要完成什么功能/探索.可以在git log 里很快的知道你做了什么事情. 仍然指向功能
读代码 从头开始读, 不懂 [1] 再一次的强调了功能和需求

[1] 代码是完成态,是线性的, 但读的形式和运行的次序是不同的.代码给出所有的通道,但是每行从哪个通道走, 你要清楚.

  1. 搞清楚这个代码是为了解决什么问题, 这个问题有哪些子问题.
  2. 清楚代码结构.从大到小: 先调一类数据, 再调一类, 都好了以后调试全部. if else, 是代码里的分支, 每个分支是做什么的, 你要清楚. 根据理解一个分支, 其他的不处理. 代码每两三行解决一个问题.
  3. 以上代码结构里的大大小小组块解决了什么问题?
  4. 读的具体方法
    1. #print 方便他人读你的代码,这是在反复验证你当时是怎么想的,怎么实现的. 不懂哪一行, 就去掉#, print你不懂的地方.
    2. 可以把代码注释掉, 看不懂, 就注释掉它, 不让他运行, 看差别, 就知道代码是在做什么.这与查 bug的冷冻调试法和二分法是一样的.制造可控 bug 以理解改行代码的意义. 最终定位到行.

需求到功能之间

  • 拆解 -> 想法 -> 实现 -> 调试 -> 拆解 ... 最后实现整个功能.
  • 之前不断强调的 MVP, 输入 -> 处理 -> 输出.
   代码 -> print -> 结果 -> 符合 -> #print -> git ->  下一个小想法
     ~             |
     |             v
     <------------不符合

if else 是编程的本质, 让计算机在面临选择的时候, 知道怎么进行下去. 每个脚本里的最小样本: 

if xx():
    print ...
else:
    pass

不断调试好,被注释掉的 print:

if xx():
    #print ...
else:
    if yy():
    print ...
    else: 
        pass
        ...

这样不断增加 if else 的过程, 就是不断从小到大实现想法, 最终实现功能的过程.

eg.线性记录line 75 - 167

代码中 数字, 符号, 括号都是什么(待完成)

一切皆数字. 脚本中的基本元素: 数字, 符号, 字母.

Py101-004/basic element and grammer of python.ipynb at master · liguanghe/Py101-004

由它们组成基本元素和语法

know what
yes if else import string print 变量 缩进4个空格 def class for..in..
no . [] () 0 1 -1

eg. 脚本里的数字和符号

  • if 1! = len(sys.argv)
  • l = line[:-1]
  • isDATE = 0
  • (i[0])

  • 以下有什么区别?

    • print (i[:-1])
    • print (i[-1])
    • print (i[0])

  • is head:\n\t{}'.format(l)

  • (','.join(l.split()))

心

这里,其实也是双关语呢, 小白到高手, 也是需求和功能啊. 一个小白, 最终的目的是成为高手. 所以, 你要知道最终呈现(高手的样子), 也要知道目前环境(自己的样子). 按照<集异璧>的写法, 这篇笔记跟那本书一样, 都是有双关语的. 我们以编程为例, 不断对比小白和高手的异同, 不断接近最终呈现. 这同时也是一个小白转变为高手的过程. 在这里统一了.

高手是我的需求, 我先把他转化成功能, 再把自己的现状转化成原始数据, 拆解功能, 逐个完成,不断趋近目标.

沉迷学习, 无法自拔. 发布文章时的快乐, 我想这叫正向反馈, 当然, 你也可以说是嘚瑟.

怼友反馈

  • (大妈)
小白 高手
每次都上网现查 本地化
不完整看官网 看官方的外链
不写教程 写教程的技巧[1]

[1] - 每个人都必须写教程, 把自己的思路串起来. - 知识是相同的, 大家最后达成也相同. - 每个人不同, 每人中间要翻越的概念重组次数(跨过认知障碍)也不相同. 举例, 小白要重建很多层概念. 要一一对应 python 的形式, 要完成编程意义的重构. 每人要跨过的认知障碍都不同. - 突破认知障碍之前和之后也都不同, - 通过私人笔记记录, 跨之前的状态,摸索途径, 跨过之后的状态. - 摸索途径是 MVP, 每个想法都有输入和输出佐证. 逻辑分支之后再打印出来, 才能明确代码是对还是错. 脚本语言可以随时打印出来. 编译就不同了, 要看运行期才能看, 调试更费力. 这些体验要自己尝试.

  • (珍教) 工整巧思完备的笔记作者问出如此基础的编程问题, 让人从根本上质疑这份笔记是否有用. 小鹤参加过 py103, 也在大妈项目组中两个月, 为什么连最基础的语法还不知道. 是哪里出了问题, 是学习方式有漏洞么?
    • (小鹤)在 py103 的时候初次接触编程, 被大量的官方文档吓住. 前三周的作业都是抄同学的代码, 勉强完成.第四周就完全做不出来了. 那时的心气不足, 也就是仍旧会假想困难, 拒绝面对, 不懂求助等等. 这些都是在怼圈慢慢矫正过来的. 真的如大妈所说, 每人要翻越的无门大山都不同. 对你很容易的编程基本知识, 恰好是我不想去查阅的, 因为我'假想'它会很难, 所以'不想'去查. 但是在怼圈里就不同了. 大妈会不断鼓励. 能明确感觉到大妈的黑客生活方式, 编程是其中的一部分, 但在不会编程具体语言之前, 能不能用黑客的思维生活呢? 我在怼圈的最大收获是, 即使截止目前为止, 我还不会一些基础的编程语法. 但是, 我已经有了以上笔记所体现出来的问题拆解思路, 需求到功能再到代码转换. 这篇笔记是很好的例子.
    • (大妈)很简单, 代码写的少. 不写代码纯粹玩概念, 大家都可以把事情说的很清楚, 上手写代码才知道自己什么都不会. 编程知易行难, 编程是要求实践. 编程语言和框架进步, 接近自然语言, 你可以通过代码来约定形式. 产品经理不会编程但可以做好的产品经理. 概念说的清, 与程序员聊的下去. 上手写就会发现很多问题. 自然语言再接近也不同, 机器语言无法忍受模糊和逻辑混乱, 是严格逻辑自洽的. 是非自然的思维情况. 多实践, 立刻写代码.
    • (诗颖)小问题, 查阅, 不知道函数意义, 就写个变量打印出来即可.
    • (明星)Python的字符串处理部分,"Python编程快速上手—让繁琐工作自动化"里有详细解答.
  • (大妈)每次怼周会的内容应出现在怼周刊,吸引大家参加怼周会.

其他资源

http://openmindclub.qiniucdn.com/res/tr/tr_MDP2py4w_1_w1cli_rebuild.html http://openmindclub.qiniucdn.com/res/tr/tr_MDP2py4w_1_w1cli_rebuild.html http://openmindclub.qiniucdn.com/res/tr/tr_MDP2py4w_1_w1cli_rebuild.html 相关的过程性习惯都包含在各种公开的代码规范文档中: The Pocoo Style Guide — Pocoo

小鹤怼圈分享笔记技能

背景

大妈在五道口现场演示编程, 小鹤无缘亲见,好在有视频可以学习, 故做笔记之. 诗颖提点笔记技能亦应分享, 现分享笔记技能. 以此为例: <- 13d[TASK]精学大妈现场编程 · Issue #176 · DebugUself/du4proto

活动

  • 形式: 直播/zoom
  • 时间: 2017-08-12 周六怼周会
  • 分享人: 李广鹤
  • 资源: 链接: http://pan.baidu.com/s/1jIDr7Si 密码: smee
    • zoom_0(1).mpr, 13:50 开始至结尾

大纲

笔记技能: 打字速度 - 文义理解 - 重点记录 - 不同角度整理 - 增加可读性, 从读者角度再不断整理. 案例: 12d[TASK]精学大妈现场编程 · Issue #176 · DebugUself/du4proto

  • 打字速度
    • 热爱工具: 我爱我的键盘和我的 Mac
    • 双拼: 超简单快速提升打字速度
    • Markdown
  • 文义理解
    • 熟悉的文档打起
    • 时间地点人物时间, 线性记录最简单
      • 完全记录案例: ZQCodingNote.md
      • 全文重点是小白和高手的区别, 有意识的做列表.
    • 结果操作
  • 重点记录
    • 原因结果
    • 理论行动
    • 找不同
  • 整理
    • 根据线性记录产生的大体思路, 找出知识点
    • 将单个知识点的内容全部复制出来, 梳理清楚
    • 找到各个知识点之间的逻辑联系, 按顺序排列,写出逻辑
      • e.g. 把线性记录中小白和高手的列表全部粘在一起, 前面加一列: 知识点. 后面加一列, 我学到什么. 再把前面列的知识点用逻辑排序, 这样可以清楚的发现内在逻辑.
    • 找到整片文章的主题
    • 写在内容之外: 反 元 空
  • 添加目录
    • 笔记的过程也要笔记
    • 不断修改的时间节点, 任务完成程度和阶段性成果记录
    • 全部完成后自然生成目录
  • 完善关联内容和致谢
    • 如果有完善的部分就可以读.
  • 添加 timelog

引申

  • 以做笔记这个项目为例, 演示如何用 github 的 issue 做项目
    • issue 是行为和知识结合点
    • issue 和 wiki 和仓库的结合形成完整项目

致谢

  • 大妈的 issue wiki 演示教育
  • 诗颖提醒我分享笔记技能
  • <集异璧>中关于递归和堆栈

怼友反馈

大妈:

  • 最简信息环 Home · DebugUself/du4proto Wiki, 里面有很多信息
  • 正确使用 issue 和 wiki 的方式
    • issue 正文反复在改.
    • github 本质是一个大的 wiki, 分解成了仓库, wiki 和 issue
    • issue 是 README 和 wiki 起草的地方.
    • 得到大家的及时反馈.
    • 时间限定有始有终.
    • 初级版本转化成代码/项目/wiki
    • 持续不断改进, 重开/新 issue 链接 wiki.
    • 信息闭环
    • git 全部关联.
      • 任务与 wiki 关联, wiki 与 issue 又关联等.网状链接, 万物相联, 是现实世界的方法.
      • 对比word, 大量割裂, 无法沟通和共同修改.
  • 环是最重要的
    • 有始有终
    • 协同关系
  • 大妈4年之内在啄木鸟 wiki 里维护了 19 万个页面, 才有这个经验.
  • 笔记优先自己读.

小鹤:

  • 做笔记尽量让别人懂, 在 blog 草稿写, 让自己知道写的东西都是要发出去给人看的.
  • 写笔记不设置特别记号, 这是知识的诅咒. 越聪明的人越容易知识的诅咒.
  • 但程序员就是这样, 不断用记号, 用尽量短的字符表达更多信息.
  • 一方面学习缩写表明信息, 一方面继续坚持别人可以懂的笔记.

ee3dbef52ae794972c2c9733bace9b84d8a1c38e

故事 Stories

~ 收集各自无法雷同的怼圈真人故事...

@liguanghe - 英语学习 Tips

  • 里程碑小故事
    • 回忆我学英语的过程, 里面有个里程碑的事件: 跟一个美国老绅士Jim持续一年, 每天 skype 通话半小时. 他非常耐心, 而且听得懂别人的英语. 我在那时掌握了基本的语音/语调/语法/常用句/对话的勇气.
    • 后来因为工作原因断掉一段时间, 好在我们断续邮件联系. 最近我英语写博客, 就是每天写信给他, 写一个主题, 然后把写的内容在博客上发出来. 这种效果非常好.
  • 和外国人开聊的途径
    • 互联网认识外国人的方法, 付费: italki (相对国内的语言课程, 非常便宜) 到国外旅游, 多住青旅, 和旅客聊天. Start talking 开聊 | Li Guanghe's blog
    • 我下周或更晚会去新西兰当地英语 club, 如果有兴趣跟他们聊的怼友可以先跟我登记, 我来当媒介组成一对一的语言对子.
  • 如何持续的聊下去
    • 刚开始是日常生活汇报, 听对方做了什么, 自己做了什么. 聊过去有意思的事情, 旅游啊什么的. 后来为了能继续有话聊, 就多接触英语节目等等, 所有跟美国和英语有关的东西, 聊. 再后来看当天的新闻, 聊新闻. 再后来主动找话题, 自己说不明白也没问题,对方说的明白呀, 当练听力啦.
    • 其实我在这边生活也经常词不达意, 秘诀就是会提问题. "what's your favioriat city?" 对方就会 balalbala 一大堆, 然后你适时的 wow, so cool, nice ,oh no, never do that, 然后就 ok 啦. 把对方的话录下来, 回头边听边写, 这样就知道对方说了什么句子, 下次用在对话里, 变成你的了.
    • 关于坚持, 因为在怼圈这里有持续的正向反馈, 因为发布博客时有心流, 因为所有的事情都可以用来写博客.所以可以坚持行动.

@liguanghe - 如何持续写作

关于博客怎么持续的写下去, 写什么, 我的心得如下:

写作与生活的每时每刻:

  • 让鼻子做它该做的 — 开智写作课结业分享 | Li Guanghe's blog
  • 人其实每时每刻都在写作, 只是写在脑子里, 没有写在纸上.
  • 生活中如果没有反省(写作和记录), 就不能平和的与过去和未来共处.
  • issue/wiki/日记/项目报告/主题分析.....一切皆博客.
  • 我的博客完整的呈现了我的日常生活和思想, 将来的老板/朋友任何人, 翻看我的博客会更容易理解我.
  • 担心内容杂乱就善用标签/分类/多页面.
    • 我的三个关键词是: 生活/新知/创造, 引导大家阅读文章, 这样就不会乱了.

极简写作环境

  • Markdown 编辑器 - github 仓库 ... 网页
  • 写作最大的问题是没有素材, 阳老谈快速写作说到, 日常积累卡片, 定期拼接成好文.
  • 卡片记录在哪里? github 仓库里有 drafts 和 posts, 卡片记录在 draft 里.
  • 用 it_all_text 将 网络文本框和 博客仓库中的drafts联系起来, 这样可将一切网络随机分享自动放进你的草稿箱(drafts), 例如github 的issue,你说不知道自己写什么, 但上面的文字可是很多的哦.
  • 觉得时机成熟, 就将 drafts 里的某篇整理成文, 放到 posts里, 一键生成博客.

推荐 Recommedations

~ 嗯哼各种怼路上发现的嗯哼...

后记 Postscript

~ 怼周刊是什么以及为什么和能怎么...

大妈曰过: 参差多态 才是生机 问题在 参差 的行为是无法形成团队的

Coming together is a beginning; Keeping together is progress; Working together is success!

<--- Henry Ford

  • 所以, 有了 大妈 随见随怼的持续嗯哼...
  • 但是, 想象一年后, 回想几十周前自己作的那些 图样图森破
  • 却没现成的资料来出示给后进来嗯哼?
  • 不科学, 值得记录的, 就应当有个形式固定下来
  • 所以,有了这个 怼周刊 (Weekly 4 DU)

What is DUW? Why we make DUW? What are the possibilities of DUW?

Dama said, variety brings vitality. But various behaviors may make us hard to cooperate as a team.

Coming together is a beginning; Keeping together is progress; Working together is success!

<--- Henry Ford

That's why Dama keeps on debugging. However, as time goes by, maybe you would not remember these days clearly and spread your experience difficultly. What a pity! The valuable should have a fixed form to be recorded. That's why we make the Weekly for DU.

点击注册~> 获得 100$ 体验券: DigitalOcean Referral Badge

订阅 substack 体验古早写作:

关注公众号, 持续获得相关各种嗯哼:
zoomquiet

自怼圈/年度番新

DU22.4
关于 ~ DebugUself with DAMA ;-)

追问

任何问题, 随时邮件提问可也:
[email protected]