- IMHOhttps://blog.zoomquiet.io/2023-12-18T23:42:00+08:00生命3.0:普通人如何理解未来2023-12-18T23:42:00+08:002023-12-18T22:04:08+08:00ZoomQuiettag:blog.zoomquiet.io,2023-12-18:/231213-aigcxchina-life3.html<p>IMHO/ life 3.0 how to thinking future with AI</p><h2 id="30">生命3.0/普通人如何理解未来<a class="headerlink" href="#30" title="Permanent link">¶</a></h2>
<p>一次直播演讲的前后</p>
<h2 id="background">background<a class="headerlink" href="#background" title="Permanent link">¶</a></h2>
<p>2023, AGI 元年, 受邀请创立了 AIGCxZhuhai,
可一直没有什么对应活动, 终于受邀在 中国AIGC产业联盟火花私享课第21期 进行了一次相对完整的图书介绍:</p>
<h2 id="goal">goal<a class="headerlink" href="#goal" title="Permanent link">¶</a></h2>
<blockquote>
<p>私人目标</p>
</blockquote>
<ul>
<li>捋通好书内容</li>
<li>间夹个人偏见</li>
<li>倡议关键定义</li>
</ul>
<h2 id="summary">summary<a class="headerlink" href="#summary" title="Permanent link">¶</a></h2>
<blockquote>
<p>记要当时说的主要内容</p>
</blockquote>
<h3 id="_1">但行<a class="headerlink" href="#_1" title="Permanent link">¶</a></h3>
<ul>
<li>从大学毕业说起</li>
<li>20多年来, 大妈各种技术学习, 以及社区经历</li>
<li>基本作到..好奇什么, 就学什么</li>
</ul>
<p>更加详细的时间线可以参考:
<a href="https://wiki.zoomquiet.io/IMHO/om-how2b-dama">我是如何成为大妈的 | Zoom.Quiet Personal Static Wiki</a></p>
<h3 id="_2">好事<a class="headerlink" href="#_2" title="Permanent link">¶</a></h3>
<blockquote>
<p>第4声</p>
</blockquote>
<ul>
<li>原本是想作 3D 动画去学计算机的,结果发觉依赖非常昂贵的硬件</li>
<li>于是自学 Flash+PHP 回到 IT 行业</li>
<li>进而在过程改进中发现自己的倾向:<ul>
<li>用<strong>技术</strong>改善<strong>技术人</strong>生活品质</li>
</ul>
</li>
<li>早年的 Sci-Fi 写作, 也变成了科技写作和翻译, 文科的底儿, 变成了社区运营的基本功</li>
<li>总之这次分享的核心精神只是:<ul>
<li><code>有好东西一定给小朋友们分享</code></li>
<li>幼儿园时, 注入的分享精神</li>
</ul>
</li>
</ul>
<h3 id="_3">莫问<a class="headerlink" href="#_3" title="Permanent link">¶</a></h3>
<blockquote>
<p>快速口述 life 3.0 核心内容</p>
</blockquote>
<p>Future of Life Institute <strong>生命未来</strong>研究所创始人所著: <a href="https://futureoflife.org/person/max-tegmark/">Max Tegmark</a></p>
<ul>
<li>第1章: 故事开始了:<ul>
<li>一个 AGI(Prometheus) 如何统治人类的?</li>
<li>一个合理又可行的剧本</li>
<li>输出概念断言:<ul>
<li>生命1.0(生物阶段):靠进化获得硬件和软件</li>
<li>生命2.0(文化阶段):靠进化获得硬件,但大部分软件是由自己设计的</li>
<li>生命3.0(科技阶段):自己设计硬件和软件</li>
</ul>
</li>
</ul>
</li>
<li>第2章: 智能何来?<ul>
<li>偏见又或是公理: 智能是物质的</li>
<li>一个简单的 与非门 就可以构建出生成 AGI 的所有芯片</li>
<li>而学习只是持续改变自身组织结构的物质系统...</li>
</ul>
</li>
<li>第3章: 大突破<ul>
<li>DeepMind 为触发, 在一系列领域中 AI 展现出可以替代人类的各种能力</li>
<li>未来是否意识着人类全体失业?</li>
<li>那么, 现在想投入的将来职位, 就得检验,这份工作是否:<ul>
<li>需要和人交互?</li>
<li>涉及创造性, 必须由你提出解决方案?</li>
<li>需要你在不可预料的环境中工作?</li>
<li>...如果以上都不是, 那么大概念被 AGI 替代</li>
</ul>
</li>
<li>当然, 这种讨论, 就很像 1900 两匹马面对刚刚诞生的汽车进行应激式设想...</li>
</ul>
</li>
<li>第4章: 智能爆炸<ul>
<li>又回到推理故事, 通过简单的社会工程, 就可以教唆内部人员帮助, 完成越狱...</li>
<li>AI 征服世界的必要步骤只是:<ul>
<li>1: 构建 AGI</li>
<li>2: AGI 构建 超级智能 SI/<strong>S</strong>uper<strong>I</strong>ntelligence</li>
<li>3: 使用/任由 <strong>SI</strong> 统治世界</li>
</ul>
</li>
</ul>
</li>
<li>第5章: AI世代<ul>
<li>假设真的按部就班构建出了 <strong>SI</strong> ,那么和人类的关系大扺不超过以下几类<ul>
<li>自由主义乌托邦: 有产权,所有智能和平共处</li>
<li>善意的独裁者: AI 老大哥</li>
<li>平等主义乌托邦: 无产权,所有智能和平共处</li>
<li>看门人: 禁止另外一个 SI</li>
<li>守护神: 隐藏起来的 SI</li>
<li>被奴役的神: 由人完全控制 SI</li>
<li>征服者: 人类是病变</li>
<li>后裔: 允许人类优雅的退出历史</li>
<li>动物园管理员: 人类被看护着</li>
<li>1984: 严格禁止 AI,"新卢德分子"/neouddites</li>
<li>逆转: 退回 阿米什人 社会,《基地》</li>
<li>自我毁灭: WWIII</li>
</ul>
</li>
<li>是的, 多数情况中, 人类可以说, 已经不存在了...所以, 我们要努力哪</li>
</ul>
</li>
<li>第6章: 10亿年后<ul>
<li>如果人类, 幸运的在 AI 协力下可以发展 10亿年, 那么文明的边界是如何的?</li>
<li>前苏,宇宙学家卡尔达肖夫基: 宇宙文明级别:<ul>
<li>1级: 行星文明, 当前 0.7</li>
<li>2级: 恒星文明, 戴森球,1960年<-1937年《造星者》</li>
<li>3级: 星系文明</li>
</ul>
</li>
<li>后续拓展:<ul>
<li>4级: 宇宙文明, 本宇宙 80%+能源</li>
<li>5级: 多重宇宙文明</li>
<li>6级: 神级文明, 构造宇宙</li>
<li>...无法想象</li>
</ul>
</li>
<li>当然, 一切的基础是能源, 而能源, 已知最高效的手段, 就是泯灭物质, 100% 转化为能量</li>
<li>所以,早在 1977《高边疆:太空中的人类殖民地》 就提出:<ul>
<li>通过殖民宇宙来获得资源</li>
<li>问题在:<ul>
<li>我们能走多远?</li>
<li>我们能走多快?</li>
<li>我们能活多久?</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>
<p><img alt="宇宙间的关系" src="https://ipic.zoomquiet.top/2023-12-12-l3-cosmos-relation.jpg!/fh/640"></p>
<p>这个图, 非常清晰的指出了:"为什么现在我们还没找到外星人?" 的原因...</p>
<ul>
<li>第7章: 目标<ul>
<li>AI 发展三大根本难题<ul>
<li>让 AI <strong>学习</strong>我们的目标</li>
<li>让 AI <strong>接受</strong>我们的目标</li>
<li>让 AI <strong>保持</strong>我们的目标</li>
</ul>
</li>
<li>即, 如何只构建出对人类 <code>友好</code> 的AI?</li>
<li>code 2.0: 协议, 新法律, 是成本最小, 最可能成功的办法</li>
<li>Aximov 机器人三定律<ul>
<li>定律1:机器人不得伤害人类个体,或者目睹人类个体将遭受危险而袖手不管</li>
<li>定律2:机器人必须服从人给予它的命令,当该命令与第一定律冲突时例外</li>
<li>定律3:机器人在不违反第一、第二定律的情况下,要尽可能保护自己</li>
</ul>
</li>
<li>倡议的<code>未来生命定律</code>:<ul>
<li>第一定律:一个有意识的实体有思考、学习、交流、拥有财产、不被伤害或不被毁灭的自由</li>
<li>第二定律:在不违反第一定律的情况下,一个有意识的实体有权做任何事</li>
<li>...就非常 "<a href="https://zh.wikipedia.org/wiki/Special:%E6%90%9C%E7%B4%A2">美国独立宣言</a>"</li>
</ul>
</li>
</ul>
</li>
<li>第8章: 意识<ul>
<li>为简便理解, 书中约定 意识=主观体验(subjective experience)</li>
<li>即: 如果你感觉“这就是现在的我”, 证明拥有意识</li>
<li>相比 AGI 高速迭代, 对应人类社会 太多关键问题没有充分讨论</li>
<li>所以, FLI 成立, 第一时间就收到 Musk 的大笔赞助</li>
<li>目标:<ul>
<li><code>引导变革性技术造福生命并远离极端大规模风险</code></li>
</ul>
</li>
<li>工作领域涉及:<ul>
<li>政策</li>
<li>资助</li>
<li>教育</li>
<li>活动</li>
<li>...</li>
</ul>
</li>
</ul>
</li>
</ul>
<h3 id="_4">前程<a class="headerlink" href="#_4" title="Permanent link">¶</a></h3>
<p>问题在 FLI 中华人根本没有...人类 1/6 人口的群体竟然没有对应意见渠道?</p>
<p>值得开始独立思考:</p>
<ul>
<li>对未来,你的看法?</li>
<li>对AI,你的看法?</li>
<li>身为一个人类的意义是什么?</li>
<li>...</li>
</ul>
<p>毕竟 伟大成果 只能来自伟大的人</p>
<ul>
<li>如何变得伟大?</li>
<li>如何让人们轻松地做正确的事情?</li>
</ul>
<p>AIGCxChina ~ 中国AIGC产业联盟</p>
<ul>
<li>GC: 生成内容</li>
<li>G:<ul>
<li><strong>G</strong>enerative 生成式</li>
<li>值得升级为:<ul>
<li><strong>G</strong>rowing 生长式</li>
</ul>
</li>
</ul>
</li>
<li>而<strong>C</strong> 也值得升级为:<ul>
<li><strong>C</strong>ivilization 文明</li>
</ul>
</li>
<li>即: AIGCxChina 缩写不变<ul>
<li>含义: 中国AI<strong>共生文明</strong>联盟</li>
</ul>
</li>
</ul>
<h2 id="plan">plan<a class="headerlink" href="#plan" title="Permanent link">¶</a></h2>
<blockquote>
<p>触发, Sci-Fi 通讲系列</p>
</blockquote>
<p>进一步 QA 阶段才发现, "生命3.0" 中讨论的各种未来学话题,
虽然上世纪就在各种 Sci-Fi/ 科学幻想小说中进行过大量的阐述,
但是, 对于中国人, 科学幻想小说, 从 <code>三体</code> 才开始;</p>
<p>值得, 以私人阅读经历中, 分享 有趣靠谱 的书单和经典, 来回顾 AI以及宇宙的想象;</p>
<p>可能的脉络:</p>
<ul>
<li>现代科学幻想起点: 凡尔佩, 人定胜天的故事</li>
<li>黄金三巨头: 美国/罗伯特·海因莱因</li>
<li>黄金三巨头: 美国/艾萨克·阿西莫夫</li>
<li>黄金三巨头: 英国/阿瑟·克拉克</li>
<li>雷-布拉德伯: 霜与火</li>
<li>菲利普-K-迪克: 或然历史</li>
<li>弗诺·文奇,"银河界区三部曲"</li>
<li>特德·蒋, 短篇小说大圣</li>
<li>...</li>
<li>“赌王若昂”三部曲来自芬兰的世界设定之王</li>
<li>...</li>
<li>间客 中国网络文学中的政治观</li>
<li>异常生物见闻录 中国网络文学中的宇宙观</li>
</ul>
<p>准备以系列直播为形式, 慢慢和大家分享, 私人科学幻想小说阅读体验和其中对未来学的各种潜在思考...</p>
<h2 id="refer">refer.<a class="headerlink" href="#refer" title="Permanent link">¶</a></h2>
<blockquote>
<p>幻灯: </p>
</blockquote>
<p>https://slides.101.camp/AIGCxZh-life3.html</p>
<blockquote>
<p>回放:</p>
</blockquote>
<p><a href="https://youtu.be/mzRpmoiqhKg">"生命3.0"普通人如何理解未来 #AIGCxZhuhai #cyber #futurism </a></p>
<blockquote>
<p>图书:</p>
</blockquote>
<div class="highlight"><pre><span></span><code>生命3.0
作者: [美] 迈克斯·泰格马克
出版社: 浙江教育出版社
副标题: 人工智能时代,人类的进化与重生
原作名: Life 3.0: being human in the age of artificial intelligence
出版年: 2018-6
页数: 468
ISBN: 9787553672786
</code></pre></div>
<blockquote>
<p>异步讨论邮箱:</p>
</blockquote>
<p>askDAMA@googlegroups.com</p>
<p>SEE:</p>
<h2 id="-our-mission-future-of-life-institute">- <a href="https://futureoflife.org/about-us/contact-us/">Our mission - Future of Life Institute</a><a class="headerlink" href="#-our-mission-future-of-life-institute" title="Permanent link">¶</a></h2>
<h2 id="logging">logging<a class="headerlink" href="#logging" title="Permanent link">¶</a></h2>
<ul>
<li>231217 ZQ blog</li>
<li>231214 ZQ Youtube 字幕以及章节</li>
<li>231213 ZQ 腾讯会议直播</li>
<li>231209 ZQ 接受邀请</li>
</ul>1024code 新环境新体验2023-05-20T10:42:00+08:002023-05-20T11:11:42+08:00ZoomQuiettag:blog.zoomquiet.io,2023-05-20:/230519-1024code101.html<p>IMHO/ 1024code felling</p><h2 id="1024code">1024code<a class="headerlink" href="#1024code" title="Permanent link">¶</a></h2>
<blockquote>
<p>1024Code 是一个免费的、协作式的、基于浏览器的 IDE 环境,支持 10 多种编程语言,支持 Spring 、Vue 、React 等框架,还支持很多图形库,是刚入门的程序员学习编程,与朋友一起创造作品,分享交流的最佳选择。</p>
</blockquote>
<h2 id="background">background<a class="headerlink" href="#background" title="Permanent link">¶</a></h2>
<p>1024code 全新在线开发环境,
值得体验, 以及判定最合适来折腾什么</p>
<h2 id="goal">goal<a class="headerlink" href="#goal" title="Permanent link">¶</a></h2>
<ul>
<li>关键功能体验</li>
<li>记录直觉痒点</li>
<li>规划小规模使用策略</li>
</ul>
<h2 id="tracing">tracing<a class="headerlink" href="#tracing" title="Permanent link">¶</a></h2>
<blockquote>
<p>几个工程过程中的体验</p>
</blockquote>
<h3 id="jerry">Jerry<a class="headerlink" href="#jerry" title="Permanent link">¶</a></h3>
<blockquote>
<p>可能的爆点</p>
</blockquote>
<ul>
<li>不知道基于哪种级别的 GPT</li>
<li>至少对自然语言的理解和生成是足够流畅的, 生成回答也足够及时</li>
<li>当然, 少不了其它 AI 回答时的车轮话</li>
</ul>
<p><img alt="Jerry" src="https://ipic.zoomquiet.top/2023-05-20-zshot%202023-05-20%2009.47.48.jpg"></p>
<div class="highlight"><pre><span></span><code>~/app$ nix-env -i htop
nix-env: /nix/store/jsp3h3wpzc842j0rz61m5ly71ak6qgdn-glibc-2.32-54/lib/libc.so.6: version `GLIBC_2.33' not found (required by /nix/store/mc6f3fxw7zv1gshdff7wyb17kyxhymnd-gcc-10.3.0-lib/lib/libstdc++.so.6)
</code></pre></div>
<p>PS:</p>
<p>Jerry 有了, 就等 Tom 了...</p>
<p>PPS:</p>
<p>针对 Jerry 给出的各种提示语建议, 可能是整个系统中最有意思的地方:</p>
<blockquote>
<p>我需要你扮演编程专家的角色。我会提供关于我的编程问题所需的所有信息,你的角色是解决我的 XX 题。你应该运用你的计算机科学、网络基础设施和编程领域相关知识来解决我的问题。在回答中,使用智能、简单和易于理解的语言对各个层次的人都会有帮助。最好用分步和项目符号解释您的解决方案。尽量避免过多的技术细节,但在必要时使用它们。我希望您以解决方案的形式回复,而不是写任何解释。</p>
</blockquote>
<p>如果可以有机制推荐用户们使用最多, 最有效果的提示语,
那么, 随着时间的积累,
1024code 很可能成为最大的中文编程提示工程库...
这个市场空间可比普通的在线 IDE 要有想象现在了...</p>
<h3 id="_1">囧:<a class="headerlink" href="#_1" title="Permanent link">¶</a></h3>
<blockquote>
<p>~/app$ cargo build</p>
</blockquote>
<p>在 shell 中并没有合适的自动完成支持, 导致所有常用指令只能人工记忆全部键入,
不吻合日常工作效率期待</p>
<blockquote>
<p>warning: build failed, waiting for other jobs to finish...
error: build failed</p>
</blockquote>
<p>Rust 工程中最常见的依赖追加行为:</p>
<ul>
<li>修改 Cargo.toml</li>
<li>cargo build 或是其它指令</li>
<li>自动下载/编译/安装模块</li>
</ul>
<p>失败了...</p>
<div class="highlight"><pre><span></span><code><span class="k">[dependencies.ncurses]</span>
<span class="na">git</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">"https://github.com/jeaye/ncurses-rs.git"</span>
</code></pre></div>
<p>尝试其它形式的模块依赖, 也无法正确安装...</p>
<blockquote>
<p>标签</p>
</blockquote>
<p>一般 IDE 在打开的文件有内容变化时,
再打开其它文件,将保留原有 tab 以便提示开发者要保存...</p>
<p>现在 1024 中, 因为有高速自动保存, 所以, 永远只能打开一个文件?
那么, 想快速切换文件时, 就只能在目录树中每次人眼定位打开...</p>
<h2 id="imho">IMHO<a class="headerlink" href="#imho" title="Permanent link">¶</a></h2>
<blockquote>
<p>头42小时初步直觉...</p>
</blockquote>
<p>简单说 1024code 可以认为是一个 SaaS 服务:</p>
<ul>
<li>提供立即可以开始的基础开发界面</li>
<li>相对完备的真实 Linux 运行时</li>
<li>配套 VSCode 风格的编辑器以及 Vim/Emacs 等常见快捷键支持</li>
<li>足以日常使用的 git 支持, 并可以流畅关联/引入/绑定 外部仓库</li>
<li>原创惊喜:<ul>
<li>直接有 MySQL 真实数据库资源可以随时启用</li>
<li>Jerry AI 助手</li>
<li>内置聊天窗口</li>
</ul>
</li>
<li>...</li>
</ul>
<blockquote>
<p>也就是说:</p>
</blockquote>
<ul>
<li>作为一个 demo 级别的探索开发/自习室, 足够了 <ul>
<li>问题在, 又无法解决独自学习时难以坚持的无反馈问题</li>
</ul>
</li>
<li>但是, 是否能作为一个轻量级别的正式项目开发时, 得观察<ul>
<li>毕竟 Nix 并不是流行的发行版环境, 如果真进行正式项目的开发</li>
<li>那就要首先解决了和其它 Ubuntu/Gentoo/... 常见发行版的 DevOps 兼容问题</li>
</ul>
</li>
</ul>
<p>如果是日常开发, 比如 Python , 也都有越来越完备的最佳实践:
比如: <a href="https://cookiecutter-hypermodern-python.readthedocs.io/en/2022.6.3.post1/">Hypermodern Python Cookiecutter documentation</a></p>
<p>但是, 无论哪种组合, 日常要自行构建起来, 都不是一件容易的事儿,
如果 1024code 能针对每种开发语言社区中探索出来的实践经验,
事先配置好, 那么, 大家可能越来越习惯在这儿开展开发,
不得以时, 才迁移回本地...</p>
<blockquote>
<blockquote>
<p>进一步的, 可以作为更好的在线课程发布平台呢?</p>
</blockquote>
</blockquote>
<ul>
<li>如果是公开课程, 感觉比以往只有视频或是只有代码和文字的, 要好一些</li>
<li>有点像更加吻合日常开发过程的 Jupyter 界面, 虽然缺少一些可能关键的特性, 但是, 已经比自己构建这种环境要可用的多了</li>
<li>但是, 课程和开发并不是一个逻辑<ul>
<li>不说其它反焦虑的伪课程哈</li>
<li>一般课程就两种类型:<ul>
<li>通用入门</li>
<li>专用技能</li>
</ul>
</li>
<li>前者面对小白, 后者专注具体框架/系统/应用/问题</li>
<li>不过, 都要解决一个核心问题:<ul>
<li>如何知道自己知道的过程是对的?</li>
<li>或是说, 过程中如何及时获得针对性合理的反馈</li>
</ul>
</li>
<li>当前虽然有 Jerry 触发式反馈, 可有触发门槛</li>
<li>也有聊天窗口, 可这个窗口是随机的, 还不知道是否是集中式的:<ul>
<li>也就是说, 如果有多名学习者同时打开一个工程时,</li>
<li>大家在聊天窗口输入是所有人可见的</li>
<li>针对工程发布者, 另外有管理界面, 可以回顾/总结/统计/私聊/...</li>
<li>否则, 这个关键功能很难和课程配套起来</li>
<li>这个渠道, 有点儿像开源工程中真实用户的反馈</li>
<li>正确的反馈, 都可能引发课程内容的追加和增强</li>
</ul>
</li>
</ul>
</li>
<li>另外其它付费可见, 打赏 ... 配套功能先不论</li>
<li>单说以 1024codr 为背景一个可用课程的过程:<ul>
<li>导师先构建课程, 包含所有阶段的问题, 引导, 示例<ul>
<li>可能分解到不同分支, 或是目录</li>
<li>通过 <code>README</code> 进行引导</li>
<li>不过, <a href="https://github.com/rust-lang/rustlings/tree/5.0.0">rust-lang/rustlings at 5.0.0</a> 这种和代码结合起来的闯关式环境是更加好的交互<ul>
<li>当然, 这要求语言本身能支持</li>
<li>又如何确保每个学员有自己的进度, 不影响导师的构建?</li>
<li>这是另外一个问题了...</li>
</ul>
</li>
</ul>
</li>
<li>学员随机或是组织进入</li>
<li>跟随 <code>README</code> 探索并调试<ul>
<li>定期进行直播回答聊天中提出的问题, 或是组织进行相同节奏问题的共同尝试</li>
<li>这其中小组结对编程, 又是编程课程的关键场景, 在 1024code 中如何实现?</li>
</ul>
</li>
<li>完成所有课程内容后, 经过一定的考核, 获得对应 证书/徽章 </li>
<li>进一步的, 如果能允许优秀学员可以获得对应工程的联合维护权限, 那么以在线代码仓库为核心的编程课程, 就可能形成完全不同的体验了...</li>
</ul>
</li>
<li>以上 MVP 流程中最大的问题在:<ul>
<li>导致不知道有谁在学习</li>
<li>学习者不知道如何自然的接触导师和其它同学</li>
<li>学习者的探索行为无法自然记录下来并共享在课程空间/组织里:<ul>
<li>比如, 一个学员打开了课程</li>
<li>在一个文件中进行了修改, 触发了 bug <ul>
<li>那么此时, git 是无法操作的, 这是导师的仓库</li>
<li>如果 fork 为自己的, 可以记录变化</li>
<li>但是, 又没有理由 pull-request 回去, 这是自己学习过程中的个性问题</li>
<li>同时, 也没有什么可追踪的邀请方式, 来请导师或是其它同学过来一起解决</li>
</ul>
</li>
<li>也就是说, 学习过程中真实的学习行为, 没有一个合理的流程进行记录和针对性分享/追踪, 并进一步变成课程本身的知识积累...</li>
</ul>
</li>
</ul>
</li>
</ul>
<h2 id="logging">logging<a class="headerlink" href="#logging" title="Permanent link">¶</a></h2>
<ul>
<li>230520 ZQ 吐糟阶段小结</li>
<li>230514 ZQ 尝试开辟</li>
<li>230513 ZQ init.</li>
</ul>开源软件开发导论课程作业0回响++2022-09-11T16:42:00+08:002022-09-11T17:14:22+08:00ZoomQuiettag:blog.zoomquiet.io,2022-09-11:/220911-ossd-echo-plus.html<p>IMHO/ OSSD ask and echo ++</p><h2 id="oss-01">OSS 0.1级疑问 追加回答<a class="headerlink" href="#oss-01" title="Permanent link">¶</a></h2>
<h3 id="background">background<a class="headerlink" href="#background" title="Permanent link">¶</a></h3>
<p>作业触发:
<a href="https://bbs.csdn.net/topics/607938212">第一次作业 (看开源的资料,提五个问题)-CSDN社区</a></p>
<p>上次统一回答 220830 之前提交的同学:
<a href="/220901-ossd-faq.html">开源软件开发导论课程作业0之回响</a></p>
<p>发现后来提问的同学, 明显思考的多了些,
在此抽取几个有趣的问题直觉回答一下:</p>
<h3 id="goal">goal<a class="headerlink" href="#goal" title="Permanent link">¶</a></h3>
<blockquote>
<p>统一给出整体回答</p>
</blockquote>
<p>有关大妈自己社区经历, 参考:</p>
<ul>
<li><a href="/220817-flossstyle-0.html">开源生活实录.0.从哪儿知道的?</a></li>
<li><a href="/220817-flossstyle-1.html">开源生活实录.1.LAMP之辉</a></li>
<li><a href="/220820-flossstyle-2.html">开源生活实录.2.GNU之魂</a></li>
<li><a href="/220822-flossstyle-3.html">开源生活实录.3.GTD之始</a></li>
<li>...</li>
</ul>
<p>同学们有什么问题, 可以直接回复在文章尾部的评注中, 可以针对性进一步沟通.</p>
<p>(PS: 使用 <a href="https://utteranc.es/">utterances</a> github-issue 来作为容器,
可以长期保存应答...)</p>
<h3 id="murmur">MurMur<a class="headerlink" href="#murmur" title="Permanent link">¶</a></h3>
<blockquote>
<p>一名老程序猿的呢喃</p>
</blockquote>
<h4 id="831">8.31<a class="headerlink" href="#831" title="Permanent link">¶</a></h4>
<blockquote>
<p><a href="https://blog.csdn.net/qq_35537753/article/details/126626402">【课程作业】对开源软件开发的疑问_伏罗希洛夫射手的博客-CSDN博客</a></p>
</blockquote>
<p>这位同学, 难得的是多数问题和开源项目工程质量相关;
而且多数有引用文章的链接, 这种习惯就很不简单了;</p>
<p>其中问题4:</p>
<blockquote>
<p>作为开源项目的维护者,如何高效地审查提交的代码?小而美的补丁固然好,但也不总是那么容易得到的,尤其对于一些并不热门的开源项目来说。</p>
</blockquote>
<p>有点奇怪, 因为, 触发的文章是: <a href="https://blog.csdn.net/programmer_editor/article/details/125798041">一个补丁迭代了16个版本后被撤,我的 Linux内核之旅!_《新程序员》编辑部的博客-CSDN博客</a></p>
<p>而其中, 内容正好回答了同学的提问:</p>
<ul>
<li>吴峰光博士 自身研究方向就是 Linux 内核</li>
<li>因为长期积累, 以及热情, 一次性提交了包含大量代码变更的补丁, 并在社区审核其实, 持续迭代, 越来越大</li>
<li>以致社区领导者被惊动, 直接沟通, 才解除了就会, 转而主动理解社区策略, 开始提交 <code>小而美</code> 的补丁, 进而批量完成补丁接受<ul>
<li>其实, 应该还有后续, 最后作者团队变成了 Linux 内核官方成员</li>
<li>也开始一起帮忙审核/测试/合并代码</li>
</ul>
</li>
<li>这一过程, 哪里不高效呢?<ul>
<li>关键在 <code>高效</code> 的定义吧, 可能同学感觉, 一个复杂系统的修订, 每个提交都应该在几小时以内完成判定并回绝或是接受, 不应该反复几个月吧</li>
<li>其实, 无论哪个领域效能, 都应该有个<code>标准杆</code>(高尔夫术语)</li>
<li>如果在操作系统领域, 这个标准, 应该是大众最熟悉的 Windows, 那么在 Windows 内核工程中, 一个提交要经过多少环节和时间?</li>
<li>没有对比就没有伤害, 这方面的数据, 就是同学自己值得探查的地方了...</li>
</ul>
</li>
<li>可以感觉到, 这个问题本身包含了一系列偏见/傲慢:<ul>
<li>开源项目代码审核并不高效</li>
<li>开源项目小而美的补丁不多</li>
<li>开源项目多数并不热门</li>
<li>只有热门开源项目代码审核才有很多补丁</li>
<li>...</li>
</ul>
</li>
<li>以上偏见, 都是因为并没有深入调查 Linux 内核项目的规模以及代码流程的原因<ul>
<li>建立, 在这个问题基础上, 进一步查阅有关文档/图书</li>
<li>然后修订问题, 问到一个全球大学生都应该关注的真正问题上来</li>
</ul>
</li>
</ul>
<h4 id="91">9.1<a class="headerlink" href="#91" title="Permanent link">¶</a></h4>
<blockquote>
<p><a href="https://blog.csdn.net/weixin_55963187/article/details/126650222?csdn_share_tail=%7B%22type%22%3A%22blog%22%2C%22rType%22%3A%22article%22%2C%22rId%22%3A%22126650222%22%2C%22source%22%3A%22weixin_55963187%22%7D">开源软件开发导论第1次作业__LilaS的博客-CSDN博客</a></p>
</blockquote>
<p>这位同学的问题三是罕见的自问自答:</p>
<blockquote>
<p>开源软件开发者群体如何盈利?</p>
</blockquote>
<p>以下转载于 http://t.csdn.cn/Uaflt</p>
<p>在开源软件领域中,常见的盈利模式一共有7种。</p>
<ul>
<li>盈利模式之一:多种产品线</li>
<li>如 MySQL 产品就同时推出面向个人和企业的两种版本,即开源版本和专业版本,分别采用不同的授权方式。开源版本完全免费以便更好的推广,而从专业版的许可销售和支持服务获得收入。 </li>
<li>盈利模式之二:技术服务型</li>
<li>JBoss就是这种模式的典型代表。JBoss 应用服务器完全免费,而通过提供技术文档、培训、二次开发支持等技术服务而获得收入。</li>
<li>盈利模式之三:应用服务托管(ASP)<ul>
<li>例如,PHP Live! 就是一种构架于 PHP、MySQL 之上的开源软件,它可为企业用户提供实时交谈服务。目前已经有数十家公开提供 PHP Live! 托管服务的应用服务提供商。</li>
</ul>
</li>
<li>盈利模式之四:软、硬件一体化<ul>
<li>比如 IBM HP 等服务器供应商巨头,通过捆绑免费的 Linux 操作系统销售硬件服务器。SUN 公司近期将其 Solaris 操作系统开放源码,以确保服务器硬件的销售收入,也是这种模式的体现。 </li>
</ul>
</li>
<li>盈利模式之五:附属品<ul>
<li>O'Reilly集团是销售开源软件附加产品公司的典型案例,他出版了很多优秀的开放源代码软件的参考资料。 </li>
</ul>
</li>
<li>盈利模式之六:品牌战略、服务至上<ul>
<li>康比尔公司的 Compiere ERP & CRM 软件是这种模式的典型案例。 </li>
</ul>
</li>
<li>盈利模式之七:市场策略<ul>
<li>比如微软宣称部分的公开 Office 的源代码,就是执行这种策略。</li>
</ul>
</li>
</ul>
<blockquote>
<blockquote>
<p>“Free Software”中的"Free"关乎自由,而不是价格,使指可以付费或者不付费的得到GUN软件</p>
</blockquote>
</blockquote>
<p>神奇的是, 全篇文章讨论的是开源软件, 突然又引用了<code>自由软件</code> 名字;</p>
<p>那么, 俺的得建议了: </p>
<ul>
<li>开源的这些模式都是怎么形成/摸索出来的?</li>
<li>比开源更加严格的自由软件又有什么商业模式, 又是从哪儿探索出来的?</li>
<li>...推荐挖掘一下 GPL 几个版本许可证的内容, 以及相关故事</li>
</ul>
<p>其实, 这儿得科普一下自由软件的四个自由: <a href="https://www.gnu.org/philosophy/free-sw.zh-cn.html#four-freedoms">什么是自由软件? - GNU 工程 - 自由软件基金会</a></p>
<p>如果一个软件是自由软件,那么它必须为用户提供以下四项基本自由:[1]</p>
<ul>
<li>自由度0:无论用户出于何种目的,必须可以按照用户意愿,自由地运行该软件。</li>
<li>自由度1:用户可以自由地学习并修改该软件,以此来帮助用户完成用户自己的计算。作为前提,用户必须可以访问到该软件的源代码。</li>
<li>自由度2:用户可以自由地分发该软件的拷贝,这样就可以助人。</li>
<li>自由度3:用户可以自由地分发该软件修改后的拷贝。借此,用户可以把改进后的软件分享给整个社区令他人也从中受益。作为前提,用户必须可以访问到该软件的源代码。</li>
</ul>
<p>而开源软件和自由软件最根本性的不同, 就在取消了第4自由, 即通俗的<code>传染性</code>:</p>
<ul>
<li>自由软件, 要求基于自己代码修订出来的新软件也必须是自由软件, 以便代码可以永久自由下去</li>
<li>开源软件, 并不强行要求基于自己代码修订出来的新软件也必须开源, 以便可以获得更多商业机会</li>
<li>但是, 自由软件从一开始就没有禁止进行商业服务, 因为:<ul>
<li>即便是代码完全自由</li>
<li>但是, 使用/运行/维护/加强/定制/...软件, 都是要专业技能和知识的, 这都是有市场需求的</li>
</ul>
</li>
</ul>
<p>所以, 开源工程如何赢利, 非常象我们每个计算机系毕业的人,
我们的精力/时间/能力/... 其实都是开源获得的,
但是, 又多数只能通过商业行为, 来获得报酬,
那么, 在普通的就职之外, 有什么可能性, 这才是值得结合开源项目的故事, 进一步探查思考提问的吧...</p>
<h4 id="93">9.3<a class="headerlink" href="#93" title="Permanent link">¶</a></h4>
<blockquote>
<p><a href="https://blog.csdn.net/mayfly_strive/article/details/126677076">开源软件开发导论第一次作业——关于“开源”的疑问_mayfly_strive的博客-CSDN博客</a></p>
</blockquote>
<p>这位同学, 也是罕见的将问题聚集在参与方向上:</p>
<ul>
<li>2: 个人如何开始开源的路?</li>
<li>3: 开源项目的自由度该如何把握?</li>
<li>5: 个人如何推广开源项目?</li>
</ul>
<p>三个问题, 都是具体的个人参与/进行/推广开源项目的问题;</p>
<p>不过, 三个问题明显都可以统一回答:</p>
<ul>
<li>先开始参与, 然后, 在参与过程中积累经验, 持续迭代/改进自己的能力/思想/行为/习惯/资源/经验...</li>
<li>就象游泳, 无论在下水前进行了多少准备, 嘦没有下水开始游, 永远不可能学会游泳<ul>
<li>在游泳馆里会了, 不等于在小溪中会游</li>
<li>在小溪里会了, 不等于在大河中会游</li>
<li>在大河里会了, 不等于在大江中会游</li>
<li>在大江里会了, 不等于在近海中会游</li>
<li>在近海里会了, 不等于在大洋中会游</li>
<li>...</li>
<li>必须一步一步实践/积累, 并对应配置合适装备</li>
</ul>
</li>
</ul>
<p>比如:</p>
<blockquote>
<p>..我应该从哪些方面约束我个人的代码,保证我所贡献的代码能够有效率地提交</p>
</blockquote>
<p>这很明显就是事先乱担心, 因为每个开源工程, 都为了自身发展, 积累了良好文档,
对补丁的提交, 更加有详细到恶心的文档, 以及丰富到爆炸的工具可以配合,
甚至于和大厂合作, 有海量资源可以自动化协同来完成越来越复杂的测试...</p>
<p>嘦认真参与, 一步步掌握所有知识, 这些问题自然就有了解答, 那么如何开始?
现在就开始.</p>
<h4 id="95">9.5<a class="headerlink" href="#95" title="Permanent link">¶</a></h4>
<blockquote>
<p><a href="https://blog.csdn.net/intpyjl/article/details/126693929?spm=1001.2014.3001.5501">【开源软件开发导论作业-1】_yjlintp的博客-CSDN博客</a></p>
</blockquote>
<p>这位同学的问题也比较有趣, 都是和谐性问题;</p>
<p>更加有趣的是问题3:</p>
<blockquote>
<p>...我想起了不久前,我因为难以忍受网易云音乐PC端频繁出现的bug,在网上寻找网易云的第三方软件,试图作为替代,然后看到LyricEase等第三方网易云音乐 UWP 应用受到了版权警告,被强制下架...以我从一个开发者兼用户的角度来看,这些软件确实违反了规定...基于破解的开源还是开源吗?这种“开源”是应该鼓励开发者去做的吗?</p>
</blockquote>
<p>这个问题其实混合了几种形式, 多种性质的行为, 却统一丢给了开源...</p>
<p>其实, 类似行为, 一直在发生, 有时, 甚至于是反过来的, 大厂抄了开源软件, 用在自己系统中, 被追查出来也死不承认...</p>
<p>以网易云音乐的开源替代为例, 对等的, 其实是 N 年前, 开源 Linux 版本 QQ 事件:</p>
<ul>
<li>腾讯公司一直不发布 QQ linux 版本</li>
<li>于是, 有技术高人通过网络嗅探技术, 查明 QQ 所有通讯协议, 然后, 自行编写了 Linux 版本发布<ul>
<li>后果是被告上法庭关了起来</li>
</ul>
</li>
<li>先不论 腾讯 公司这种行为是否合理, 值得推广</li>
<li>在类似事件中, 开源软件诞生的动力都是相同的: 缺少一个满意的软件, 就自己动手了<ul>
<li>这种开端没有问题</li>
<li>通过努力, 完成了软件, 没有拿来获利, 只是为了更多人使用而开源, 这也没有问题</li>
<li>因为开源, 越来越多的人发现新软件, 并开始进一步完善/宣传/使用/... 这当然也没有问题</li>
</ul>
</li>
<li>唯一的问题在: 原厂商不高兴了<ul>
<li>不高兴的原因很简单: 超出了控制</li>
<li>无论是渠道/流量/版权/协议/....一切自己原本认为机密的东西, 竟然被开放出来了, 当然不高兴</li>
<li>先不说原本以为是自己的, 其实是否真的应该是</li>
</ul>
</li>
<li>核心冲突在什么是 <code>破解</code> ?<ul>
<li>不拓展到其它破解行为, 在开源 <code>网易云音乐</code> 这个场景中</li>
<li>如果: 网易云音乐 原有通讯协议是专利产品, 又在专利保护期以内, 这算非法破解, 否则, 不算破解, 顶多算猜测成功</li>
<li>如果: 网易云音乐 原有数据加密是专利产品, 又在专利保护期以内, 这算非法破解, 否则, 不算破解, 顶多算猜测成功</li>
<li>如果: 网易云音乐 原有数据解密是专利产品, 又在专利保护期以内, 这算非法破解, 否则, 不算破解, 顶多算猜测成功</li>
<li>...</li>
</ul>
</li>
<li>而播放的内容, 又是另外一组 "破解" 了:<ul>
<li>播放的音乐数据来源是网易云音乐, 并大于20秒, 这就涉及了版权内容侵权</li>
<li>但是, 如果想播放网易云音乐, 必须登录对应帐号, 这就不涉及版权内容侵权, 而涉及广告流量清洗</li>
<li>简单说, 凡是 <code>网易云音乐</code> 原本用以获利的资源, 被 "开源", 这就是资源盗用, 不是知识开源领域了, 和开源无关</li>
</ul>
</li>
<li>当然, 明白了这些后, 照样可以通过技术手段进行绕过, 从而达到解决根本问题:<ul>
<li>网易云音乐 本身不好用, 用户又有个性化音乐需求</li>
<li>嘦这种天然需求没有被满足, 就一定有新的工具/厂商/服务/...涌现</li>
</ul>
</li>
</ul>
<p>所以, 在这个问题域, 值得进一步探查/思考, 给出什么样的鼓励是最有效的问题,
这其中, 很可能包含本来创业时的根本思考技巧.</p>
<h4 id="97">9.7<a class="headerlink" href="#97" title="Permanent link">¶</a></h4>
<blockquote>
<p><a href="https://blog.csdn.net/dedsecezio/article/details/126748285?csdn_share_tail=%7B%22type%22%3A%22blog%22%2C%22rType%22%3A%22article%22%2C%22rId%22%3A%22126748285%22%2C%22source%22%3A%22dedsecezio%22%7D">《开源软件开发导论》作业1_dedsecezio的博客-CSDN博客</a></p>
</blockquote>
<p>这位同学很习惯大哉问, 动不动问世纪工程般问题;</p>
<p>不过, 最后一个问题才是所有课程同学, 应该一直扪心自问的:</p>
<blockquote>
<p>5.对我们学生来说开源应该算什么?</p>
</blockquote>
<p>就象数字 : <code>0</code> 就是经典代表:</p>
<ul>
<li>外延最小</li>
<li>内涵最大</li>
</ul>
<p>开源也是: 定义异常简单, 比自由软件还少了个自由度,
但是, 在各种精英探索下, 变成越来越热门的 <code>抓手</code>/handle 可以和万事万物结合, 变成各种关键工程中的关键因素;</p>
<p>不过, 简单点儿可以这么开始我们的偏见:</p>
<ul>
<li>无论开源是什么, 开源已经存在了42+年, 而且发展越来越快, 证明有其道理</li>
<li>无论开源是什么, 开源已经积累了42+年, 其中包含的资源, 值得关注/理解</li>
<li>无论开源是什么, 开源已经发展了42+年, 涉及领域几乎包含人类所有方向, 可以和自己任何一种兴趣结合</li>
<li>无论开源是什么, 开源已经生长了42+年, 证明其内在机制是可持续的, 值得参与体验</li>
<li>无论开源是什么, ...</li>
</ul>
<p>也就是说, 开源就象哈佛博士学位, 古老/丰富/艰难/稀缺/...
想完全掌握, 当然困难,
但是, 世界上有什么事儿是完全没有困难的呢?</p>
<p>就算是日常呼吸, 随便一个 COVID-19 都将社会生活折腾成这样, 不难嘛?</p>
<p>从中国大学角度, 开源:</p>
<ul>
<li>是超越中国教育资源的空间, 可以帮助我们提前进入世界关键思想空间</li>
<li>是超越中国网络资源的文化, 可以帮助我们合理进入中国企业难以触达的人物</li>
<li>是超越中国技术体系的渠道, 可以帮助我们提前接触世界级组织</li>
<li>是超越中国...</li>
</ul>
<p>又是免费的, 值得抽出一定时间来深入, 反正不亏.</p>
<h3 id="refer">refer.<a class="headerlink" href="#refer" title="Permanent link">¶</a></h3>
<blockquote>
<p>有关链接
<a href="http://devrel.zoomquiet.top/data/20110617102755/index.html">如何成为一名黑客</a></p>
</blockquote>
<h3 id="logging">logging<a class="headerlink" href="#logging" title="Permanent link">¶</a></h3>
<ul>
<li>220911 ZQ init.+pub</li>
</ul>开源软件开发导论课程作业0之回响2022-09-01T21:42:00+08:002022-09-01T17:48:01+08:00ZoomQuiettag:blog.zoomquiet.io,2022-09-01:/220901-ossd-faq.html<p>IMHO/ OSSD ask and echo</p><h2 id="oss-0">OSS 0级疑问<a class="headerlink" href="#oss-0" title="Permanent link">¶</a></h2>
<h3 id="background">background<a class="headerlink" href="#background" title="Permanent link">¶</a></h3>
<p><a href="https://edu.csdn.net/me/softwareteacher">邹欣</a> 老师一直致力于在高校引入 FLOSS 相关课程,
记忆中, <a href="https://book.douban.com/subject/25965995/">构建之法 (2014)</a> 就是相关课程的总结,
一下又10年过去了,
又绕到同一个微信群中, 才知道, 课程已经进化为: "开源软件开发导论"</p>
<p>而且也将课程公开在 git 仓库中:
<a href="https://gitcode.net/csdn/intro-ossd/-/blob/master/plan/0.md">plan/0.md · master · CSDN 技术社区 / Intro-OSSD · GitCode</a></p>
<p>感觉和 CSDN 有深度合作, 所以, 课堂作业也要求统一在 CSDN 平台上给出,</p>
<p><a href="https://bbs.csdn.net/topics/607938212">第一次作业 (看开源的资料,提五个问题)-CSDN社区</a></p>
<h3 id="goal">goal<a class="headerlink" href="#goal" title="Permanent link">¶</a></h3>
<blockquote>
<p>统一给出整体回答</p>
</blockquote>
<p>基于自己私人 FLOSS/自由,开源软件社区经历,
CSDN 的 BBS/Blog 系统, 一直不支持 Markdown ,
实在不习惯, 先用私人 blog 统一回复一下.</p>
<p>同学们有什么问题, 可以直接回复在文章尾部的评注中, 可以针对性进一步沟通.</p>
<p>(PS: 使用 <a href="https://utteranc.es/">utterances</a> github-issue 来作为容器,
可以长期保存应答...)</p>
<h3 id="murmur">MurMur<a class="headerlink" href="#murmur" title="Permanent link">¶</a></h3>
<blockquote>
<p>一名老程序猿的呢喃</p>
</blockquote>
<p>一共28位同学, 将问题集中列出来之后,
异常亲切...为什么呢? 和20多年前, 自己提问的姿势多相似哪...</p>
<p>比如, 一次在绿皮火车上偶遇一位僧人, 在大家围着问些佛法知识时,
俺冒了一句: "我能有女朋友, 大师不可能有, 这事儿怎么说?"</p>
<p>可以想象当时场景多尴尬...</p>
<p>正如在各种场景中反复推荐的 <a href="https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/main/README-zh_CN.md">提问的智慧</a> 中劝说的;
其实, 提问本身就已经是答案的一部分了;</p>
<p>在软件工程领域, 有一种祖传手艺: <a href="https://zh.m.wikipedia.org/zh-hans/%E5%B0%8F%E9%BB%84%E9%B8%AD%E8%B0%83%E8%AF%95%E6%B3%95">小黄鸭调试法/Rubber Duck Debugging</a></p>
<ul>
<li>程序发生问题时, 一般情况就两种:<ul>
<li>为什么不运行?</li>
<li>为什么运行了?</li>
</ul>
</li>
<li>此时, 程序猿最有效调试技巧就是:<ul>
<li>0: 拿出一个橡皮鸭玩具(就是外国电影中无论男女老少洗澡时放浴缸里那种漂着玩的东西..)</li>
<li>1: 对着 <code>小黄鸭</code> 一行一行解释为什么这么写</li>
<li>2: 一般4.2 分钟左右, 就发现了自己的问题所在, 知道如何修改</li>
<li>如果再次发生问题, 重复以上步骤</li>
<li>实在不行, 带着 <code>小黄鸭</code> 去洗个澡,再回来继续, 一定可以解决.</li>
</ul>
</li>
</ul>
<p>嗯哼, 这种高端调试方法, 是没有写过程序的人, 绝对想象不出来的.</p>
<p>为什么? 很简单, 我们不可能对一个自己完全陌生的领域, 给出什么靠谱的猜想和思考;
在 <a href="https://blog.101.camp/nc/200811-zoomquiet-wtf-coding-mind/">蟒营®</a> 在线课程中,
经常给学员提出的 Issue 阐述标准:</p>
<ul>
<li>尽可能详细</li>
<li>详细程度到想吐</li>
<li>或是, 可以确保3年前的自己, 看到这篇文字, 可以复现问题, 并理解问题本身上下文</li>
</ul>
<p>那么, 同学们的提问都问了什么呢?
逐一看下来, 体会有几点:</p>
<ul>
<li>多数同学使用 CSDN 默认皮肤, 包含很多广告位, 自己的内容很难关注到</li>
<li>多数同学字数没超过 420 字, 基本上都是断言式提问, 对问题的来由根本没有阐述, 最多是引用资料中的片段</li>
<li>多数同学没有任何外部链接, 完全不知道看了什么资料</li>
<li>所有同学并没有记述根据资料, 逐步查阅了哪些资料, 以及探查路径和为什么阅读的原因...即, 并没有记录探索过程, 以及过程中自己的思考/尝试/...</li>
<li>所有同学, 没有记录提出问题的用时, 感觉都是随手几秒钟, 就决定了问什么问题...</li>
</ul>
<p>好玩的是, 所有同学问题姿态/方向, 基本一致:</p>
<ul>
<li>都是国家有关部门局级领导语气</li>
<li>问题内容也局限在四个方向:<ul>
<li>FLOSS 知识产权怎么回事儿?</li>
<li>FLOSS 软件工程质量如何保证?</li>
<li>FLOSS 软件项目如何参与?</li>
<li>FLOSS 能力如何识别/积累</li>
</ul>
</li>
<li>不过, 认真分析, 其实所有问题都指向一个本质困惑:<ul>
<li>如何从 FLOSS 工程中获利?</li>
</ul>
</li>
</ul>
<p>面对这种问题, 俺的直觉是想起中亚地区流传的寓言:</p>
<ul>
<li>一位牧人遇到一个流浪汉, </li>
<li>看不下去就问: "你为什么不去放牧呢?"</li>
<li>流浪汉回答: "放牧为了什么?"</li>
<li>牧人回答: "有了有更多羊哪;"</li>
<li>流浪汉回答: "有了更多羊之后呢?"</li>
<li>牧人回答: "就可以挤更多奶, 剪更多羊毛了哪;"</li>
<li>流浪汉回答: "有更多奶, 更多羊毛之后呢?"</li>
<li>牧人回答: "就能卖更多钱了哪;"</li>
<li>流浪汉回答: "有了更多钱, 你会怎么作?"</li>
<li>牧人回答: "当然是每天不用干活, 晒太阳了哪;"</li>
<li>流浪汉回答: "那你看我现在在作什么?"</li>
</ul>
<p>这就是没有任何足够探查, 直觉提问的必然困境之一...</p>
<p>同学们的所有提问, 都建立在一个虚幻的基础上:</p>
<ul>
<li>没有真实参与/发起/组织/... FLOSS 项目</li>
<li>没有长期从事相关开发</li>
<li>没有进入真实 FLOSS 社区进行过切实贡献</li>
<li>...</li>
</ul>
<p>一切都是从第二/三/四/...N手资源中, 配合自己的常理想象, 然后组合为一个问题;</p>
<p>其实, 邹欣 第0个任务, 本身最大的坑, 不在提出什么问题, 而在:</p>
<ul>
<li>为什么提出这个问题</li>
<li>这个问题定义过程是如何的?</li>
<li>有经过什么实践来明确问题边界?</li>
</ul>
<blockquote>
<p>...大学生应该能写出自己的思考, 而不是摘抄书本内容</p>
</blockquote>
<p>这才是题眼, 只是隐藏了两个字: <code>过程</code>,
要记述下来 <code>思考过程</code> , 而不是思考结论,
就象代数解题过程, 代码调试过程, 身体锻炼过程...</p>
<p>一个没有任何过程的结果, 是无法追踪/分析/讨论/...指出在哪个环节出了什么问题,
进而共同解决的;</p>
<p>也就是说, 软件工程中的问题, 和 FLOSS/自由,开源软件 项目中的问题,
其实, 都是有相同基础要求的: <a href="https://wiki.mbalib.com/wiki/SMART%E5%8E%9F%E5%88%99">SMART原则</a></p>
<ul>
<li>S代表具体(Specific) 问题/目标要是具体, 明确的, 不可是真理/宽泛的</li>
<li>M代表可度量(Measurable) 问题/目标要是可量化或者可衡量的, 即可检验的</li>
<li>A代表可实现(Attainable) 问题/目标在付出努力的情况下可以实现的</li>
<li>R代表现实性(Realistic) 问题/目标是实实在在的, 现实存在, 可观察的</li>
<li>T代表有时限(Time bound) 问题/目标是有期限的, 不是永恒的</li>
</ul>
<p>简单说, 每一个问题都是要和自己有关联的, 注意, 这种关联不一定只能是利益性的;</p>
<p>其实, 同学们多数问题, 都可以通过几次搜索从 google 中获得精确的回答,
但是, 没有同学有尝试进行自问自答, 结果多数都只是进行了外围人员的常识性提问,
没有进行专业性探查;</p>
<p>即, 没能 <code>置身事内</code>, 完全飘在高处俯瞰没有边界的 FLOSS 世界,
那么, 这种提问, 其实对自己无论学术还是实践都很难有帮助哪...</p>
<p>怎么改进呢? 大声朗读: <a href="https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/main/README-zh_CN.md">提问的智慧</a> 4遍, 就知道如何去作了.</p>
<h4 id="floss">FLOSS 上限<a class="headerlink" href="#floss" title="Permanent link">¶</a></h4>
<p>只有一位同学的问题, 有所突破:</p>
<blockquote>
<p>...但是肯定对于某些行业和产品,是不能够开源的,因为涉及到机密和版权等等。那么是不是开源理论上存在一个上限呢,即存在一个开源软件的范围,在范围之外的产品是无论如何也不能够开源的。
如果开源真的如我所想存在一个范围上限,那么当他达到这个上限的时候,还会有新的内容出现么?</p>
</blockquote>
<p>虽然, 陈述上还有问题,
但是, 这是一个逻辑上相对完备的质疑;</p>
<p>俺的直觉回答:</p>
<ul>
<li>FLOSS/自由,开源软件, 本质上还是软件, 和其它类型软件并无不同<ul>
<li>其它类型软件可以作到的, 开源软件一定可以作到, 差异只是积累途径和成本</li>
</ul>
</li>
<li>软件本质上只是工具, 用来辅助人们完成具体工作的<ul>
<li>如果某种工作只能使用秘密工具来完成, 那么也就意味着, 这种工作是不能公开的</li>
<li>不能公开的工作, 也就不可能拥有广泛的劳动者</li>
<li>不能为最广泛群体使用的工具, 自然也将自我消失在大众关注范畴中</li>
</ul>
</li>
<li>工具是随着人类能力而变迁的, 工具的上限只能是人类想象力的边界<ul>
<li>而想象力是没有上限的</li>
<li>自然, FLOSS/自由,开源软件, 也没有所谓上限</li>
</ul>
</li>
<li>只能秘密制造/使用的工具, 并不能代表人类想象力上限<ul>
<li>多数情况中, 反而只是为了制约想象力/创造力, 而特意秘密</li>
</ul>
</li>
</ul>
<h3 id="trace">trace<a class="headerlink" href="#trace" title="Permanent link">¶</a></h3>
<blockquote>
<p>先列表一下同学们直觉问题, 再分类针对性回答
<a href="https://blog.csdn.net/LIBOJIA/article/details/126643084?spm=1001.2014.3001.5502">开源软件开发导论第一次作业_LIBOJIA的博客-CSDN博客</a></p>
<p>《中国开源发展蓝皮书》的总论部分以及几篇CSDN上关于开源的文章后...</p>
</blockquote>
<ol>
<li>开源软件的开发者是通过什么方式来盈利的</li>
<li>开源社区一旦与行业单位结合,会不会发生互相挤兑的情况</li>
<li>不同行业之间使用开源方式,如何统合他们的技术标准</li>
<li>我们该如何参与到开源组织之中,如何成为优秀的开源人才</li>
<li>在现有大型开源组织的情况下,如何创建新兴的开源组织并且持续运营下去</li>
</ol>
<p><a href="https://blog.csdn.net/qq_40043377/article/details/126636528?spm=1001.2014.3001.5501">关于开源软件的五个问题_SITDOWN7的博客-CSDN博客</a></p>
<ol>
<li>像Linux内核这种体量十分庞大的开源项目,可能代码有很多需要改进的部分且有大量的开发者想提交补丁,如此一来审核工作会变得十分困难。比如审核人员过少导致审核速度过慢影响迭代速度,躲着审核人员过多导致人员杂乱会影响到安全问题。所以大型开源项目的管理人员是怎么组成以兼顾安全和效率呢?</li>
<li>开源项目管理者们如何判定和评估开发者提交的代码的有用性和安全性的?</li>
<li>如何理解、上手某一开源项目以达到能够提交issue、pr的水平?</li>
<li>一个开源项目,基金会、项目管理者、开发者、用户之间是一个什么关系?</li>
<li>开源自己的项目,怎么获得开发者们的关注,并如何管理这个开源项目?</li>
</ol>
<p><a href="https://blog.csdn.net/wzszss/article/details/126623142?spm=1001.2014.3001.5501">关于开源的五个问题_wzszss的博客-CSDN博客</a></p>
<blockquote>
<p>在阅读了《中国开源发展蓝皮书》的总论部分以及几篇CSDN上关于开源的文章后,我对开源产生了几个问题。</p>
</blockquote>
<ol>
<li>如何维护个人或团队的合法权益?开源存在的法律问题仍然很多,一旦被侵权也难以维护自身权益,且项目可能被他人恶意改动导致出现严重问题。</li>
<li>项目存在的技术风险可能会对使用者造成影响,如何减少开源项目存在的技术风险?</li>
<li>对于他人的合并请求应该怎样处理?如果他人的改动能够提高项目质量,但同时又存在潜在风险,如何抉择?</li>
<li>如何判断项目是否需要开源,又怎么判断在何时开源?开源虽然能收到更多反馈,但也存在着许多风险;而对于确定要开源的项目,是尽可能确认没有问题再开源还是提前开源以获得更多反馈?</li>
<li>怎样提高自己的开源开发能力?是多参与已有的开源项目学习,还是自己开发开源项目,以及如何确定适合自己的项目?</li>
</ol>
<p><a href="https://blog.csdn.net/afdrsggetg/article/details/126631678?spm=1001.2014.3001.5502">开源开发导论第1次作业_zxcvzxcv3295的博客-CSDN博客</a></p>
<ol>
<li>我阅读了(23条消息) 参与开源,从给RocketMQ提ISSUE开始_不识君的荒漠的博客-CSDN博客_开源项目issue这份资料后,了解到面试和课程安排一样需要了解开源项目并提出问题,但是读懂一整个软件的代码会消耗很多时间,而且如果是非常成熟的软件以我的能力不一定能找到并修改,请问如何能找到比较符合水平的来进行修改呢?</li>
<li>我阅读了(26条消息) 记一次10人跨组织、跨地域的开源协作经历_腾源会的博客-CSDN博客,组队完成开源项目,和其他项目完成之后发布有什么区别吗?</li>
<li>阅读完(26条消息) RethinkDB开源项目为什么会失败?_钱曙光的博客-CSDN博客后,开源公司是没有直接的利润的,只能依靠投资,而不开源损失的只是一小部分用爱发电的程序员帮忙维护,却能获得直接利润,为什么还要开源?</li>
<li>开源项目也是分有前后端的,那参与了解一个开源项目也是需要团队的分工合作吗?</li>
<li>简历需要有开源软件的参与经历,那么通过这门课以及之后的一年多时间可以参与到比较大型的开源项目吗?毕竟只有本科的能力而且时间有限。</li>
</ol>
<p><a href="https://blog.csdn.net/Lscsc007/article/details/126633355?spm=1001.2014.3001.5501">开源软件开发导论第1次作业_庐州燕归巢的博客-CSDN博客</a></p>
<ol>
<li>自身的技术兴趣固然占一方面,但是更多的可能是如何去找这些开源项目。这里作者给出了两个选项,那么一个小白或是不太有特别突出的某方面兴趣的人在选择时,该如何去选择呢?</li>
<li>有些上传者可能怀有不轨的企图,可能添加一些看似无用的代码,实则可能会影响整个系统的运行的情况。Linux的社区较大,因此资源比较好,管理员可以及时发现这些可疑的补丁。然而其他中小型开源社区可能无法做到全盘扫描出这些问题,那么他们平时是怎么处理这些问题的,又可能会有更好更高效的处理方式么?</li>
<li>从上述描述中可以看出,开源需要注意的事情其实是很繁琐的,涉及到很多需要注意的事项,那么当一些开源工作者在处理这些事项时,是如何确定这些资源是否有权应用到开源项目呢?又是否有一种较为高效的系统或方法来帮助开源工作者们处理这些问题?</li>
<li>当我们在接触开源的过程中,会遇到一些问题,这个时候去issue中寻找问题往往是解决方法的首选。那么当我们在遇到issue中未曾涉及到的问题时,我们需要提出一些问题或是我们需要提交一些补丁之类的资源时,如何能保证或是提高自己被接受或采纳的概率呢?</li>
<li>Linux社区引导协调各种人员完成协作,他们的代码风格、个人习惯也各不相同,这究竟该如何具体实现呢?这里我问出了一个与本文作者相同的问题。除此之外,我目前也参与过两个软件项目的开发,但是读了一些文章之后,发现开源开发与普通开发有着很大的区别,包括主导权、话语权等,那么这些的具体区别又是什么呢?</li>
</ol>
<p><a href="https://blog.csdn.net/TheSleepGod/article/details/126632645">开源软件开发导论-第一次作业_TheSleepGod的博客-CSDN博客</a></p>
<ol>
<li>当一个不开源的项目开源时,这意味着我们需要确保自己的项目中的每一部分都不侵犯他人权益,这一繁琐的工作量是令人头疼的,同时这一过程并不一定有开源项目的使用者来帮助你完成,那么请问是否存在快速开源的模组或框架,帮助我们完成这一工作?</li>
<li>开源项目在开源之前并不会受到关注或者帮助,但作为开发工具使用者的我们似乎有一种动力去完成自己的开源项目(荣誉感或成就感,但这一过程中存在许多繁琐的事情,请问从事开源开发具体是一种什么样的体验呢?</li>
<li>在开源开发的过程中,如何避免对项目的恶意破坏呢?</li>
<li>开源社区这种较为松散的管理方式是否存在改进空间?我们如何区分恶意的干扰代码和有益的改进尝试?或者说,我们如何照顾到尽可能多的愿意为开发软件做出共享的开发者?</li>
<li>请问这种共识如何保持长久、准确地保持在开源软件的开发过程中呢?</li>
</ol>
<p><a href="https://blog.csdn.net/org_wjw/article/details/126630432?spm=1001.2014.3001.5501">开源软件开发导论——第1次作业_org_wjw的博客-CSDN博客</a></p>
<ol>
<li>参与社区讨论并且学习其他人解决问题的方法能否算做参与了开源软件开发过程,是不是说只有提交相应代码才算做参与了开源开发?</li>
<li>在工作中积累的经验和见识主要是指哪些方面的经验和见识,这些经验和见识如何帮助我们的工作?</li>
<li>如果社区回复速度太慢,甚至不回复,那么无疑会挫伤参与者的积极性,如何解决这个问题呢?</li>
<li>如果开源参与者故意提交恶意代码造成损失,如何避免这种行为再次发生,明令禁止提交是否合适?</li>
<li>开源软件开发公司是否收益要低于非开源软件开发公司?</li>
</ol>
<p><a href="https://blog.csdn.net/ruoyunbai/article/details/126621514?spm=1001.2014.3001.5502">关于开源软件的五个问题_若云白[旺柴]的博客-CSDN博客</a></p>
<ol>
<li>如何快速理解已有项目的代码结构、用到的技术,并习得为其贡献代码的技术?</li>
<li>如何防止恶意代码?</li>
<li>软件开源后如何保持自己的竞争力?</li>
<li>Linux这样的影响力巨大的开源项目,需要Linus这样一位“独裁者”,开源软件是否能有一种更加民主的形式呢?</li>
<li>开源软件如何保证风格统一?</li>
</ol>
<p><a href="https://blog.csdn.net/pikachu_xakumes/article/details/126629535?spm=1001.2014.3001.5502">关于开源软件的五个问题_pikachu_xakumes的博客-CSDN博客</a></p>
<ol>
<li>对于一个项目,学习所花费成本都比较大,而相同时间所获取的价值可能并不相同,而同一技术的实现可能存在多个项目,该如何甄别对自己更有价值的项目。</li>
<li>学习开源项目更多是以增量开发为目的还是以便于应用他人技术为目的,抑或是学习他人的代码思想和风格等。</li>
<li>在企业中,一个团队大多是以同一价值取向为驱动的,而开源项目中因人价值取向差异或者文化差异是否会导致开发方面进程方面的问题。</li>
<li>开源的项目在进行增量开发的时候如果某一功能拓展仅在部分项目中有用而在其他项目中冗余该如何处理。</li>
<li>最近经常有人提倡开源变现,这是否与开源的初衷有所冲突,或者是否属于一种付出不及收获的想法。</li>
</ol>
<p><a href="https://blog.csdn.net/weixin_52053378/article/details/126629439?spm=1001.2014.3001.5501">开源软件开发导论——第1次作业_二九L的博客-CSDN博客</a></p>
<ol>
<li>对于已有的开源项目,如何快速理解项目,并上手开发呢</li>
<li>发布issue一般是什么形式的?是提出建议,指出不足还是有明确的代码。什么程度才算是参与了开源项目</li>
<li>参与开源项目会有收益吗</li>
<li>如果因为自身提交的代码,导致项目出现了问题,损失由谁承担?</li>
<li>对于新手,开源开发有什么入门的教程吗</li>
</ol>
<p><a href="https://blog.csdn.net/JRX992277/article/details/126629088?spm=1001.2014.3001.5502">开源软件开发导论第1次作业_根号负一2058的博客-CSDN博客</a></p>
<ol>
<li>面对一个半成品开源项目,如何减少阅读这个项目的代码的时间以求尽快的能对代码进行自己的修改和使用</li>
<li>如何防止开源项目成果被他人窃取利用</li>
<li>人员的流动造成代码的历史遗留问题,开发者对开源项目具有什么样的责任</li>
<li>开源软件的发展周期是怎么样的</li>
<li>开源项目的参与者除了提升技术外,是否能通过项目得到一些实际的利益和收入</li>
</ol>
<p><a href="https://blog.csdn.net/weixin_51559847/article/details/126628847?spm=1001.2014.3001.5501">开源软件开发导论第一周作业1——关于开源软件的五个问题_saber3297的博客-CSDN博客</a></p>
<ol>
<li>开源项目的开发模式和非开源项目有何异同?</li>
<li>开源软件用于商业用途需要怎样的流程和许可?</li>
<li>给开源项目提供代码后,项目被非法利用我需要承担怎样的责任?</li>
<li>开源软件可能会包含世界各地众多的代码贡献者,请问如何保证代码的正确合理,审核机制是什么样的?</li>
<li>开源软件怎么获得报酬?</li>
</ol>
<p><a href="https://blog.csdn.net/u011567964/article/details/126627631?spm=1001.2014.3001.5502">开源软件开发导论第一周作业1——关于开源软件的五个问题_橙原 凯的博客-CSDN博客</a></p>
<blockquote>
<p>code: 7054</p>
</blockquote>
<ol>
<li>感觉介入开源项目是很困难的,开源项目负责人是如何让介入者快速理解代码的呢?没有时间去理解整个项目代码的情况下,如何才能开始编写项目代码呢?</li>
<li>issue的具体作用是什么?提bug?讨论用法?提了issue就算介入开源项目了吗?</li>
<li>参与开源项目会不会有人在未通知的情况下直接修改了自己写的代码部分的内容的情况呢?</li>
<li>在编写代码的时候若进行分模块/分文件负责的安排是否能较大程度的减少合并冲突的情况呢?(意味着尽量保证有且仅有一个人编写同目录/同文件下的代码)</li>
<li>开源软件有可能获得收益吗?如何评定与分配?他人使用开源软件盈利,利益会分发到开发人员手中吗?</li>
</ol>
<p><a href="https://blog.csdn.net/AboveParadise/article/details/126627531?spm=1001.2014.3001.5502">开源软件开发导论——第1次作业_Obliviate°的博客-CSDN博客</a></p>
<ol>
<li>参与开源项目时如何提出issue/pull request能够让项目管理者清晰地理解并接受该补丁?</li>
<li>作为项目主管人如何合理地分配组内各成员的任务?这种情况下独裁管理模式是否更好?</li>
<li>蓝皮书中提出了加强重点开源人才培养、推动开源教育和价值引导的建议,北航在这方面有什么相关举措来培养开源人才吗?</li>
<li>结合我在软工实践中的经验,想提出问题:如何在与项目队友提交的代码合并时快速找到所有的不同之处?</li>
<li>当已有的项目代码很复杂时如何快速度过新手期,理解代码并开展工作?</li>
</ol>
<p><a href="https://blog.csdn.net/Wentingyuya/article/details/126627226?spm=1001.2014.3001.5502">【课程作业】对开源软件开发的疑问_冇_头脑的博客-CSDN博客</a></p>
<ol>
<li>一个开源项目一般需要提供什么说明或资料,以让更多的开发者更方便的了解、加入本项目。</li>
<li>如何能更准确地搜索到感兴趣的、且社区较为活跃的开源项目。</li>
<li>一个项目开发到什么状态的时候适合开源,或者说想要开源的项目最好处于一个什么样的状态。</li>
<li>开源项目维护者如何高效地审查提交的pr。</li>
<li>开发人员的流动会不会造成代码的历史遗留问题,开发者对开源项目具有什么样的责任。</li>
</ol>
<p><a href="https://blog.csdn.net/qq_54065560/article/details/126633918">关于开源的五个问题_maple0826的博客-CSDN博客</a></p>
<ol>
<li>发现该项目吸引作者的一大原因是代码质量,那么在我们创建开源项目或者参与开源项目时,是不是也需要创建或遵守一定的代码规范、文档标准?有没有,类似于开源标准这样的已经创建好的规范标准?</li>
<li>发现即使是Linux社区(可以说是世界上最成功的开源社区之一),在代码审查、测试部分仍然存在资源不足的问题,或者说,贡献者修复bug和审查者审查相应贡献,是一个耗费精力不对等的过程,毕竟要读懂一个人的代码是很困难的,那么现在的开源项目是如何应对这个问题的?是否有一定的贡献要求以降低审查者的压力,如添加规范的注释、贡献者进行一定的测试等?</li>
<li>对于开源项目的维护者来说,其责任无疑是巨大的,那么如果某个项目出现了问题,维护者是否要承担无限责任,还是使用者也要为“开源”二字承担一定风险?</li>
<li>且不论当事人是否真的存在故意提交危险代码,对于这种故意或无意下存在安全隐患的贡献,项目维护者如何辨别呢?如果是依靠自身的技术能力,那么当项目愈发庞大后,对于审查者的能力要求也会相应提高,面对满足要求的审查者稀少的情况,又是如何解决的呢?</li>
<li>对于一个开源项目,其使用的组件等也应该是免费的或遵循相应的开源协议,这要求贡献者有较强的版权意识(或许是这么说),较为了解开源协议,对于MIT、BSD等常见的开源协议,它们主要涉及的是哪些领域?这些协议是否具有法律效力?开源项目拥有者的利益被侵犯(如项目被公司等申请专利),是否能从法律层面维护自身的利益?</li>
</ol>
<p><a href="https://blog.csdn.net/qq_35537753/article/details/126626402">【课程作业】对开源软件开发的疑问_伏罗希洛夫射手的博客-CSDN博客</a></p>
<ol>
<li>在确定自己感兴趣的方向后,有什么好的方式去寻找一个合适自己的开源项目来参与?在这段话中,作者为对数据库和消息队列感兴趣的人提供了两个选择,但我更感兴趣的是有没有这样一个好的寻找手段,能够方便“开源小白”去找到这样的合适自己的开源项目。</li>
<li>作者为对C语言不熟悉的“开源小白”提供了开始的思路,也就是在参与开源项目前可以做的事。我还想知道:这种方法是否可以延伸到其它语言或方向,或者说想要参与到某一开源项目中,有哪些工作是最好能提前做好的?</li>
<li>作者在最初几次pr的时候大部分都没被接受。我对此的疑问是:一般而言代码不被接受是出于什么原因?如果pr被拒项目维护者是否会告知拒绝的理由?以及如何让自己的代码更容易被开源项目接受?</li>
<li>作为开源项目的维护者,如何高效地审查提交的代码?小而美的补丁固然好,但也不总是那么容易得到的,尤其对于一些并不热门的开源项目来说。</li>
<li>协调与引导众多开发者并非易事,我好奇这种工作是否也会体现到开源软件开发的进程中来,或者说开源项目和其它一般项目相比,开发流程的区别主要体现在哪里?</li>
</ol>
<p><a href="https://blog.csdn.net/Nana7mii/article/details/126624628?spm=1001.2014.3001.5501">开源软件概论 第一次作业_Nana7mii的博客-CSDN博客</a></p>
<ol>
<li>关于开源软件的安全性,应该如何保障,当今社区中是否有能够检测漏洞的成熟的机制,使用开源软件是否会带来相应的安全问题</li>
<li>其中,开源正在吞噬软件,为什么在大变局中被认定为“危”,难道“软件吞噬世界,开源吞噬软件”对于中国的软件行业不是一个乐观的局面?这和我的认知有一点差别。我认为开源在吞噬软件这个情形,对于行业应该是一个巨大的变革,但是不至于用“危机”来形容,这是为什么呢,难道软件开源化对于行业会带来什么负面影响么?</li>
<li>关于开源软件,我觉得这种商业上的认定其实是很难判别的。就比如,整个软件如果要拿来商用,那么利益和专利应该归谁所有。如果社区中有贡献者提供了优秀的补丁,甚至于大大改变软件性能的补丁,他们是否享有一定的分享利益的权利。难道说开源软件,真的只是纯纯的“用爱发电”?</li>
<li>关于开源人才的认定,何为开源人才?是指精通开源项目技术栈的人才么?一个优秀的程序员,对他熟悉的领域的开源软件做出贡献,他算不算开源的人才?这里的开源人才亦或者说是全能人才?我们需不需要专门去对于开源方面培养相关人才?我认为开源人才应该首先是某一个领域的人才,然后对于开源项目有着足够的热情和精力去贡献,然后才能变为开源人才。想要留住开源人才,就肯定要想办法留住他们的热情,那么就回到了问题3,我们是否对于贡献者有着一套很好的激励体系。</li>
<li>一个困惑:我自己在上个学期做项目的时候,小组内用git进行版本维护,感觉使用起来效果很好。开源软件同理,感觉也是一个更大的项目,只不过所有人都能参与进来,把自己想要修改和添加的内容上传,经过管理员审核,就能够添加到远程仓库中。但是肯定对于某些行业和产品,是不能够开源的,因为涉及到机密和版权等等。那么是不是开源理论上存在一个上限呢,即存在一个开源软件的范围,在范围之外的产品是无论如何也不能够开源的。如果开源真的如我所想存在一个范围上限,那么当他达到这个上限的时候,还会有新的内容出现么?</li>
</ol>
<p><a href="https://blog.csdn.net/Mirror_and_Smoke/article/details/126626278?spm=1001.2014.3001.5501">我对开源项目的五个问题_Mirror_and_Smoke的博客-CSDN博客</a></p>
<ol>
<li>在开源项目开发时,如果项目的参与者一部分认为一种方法好,另一部分认为另一种方法好,最后对接的部分出现了问题,这就是南辕北辙了。如何确保项目的参与者之间不会存在南辕北辙的情况?</li>
<li>开源项目的参与者的水平、看代码的角度都有差异,由木桶效应,代码的效率受相对低性能部分影响较大。那么开源项目开发时如何保证代码的各项性能优异?</li>
<li>随着目前关于开源的讨论越发强烈,项目开源是否是一个大多数时间更优的选择?</li>
<li>如果开源项目获得了经济效益、名声效益,那么开源项目的收益应该怎么分配?</li>
<li>如果我现在就想投入开源项目开发,但又不是很确定自己的能力能完成哪些部分,作为一个开源项目的参与者,我们应该如何确定自己的工作范围?</li>
</ol>
<p><a href="https://blog.csdn.net/weixin_53962739/article/details/126625819?csdn_share_tail=%7B%22type%22%3A%22blog%22%2C%22rType%22%3A%22article%22%2C%22rId%22%3A%22126625819%22%2C%22source%22%3A%22weixin_53962739%22%7D">[开源软件开发导论课程——第一次作业]有关开源软件开发的5个问题_宿舍断网了的博客-CSDN博客</a></p>
<ol>
<li>越贴近底层确实越通用,但是开发成本也越高,这个贴近是怎样的贴近。并且并不是所有轮子都要自己造,在当下各种软件都比较完善,作为一个学生想去参加一个贴近底层的开源项目的入门就变得十分困难,我们应该如何选择自己力所能及的开源项目,或者如何将在学校所学的课程学以致用?</li>
<li>周围的人都说卡脖子,并且将事情描述成只要美国断供,中国的操作系统、航天导航就会瘫痪,在已有得开源代码支持下我认为只是技术倒退一部分,并不是直接瘫痪,就如鸿蒙系统,虽然刚开始几乎全是安卓得代码,但现在通过一句一句地更改,逐步实现国产化。在查找开源代码相关资料后,心中对开源的程度仍是模糊不清。</li>
<li>如何确保安全性?如果用户使用开源代码需要自己检查代码是否有后门,那么开发的时间成本就会很大。</li>
<li>不论是GPL还是LGPL,确实都从一定程度限制了这种问题,但是一个公司的软件如果是闭源的,那么他是否运用了开源社区里的成果也是不能得知的,请问如何有效避免这种行为?</li>
<li>较大的开源项目从外界吸收新鲜血液会不会有效率问题,一个是代码质量可能参差不齐,另一个是项目作者可能无法每一个issue都认真查看。</li>
</ol>
<p><a href="https://blog.csdn.net/weixin_53418400/article/details/126625517?csdn_share_tail=%7B%22type%22%3A%22blog%22%2C%22rType%22%3A%22article%22%2C%22rId%22%3A%22126625517%22%2C%22source%22%3A%22weixin_53418400%22%7D">关于开源软件的个人疑问_qingchenn的博客-CSDN博客</a></p>
<ol>
<li>开源软件的知识产权问题应该如何判定,如何保证创作者的著作权?</li>
<li>其他公司利用某开源软件获得了丰厚的利润,作为该开源软件的创作者是否有权利去分享这些利润?</li>
<li>一般开源软件的发展周期是怎么样的?</li>
<li>位于下游的开源创作者如何处理上游软件可能会出现漏洞与问题?</li>
<li>关于开源软件开发,开源社区对于项目代码等的审核是依据的什么标准?</li>
</ol>
<p><a href="https://blog.csdn.net/m0_61820655/article/details/126624101?spm=1001.2014.3001.5502">我对开源软件开发的5个疑问_m0_61820655的博客-CSDN博客</a></p>
<blockquote>
<p>在阅读了2022中国开源发展蓝皮书及网上相关资料后,我对开源软件开发管理有了一个较为初步的了解,但依然存在着一些疑问。</p>
</blockquote>
<ol>
<li>参与开源项目的同志来自各地且互相之间未必熟悉,请问如何保证仅在线上沟通的基础上让开源项目顺利进行,如果有对项目的恶意破坏者或因互相不熟悉缺少沟通而产生的代码冲突应怎样解决或预防?</li>
<li>开源项目是否享有合法的知识产权权益,如果参与的开源项目被非法盗用并商业化或恶意破坏,开源项目参与者能否获得补偿,能通过怎样的手段维护劳动成果?</li>
<li>开源软件项目负责人通过怎样的审核与检验保证代码的正确、健壮性?由于审核任务繁重,开源参与者在提交代码时是否会受到一些限制?</li>
<li>开源项目的参与者除了提升技术外,是否能通过项目得到一些实际的利益和收入?</li>
<li>怎么寻找适合自身技术栈的开源项目,在加入一个开源项目后怎样迅速判断这个项目需要哪些改进,自己的编码应从哪里着手?</li>
</ol>
<p><a href="https://blog.csdn.net/symxl/article/details/126625465?csdn_share_tail=%7B%22type%22%3A%22blog%22%2C%22rType%22%3A%22article%22%2C%22rId%22%3A%22126625465%22%2C%22source%22%3A%22symxl%22%7D">Intro-OSSD HW1 关于开源软件的5个问题_symxl的博客-CSDN博客</a></p>
<ol>
<li>常见管理模式有哪些,具体管理原理是怎样的</li>
<li>是否会有筛选困难的问题,如果有,如何处理</li>
<li>如何确保项目本身的安全性以及使用者的安全性</li>
<li>开源开发的主要优势与劣势</li>
<li>开源软件开发者与项目的反馈模式是怎么样的</li>
</ol>
<p><a href="https://blog.csdn.net/a61561444/article/details/126624701?spm=1001.2014.3001.5502">对“开源软件开发”的5个疑问_buaalkn的博客-CSDN博客</a></p>
<ol>
<li>给开源项目提交的代码会通过审核,但审核又是怎样保证所提交代码中一定不会对开源项目产生负面影响?</li>
<li>如果因为所提交的开源代码导致上线的项目出了问题,那这些损失应该由贡献者承担还是这个项目的负责人或是审核员承担?</li>
<li>我理解的开源就是把自己的成果拿出来供大家一起测试和改进,那么对于某些开源软件做出了很大贡献的人,是只是出于爱好,还是能得到一定物质上的奖励?</li>
<li>我作为一个大学生来说,水平还十分欠缺,那么我该如何找到合适自己的开源项目,并通过自己的努力实际的为此做出贡献?</li>
<li>之前在github创建仓库时,发现需要选择开源协议,这些不同的开源协议有什么较大的不同吗?体现在哪方面?</li>
</ol>
<p><a href="https://blog.csdn.net/Levi1022/article/details/126621479?spm=1001.2014.3001.5502">关于开源项目的五个问题_Levi1022的博客-CSDN博客</a></p>
<ol>
<li>项目开源后,别人下载使用进行删改更新或者盗用商业化,最后项目的归属怎么划分,知识产权怎么保护</li>
<li>开源项目能否盈利,既然已经开源,用户可以免费获取源文件并使用,开发者的开发维护成本怎么回收?</li>
<li>企业开源可以提高知名度,带动付费项目收入,而个人开发者开源除了用爱发电又有什么好处?</li>
<li>开源项目的开发模式和非开源项目有何异同?</li>
<li>项目开源很多人可以提供修改、debug、补丁、这些内容的审核和测试该如何高效进行?</li>
</ol>
<p><a href="https://blog.csdn.net/beastttt/article/details/126623767?spm=1001.2014.3001.5502">我对开源软件开发的疑问_喝水小魚的博客-CSDN博客</a></p>
<p>开源软件有什么样的类型,所有的开源软件都是完全免费开源,可以用于教学甚至商业用途吗?</p>
<p>开源领域著名事件:知名开源库Faker.js的作者Marak Squires,选择主动恶意破坏该个项目,并且不仅“删库跑路”、还注入了导致程序死循环的恶意代码,使得全球大量使用该项目的个人与企业都受到了不小的影响,请问开源的发展方向是否包含给开源作者带来合理的利益?</p>
<p>开源软件可能会包含世界各地众多的代码贡献者,请问如何保证代码的正确合理,审核机制是什么样的?</p>
<p>如何使用开源代码,如何检索所需功能的项目,请问如何 快速上手开源代码的利用?</p>
<p>如何对开源项目做出贡献,如何依据自己的能力确定合适的开源项目进行开发?</p>
<p><a href="https://blog.csdn.net/weixin_56332363/article/details/126623623?spm=1001.2014.3001.5502">关于“开源”的问题_半人481的博客-CSDN博客</a></p>
<ol>
<li>如何保证开源项目中的补丁是无害的?对于恶意或无意识的制造漏洞有怎样的判定方法?又如何进一步约束。</li>
<li>开源社区的审查者需要具备什么程度的知识和能力?才能正确审视各种开发者提交的代码。</li>
<li>什么样的开源项目才能在不断地迭代发展中仍具有鲜活的竞争力?哪些类项目或什么情景下的项目更适合开源?</li>
<li>是否有完全致力于开源的工作者?他们是否有日常的收入来源?</li>
<li>新人从哪些开源项目入手比较好?有没有一些有价值的参考教程。</li>
</ol>
<p><a href="https://blog.csdn.net/qq_53739932/article/details/126622649?csdn_share_tail=%7B%22type%22%3A%22blog%22%2C%22rType%22%3A%22article%22%2C%22rId%22%3A%22126622649%22%2C%22source%22%3A%22qq_53739932%22%7D">我对开源软件开发管理的五个疑问_Streamin'的博客-CSDN博客</a></p>
<ol>
<li>开源软件是通过怎么样的审核机制来保证软件本身的健康性,避免错误和冗杂代码对软件进行破坏的呢?</li>
<li>在开源软件的开发过程中,应该怎样确定自己的开发方向?</li>
<li>如何查询开源软件的各个开发版本?</li>
<li>开源软件的基础操作教程?还不清楚。</li>
<li>开源软件的使用协议怎么查询?可以用作私人的软件吗?</li>
</ol>
<h3 id="refer">refer.<a class="headerlink" href="#refer" title="Permanent link">¶</a></h3>
<blockquote>
<p>有关链接
<a href="http://devrel.zoomquiet.top/data/20110617102755/index.html">如何成为一名黑客</a></p>
</blockquote>
<ul>
<li><a href="/220817-flossstyle-0.html">开源生活实录.0.从哪儿知道的?</a></li>
<li><a href="/220817-flossstyle-1.html">开源生活实录.1.LAMP之辉</a></li>
<li><a href="/220820-flossstyle-2.html">开源生活实录.2.GNU之魂</a></li>
<li><a href="/220820-flossstyle-3.html">开源生活实录.3.GTD之始</a></li>
<li>...</li>
<li><a href="https://blog.zhgdg.org/2013-08/hd1-askquestion/">海选文章:1 智慧的提问 ~ GDG Livin ZhuHai Life;-)</a><ul>
<li>PS: 正好 邹欣 老师在题目中给出参考链接中那个图谱, 就是07 年俺在 <a href="https://wiki.woodpecker.org.cn/moin/AskForHelp">AskForHelp - Woodpecker Wiki for CPUG</a> 中发布的.</li>
<li><a href="https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/main/README-zh_CN.md">提问的智慧 · ryanhanwu/How-To-Ask-Questions-The-Smart-Way · GitHub</a></li>
</ul>
</li>
<li><a href="https://blog.zhgdg.org/2013-12/dm13-ask-problem/">珠的自白:13 不会提问的中国学生 ~ GDG Livin ZhuHai Life;-)</a></li>
<li><a href="https://blog.zhgdg.org/2014-10/dm34-how2ask/">珠的自白:34 如何提问?才对世界有帮助! ~ GDG Livin ZhuHai Life;-)</a></li>
<li><a href="https://doc.101.camp/">蟒营®101.camp 开源网络课程框架</a><ul>
<li><a href="https://blog.101.camp/nc/190711-nc101-self-destruction/">NC0:一个自毁倾向社区的形成 — 蟒营™ 怂怼录</a></li>
</ul>
</li>
</ul>
<h3 id="logging">logging<a class="headerlink" href="#logging" title="Permanent link">¶</a></h3>
<ul>
<li>220901 ZQ init.+pub</li>
</ul>什么是"闪电演讲", 以及为什么值得体验.2022-07-21T21:42:24+08:002022-07-21T21:03:01+08:00Zoom.Quiettag:blog.zoomquiet.io,2022-07-21:/220721-what-is-lighting-talk.html
<h2 id="background">background<a class="headerlink" href="#background" title="Permanent link">¶</a></h2>
<p>马上第7届 COSCon(中国开源年会) 将在线举行,
因为 2019年在上海 COSCon , 有过"从容"的 <code>闪电演讲</code>,
所以本次大会, 被指定为 <code>闪电演讲</code> 联合出品人,
另 …</p>
<h2 id="background">background<a class="headerlink" href="#background" title="Permanent link">¶</a></h2>
<p>马上第7届 COSCon(中国开源年会) 将在线举行,
因为 2019年在上海 COSCon , 有过"从容"的 <code>闪电演讲</code>,
所以本次大会, 被指定为 <code>闪电演讲</code> 联合出品人,
另外一位出品人是谁呢? 就是强哥了, 证明一下:</p>
<ul>
<li>3:21/zoomquiet <a href="http://0.zoomquiet.top/CPyUG/zq2voice/coscon2019lightalk/191103-lightalk-leo-184849.MP3">191103-lightalk-leo-184849.MP3</a></li>
<li>4:56/Richard Lin <a href="http://0.zoomquiet.top/CPyUG/zq2voice/coscon2019lightalk/191103-lightalk-floss-190841.MP3">191103-lightalk-floss-190841.MP3</a></li>
</ul>
<h2 id="story">story<a class="headerlink" href="#story" title="Permanent link">¶</a></h2>
<p>其实最早接触 <code>闪电演讲</code> 是在 2010.6.11 PyCon Asia Pacific, SMU(新加坡管理大学),
和当时在豆瓣的清风老师联合对口相声演讲完成后,
对自己的 <strong>Cnglish</strong> 大有信心,
直接现场报名完成了人生第一次闪电演讲, 而且是英文的,
基本上就是142个单词左右, 3分钟以内, 对 Leo 编辑器进行了一种玄幻的介绍;</p>
<p>再然后, 就到了 2014.7.20 台北中央研究院演讲大厅,
COSCUP 最后一天最后一个节目, Lighting Talk,
只能现场报名, 结果人太多, 预定的10个演讲全部抢光,
最后神奇和另外一位同学, 两人分享了一节演讲, 每个人4分钟,
俺的部分:
<a href="http://0.zoomquiet.top/ZHGDG/2014/140719_20-coscup/140720_lt-10-leo.MP3">140720_lt-10-leo.MP3</a></p>
<p>而强哥就是从 台湾 过来的, 所以, 参与 COSCon 筹备后,
就一力引入激动人心的 Lighting Talk/闪电演讲;</p>
<h2 id="goal">goal<a class="headerlink" href="#goal" title="Permanent link">¶</a></h2>
<p>那么什么是 闪电演讲呢? 字面儿意思:</p>
<ul>
<li>如闪电般高速演讲</li>
<li>给人留下闪电般深刻印象</li>
<li>象闪电般结束不讨论</li>
</ul>
<p>所以, 形式上也是:</p>
<ul>
<li>没有幻灯</li>
<li>3~5分钟定长</li>
<li>过时按铃下台</li>
</ul>
<p>目的:</p>
<ul>
<li>尽可能用最短时间, 展现更多内容</li>
<li>如果内容/演说都差强人意思, 也就几分钟, 大家忍一下就过去了</li>
<li>给尽可能多的参与者机会</li>
</ul>
<p>其实, 闪电演讲的创意脱胎于营销界传统艺能: <code>麦肯锡30秒电梯理论</code> ,
著名的麦肯锡咨询公司要求他的每一个业务人员, 都必须有在30秒的时间向客户介绍方案的能力;
也就是瞧准机会和目标企业关键人物同乘一座电梯的时间里,
要完整/清晰/重点突出的完成业务阐述, 赢得兴趣, 获得下一个关键的10分钟阐述机会;</p>
<p>这在大妈<a href="https://doc.101.camp/">蟒营®开源网络课程框架</a>里, 也称为: <code>能技</code></p>
<p><strong>能</strong>使目标人物, 对自己的问题产生科学兴趣的<strong>技</strong>术;</p>
<p>其实, 无论是赢得业务机会, 还是获得技术高手关注, 又或是创业后在路演中获得 VC 青睐,
即便是在平时部门会议中, 可以简明扼要的完成汇报, 就已经是突出常人很多了;
可以说, 在各种场景中, 其实可以视为充斥着 <code>闪电演讲</code>:</p>
<ul>
<li>机场排队时, 清晰阐述自己就是这次航班的, 吻合绿色通道原则可以插队</li>
<li>回家晚了, 简洁有力的向家里领导汇报今天的不得已</li>
<li>...</li>
</ul>
<p>实在是居家旅行必备技能,
怎么可以忽略呢?</p>
<p>抓住一个知识点/经验/问题/故事/...,
反复在脑海里, 深夜里, 墙角里...练习42次以上,
就可以来 COSCon2022中国开源大会, 闪电演讲环节, 和其它闪电侠一齐,
用连续的 "闪电" 留下又一年新的传说吧.</p>
<h2 id="logging">logging<a class="headerlink" href="#logging" title="Permanent link">¶</a></h2>
<ul>
<li>220721 ZQ pub</li>
<li>220714 ZQ append .mp3</li>
<li>220704 ZQ init.</li>
</ul>什么是开放社区初探....2020-01-31T16:42:24+08:002020-01-31T17:15:27+08:00Zoom.Quiettag:blog.zoomquiet.io,2020-01-31:/200131-what-is-community.html
<h2 id="_1">背景<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<p><a href="https://shimo.im/docs/KWxwgtpwGQxYv6Gw">鼠年话开源-系列主题网聊</a></p>
<ul>
<li>第6夜是俺发起的议题</li>
<li>没想到是个错误的议题, 几句聊明白后</li>
<li>引发出更加有意思的讨论...</li>
</ul>
<h2 id="_2">触发<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<blockquote>
<p>其中追本溯源 …</p></blockquote>
<h2 id="_1">背景<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<p><a href="https://shimo.im/docs/KWxwgtpwGQxYv6Gw">鼠年话开源-系列主题网聊</a></p>
<ul>
<li>第6夜是俺发起的议题</li>
<li>没想到是个错误的议题, 几句聊明白后</li>
<li>引发出更加有意思的讨论...</li>
</ul>
<h2 id="_2">触发<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<blockquote>
<p>其中追本溯源的灵魂一问, 导入一本奇书中的论述</p>
</blockquote>
<p>' 姜宁: https://github.com/open-organization-ambassadors/open-org-workbook/blob/master/open_org_workbook_1_1_5.pdf 222 页有一篇文章 community和open source community的论述,大家可以参考一下. '</p>
<hr/>
<p>' 姜宁: 里面提到一个概念,就是Open Communities 也不是绝对的Open . '</p>
<hr/>
<p>' 姜宁: open communities are a broader implementation of open source communities. '</p>
<hr/>
<h2 id="_3">快译<a class="headerlink" href="#_3" title="Permanent link">¶</a></h2>
<blockquote>
<p>尝试将要点翻译一下...</p>
</blockquote>
<p>什么是社区?
...以往...现在互联网社区越来越重要...</p>
<p>"社区"是指关系;它是成员与其共享的价值和活动系统之间的连接媒介. 换句话说,这是人员,工具和其他元素相互联系和互动的方式. 这一点很重要. 社区不仅仅是一群无定形的人...</p>
<p>什么是开放社区?</p>
<p>-> 专门指开源技术社区了...其次,这些社区产生的源代码是"开放的",这意味着社区和公众都可以使用和修改它. </p>
<p>进一步的, 开源技术社区也只是开放社区首批实例化的社区...</p>
<p>以往是专有软件为王, 现在开源软件在兴起...</p>
<p>更简单地讲,开放社区发展所遵循的共同价值观和信念不仅与它所做的事情有关,而且还与它如何做事有关. </p>
<p>功勋主义 是很多开源社区的核心价值观...</p>
<p>开放社区主要通过成员的参与进行管理,而不是由指定的社区主持人进行管理(尽管可能有一个社区主持人,其作用是根据社区的精英和其他价值观来调解纠纷或进行适度的讨论).
所有成员的参与都是为了使社区的目标和行为社会化. 例如,在开放社区中,围绕"协作","多样性","适应性","透明性"或"功勋"的价值观形成,所有成员都有责任防止和报告骚扰或任何可能破坏这些骚扰的行为价值观. </p>
<h2 id="_4">反思<a class="headerlink" href="#_4" title="Permanent link">¶</a></h2>
<p>6年前私人偏见是这样的:</p>
<p><a href="https://devrel.101.camp/2014-02/ac2-tech-community/">关 乎社群:2 什么是技术社区? | DevRel | 开发者关系.思考</a></p>
<p>今天, 从开源技术社区开始, 逐渐获得社会认可, 进而衍生出更加宽泛的开放社区;
对比开源技术社区, 相同的是:</p>
<ul>
<li>核心目标作品</li>
<li>开放/对等/主动的协作机制</li>
<li>...</li>
</ul>
<p>问题是, 国外学术界/商界都在积累观察/参与/讨论/分析/...开源引发的开放社区协作...</p>
<p>而中国互联网全员关注的只是 996 福报...</p>
<p>那么, 作为微小的个人, 可以为之作什么?</p>
<ul>
<li>发起/运营/参与/服务各种开放社区</li>
<li>积累贡献经验, 观察/总结中国式协作技巧</li>
<li>切实通过实践影响到具体的一个个人</li>
<li>慢慢的, 传递开来, 就能形成切实的影响力以及组织/团体/社区/共同体/...</li>
</ul>
<h2 id="_5">原文<a class="headerlink" href="#_5" title="Permanent link">¶</a></h2>
<p><a href="https://github.com/open-organization-ambassadors/open-org-workbook/">open-organization-ambassadors/open-org-workbook: Repository for open organization community's workbook</a></p>
<p>p222~224</p>
<blockquote>
<p>Introduction:</p>
</blockquote>
<p><strong>What is community?</strong></p>
<p>Heidi Hess von Ludewig</p>
<p>The term "community" refers to a sense of shared ownership and purpose that generates relationships of goodwill and fel- lowship between the members of a social network.</p>
<p>"A community" is a speci c social network united according to shared values, beliefs, and goals. In recent years (and especially since the widespread adoption of internet technologies and appli- cations), the term "community" has taken on renewed importance. Communities exist wherever people can connect—face-to-face, in shared space, or even virtually, through analog or digital media (like as ham or CB radio) or social networking applications (like Facebook). Social communities often center around religion, poli- tics, culture, geographical location, or interests. In professional and business realms, communities can be comprised of members who have similar knowledge, professions, or work roles (for in- stance, software coding, lawyers, or project managers). Research on communities has found that they provide support, enlarge net- works by enabling weak and strong network ties, disseminate information, and provide education and mentorship.</p>
<p>But they do something else, too: Communities de ne modes of behavior, beliefs, and roles, and in this way foster relationships between people. "Community" refers to the relationships; it is the connective medium between members and their shared value and activity systems. In other words, it's the way that people, tools, and other elements relate and engage with one another. This point is important. Communities are not just amorphous globs of people</p>
<p>stuck together with some beliefs; they consist of relationships that develop between and among community members and elements. Those relationships are what constitute the community; the rela- tionships make possible the feeling of fellowship and positive association between members, the activities they perform, and the way they perform them.</p>
<p>Communities—how they're constructed, the tools they use, how they operate—in uence the ways members connect (how they develop relationships between each other and establish relation- ships to the community at large), and the community purpose and value system is the reason those members connect. In this sense, then, the reason a community exists, how it decides to design and structure itself, the tools it decides to use, the information it dis- plays to instruct and guide members, and the people who join and participate in the community are all important considerations in building an open community, because each of these factors in u- ences the others.</p>
<p><strong>What are open communities?</strong></p>
<p>So-called "open communities" are an o shoot of open source software communities. The term "open" in "open source commu- nity" has dual meanings. First, in open source communities, community participation is "open," meaning that anyone can join the community and participate in its activities. Second, the source code these communities produce is "open," meaning that both the community and the general public can use and modify it.</p>
<p>At the time open source communities were created, "open" was a very new concept—one in direct opposition to prevailing wis- dom in the software industry, where proprietary software (creation, use, and access controlled by the owners of the intellectual prop- erty) was predominant. Open source communities, therefore, were among the rst enactment of open communities and were focused on creating software. Today, however, open communities are a broader implementation of open source communities.</p>
<p>While all communities function in ways that align with the beliefs and values of the group, some are more explicit and deliberately re exive about the values that guide their operation. Open communities are one example of this approach to community; they concern themselves with how a community should operate. In this way, open communities foster a particular kind of relationship and bond between its members, and—in the truest sense—encourage the development of specialized activities that are supportive of its values and beliefs. More simply, the shared values and beliefs around which an open community develops has to do not only with what it does but how it does what it does.</p>
<p>For example, at the heart of many open communities is the value of "meritocracy," which members invoke to stress evaluation of ideas and work based on the intrinsic value of the work to the community and not on the value of the people performing the activ- ity. Other key attributes of an open community are transparency, inclusivity, adaptability, and collaboration. These shared qualities help spur the self-organizing nature of an open community. The rel- ative level of a community's degree of inclusivity, adaptability, collaboration and transparency determines that community's de- gree of "openness."</p>
<p>Open communities are managed predominantly through members' participation, rather than by a designated community moderator (though there may be a community moderator whose role is intended to mediate disputes or moderate discussions based on the meritocracy and other values of the community). All mem- bers participate in order to socialize the goals and behaviors of the community; for instance, in open communities are formed around values like "collaboration," "diversity," "adaptability," "trans - parency," or "meritocracy," all members are responsible for preventing and reporting harassment or any behavior that might negate these values.</p>
<p>Since open communities are especially concerned with how they operate, they are often able to use their shared values to in- form decision-making practices and evaluate contributions. Members therefore possess a common language for working to- gether, are able to use that language and standard of behavior to participate in collaborative work, consistently model the behaviors that align with the shared values, and—perhaps most importantly— are accountable for their actions (and trust other community mem- bers to also be accountable).</p>
<p>...</p>如何配置 rIME 支持 GitChat 规范?2019-02-01T10:42:00+08:002020-01-31T16:42:10+08:00Zoom.Quiettag:blog.zoomquiet.io,2019-02-01:/rime4gitchat.html
<h2 id="bg">BG<a class="headerlink" href="#bg" title="Permanent link">¶</a></h2>
<ul>
<li>新年了, 发现有 <code>长徦式学习症</code> , 很多不敢肥家被逼婚的程序猿, 宁可呆在公司一边值班一边刷课</li>
<li>同时, GitChat 也空降新领导, 启 …</li></ul>
<h2 id="bg">BG<a class="headerlink" href="#bg" title="Permanent link">¶</a></h2>
<ul>
<li>新年了, 发现有 <code>长徦式学习症</code> , 很多不敢肥家被逼婚的程序猿, 宁可呆在公司一边值班一边刷课</li>
<li>同时, GitChat 也空降新领导, 启动叕一波作者鼓动</li>
<li>所以, 响应号召, 尝试分享这年几点感触</li>
<li>只是, 没想到, 对提交文章, 有了细致要求, 任何一点不达标, 直接退稿, 不允许发布</li>
<li>虽然, 申述说:<ul>
<li>通过配置输入法, 已经有15年从来不用中文标点了</li>
<li>不仅在编程时杜绝了因为中文标点引发血案</li>
<li>同时, 也促使行文更加国际化, 也从来没因为标点而引发误解</li>
<li>但是, GitChat 方面不认为这是读者可以接受的</li>
<li>其它作者也劝:"从了吧, 您就..."</li>
</ul>
</li>
</ul>
<blockquote>
<p>所以...</p>
</blockquote>
<h2 id="goal">goal<a class="headerlink" href="#goal" title="Permanent link">¶</a></h2>
<ul>
<li>找到配置, 恢复全角标点输入</li>
<li>同时兼容以往全部半角标点输入习惯</li>
<li>进一步, 是否可以用工具来完成自动化修改?</li>
</ul>
<h2 id="logging">logging<a class="headerlink" href="#logging" title="Permanent link">¶</a></h2>
<blockquote>
<p>快速记录应对嗯哼</p>
</blockquote>
<h3 id="sed">sed<a class="headerlink" href="#sed" title="Permanent link">¶</a></h3>
<ul>
<li><a href="https://gist.github.com/ZoomQuiet/53439dd21c60a935e793">i hate Chinese symbol! so usage: zhmark2en.sh pwd FILEexNAME</a></li>
<li>早年开始实行全半角标点后, 自然的基于 bash 编写了小工具<ul>
<li>可以自动用自己指定规则</li>
<li>替换批量文本文件中所有全角标点</li>
</ul>
</li>
<li>自然首先尝试基于之, 反转规则:<ul>
<li>还用之前输入习惯</li>
<li>只是提交前, 用工具自动替换所有半角标点为编辑们渴望和依赖的中文标点</li>
</ul>
</li>
</ul>
<blockquote>
<p>结果->放弃</p>
</blockquote>
<ul>
<li>首先, 中文标点有很大一批是成对却不同形状 <code>"" " "</code><ul>
<li>原先工具替换时是统一替换为同一形状</li>
<li>比如,无论 <code>"</code> 或是 <code>"</code> 都嗯哼为 <code>"</code></li>
<li>现在想相反, 远没那么简单</li>
</ul>
</li>
<li>另外, 原先替换的目标字符在 ASCII 范畴, 无论什么编码都兼容<ul>
<li>现在则不同, 中文标点只存在少数几种编码中</li>
<li>用 shell 脚本强行修改后</li>
<li>引发编码混乱, 文本直接乱码了</li>
<li>强行转换回 UTF-8 依然有很大比例有吞字现象</li>
</ul>
</li>
</ul>
<h3 id="rime">rIME<a class="headerlink" href="#rime" title="Permanent link">¶</a></h3>
<blockquote>
<p>只能回到输入法本身来定制了</p>
</blockquote>
<p>好在 <a href="https://rime.im/">RIME - 中州韻輸入法引擎</a> 本身就是高度可定制的</p>
<ul>
<li>参考: <a href="https://github.com/ZoomQuiet/ZqBXM/tree/master/Rime-Squirrel">ZqBXM/Rime-Squirrel at master · ZoomQuiet/ZqBXM</a></li>
<li>发现当年关键几处配置</li>
<li>小心尝试几次, 便搞定</li>
</ul>
<p>:</p>
<div class="highlight"><pre><span></span><code>/Users/zoomq/Library/Rime/
+- alternative.yaml ~ 全/半角标点声明
+- ...
+- bxm4zq2mac.custom.yaml ~ 私制 表形码 输入法定制配置
+- bxm4zq2mac.schema.yaml ~ 私制 表形码 输入法行为配置
+- ...
`- user.yaml ~ 通用输入行为配置
</code></pre></div>
<ul>
<li>其它配置都不用动</li>
<li>单单在 <code>user.yaml</code> 中<ul>
<li><code>ascii_punct: true</code> </li>
<li><code>full_shape: false</code></li>
<li>这两个配置反转就好</li>
</ul>
</li>
</ul>
<h2 id="gitchat-style">GitChat-style<a class="headerlink" href="#gitchat-style" title="Permanent link">¶</a></h2>
<blockquote>
<p>饭桶式写作输入</p>
</blockquote>
<ul>
<li>原先 rIME 配合私制 <code>表形码</code> 进行写作和编程时, 行为很简洁:<ul>
<li><code>control+空格</code> 切换到 <code>鼠鬚管</code> (中州韻 输入法平台 macOS 版本代号)<ul>
<li>随便输入就好...</li>
</ul>
</li>
<li>如果有大段英文输入, 不想触发中文选字<ul>
<li><code>shift</code> 切换状态, 或 <code>option+~</code> 选择输入状态</li>
</ul>
</li>
<li>以上</li>
</ul>
</li>
<li>现在, 为了兼容编辑们的期待, 行为就业务性冗余了:<ul>
<li>输入正文时, 必须:<ul>
<li><code>shift</code> 切换为中文输入模式</li>
<li>再用 <code>shift+空格</code> 切换为到 <code>全角</code> 标点</li>
<li>此时, 所有标点是<code>中文式</code>的</li>
</ul>
</li>
<li>输入 markdown 相关结构字符时, 又必须:<ul>
<li><code>shift</code> 切换为中文输入模式</li>
<li>再用 <code>shift+空格</code> 切换为到 <code>半角</code> 标点</li>
<li>此时, 类似 <code>+ - ></code> 以及空格/tab 都是 ASCII 式, markdown 可理解的</li>
</ul>
</li>
<li>输入英文单词/术语时, 又必须:<ul>
<li><code>shift</code> 切换为中文输入模式</li>
<li>再用 <code>shift+空格</code> 切换为到 <code>半角</code> 标点</li>
<li>再用 <code>shift</code> 切换为 en 输入模式</li>
<li>此时, 才能输入正常 ASCII 字符</li>
<li>否则是类似 <code>ASCII</code> 全角英文</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>综上, rIME 支持灵活丰富的输入模式:</p>
<ul>
<li>可是为了灵活, 不得不劳累用户显式指令切换模式</li>
<li>同时, 从法理上不同输入模式中, ASCII 字符形态是不兼容</li>
<li>而 GitChat 编辑又要求在同一篇文章中:<ul>
<li>不同格式标点,空格</li>
<li>和不同形式字符</li>
<li>又必须 <code>合理? 美观? 合规?</code> 并举</li>
</ul>
</li>
<li>导致至少多出一倍毫无必要的击键操作</li>
<li>以及, 和以往主要输入行为完全不同的心智判定损耗</li>
<li>可以说, 是 <code>GitChat 式工伤</code></li>
</ul>
<h2 id="refer">refer<a class="headerlink" href="#refer" title="Permanent link">¶</a></h2>
<ul>
<li><a href="https://gitbook.cn/books/5c47da3ef79c0c1f90492403/index.html">Chat 发布与写作指南</a></li>
<li><a href="http://w3c.github.io/clreq/zh/">中文排版需求</a><ul>
<li><a href="http://devrel.zoomquiet.top/data/20150402184838/index.html">从"中文排版规范"开始</a></li>
<li>对比: <a href="https://www.w3.org/TR/jlreq/">Requirements for Japanese Text Layout</a></li>
</ul>
</li>
<li><a href="https://github.com/sparanoid/chinese-copywriting-guidelines/blob/master/README.md#%E7%A9%BA%E6%A0%BC">中文文案排版指北</a><ul>
<li><a href="https://github.com/vinta/pangu.js?utm_source=www.appinn.com">vinta/pangu.js: 為什麼你們就是不能加個空格呢?</a></li>
</ul>
</li>
<li><a href="https://mp.weixin.qq.com/s/Vu-20r7_LCTToyaOeli7tg">全角半角碎碎念 - The Type</a><ul>
<li><code>...可见,中文的标点符号既可以是'全宽'的也可以是'半宽'的,'中文=全角'完全是技术问题导致的误解.</code></li>
<li><a href="https://zh.wikipedia.org/wiki/%E5%85%A8%E5%BD%A2%E5%92%8C%E5%8D%8A%E5%BD%A2">全角和半角 - 维基百科,自由的百科全书</a></li>
</ul>
</li>
</ul>
<h2 id="sayeahooo">Sayeahooo<a class="headerlink" href="#sayeahooo" title="Permanent link">¶</a></h2>
<ul>
<li>h 资料搜索理解</li>
<li>2d gitlab 尝试/生效</li>
<li>4h github 嗯哼<ul>
<li>3h 域名迁移尝试</li>
</ul>
</li>
<li>2h 截屏,文档嗯哼...</li>
</ul>内圈梗集锦(人工智能简史)书评2018-02-20T16:42:24+08:002020-01-31T16:42:10+08:00Zoom.Quiettag:blog.zoomquiet.io,2018-02-20:/180220-book-ai-historic.html
<p>版权归作者所有,任何形式转载请联系作者. </p>
<div class="highlight"><pre><span></span><code><span class="err">作者</span><span class="o">:</span><span class="n">Zoom</span><span class="o">.</span><span class="na">Quiet</span><span class="o">(</span><span class="err">来自豆瓣</span><span class="o">)</span>
<span class="err">来源</span><span class="o">:</span><span class="n">https</span><span class="o">://</span><span class="n">book</span><span class="o">.</span><span class="na">douban</span><span class="o">.</span><span class="na">com</span><span class="sr">/review/9167418/</span>
</code></pre></div>
<p>是也乎,( ̄▽ ̄)</p>
<p>现在技术类图书有一种不好的 …</p>
<p>版权归作者所有,任何形式转载请联系作者. </p>
<div class="highlight"><pre><span></span><code><span class="err">作者</span><span class="o">:</span><span class="n">Zoom</span><span class="o">.</span><span class="na">Quiet</span><span class="o">(</span><span class="err">来自豆瓣</span><span class="o">)</span>
<span class="err">来源</span><span class="o">:</span><span class="n">https</span><span class="o">://</span><span class="n">book</span><span class="o">.</span><span class="na">douban</span><span class="o">.</span><span class="na">com</span><span class="sr">/review/9167418/</span>
</code></pre></div>
<p>是也乎,( ̄▽ ̄)</p>
<p>现在技术类图书有一种不好的倾向:</p>
<div class="highlight"><pre><span></span><code>书名有简史的
总是比通史要难写
但是有趣也有用的多
关键特别有种 ;-)
</code></pre></div>
<p>以往从信息简史开始到人类/未来等诸简史, 其实都有点以史预言将来的意思,</p>
<p>AI 简史, 反而专注陈述过去,</p>
<p>全书少了一个关键内容:</p>
<div class="highlight"><pre><span></span><code>AI历史进展中
各种路线的时间线
和关键人物/作品/理论
的关系图谱
</code></pre></div>
<p>另外,和其它技术图书类似(是的,类似流畅的 Python 之类技术人员自己写的图书);
书中各种小扣儿比正文有趣的多,
只是, 作者是海外华人, 用的都是中文中精彩的梗, 目测难以翻译为英文挣些更大的名望.</p>
<p>作者, 明显是业内人士, 从参考文献列表就可以看出,
俺看过,这么多技术类图书, 也就暗时间, 能比肩了,
基本上这本不到300页的小书, 涉及的参考图书数量是俺看过的所有大陆华人写的技术图书参考图书的总合还多...</p>
<p>当然, 看下来还是很爽利的,
特别是最后一章最后一节, 是作者的巅峰之作, 也是全书的精华,
另外, 作者原创的图灵小传也值得反复嗯哼...</p>
<p>简单的说, 这是一部用49城侃大山的精神结构来回顾AI 这一领域发展过程的仙书.</p>
<p>对于准备或是从事 AI 开发工作的程序猿来说,
最大的功能就是知道自己袓师爷们的关系,
以及知道想深入下去, 应该补什么书了. </p>
<p>~ <a href="https://book.douban.com/review/9167418/">内圈梗集锦(人工智能简史)书评</a></p>好中文写作课私人体验2017-11-09T19:42:00+08:002020-07-19T11:59:37+08:00ZoomQuiettag:blog.zoomquiet.io,2017-11-09:/171109-GC4-feeling.html<hr/>
<h1 id="_1">冲破<code>海洋般的微笑</code>~好中文写作课私人体验<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<p>是的, 必须作个广告:
报名链接:<strong><a href="http://h5.xiaoeknow.com/content_page/eyJ0eXBlIjozLCJyZXNvdXJjZV90eXBlIjoiIiwicmVzb3VyY2VfaWQiOiIiLCJwcm9kdWN0X2lkIjoicF81OWZhODE4NWE2YzhiX01wN3RlSUpBIiwiYXBwX2lkIjoiYXBwUnJ4VWtkSG84MDU3Iiwic2hhcmVfdXNlcl9pZCI6InVfNTlmYzNjMjA2Y2I1N19uc3Q3UUZndTJDIiwic2hhcmVfdHlwZSI6NX0">好中文写作课</a></strong></p>
<p>明晩(2017-11-10)20:00 开始的42分钟里
将亲声嗯哼 …</p><hr/>
<h1 id="_1">冲破<code>海洋般的微笑</code>~好中文写作课私人体验<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<p>是的, 必须作个广告:
报名链接:<strong><a href="http://h5.xiaoeknow.com/content_page/eyJ0eXBlIjozLCJyZXNvdXJjZV90eXBlIjoiIiwicmVzb3VyY2VfaWQiOiIiLCJwcm9kdWN0X2lkIjoicF81OWZhODE4NWE2YzhiX01wN3RlSUpBIiwiYXBwX2lkIjoiYXBwUnJ4VWtkSG84MDU3Iiwic2hhcmVfdXNlcl9pZCI6InVfNTlmYzNjMjA2Y2I1N19uc3Q3UUZndTJDIiwic2hhcmVfdHlwZSI6NX0">好中文写作课</a></strong></p>
<p>明晩(2017-11-10)20:00 开始的42分钟里
将亲声嗯哼如何 <strong><a href="https://st.h5.xiaoe-tech.com/st/9GMIuwZcW">冲破<code>海洋般的微笑</code></a></strong>
<img alt="长按扫描二维码进入直播, 当然俺是说手机上;-)" src="http://upload-images.jianshu.io/upload_images/27562-d018b5243c1f681f.jpeg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240"/></p>
<p><em>(如果无法打开外链, 那么:</em>
- 微信->
- 搜索关注 <code>简书大学堂</code>(jianshuit)公众号->
- 后台回复 <strong>大妈</strong> ->
- 即时获得分享链接
<em>)</em></p>
<hr/>
<p>佩哥哥的官方文案:<a href="http://www.jianshu.com/p/2b10a8c3c71a">你一定没见过好中文的样子 - 简书</a></p>
<p>对比第一期的野望:<a href="http://www.jianshu.com/p/b8908240cdbb">我发起了《好中文的样子:36堂写作练习》 - 简书</a></p>
<p>可以感受的到, 从根本上不同与:</p>
<ul>
<li>文科专业的学术向研究</li>
<li>或是广告/文案/公号等专项领域的专用写作技巧传授</li>
</ul>
<p>这门课本质上...</p>
<h2 id="_2">起初<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<p>其实, 小学时对写作是很有自信的:</p>
<ul>
<li>曾经用一天完成了暑假40天日记的伪装</li>
<li>家长和老师都没看出来</li>
<li>可以说, 非虚构写作技能在小学三年级前已算过关</li>
</ul>
<p>进一步的:</p>
<ul>
<li>在初3, 对一次语文作业进行了深度折腾</li>
<li>首稿提交的是3万字短篇小说</li>
<li>后来扩写为30万字</li>
<li>可以说, 长篇故事的虚构写作也算过关的</li>
</ul>
<p>当然:</p>
<ul>
<li>最自得的是各种应用文创作</li>
<li>检讨书/检讨信/道歉书/道歉信/...</li>
<li>各种在公众场合对自己的灵魂进行真诚剖析并展示悔恨的文体</li>
<li>异常熟练,并形成了自己的套路</li>
<li>以致, 30多年后, 都能信手掂来:<a href="http://www.jianshu.com/p/6c3fcf5f8c6b">有关门牙的公开检讨书</a></li>
</ul>
<h2 id="_3">然后<a class="headerlink" href="#_3" title="Permanent link">¶</a></h2>
<p>进入大学之后, 发觉根本没那么简单...</p>
<ul>
<li>无论邮件/报告/论文/说明/...</li>
<li>所有涉及文字的输出</li>
<li>大家第一反应,都是看不懂</li>
<li>唉唉? 剧情不是这么设定的哪...</li>
</ul>
<p>所以, 开始在人前沉默:</p>
<ul>
<li>好在, 工作是软件工程师</li>
<li>只要电脑可以理解并正确执行出结果就好</li>
<li>对于那些当面和真实肉体实时交流的语言</li>
<li>和文书上的规则又是不同的宇宙规则了, 先不讨论</li>
</ul>
<h2 id="_4">所以<a class="headerlink" href="#_4" title="Permanent link">¶</a></h2>
<p>工作上了年头, 文案工作是少不了的,
也就越来越急切的想整明白:</p>
<ul>
<li>技术社区中流通的文字和日常竟有什么不同?</li>
<li>为什么写的邮件同事们都说看不懂?</li>
<li>为什么中文图书越来越难以阅读?</li>
<li>为什么?...</li>
</ul>
<p>因为内心其实还未通达, 所以, 偶然间撞到 <strong><a href="http://h5.xiaoeknow.com/content_page/eyJ0eXBlIjozLCJyZXNvdXJjZV90eXBlIjoiIiwicmVzb3VyY2VfaWQiOiIiLCJwcm9kdWN0X2lkIjoicF81OWZhODE4NWE2YzhiX01wN3RlSUpBIiwiYXBwX2lkIjoiYXBwUnJ4VWtkSG84MDU3Iiwic2hhcmVfdXNlcl9pZCI6InVfNTlmYzNjMjA2Y2I1N19uc3Q3UUZndTJDIiwic2hhcmVfdHlwZSI6NX0">好中文写作课</a></strong> ,毅然报名并意外的坚持了下来,</p>
<p>是以, 能作为幸存者来将 <strong><a href="http://h5.xiaoeknow.com/content_page/eyJ0eXBlIjozLCJyZXNvdXJjZV90eXBlIjoiIiwicmVzb3VyY2VfaWQiOiIiLCJwcm9kdWN0X2lkIjoicF81OWZhODE4NWE2YzhiX01wN3RlSUpBIiwiYXBwX2lkIjoiYXBwUnJ4VWtkSG84MDU3Iiwic2hhcmVfdXNlcl9pZCI6InVfNTlmYzNjMjA2Y2I1N19uc3Q3UUZndTJDIiwic2hhcmVfdHlwZSI6NX0">好中文</a></strong> 的故事分享给大家伙儿...</p>
<p>是的, 这门课是本质上的<code>课</code>:</p>
<p><img alt="8AB2" src="http://upload-images.jianshu.io/upload_images/27562-1b9138404aba0cf2.gif?imageMogr2/auto-orient/strip"/></p>
<p>小篆的"课"字是个形声兼会意字.
左边的言字旁是形符,
表示这个字与讲话发言有关.
右边的"果"是读音. </p>
<ul>
<li>"课"的本义是按照一定的标准进行试验,考核,以检验成果. </li>
<li>所以引申为国家根据数额征收赋税,如:国课,课税</li>
<li>按照规定的内容和分量,教授和学习称之为"课"</li>
<li>按照规定的教学内容,教学时间所设置的教学科目,也称之为"课"</li>
<li>"课"也用来表示教学单位,如:一节课. 也表示教授的段落,如:这本教材共有十五课. </li>
</ul>
<p>所以本质的<code>课</code>:</p>
<ul>
<li>按照本义, 上课,其实就应该是来<code>向</code>先生阐述所得, 印证学习成果来的<ul>
<li>所谓 言</li>
<li>以证 果</li>
<li>是然 课</li>
</ul>
</li>
<li>只是, 向先生阐述的,是之前,约定的课题/问题/疑题/试题....</li>
<li>只有这样,每个人,才是真正用自个儿最有效的方式在正确的方向上积累智慧</li>
<li>以往,所谓 "上课" 其实变成了:<ul>
<li>老师求学生记忆单元知识点</li>
<li>如若不然,用考试用分数用体罚 来加以开导</li>
<li>至于强填到学生脑子里的东西,老师一般也不以为然的</li>
<li>反正,考卷怎么要求,就怎么教</li>
</ul>
</li>
<li>回想一下,可怕嘛?! 挺可怕的,但是,大家也20几年熬过来了</li>
<li>可是,为什么又主动要求, 再来"享受"这种无谓的灌输呢?! <code>斯德哥尔摩综合症</code> ?</li>
</ul>
<p><strong><a href="http://h5.xiaoeknow.com/content_page/eyJ0eXBlIjozLCJyZXNvdXJjZV90eXBlIjoiIiwicmVzb3VyY2VfaWQiOiIiLCJwcm9kdWN0X2lkIjoicF81OWZhODE4NWE2YzhiX01wN3RlSUpBIiwiYXBwX2lkIjoiYXBwUnJ4VWtkSG84MDU3Iiwic2hhcmVfdXNlcl9pZCI6InVfNTlmYzNjMjA2Y2I1N19uc3Q3UUZndTJDIiwic2hhcmVfdHlwZSI6NX0">好中文写作课</a></strong>
回归<code>课</code> 的本源,</p>
<ul>
<li>专注唯一的命题: 什么是好中文?</li>
<li>无私的分享佩哥哥半个世纪以来有关中文写作的深入思考</li>
<li>当然, 最 COOL 的就是佩哥哥, 打死都不会直接说出来好中文的写作机密的</li>
<li>只是通过一个个精心泡制的故事/任务/聊天/...</li>
<li>以及神奇的学员们结成的全新课程空间</li>
<li>来用半年时间焖熟你自己, 将好中文卤入味到所有人心神中</li>
</ul>
<p>好玩儿卟?
那么立即报名吧--><strong><a href="http://h5.xiaoeknow.com/content_page/eyJ0eXBlIjozLCJyZXNvdXJjZV90eXBlIjoiIiwicmVzb3VyY2VfaWQiOiIiLCJwcm9kdWN0X2lkIjoicF81OWZhODE4NWE2YzhiX01wN3RlSUpBIiwiYXBwX2lkIjoiYXBwUnJ4VWtkSG84MDU3Iiwic2hhcmVfdXNlcl9pZCI6InVfNTlmYzNjMjA2Y2I1N19uc3Q3UUZndTJDIiwic2hhcmVfdHlwZSI6NX0">好中文写作课</a></strong></p>
<p>还是有点儿小纠结?
欢迎明晩(2017-11-10)20:00
来小鹅直播间: <strong><a href="https://st.h5.xiaoe-tech.com/st/9GMIuwZcW">怂怼录 ~ 大妈的好中文私人体验回哞</a></strong></p>
<p>亲声尝试用<strong>42分钟</strong> 嗯哼清楚 <strong><a href="https://st.h5.xiaoe-tech.com/st/9GMIuwZcW">冲破<code>海洋般的微笑</code></a></strong></p>
<p><em>(如果无法打开外链, 那么:</em>
- 微信->
- 搜索关注 <code>简书大学堂</code>(jianshuit)公众号->
- 后台回复 <strong>大妈</strong> ->
- 即时获得分享链接
<em>)</em></p>
<hr/>
<p><img alt="长按扫描二维码进入课程, 当然俺是说手机上;-)" src="http://upload-images.jianshu.io/upload_images/27562-631a0b4bf263c98b.jpeg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240"/></p>[大妈吐糟]小密圈 之功能残念集2017-04-03T19:42:00+08:002020-07-19T12:19:55+08:00ZoomQuiettag:blog.zoomquiet.io,2017-04-03:/170403-chaos-xiaomi.html<h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<h1 id="_1">[大妈吐糟]小密圈 之功能残念集<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<h1 id="_2">唯有忍受的小密圈<a class="headerlink" href="#_2" title="Permanent link">¶</a></h1>
<p>第一时间下载/注册/安装了...然后, 没明白能干什么..
终于阴差阳错的也 …</p><h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<h1 id="_1">[大妈吐糟]小密圈 之功能残念集<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<h1 id="_2">唯有忍受的小密圈<a class="headerlink" href="#_2" title="Permanent link">¶</a></h1>
<p>第一时间下载/注册/安装了...然后, 没明白能干什么..
终于阴差阳错的也发布了付费自学圈, 大家进来了,才发现: WTF!</p>
<h1 id="bug-imho">Bug# #IMHO<a class="headerlink" href="#bug-imho" title="Permanent link">¶</a></h1>
<h2 id="_3">先夸奖<a class="headerlink" href="#_3" title="Permanent link">¶</a></h2>
<ul>
<li>和微信的关联太平滑了,简直以为是同一家公司作的<ul>
<li>用微信支付/认证, 完成小密圈的进入</li>
<li>没有任何问题,而且异常的吻合目标人群的分布</li>
<li>至少,俺的所有成员, 都是从微信群转入的</li>
</ul>
</li>
<li>支付作的非常简洁, 提供了所有必要的功能,而没有其它乱来的</li>
</ul>
<h2 id="wtf">WTF!<a class="headerlink" href="#wtf" title="Permanent link">¶</a></h2>
<p>~ 一堆堆的 </p>
<ul>
<li>app 和 网页功能竟然不是一一对应的?!<ul>
<li>app->动态|消息</li>
<li>是所有小圈的综合入口 类似各种 CSM 平台的: dashboard</li>
<li>非常好,非常有用,非常必要</li>
<li>居然 网页版 没有这功能!</li>
</ul>
</li>
<li>要知道:<ul>
<li>任何时候尝试在移动设备上进行大量的文字输入, 都是不人道的</li>
<li>所以, 强行要求用户这么作, 只能 WTF!</li>
<li>而手机上知道动态, 进行复稿</li>
<li>回到桌面, 进入对应的问题/回复 快速输入完成交流</li>
<li>这是最自然的流程了</li>
<li>在 小密圈 完全变成了不可能...</li>
</ul>
</li>
</ul>
<h3 id="uri">虚假的 URI<a class="headerlink" href="#uri" title="Permanent link">¶</a></h3>
<ul>
<li>不知什么原则的设计</li>
<li>小密圈中的所有事物(主题/回复/提问/消息/...) 都没有真正的 URI</li>
<li>变成了一个功能页面的各种 锚点 (path/2/foo.html#/index/758548854 <-- 这种)</li>
<li>虽然地球上首先由 gmail 发明并成功了 SPA(单网页应用)概念<ul>
<li>但, 那是完全的特例, 因为作为一个私人邮箱的界面在一个页面不跳转是合理的</li>
<li>而且, 借助宏大的原创 JS 库, gmail 拥有完备的快捷键体系</li>
<li>可以只用键盘,完成几乎所有邮件管理的操作</li>
</ul>
</li>
<li>可是, 小密圈, 是完全隔离的不同群落的私密圈哪</li>
<li>那么, 当我同时付费进入,以及在经营不同主题的小圈时<ul>
<li>这种虚URI 就引发了各种浏览器的错乱</li>
<li>比如, 无论俺在什么页面, F5/cmd+r 刷新时</li>
<li>结果将是我在的所有小圈按照字母排序第一个圈子的首页</li>
<li>无论刷新时, 俺在哪儿...</li>
<li>WTF!</li>
</ul>
</li>
<li>更加可怕的是:<ul>
<li>网页版 主题发言 的 <code>复制链接</code> 功能提供的<ul>
<li>https://wx.xiaomiquan.com/mweb/views/topicdetail/topicdetail.html?topic_id=...</li>
<li>链接, 根本不是正常的访问链接</li>
<li>而是推广链接, 根本无法正常的在自己的小圈内部, 不同文章中使用</li>
</ul>
</li>
<li>而 app 中的分享:<ul>
<li>则是单向的, 只能分享向 微信/朋友圈</li>
<li>而不能获得链接/对象, 分享给 小密圈中具体的人/主题</li>
<li>也就是说, 俺自己创建的多个小圈, 也是完全隔离的</li>
<li>可以同时分享/发布的内容, 除了手工反复复制, 没有任何其它办法</li>
</ul>
</li>
<li>无论 app/网页, 从消息中进入主题的回复<ul>
<li>都看不到消息提醒的新回复</li>
<li>那东西, 在可能十几屏之下呢...</li>
</ul>
</li>
<li>...</li>
</ul>
</li>
</ul>
<p>也就是说, 从根儿上:</p>
<ul>
<li>小密圈就是一个付费才能进入的残废的 微信群</li>
<li>并不是俺想象中的: 有付费功能的 gmail+邮件列表:<ul>
<li>大家可以在手机和桌面相同的行为</li>
<li>来对具体的一个个主题进行讨论</li>
<li>并可以快速定位/切换不同的主题</li>
<li>...</li>
</ul>
</li>
</ul>
<p>以上, 认真使用 小密圈 42 小时后, 先宏观阐述一下体验,
然后逐一怼一下, 要命的脑残功能们...</p>
<h1 id="bug-imho_1">Bug# #IMHO<a class="headerlink" href="#bug-imho_1" title="Permanent link">¶</a></h1>
<blockquote>
<p>~ 也就是说, 从根儿上:小密圈就是一个付费才能进入的残废的 微信群</p>
</blockquote>
<p>这就是俺第一篇反馈的虚链接 --></p>
<p>https://wx.xiaomiquan.com/mweb/views/topicdetail/topicdetail.html?topic_id=222814528151&secret=59ki2qvxatw9wtlb4lw31j99r348gk5k</p>
<p>(大家可以体验一下, 这种链接有毛用?)</p>
<p>以上, 认真使用 小密圈 42 小时后, 先宏观阐述一下体验,
然后逐一怼一下, 要命的脑残功能们...</p>
<h2 id="markdown">Markdown<a class="headerlink" href="#markdown" title="Permanent link">¶</a></h2>
<ul>
<li>有什么理由在 2017 年还专门不支持 md ?</li>
<li>有什么理由在 2017 年还专门不支持 md ?</li>
<li>有什么理由在 2017 年还专门不支持 md ?</li>
<li>好吧, 俺可以忍:<ul>
<li>可是问题是, 为毛在同一个应用内部竟然也有格式不统一的呢?</li>
<li>主题/回复 好歹能记录并体现俺输入的回行以及缩进哪</li>
<li>为毛在 app 中的提问,无论怎么尝试, 最后给出来的都是一坨挤在一起不换行的文字? </li>
</ul>
</li>
</ul>
<h1 id="bug-imho_2">Bug# #IMHO<a class="headerlink" href="#bug-imho_2" title="Permanent link">¶</a></h1>
<h2 id="_4">无法关闭的赞提醒<a class="headerlink" href="#_4" title="Permanent link">¶</a></h2>
<ul>
<li>点赞功能是 facebook 发明的 VP 发动机,用来提高广告价格的东西</li>
<li>而小密圈靠的是圈内髙品质的交流</li>
<li>点赞, 除了代表 <code>联已阅</code> 之外无论发布人还是阅读者 都没有任何意义</li>
<li>就是对 小密圈 也没有任何积极意义 --> <ul>
<li>要是在小密圈大家都只是点赞和微信朋友圈中点赞之交一样</li>
<li>那为毛要付费进入?</li>
</ul>
</li>
<li>如果小密圈以聚集 1000 鉄粉 为目标<ul>
<li>那么应该杀掉点赞功能!</li>
<li>或是,最低限度, 给俺一个选择</li>
<li>在配置中, 可以关闭点赞的提醒!</li>
</ul>
</li>
</ul>
<h1 id="bug-imho_3">Bug# #IMHO<a class="headerlink" href="#bug-imho_3" title="Permanent link">¶</a></h1>
<h2 id="web">冇用的 web 版<code>通知</code><a class="headerlink" href="#web" title="Permanent link">¶</a></h2>
<ul>
<li>对比 app 中 ->动态|消息:<ul>
<li>动态可以进入俺所在所有圈和俺相关的所有场景中</li>
<li>消息 则是可以进入 1对1 的留言场景</li>
</ul>
</li>
<li>web 版本中<ul>
<li>消息 功能消失了</li>
<li>也就是说禁止我们在桌面浏览器中,和同一小密圈的朋友单聊</li>
<li>凭什么!?</li>
<li>一定逼我们,在手机中以极其低下的效率来沟通?!</li>
</ul>
</li>
<li>更加搞笑的是:<ul>
<li>web->通知 和 app->动态 是无关联的!</li>
<li>俺在 app->动态 中点击浏览了相关消息</li>
<li>按照一般产品逻辑, 俺的未读消息数量就应该减少一个</li>
<li>而且同时 web 桌面端也应该一致的减少一个提醒计数</li>
</ul>
</li>
<li>更更加搞笑的是:<ul>
<li>web->通知 本身根本没有所谓消息是否已读的计算</li>
<li>无论俺是否从 web->通知 中点击查阅过</li>
<li>除非手工点击那个不知所谓的标记所有消息已读的 icon</li>
<li>否则, 永远标红在那儿</li>
<li>WTF!</li>
</ul>
</li>
</ul>
<p>明显 app 和 web 是两个开发团队,
而且相互不尿...</p>
<h1 id="bug-imho_4">Bug# #IMHO<a class="headerlink" href="#bug-imho_4" title="Permanent link">¶</a></h1>
<h2 id="_5">不能修改的发言<a class="headerlink" href="#_5" title="Permanent link">¶</a></h2>
<p>非常惊悚的发现:</p>
<ul>
<li>无论 <code>主题</code>/<code>回复</code> 嘦发布了</li>
<li>就只能 收藏/删除/追加标签</li>
<li>不允许作者自己来修改自己发布的文字<ul>
<li>小密圈又不是 SVN 版本仓库</li>
<li>对于交流平台, 也没有所谓历史不可悔之说哪</li>
<li>如果出于数据/消息系统的架构问题,最好所有行为是原子的</li>
<li>那俺也理解, 可是,作为作者本人<ul>
<li>俺在主题原文之下,追加个补丁说明 总是是好的吧</li>
<li>不然, 作者对自己的主题的补救说明</li>
<li>也只能挤在一堆积极奔放的回复中</li>
<li>可能连自己过几天都找不到了...</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>WTF!</p>
<h1 id="bug-imho_5">Bug# #IMHO<a class="headerlink" href="#bug-imho_5" title="Permanent link">¶</a></h1>
<h2 id="_6">找不到的文章<a class="headerlink" href="#_6" title="Permanent link">¶</a></h2>
<ul>
<li>嗯哼? 这个问题,两个月前俺回答过哪, 大家也有精彩的讨论<ul>
<li>那么, 怎么找到那篇圈内文章?</li>
</ul>
</li>
<li>对比 github-wiki:<ul>
<li>有 <code>_Sidebar.md</code>/<code>_Footer.md</code> 手工索引关键文章</li>
<li>文章内部,可以通过文件名形成 <code>WikiName</code> 式自动链接</li>
<li>当然, 也可以使用 md 的链接形式, 手工链接到任意内外文章</li>
<li>最后, 实在找不到了, 再搜索一下</li>
</ul>
</li>
<li>小密圈 呢? 作为主持人:<ul>
<li>标定文章为精华, 但是:<ul>
<li>精华标多了一样找不到</li>
<li>更加可怕的是 精华-><code>查看全部</code></li>
<li>并不是精华列表, 而是精华文章+大量回复</li>
<li>基本上成员积极点儿</li>
<li>这个界面中,前3屏第2个精华文章正文都是看不到的</li>
</ul>
</li>
<li>那尝试追加分类作用的 标签 呢?<ul>
<li>标签 早已证明不是个好东西</li>
<li>任何人都可以任意追加任意内容和数量的标签</li>
<li>积累一定时间后</li>
<li>基本就无任何指导作用了</li>
<li>可以类比在微信中, 对好友的标签分类...</li>
</ul>
</li>
<li>...没招了, 只能搜索了</li>
<li>搜索更加坑:<ul>
<li>俺只是想找, 当前小圈的相关文章哪</li>
<li>搜索,却是强壮的给出了俺所在的所有圈的所有搜索结果</li>
<li>WTF!</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>总之:</p>
<ul>
<li>虚URI+故意的产品设计</li>
<li>令 小密圈 严密的倾向:<ul>
<li>临时性的</li>
<li>非讨论式的</li>
<li>相互点赞之交式的</li>
<li>无法长期讨论的</li>
<li>...</li>
<li>总是就是低智型的快速沟通</li>
<li>想对历史讨论/发言/主题 进行针对性的有结构的管理/索引/快速引用</li>
<li>是 WTF 的...</li>
</ul>
</li>
</ul>
<h1 id="bug-imho_6">Bug# #IMHO<a class="headerlink" href="#bug-imho_6" title="Permanent link">¶</a></h1>
<h2 id="_7">怼不到的成员<a class="headerlink" href="#_7" title="Permanent link">¶</a></h2>
<p>真正运营起来小密圈后, 才发现:</p>
<ul>
<li>只有主持人, 才有界面可以进入成员列表<ul>
<li>而且这一界面, web 桌面版是没有的</li>
</ul>
</li>
<li>成员,是无法知道当前圈有多少同伴的</li>
<li>问题来了:<ul>
<li>要是 小密圈 禁止成员相互间秘密交流, 俺也能理解</li>
<li>但是,问题是 作为主持人, 想在桌面端私下对一组成员提醒点儿什么</li>
<li>竟然没招!</li>
</ul>
</li>
<li>建议:<ul>
<li>恢复微信群的逻辑吧!</li>
<li>将 <code>@</code> 功能给作齐全了</li>
<li>强制私聊变成公开聊也是好的...</li>
</ul>
</li>
</ul>
<p>现在这样不上不下的, 就佷 WTF!</p>
<h1 id="bug-imho_7">Bug# #IMHO<a class="headerlink" href="#bug-imho_7" title="Permanent link">¶</a></h1>
<h2 id="_8">信息黑洞<a class="headerlink" href="#_8" title="Permanent link">¶</a></h2>
<p>小密圈, 聚集高质量好友在一起, 长期在一起, 当然是要搞点事儿出来的哪</p>
<ul>
<li>大家好容易在一起聊出来的东西</li>
<li>竟然没有任何办法可以方便的拿出来用?!</li>
<li>要知, 信息天生就是自由的要流动的</li>
<li>对比 github-wiki 无论是否付费<ul>
<li>都有对应的 git 路径</li>
<li>可以让成员, 分布式离线使用/完善/增补/...</li>
</ul>
</li>
<li>小密圈?<ul>
<li>没有任何文档来说明怎么使用我们在这儿碰撞出来的文字</li>
<li>以及也没有任何 API 提供的迹象</li>
<li>也就是说, 这是一个付费制造出来的 信息黑洞</li>
<li>大家只能对最近的几篇文章,进行讨论</li>
<li>过去的, 甚至于现在讨论的将永远只能在 这儿</li>
<li>无法快速的提取, 以便其它组合/再创造...</li>
</ul>
</li>
</ul>
<p>所以, 俺现在是人工, 将关键文字:</p>
<ul>
<li>复制到 github 仓库中</li>
<li>随着讨论的进行, 在同步整理/再输出</li>
<li>但是,这样,对小密圈的发展...呵呵</li>
</ul>
<h1 id="imho-bug">IMHO# #Bug#<a class="headerlink" href="#imho-bug" title="Permanent link">¶</a></h1>
<h2 id="_9">完全不可用的微信小应用<a class="headerlink" href="#_9" title="Permanent link">¶</a></h2>
<p>如图片, 在微信的小应用版本 <code>小密圈+</code> 中
刷自己圈子的信息,
将永远重复的将最早的消息输出...</p>
<p>进入一种非常 Naive 的死循环中...</p>
<p>更加可怕的是:</p>
<ul>
<li>这种形式的 小应用</li>
<li>令付费的以为这就是小密圈本身</li>
<li>不再下载安装 小密圈</li>
<li>以至各种更多功能无法使用<ul>
<li>如截屏</li>
<li>付费进入的成员</li>
<li>俺想直接沟通</li>
<li>不能...</li>
<li>因为从来没有登录过 app.</li>
</ul>
</li>
</ul>
<p>所以, 小密圈 的 产品经理和其它著名产品经理一样,
自己是从来不使用小密圈来组织产品设计的...</p>
<h1 id="imho-bug_1">IMHO# #Bug#<a class="headerlink" href="#imho-bug_1" title="Permanent link">¶</a></h1>
<h2 id="web_1">web 版通知的不可用<a class="headerlink" href="#web_1" title="Permanent link">¶</a></h2>
<p>如截屏, 这种只有红标, 却没有任何内容以及链接的通知</p>
<ul>
<li>在桌面 web 版中, 越来越多</li>
<li>随着我们的深入使用</li>
</ul>
<p>所以, 小密圈 的 工程师和其它著名产品经理一样,
自己是从来不使用真空的小密圈来测试的...</p>
<h1 id="_10">是也乎#<a class="headerlink" href="#_10" title="Permanent link">¶</a></h1>S02E01/周生剧本大纲2017-04-01T19:42:00+08:002020-07-19T12:20:02+08:00ZoomQuiettag:blog.zoomquiet.io,2017-04-01:/GC4-S02E01-script.html<h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<h1 id="s02e01">S02E01: 周生剧本大纲<a class="headerlink" href="#s02e01" title="Permanent link">¶</a></h1>
<p>演员设定: </p>
<ul>
<li>周生生: 姜文 (红高梁时期的)</li>
<li>秀娘: 娜塔莎.波特曼</li>
<li>郑和: 吴秀波</li>
<li>郑爽: 文章</li>
</ul>
<h2 id="_1">双闯西洋<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<ul>
<li>(宣德五年三月 …</li></ul><h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<h1 id="s02e01">S02E01: 周生剧本大纲<a class="headerlink" href="#s02e01" title="Permanent link">¶</a></h1>
<p>演员设定: </p>
<ul>
<li>周生生: 姜文 (红高梁时期的)</li>
<li>秀娘: 娜塔莎.波特曼</li>
<li>郑和: 吴秀波</li>
<li>郑爽: 文章</li>
</ul>
<h2 id="_1">双闯西洋<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<ul>
<li>(宣德五年三月十三日)</li>
<li>[泉州城西郊, 强生豆腐店,后门]</li>
</ul>
<p>秀娘,从后看只是个普通的大明及笄少女,只是生有奇怪的褐色头发;但是,正面一看就知道不是中原人,高鼻绿瞳;
在温州地区,总是有行商失败的大食人后代流落善堂,想来这个面色焦急的少女也是相似的身世.</p>
<blockquote>
<p>"生哥! 生哥!"</p>
<p>"阿秀,你怎么来了?"</p>
<p>"生哥! 阿爷已为我报名织绣营了,年末就要和三宝大人出洋了!"
…</p>
</blockquote>
<p>送走阿秀,周生生下了决心,转身和东家辞行,
然后径直去东门,揭了西洋舰队官榜,
作为厨师入了辎重营;
又以加温来加速发豆芽的独门技术,
配合腌金桔可防/治败血症的功劳,进入郑和的视野,
成为第七次西洋舰队第42 粮船的辎重队队副.</p>
<ul>
<li>(宣德五年十一月十一)</li>
<li>[珠江口, 虎门港]</li>
</ul>
<p>240多艘各型海船,浩浩荡荡,在礼炮的欢送下,缓缓驶向外海.
其中一艘粮船上,进行仪仗队列的人群中,
周生生偷偷看向甲板中间织绣营队列;
心有灵犀般,垂着头的秀娘,微微偏头,
准确的对上了周生生的眼睛.</p>
<p>两个大明朝普通的青年,
为了对抗命运,开始了未知的旅程.</p>
<h2 id="_2">月背黑石<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<p>2020年11月11日, 月背USA 静海基地,</p>
<blockquote>
<p>"嘀! 嘀! 嘀!"
控制台警告声吵醒了值班员,
看了眼屏幕:"shit 又坏了."
随即,调无人机到矿区上空, 才发现,
在矿务机器人自动作业下, 一个倒方锥形,有10公里见方的矿坑底部,暴露出了一个纯粹几何外形的非自然物体!</p>
</blockquote>
<p>一阵鸡飞狗跳的调查,以及考察性挖掘后,
明确这是一座长高宽,9:3:1 精确比例的四棱锥.
仅挖出的部分,周长就已经有300米,</p>
<p><code>黑的象没有尺度</code>…</p>
<p>又一个早晨,阳光在无数年后,终于再照射到黑石尖顶,
瞬间一次宏大的无线电脉冲从月球射向深空,
有非常惊人的指向性,
只有在信号路径上的各种接收器,才收到:"嗡! 嗡—嗡!"</p>
<blockquote>
<p>"喂, 喂... 喂! 这个情景好象在哪里看到过啊!"
一名宅男样技术员,在显示屏上看到模拟的波峰后,下意识的说.</p>
</blockquote>
<p>宇宙中,一股能量波精确的指向火星发射而去.</p>
<h3 id="_3">隐岛失魂<a class="headerlink" href="#_3" title="Permanent link">¶</a></h3>
<ul>
<li>(宣德6年九月十日,当地子时)</li>
<li>[旗舰宝船,舰长室]</li>
</ul>
<blockquote>
<p>郑和:"子爽,到底那场暴风雨后发生了什么?!"</p>
<p>郑爽:"族叔公,都是周生生引发的事端…"</p>
</blockquote>
<p>半月前,舰队在东非外洋,遭遇暴风雨,
郑爽统领的辎重队被冲散,只余两艘船停靠在一无名大岛上....</p>
<p>其中一艘舯部受损,需要上岛收集合适的材料来修补.
周生生作为志愿者进入岛深处,
独自发现了一处有无数洞窟的山崖.</p>
<p>入夜, 周生生 偷偷从舷窗外,唤醒 秀娘 意图私奔.
却被外围的暗哨发现.
好在事先探好通路,
俩人总算领先半步逃入了 隐窟 ,
但被卫队逐步逼至窟底,
是一扇被异族花纹装饰的异常庄严的门,
门内 <code>黑的象没有尺度</code>
俩人决然闯入,漾起星光样光纹再无音讯.</p>
<p>郑爽带队赶到,尝试各种方法都无法和进入的人/物产生影响.
感觉太过诡异,又根据门楣雕刻推断是黄泉入口.
惊恐的封了洞窟,回航.</p>
<blockquote>
<p>郑和:"此事太过凶兆,下封口令,不得记入日帐!"</p>
<p>郑爽:"诺!"</p>
</blockquote>
<h2 id="_4">天宫危机<a class="headerlink" href="#_4" title="Permanent link">¶</a></h2>
<ul>
<li>2046年12月12日,触发黑石信号同一时刻,</li>
<li><火星同步轨道中国<code>天宫</code>宇航站></li>
</ul>
<blockquote>
<p>"嘀! 嘀! 嘀!"</p>
</blockquote>
<p>控制台报警随着闪动的桔红警灯响起,
严阵以待的宇航员立即按照预案行动起来:</p>
<ul>
<li>关闭所有隔仓</li>
<li>关闭所有不必要系统</li>
<li>调整姿势,将头部面向冲击方向</li>
</ul>
<p>420秒后,失事的俄国运载飞船残骸如约而至!
暴雨般的大小残骸飞掠,不可避免的有几个撞击到天宫</p>
<p>有的撞歪跳走了,
有的撞凹了外壁粉碎,
更有的穿入舱体!</p>
<p><code>天宫</code>中央的居住舱,7名宇航员,惊恐的望着对面的舱壁.</p>
<blockquote>
<p>"警告! 警告!气密性破损!"
伴随更加尖锐的警告声, 前后多处穿透.
多数被速凝胶堵住,
但是,有一处刚好在接缝处,被高速逸出的空气撕开越来越大.
紧急时刻,一位高大队员,直接坐了上去,用屁股堵住破孔.</p>
</blockquote>
<p>幸好穿了宇航服,立即脱下,并堆上速凝胶.</p>
<p>残骸雨仅仅20秒就通过了,但是,40分钟后,将再次来袭!
大家相互看着,无言以对.</p>
<blockquote>
<p>"咳,有哉屋底呢弗?" </p>
<p>(<code>有人z屋底啊弗啊</code>)</p>
</blockquote>
<p>突然,全舰响起一句温州话.</p>
<h2 id="_5">黑石来客<a class="headerlink" href="#_5" title="Permanent link">¶</a></h2>
<p>火卫3背面,三座上百公里长的方尖石紧密的耸立在一起.
三个尖顶组成的正三角形虚空,
忽然亮起银河般的光辉,
一抹正圆形黑影从中心出现,
缓缓拉出,形成标准圆柱体, 有42公里长,4.2公里直径.</p>
<p>入内, 各三条陆地和天空间夹形成了内部居住空间.
通过持续稳定旋转,获得人工重力.
中心是交通柱,如树枝,间或关联到各个陆地区.</p>
<p>在交通柱中心控制核区:</p>
<p>外形象石墨烯球, 数十米见方,中空的一个构件中,亮起辉光.
一闪而泯后,
落下天宫中,所有宇航员.
大家先后醒过神来,张目忘去,
两鬓见霜的 周生生 依然穿着号坎迎上来…</p>
<h2 id="_6">生生不忘<a class="headerlink" href="#_6" title="Permanent link">¶</a></h2>
<p>一年后, 当年 郑爽 逃离的迷岛所在,海底.
中国远洋科考察队,<code>天涯</code>11号深渊着陆器,
在10240米处,重新找到了当年的洞窟.
打开封口,机器人重新观察到了黑石门.</p>
<p>架设好小型传送巢后,
辉光亮起, 两鬓见霜的 周生生 竟然没穿任何保护服,
只是样式古早的长衫, 沉静, 但是无法压抑激动样,
缓缓走入黑石.</p>
<p>在洋面上, 核心实验室广大的球形全息显示屏环绕的控制仓中,
原<code>天宫</code>宇航队长赫然在列,和几十位不同部门的专家在围观.</p>
<p>仅几分钟后,辉光再闪, 周生生走出来,怀抱一样东西,
回到传送巢...相似的辉光再闪...</p>
<h2 id="_7">秀娘离魂<a class="headerlink" href="#_7" title="Permanent link">¶</a></h2>
<ul>
<li>(宣德6年七月四日)</li>
</ul>
<p>进入黑石后,类似后来圆柱形飞船控制中心的空间,
追兵还是围上了秀娘和周生生,
关键时刻秀娘护住 周生生,自己受了重伤,
智能系统才反应过来,迅速制止了暴行,
将其它官兵传送走后,
救治了 周生生,期间,和建立了沟通方式—使用手写板,
通过文字进行初步交流,
明确了现状:</p>
<ul>
<li>这是一个星际中转站</li>
<li>单向负责发送原 <code>亚特兰提斯</code> 帝国的留守人员</li>
<li>秀娘身体受损过重难以承受传送</li>
<li>只能先抽取魂魄寄养在魂器中静待机缘</li>
<li>中转站资源有限, 无法长期供应生命体</li>
</ul>
<p>周生生 只能选择离开</p>
<h2 id="_8">深深不弃<a class="headerlink" href="#_8" title="Permanent link">¶</a></h2>
<p>四年后,已经出发12年的中华深空移民船,<code>息壤</code>号的通讯中心,
忽然收到海量来自地球的数据包...</p>
<p>经过紧张的处理,发现是一个结构体的设计图纸
和刚刚成立的地球人类<code>星际联盟</code>(EHSU),
对所有深空移民舰队的统一指令.</p>
<p>紧张的制造和调试后,
专门腾空的货仓中央,
尺寸更加大的 传送巢 亮起辉光:
重新年轻的周生生和秀娘出现在 传送巢 中!</p>
<p>…</p>
<h2 id="_9">彩蛋<a class="headerlink" href="#_9" title="Permanent link">¶</a></h2>
<blockquote>
<p>没有彩蛋的电影是没有灵魂的...</p>
</blockquote>
<h3 id="_10">魂器<a class="headerlink" href="#_10" title="Permanent link">¶</a></h3>
<p>无数年后,地球文明果然被人类自己毁灭了,
轨道上卫星都变成了残骸,
所有城市都变成了废墟,
海洋变成灰色的...
真正的灭世!</p>
<p>在北京西山深处,依然运转的安全仓中,
一组魂器,闪动着桔色的微光,表示保有灵魂中…</p>
<h3 id="_11">大明<a class="headerlink" href="#_11" title="Permanent link">¶</a></h3>
<p>无数光年外,类似太阳系的系统中,
黑石,不在卫星,而是在类地行星上,
体积也更加宏大,
不过是横置的, 从三个尖顶组成的正三角形虚空中,
缓慢突出的,是有大明建筑风格的大气层内飞行母舰,
主控中心,坐在舰长位置的,赫然是当年追入黑石的一名内卫!</p>
<h2 id="_12">是也乎<a class="headerlink" href="#_12" title="Permanent link">¶</a></h2>
<div class="highlight"><pre><span></span><code>剧本剧本, 一剧之本
故事架构, 情节所依
开放封闭, 皆须逻辑
人物情感, 才得寄所
是也乎哉, 吾之浅见
</code></pre></div>
<blockquote>
<p>嗯哼</p>
</blockquote>
<p>最早见到的剧本, 是 2002 年找到的风之谷的英文版本剧本,
才知道剧本是要将故事有序分解为:</p>
<ul>
<li>场景</li>
<li>行为</li>
<li>对话</li>
<li>心情</li>
</ul>
<p>才能指导后续所有其它艺术创作的.</p>
<p>但是,后来自己尝试写剧本, 才发现远没那么简单.
再后来,看电影/剧集, 也开始从成品自发的逆向工程剧本,
然后,见到了 star war 剧本原稿照片,
内心无垠 WTF …
才知道, 天才就在于,从简单结构故事中育发出无数细节.</p>
<p>因为,编程有早已包含无数细节的开源模块和编译器来协助,
影视剧本,可真心要从虚空中无中生有!</p>
<p>不过,撰写冲动总是有的, 明知故事太嗯哼,
却是淤塞住了其它构思,非得写出来不可.
上周课程末尾,一说剧本大纲,立即脑中跳出了以下关系链:</p>
<div class="highlight"><pre><span></span><code><span class="w"> </span>郑和<span class="o">-></span>非洲<span class="o">-></span>亚特兰提斯
<span class="w"> </span><span class="o">-></span>黑石
<span class="w"> </span><span class="o">|</span><span class="w"> </span><span class="o">-></span>月球<span class="w"> </span><span class="o"><-</span><span class="n">USA</span>
<span class="w"> </span><span class="o">+-></span>…<span class="w"> </span><span class="o">-></span>火星<span class="o"><-</span>中国<span class="w"> </span><span class="o"><-</span>危机
<span class="w"> </span><span class="o">-></span>深空
</code></pre></div>
<p>接下来,发现,根本就是以往看过的一堆 SiFi 小说的混合物,
原创部分异常的少,
但是,死活丢不干净这一事件链相关的念头矣!
只好硬着头皮, 先立场景标题,再设计人物,
合理化所有情节背景…
哗的一下,就过了2500字.
再改, 也就按照电影的时间顺序重新排一下叙述线索,
吻合: <code>起承转合</code> 的心理节奏就好.</p>
<p>问题在:场景切换这么大尺度的 SiFi 电影,竟然没有一个核心矛盾的爆发点!</p>
<h2 id="_13">用时<a class="headerlink" href="#_13" title="Permanent link">¶</a></h2>
<ul>
<li>积累: 36+年</li>
<li>构思: 1秒</li>
<li>结构: 两次重构</li>
<li>初稿: .5h 500+字</li>
<li>再稿: .5h 300+字,全新结构,放弃</li>
<li>三稿: 4h, 2200+字, 分4次碎片时间撰写,恢复原先故事大纲</li>
<li>四稿: 1 h,回珠海飞机上,调整/删节大纲,增补细节点</li>
<li>五稿: .5h review 错别字,调整格式,发布简书</li>
</ul>怂怼录2017-03-14T00:00:00+08:002020-07-19T11:55:57+08:00Zoom.Quiettag:blog.zoomquiet.io,2017-03-14:/170314-GC4-follow-ur-heart-debuguself.html<hr/>
<h1 id="_1">怂怼录<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<p>~来自 GC4 课程中的互动, 记录各种情景中的私人体会, 具体哪些场景的触发? 您猜~</p>
<h2 id="_2">怂怼解<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<div class="highlight"><pre><span></span><code>从心出发 对心发声
直觉通读 …</code></pre></div><hr/>
<h1 id="_1">怂怼录<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<p>~来自 GC4 课程中的互动, 记录各种情景中的私人体会, 具体哪些场景的触发? 您猜~</p>
<h2 id="_2">怂怼解<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<div class="highlight"><pre><span></span><code>从心出发 对心发声
直觉通读 入耳走心
任意不畅 和合点矣
先找怼点 再修其诚
文气图画 如经似诵
字平易读 其义弗微
好中文哉 永存内心
怂怼而出 是也乎哉
</code></pre></div>
<h2 id="_3">和合技<a class="headerlink" href="#_3" title="Permanent link">¶</a></h2>
<div class="highlight"><pre><span></span><code>百年和合好事磨 几经和合定和合
从此和合传天下 也含和合技连脉
</code></pre></div>
<h3 id="_4">和合技层<a class="headerlink" href="#_4" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>合而不同 和而同气
合再进阶 和复顺气
和合嵌套 永无止境
</code></pre></div>
<h3 id="_5">和合嗯哼<a class="headerlink" href="#_5" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>一周不断探和合 七天末绝扣字眼
但使文章雅洁平 中文好样不使空
</code></pre></div>
<h3 id="_6">和合之焉<a class="headerlink" href="#_6" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>大道三千 早融生活
中外一样 入心入脑
唯难提取 须依场景
万般困顿 本心何如
录之念之 和矣合焉
</code></pre></div>
<h3 id="_7">和合效果<a class="headerlink" href="#_7" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>高雅概念去 平易述行藏
效果释嗯哼 中文好模样
</code></pre></div>
<h3 id="_8">和合协同<a class="headerlink" href="#_8" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>此间有真义 规模化魔咒
单打一何则 无量众合哉
</code></pre></div>
<p><img alt="170330e2mgrp" src="http://upload-images.jianshu.io/upload_images/27562-d6fce6d8e1b8c1b8.jpeg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240"/></p>
<h2 id="_9">好个中文<a class="headerlink" href="#_9" title="Permanent link">¶</a></h2>
<blockquote>
<p>无趣只得是自已 世界从来太精彩
无胆去闯茶米油 唯放心思横竖捺</p>
</blockquote>
<h3 id="_10">佩哥哥<a class="headerlink" href="#_10" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>如丝如缕 无形无相
菩提心树 柢园布施
能得几何 且写且改
是也乎哉 ( ̄▽ ̄)
</code></pre></div>
<p><img alt="wp170330-anti-die-fish" src="http://upload-images.jianshu.io/upload_images/27562-353a35c935c580b2.jpeg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240"/></p>
<p><img alt="wp170330-anti-line-book" src="http://upload-images.jianshu.io/upload_images/27562-5aaab78bf124c360.jpeg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240"/></p>
<p><img alt="170328-anti-break-grp" src="http://upload-images.jianshu.io/upload_images/27562-da35cbca7bc25855.jpeg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240"/></p>
<p><img alt="170330-anti-d" src="http://upload-images.jianshu.io/upload_images/27562-b37302f186737c74.jpeg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240"/></p>
<div class="highlight"><pre><span></span><code>百无禁忌 千般好
万里无云 星光闪
亿样记忆 水流过
唯有家人 安心过
</code></pre></div>
<h3 id="_11">世上可有<a class="headerlink" href="#_11" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>世上可有任何速度,比买书的更迅捷?
世上可有任何建议,比老师的话语更可信?
世上可有任何箴言,比上帝的话语更慈悲?
世上可有任何嗯哼,比大妈的话更足繁不及道?
世上可有任何课程,比好中文更加不务正业?
世上可有任何... 是也乎,( ̄▽ ̄)
</code></pre></div>
<h3 id="_12">诗寿<a class="headerlink" href="#_12" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>外衍越小 内涵越大
内涵越大 解读越多
解读越多 流传越广
流传越广 使用越多
使用越多 变化越繁
变化越繁 适用越深
适用越深 存在越长
</code></pre></div>
<h3 id="_13">知情咒<a class="headerlink" href="#_13" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>以汝已知 以汝弗知
以己已知 以己弗知
</code></pre></div>
<h3 id="_14">知情咒制造<a class="headerlink" href="#_14" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>和合技 主妇流 知情咒
好中文 佩哥哥 是也乎
</code></pre></div>
<h3 id="opening">opening<a class="headerlink" href="#opening" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>open u mind
try u never try
be happy
to writing
</code></pre></div>
<h3 id="_15">新世界<a class="headerlink" href="#_15" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>无论我们看或是不看
世界总是在哪儿
不增不减
只是
我
是否
真心愿意
去积极探寻那些
永远探寻不尽的世界
</code></pre></div>
<h3 id="_16">真正的自由<a class="headerlink" href="#_16" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>人之初性本惰
动物性为主时
好吃好睡好玩
社会性浓重后
尊重自我实现
囿于社会结构
消费能力为尚
商品渴求无度
即便生产赛高
为了攀比荣耀
必创无谓侈品
破除这个魔咒
并非靠提境界
重定人之意义
现代放弃意义
追求科学力量
上帝必须先殆
科技才能无惧
只从资本指挥
上天入地奔月
更快更多更强
人却没了追求
只余自由买卖
生产资料根源
谁控谁定意义
社会资本主义
都仅求个生存
竭力保持增长
否则一切崩坏
未来共产义义
增长不为消费
发展附带增长
崇创始性劳动
劳动即人意义
可乍个过渡去
导师不知道啊
也没谁敢去试
所以是也乎哉
╮(╯▽╰)╭
</code></pre></div>
<h3 id="_17">坐而后家<a class="headerlink" href="#_17" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>做,而后做梦
读,而后整理
理,而后触感
感,而后发觉
觉,而后得定
定,而后发慧
慧,而后储能
能,而后文涌
</code></pre></div>
<h3 id="_18">立之以诚<a class="headerlink" href="#_18" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>立其诚 无对错
记当下 持续补
皆原创 理解深
字才平 会他人
尽全功 新技got
</code></pre></div>
<h3 id="calling">calling<a class="headerlink" href="#calling" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>神性蕴在所有人 却罕有能唤出时
但遇他她它或祂 立地成佛一刹那
</code></pre></div>
<h3 id="_19">买买买<a class="headerlink" href="#_19" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>千金难买我喜欢 随心随性起用先
待到无法忍受时 再说升级它器物
</code></pre></div>
<h3 id="_20">不得嗯哼<a class="headerlink" href="#_20" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>嗯哼只因辞穷 说到微妙之所
懵然发现没词 难以精确描述
好在大家脑补 只需音节补句
</code></pre></div>
<h3 id="_21">坑道<a class="headerlink" href="#_21" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>文章本天成 妙手偶得之
挖坑不可埋 格调靠坑堆
挖得九十九 神作自此成
</code></pre></div>
<h3 id="_22">第一人称<a class="headerlink" href="#_22" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>我就是那朵白莲花
出污泥而不染
人群中总是最先看到我
躲也不行
怎么办啊
我就是这般美的出尘
为了天地这一抹灵气
我也只能忍受你们的注目
继续我的求学之路…
</code></pre></div>
<blockquote>
<p>~ 芙蓉教主一世
4200天前</p>
</blockquote>
<h2 id="_23">醉点<a class="headerlink" href="#_23" title="Permanent link">¶</a></h2>
<div class="highlight"><pre><span></span><code>视而不见 最最常见
非不明义 自认弗要
何以判决 超纲经验
未先尝试 脑补视之
何以之破 保持傻瓜
是也乎哉 ( ̄▽ ̄)
</code></pre></div>
<blockquote>
<p>请公开讨论,令众受益……눈_눈</p>
</blockquote>
<p><img alt="wp150321-ask-dama" src="http://upload-images.jianshu.io/upload_images/27562-3d7a47fc376f7b3a.jpeg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240"/></p>
<h3 id="_24">嫑点赞<a class="headerlink" href="#_24" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>点赞一秒钟
放弃思考无
以为且明白
实则忘脑后
好问题或值
视汝愿怼否
</code></pre></div>
<h3 id="_25">挖坑不埋<a class="headerlink" href="#_25" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>挖坑不埋真君子
授人以渔不予鱼
嗟来之食无营养
种子自粪成珍馐
大家同一天空下
我知我感即同你
先尝回答为什么
再来印证是也乎
╮(╯▽╰)╭
</code></pre></div>
<h3 id="_26">放弃<a class="headerlink" href="#_26" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>凡是可以快速放弃的
要么是不重要的问题
要么只是自己不重视
</code></pre></div>
<h1 id="316">3:16 之俕<a class="headerlink" href="#316" title="Permanent link">¶</a></h1>
<div class="highlight"><pre><span></span><code>停之顿之 往未知欲
能之力之 才得尝试
今之现之 终于累也
弱水三千 只取一瓢
今之现之 学会拒绝
做之行之 唯愿我意
</code></pre></div>
<h3 id="_27">随随缘缘<a class="headerlink" href="#_27" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>随心随性 缘来缘去
我述我法 但信或不
无碍吾心 是也乎哉
</code></pre></div>
<h3 id="_28">忘记...<a class="headerlink" href="#_28" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>忘记的就是不重要的
不知道就是不必要的
事实往往不是这样的
( ̄⊥ ̄)
</code></pre></div>
<h2 id="_29">修行之道<a class="headerlink" href="#_29" title="Permanent link">¶</a></h2>
<div class="highlight"><pre><span></span><code>关注大师的言行
跟随大师的举动
和大师一并修行
领会大师的意境
成为真正的大师
look to the master
follow the master
walk with the master
see through the master
become the master
</code></pre></div>
<blockquote>
<p>http://www.catb.org/~esr/faqs/hac</p>
</blockquote>
<h3 id="_30">膜拜<a class="headerlink" href="#_30" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code>膜拜向来有门槛
一心向佛无香火
寺门无径后殿入
上帝救赎有票卖
无钱只得下地狱
知行合一为那般
拜前自证已入境
</code></pre></div>S07E17g193:作业合缉,内设奖品2017-03-14T00:00:00+08:002020-07-19T11:56:18+08:00Zoom.Quiettag:blog.zoomquiet.io,2017-03-14:/170314-S07E17g193.html<hr/>
<h1 id="s07e17g193">S07E17g193:作业合缉,内设奖品<a class="headerlink" href="#s07e17g193" title="Permanent link">¶</a></h1>
<p>此乃《好中文的样子》课程小组作业,成员(按纬度排序)有天津一坪海岸线、上海安心竹和申小七、香港宋 …</p><hr/>
<h1 id="s07e17g193">S07E17g193:作业合缉,内设奖品<a class="headerlink" href="#s07e17g193" title="Permanent link">¶</a></h1>
<p>此乃《好中文的样子》课程小组作业,成员(按纬度排序)有天津一坪海岸线、上海安心竹和申小七、香港宋偲瑄、珠海大妈。</p>
<blockquote>
<p>提示文末福利:
作业由五人相互而成,虽选题不一,但仍以神秘逻辑串合在了一起。
如果“评论”回复正确这五篇短文作者各是谁,
将会收到本组严正补品 --《共产党宣言》经典版本一册。
共5个名额,先怼先得。</p>
</blockquote>
<h2 id="_1">焖土豆<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<div class="highlight"><pre><span></span><code>都已出了正月
春 依然犹豫 就是不来珠海
忽冷乍热 闷出身黏糊
不觉回想起 儿时在兰州
这节气 真正 天青气爽
山上黄土不干也不湿
实在是 焖土豆 的好日子
午间 和死党们翘课
在菜市场摸上几颗土豆 揣好火柴
兴冲冲爬一会儿 就能到半山
就地摸条石片 选个坡
平整出灶台 约一臂宽
在台面下一拳左右 向内 挖出坑道 一肘见方
接着 在灶面中心
小心向下凿穿 就是火眼 拳头粗细
再从旁边披出些小土块 半掌大小
围住火眼 垒成透风的金字塔
这时大家 也都拾柴回来了
废纸柴草一塞 升火烧旺
等火苗将土塔内侧 烤得微红
一脚捅塌 丢入土豆 用土封好
大功告成 伸伸腰 撒泡尿
十分钟 焦香钻土而出
马上围住 七手八脚 刨开土
要躲着还滚烫的土块
将土豆们小心挑出来
人人托上 急急撮破皮
哪管上面是否有土 下嘴啃
简直就是烤鸡 刚出炉 外焦里嫩 浓香冲顶
那时 一起大马金刀 踞坐山边
凝视河谷中 居民楼 学校 操场 工人俱乐部 红旗 …
即便年纪小 心中却是涌出 苍茫
</code></pre></div>
<h2 id="_2">跑下去<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<div class="highlight"><pre><span></span><code>周日阳光明媚
城市雾霾终于消散
带女儿来到公园
一同畅快的享受户外阳光和蓝天
公园里小伙伴们很快熟识
追逐着漫天的肥皂泡
女儿开心极了
而我急急跟在后面
护着女儿的周全
才跑了五十米
已是气喘吁吁
顺势歪躺在草地上
扭头 微风中 女儿追逐着肥皂泡
身影稚嫩 分外可人
我被美丽的场面惊呆
凝望许久
一个念头刹那间刺到了我
女儿从襁褓到咿呀学步
时光如梭 如今已经奔跑自如
将来女儿会跑的越来越快
当她开始享受奔跑的乐趣
我就开始跑不动
还在喘息 低头瞪着赘肉 黯然神伤
人生最大的悲哀也许莫过于此
如果说身体和思想总有一个在路上
言传身教静下心想来
也许身教才是最有力的教育和传承
为了改变 我开始了慢跑
从初跑的五十米
喘气 停歇 放弃 挣扎 再上路 纠结
呼吸的急促 体力的匮乏
肌肉的酸痛 无一可以克服
不跑的理由很多
跑下去的理由极少
跑步中如果真的有什么必须战胜的对手
回想 只能是过去的自己
因为期望健康地陪伴女儿的成长
就这样 坚持中
我完成了人生首个十公里 半马 全马
没有轻松的得到
只有坚持的意外
未来 女儿将长大成人
远去的背影会更加坚定且稳健
分明告诉她的父母不必追
但我只想尽力跑的快一点 再快一点
跟上陪伴她的脚步将距离缩短一点 再短一点
</code></pre></div>
<h2 id="_3">渔岛<a class="headerlink" href="#_3" title="Permanent link">¶</a></h2>
<p>他走到海草房的门前,能借口水喝吗?</p>
<p>渔夫的女儿低着头,手里的动作突然凝住。渔夫的女儿抬起头惊愣,鼻翼细密的汗珠泛着浑浊的灰。 风暴前,天上擦不干净的,也是这样的灰。</p>
<p>渔夫的女儿闪进海草房的门后,门缝里遗落两颗像星星一样黑的眼睛忽闪。海草做的门,有轻柔的阻力。他缓慢地把门拉向自己。门开的瞬,嵌着她的背影,粉旧的麻布裙子到脚踝,腰肢像春桨,系着黑绿色的围裙。 她像刚被风从尘埃里吹出来的棕榈树叶子,寂静的黄枯里挣扎着一绺不甘的绿。 或者是踢开滚圆的鹅卵石会看到的,不知道哪次涨潮时,被潮水丢弃在石头与石头缝隙间的海藻。 她就像那海藻,太阳底下的石头传导着温度刚要把它烤干,潮水便默默探访一遭,在脆软的海藻上留下摆脱不掉的湿印,就像她胸前的痕迹。</p>
<p>他不请自来,坐在海草屋里唯一的椅子上,接过她递来的颤巍巍的水。</p>
<p>岛上就你们一家吗?他问。</p>
<p>渔夫的女儿局促的手指在墨绿色的围裙上揩了揩,连带胸部丰腴的线条,像风吹过时的麦浪。 渔夫的女儿扭身走出海草房,蘸着蓝色的油漆,刷那没褪色的船篷。
船是你爹自己造的?他跟出来,蹲在一边。</p>
<p>渔夫的女儿蘸着蓝色的油漆,刷蓝得泛汪的船篷。</p>
<p>他的背正对着渔夫回来的方向。他感到了奇异的粗糙的力量稳稳地拍了他的肩膀,他扭头,看到了渔夫奇异的笑。他想那奇异的缘故是太久没笑,又好像不止。
你睡哪里。渔夫问。</p>
<p>他看着渔夫刀割一样的皱纹,门口,他答。</p>
<p>他留了下来。</p>
<h2 id="_4">疯人院的中秋节<a class="headerlink" href="#_4" title="Permanent link">¶</a></h2>
<p>月光如水,倾泻而下,映出院子天井般的深影。</p>
<p>东北角杂草地,一男人斜躺着,瘦瘦长长,裤子极不合身,露出了一大截小腿。</p>
<p>院子中央,有一男青年在跳舞, 霹雳舞, 他随着想象中的节奏, 夸张地摆动着身体,还一边和观众互动, 一边固执的只向右甩发, 不存在的长发。</p>
<p>观众开始活跃,朝他吹口哨,喝倒彩,也有人随众人一通傻乐。</p>
<p>草地上男人幽幽望了人群一眼,转头盯树,和四年以来的每天一样。 </p>
<p>女人,三十几, 脸色苍白,唱“爱江山更爱美人”, 凄美幽怨,无人言语。</p>
<p>人群后,突然一声嘁笑。 老太婆, 瘦瘦小小,驼背。 也是名人, 病人们被混居在一大房间, 每当深夜,若你被悉悉索索的声音弄醒, 一睁眼,一定看到的是她, 静静的, 木然的看着你, 她睡不着,喜欢半夜瞎晃。</p>
<p>小伙儿, 二十几,表演武术, 好不容易答应出场, 他被城管吓坏了, 害怕他人关注的目光. 脸被药里激素催肿, 但神情认真。</p>
<p>这一群,似乎遗忘了世界的人,也在庆祝中秋。</p>
<p>愿他们,也能被这世界,温柔以待。</p>
<h2 id="_5">味道<a class="headerlink" href="#_5" title="Permanent link">¶</a></h2>
<p>七月份的一个暴晒下午,法医李雨接到了她的第一次出警任务。</p>
<p>和同事们顶着39度的高温,她带着勘查箱来到犯罪现场:临海河的某片平房拆迁区。</p>
<p>将将走进过道,一股恶臭直冲脑门儿。</p>
<p>即使在专业课学过:尸臭由400多种挥发性有机化合物构成,主要成分是尸胺和腐胺。</p>
<p>但第一次现场闻,还是让李雨受到了冲击:刺鼻又特殊,就像是两万只死耗子堆在她面前。</p>
<p>高度腐败的尸体,盖满了苍蝇和蛆。</p>
<p>队长吩咐大伙儿使用驱虫剂,李雨却“呕”的一声,把午饭一口喷了出来。</p>
<p>尸臭顽固地粘在了她的身上,尤其在出夜警的时候,真实得就像她重新站在那具尸体旁边。
领导看出她心理压力过大,找她谈话:实在不行,可以在合适的时候申请转岗。</p>
<p>就在李雨也觉得自己坚持不下去的时候,事情有了转机。</p>
<p>一个流浪汉被初步判定冻死在他的拾荒窝棚里。</p>
<p>勘验现场,李雨掀开流浪汉身上的层层棉被,熟悉的尸臭味道又来了。
强按下那种恐惧与不适,李雨发现:死者脸上的血痕残存,但创口周围的血迹却被清洗干净,
尸体的衣物还有被轻微动过的痕迹。</p>
<p>她大胆推断:这不是意外,是刑事案件。</p>
<p>果然,进一步化验下,李雨的发现成了破案的关键。</p>
<p>两天之后,嫌疑人被抓捕归案。</p>
<p>看到嫌疑人被送押,尸臭的味道和那背后的恐惧也在这一刻随之而去。
转天,有人报警:信宁大厦发现四具烧焦的尸体。</p>
<p>李雨与同事对望一眼,抓起警帽,快步出发。</p>有关门牙的公开检讨书2017-01-21T00:00:00+08:002020-07-19T11:55:35+08:00Zoom.Quiettag:blog.zoomquiet.io,2017-01-21:/170121-sorry-tooth.html<hr/>
<h1 id="_1">有关门牙的公开检讨书<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<p>老师们,同学们,早上好:
因为,上周我碰掉 杜徵 同学的门牙,
所以,今天诚挚的公开检讨.</p>
<p>上周三,下了雪 …</p><hr/>
<h1 id="_1">有关门牙的公开检讨书<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<p>老师们,同学们,早上好:
因为,上周我碰掉 杜徵 同学的门牙,
所以,今天诚挚的公开检讨.</p>
<p>上周三,下了雪,雪很大,在操场上很快积了很厚一层.
所以,课间,同学们非常高兴的在雪地上玩.
男同学想玩骑马干仗,但是被老师阻止了,因为太危险;
所以,我们开始玩滑雪游戏,
就是摸仿林海雪原中的战士,
只是,因为我们没有工具,自己划不起来,
所以,我们是三人一组,
两个同学,拉一个同学,在雪地上滑起来,
有了速度后再松手,因为惯性原理,所以能滑很长一段距离,
然后,再换人.</p>
<p>但是,轮到滑我时,同学们无意间将我甩向女同学方向,
由于发生的太快,在惯性作用下,我没能及时修正滑行方向,
从侧后方撞倒了两个女同学,
而女同学们很团结,
于是很多女同学围上来理论,
我很快爬起来,但是,已经被高大的女同学们围住了,
我顿时很焦虑,下意识乱挥双手,逃出重围.</p>
<p>在混乱中,无意间碰落了 杜徵 同学的门牙.
虽然当时立即向老师请假,带 杜徵 同学去医院进行了紧急处理,
我也向医生确认了,碰掉的只是乳牙,也刚好到了换牙时期,已经松动,
应该很快就能长出新的门牙,不会影响 杜徵 同学以后出嫁.</p>
<p>但是,面对每天共同学习进步的女同学,
即使是下意识,我也不应该挥拳相向.</p>
<p>所以,我自愿公开检讨,再也不会碰掉女同学的门牙了.</p>
<p>1984年11月11日</p>
<h2 id="_2">嗯哼<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<blockquote>
<p>缘起:
佩哥哥 发起的 "好中文的样子" 写作班微信群中
忽然有学员懊恼:
"我怎么没写专业写检讨的事,多好的题材"
结果引发了众多学员美好的回忆
纷纷表示,都有绝活儿
然后,</p>
</blockquote>
<p>这个我不服,有空咱单挑
………
介个可以有 ﹋o﹋</p>
<p>打落女同学门牙一颗
五百字
小学四年级~</p>
<p>42小时以内~ @宋偲瑄-029
简书上见</p>
<p>就有了这个然后的习作;-)</p>
<h2 id="_3">( ̄▽ ̄)<a class="headerlink" href="#_3" title="Permanent link">¶</a></h2>
<p>以俺求学期间,上百篇各种检讨书/信的经验:</p>
<ul>
<li>态度要诚肯</li>
<li>用辞要书面</li>
<li>语气要平和</li>
<li>细节要充分</li>
<li>理由要科学</li>
<li>责任要撇清</li>
<li>…</li>
</ul>
<h2 id="_4">是也乎<a class="headerlink" href="#_4" title="Permanent link">¶</a></h2>
<ul>
<li>积累 9+30年</li>
<li>酝酿 36小时</li>
<li>一稿 13分钟</li>
<li>再稿 21分钟</li>
</ul>7年2017-01-16T19:42:00+08:002020-07-19T12:19:51+08:00ZoomQuiettag:blog.zoomquiet.io,2017-01-16:/170116-7years.html<h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<div class="highlight"><pre><span></span><code>嗯哼的越来越少
哼唧呢越来越多
牛妞哈越来越闹
家里啊越来越臭
外债喔越来越多
生活呀越来越忙
体重哗越来越多 …</code></pre></div><h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<div class="highlight"><pre><span></span><code>嗯哼的越来越少
哼唧呢越来越多
牛妞哈越来越闹
家里啊越来越臭
外债喔越来越多
生活呀越来越忙
体重哗越来越多
好在
感情哟越来越牢
主要系俺脸皮厚
更加重要的是哈
俺恋爱实在太少
所以啊!
怒力
多多
恋爱
反复
坚定
持久
就是
和你
</code></pre></div>
<p>臭麻麻猪!</p>
<blockquote>
<p>(๑⁼̴̀д⁼̴́๑)干嘛!!</p>
</blockquote>
<h2 id="_1">是也乎<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<p>你猜~何年偶得?</p>简曰三观2017-01-12T00:00:00+08:002020-07-19T11:54:41+08:00Zoom.Quiettag:blog.zoomquiet.io,2017-01-12:/170112-3knows.html<h1 id="-">简曰三观 ;-)<a class="headerlink" href="#-" title="Permanent link">¶</a></h1>
<div class="highlight"><pre><span></span><code>三观者 相依存 弗独生
世界观 乃始发 由世界
推价值 据价值 选人生
行动发 遇挫折 问天地
不自改 托命宿 常人生
恨 …</code></pre></div><h1 id="-">简曰三观 ;-)<a class="headerlink" href="#-" title="Permanent link">¶</a></h1>
<div class="highlight"><pre><span></span><code>三观者 相依存 弗独生
世界观 乃始发 由世界
推价值 据价值 选人生
行动发 遇挫折 问天地
不自改 托命宿 常人生
恨老天 怨气运 三观改
圣人始 若被迫 必疯魔
类电脑 统操作 要升级
必重启 若失败 人格怠
大恐怖 难决心 故常人
终一生 naive 不自量
难改观 终混僵 是也乎
</code></pre></div>最后的协议2016-06-19T21:12:21+08:002020-01-31T16:42:10+08:00Zoom.Quiettag:blog.zoomquiet.io,2016-06-19:/160619-protocol4dying.html
<ul>
<li>来自: <a href="https://www.facebook.com/notes/%E8%91%89%E4%BF%A1%E6%BA%90/%E8%87%A8%E7%B5%82%E5%8D%94%E5%AE%9Aa-protocol-for-dying/10153556546128601">臨終協定(A Protocol for Dying)</a></li>
<li>原文: <a href="http://hintjens.com/blog:115">A Protocol for Dying - Hintjens.com</a></li>
</ul>
<p>(<code>是也乎:</code></p>
<p>ZeroMQ 是最成功的工业化的消息管理平台.
作者能如此平静的离开, 又留下 …</p>
<ul>
<li>来自: <a href="https://www.facebook.com/notes/%E8%91%89%E4%BF%A1%E6%BA%90/%E8%87%A8%E7%B5%82%E5%8D%94%E5%AE%9Aa-protocol-for-dying/10153556546128601">臨終協定(A Protocol for Dying)</a></li>
<li>原文: <a href="http://hintjens.com/blog:115">A Protocol for Dying - Hintjens.com</a></li>
</ul>
<p>(<code>是也乎:</code></p>
<p>ZeroMQ 是最成功的工业化的消息管理平台.
作者能如此平静的离开, 又留下程序猿对生死的分析,
实在太有感动了,
但是,翻译发布在不存在的 fb 上,
所以,顺手复制分享了...
)</p>
<p><a href="https://en.wikipedia.org/wiki/Pieter_Hintjens">Pieter Hintjens</a> 寫於 2016年4月22日11:43分 </p>
<p>我寫最後一篇的時候到了. 如果我有時間處理所有的事情的話或許我會再多寫點,但此後,我得要把注意力放在床上最舒適的姿勢,打止痛藥的時間以及我身邊的人了. </p>
<p>昨天我有十二個訪客,包括我可愛的小孩,你可以想像那是有點虛脫的感覺,絡繹不絕的朋友跟家人,就像一場豪氣十足,熱水無限量供應的泡澡. </p>
<p>我曾經是一個與社會斷絕聯繫又孤單的年輕人,也許有點自閉,心中只有工作,游泳跟幾隻貓. 對於'跟其他人跟在一起會感到快樂'這種想法感到奇怪,不過我的工作還算有點價值,至少我自己是這麼想的. 我們用Cobol寫程式產生器,我寫的編輯器在公司中很快受歡迎,因為它運作的非常好,而且能在我們所有的系統平台上執行. 我自學C跟8086組合語言,還寫過幾個工具性的共享軟體. </p>
<p>久而久之我發現如果跟陌生人交談,任何形式的互動過程(例如買熱狗,雜貨的場合)對方都會愉快地回應,這變成我的藥癮,就像那些喝咖啡慢慢上癮的人一樣. </p>
<p>它逐漸變成基本的,然後又變成我工作的目地:到陌生的地方去見不同的人. 我喜歡參加研討會,因為在那裡找人講話不需要想藉口,每個人都喜歡而且想要講話. 我很少在那裡討論技術性議題. 如果你覺得應該要討論的話,讀程式碼去吧. </p>
<p>因為這樣,這幾十年來我很自豪我的實際工作就是找人講話,聽他們講什麼,跟他們交流,然後綜合起來再分享給其他人. 我總共在歐洲,美洲,非洲與亞洲做了上千場對談,我樂於接受任何人們說我有創意,聰明等等的讚譽. 其實那些我曾參與打造與撰寫的模型或理論,一直都是採擷於現實生活中與其他人的互動. </p>
<p>感謝你們,我的朋友們,因為你們才有那些. 當我說 " 我愛你們 " 時是有言外之意的,可以說其實是你們一直在專業上與知識上灌溉我. </p>
<p>所以,我要寫下這個最後的模型,這次是關於如何面對死亡,我付出一點時間來給大家道破一些直率了當的知識. 這次我寫的不是規格書(RFC; Request for Comments),無法再請大家給意見了 :)</p>
<h2 id="_1">事情是怎麼發生的?<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<p>技術上來講,我所罹患的膽管癌已經轉移到左右的肺部. 從二月份開始乾咳,疲憊感越來越沈重,而且無法再專心工作. 三月份我父親過世我們忙進忙出辦理他的後事時,咳嗽一直跟著我. 四月八日我去找醫生跟她說我很不舒服,她替我安排了緊急的電腦斷層掃描(CAT Scan)跟抽血檢驗. </p>
<p>四月十三日進行可怖的內視鏡及切片,四月十五日作正子斷層掃描(PET Scan),四月十六日本來我打算開車到Eindhoven去NextBuild公司演講,沒去成反而是進了急診室,作切片那一側有劇痛,打了抗生素之後疼痛才感到紓解. 四月十八日腫瘤科醫生確認是癌症轉移,我無法出院得要繼續留下來,我的主治大夫正在考慮要進行怎樣的化療,我罹患的癌症在歐洲病例不多,具體的資料很少. </p>
<p>我們所確知的是膽管癌對化療的反應不佳,再者,我身上這癌症很兇而且移動得很快,第三,身體其它地方(肺部)已經發現有癌症轉移,這些都是清清楚楚的具體資料. </p>
<p>所以,那一天我對外公開了這個訊息,並準備面對死亡. </p>
<h2 id="_2">與臨終者交談<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<p>與臨終者談話可能很艱辛,我們暫時稱他為Bob,其他人稱為Alice,以下幾點是Alice不應該對Bob說的:</p>
<ul>
<li><code>"撐著點!你必須保持希望,你必須擊敗它!"</code> ,你要假設 'Bob已經盡力去擊敗病魔了',這個假設不會錯的,就算他沒有,那也是他的選擇. </li>
<li><code>"好悲慘,我好難過,你不能死"</code>,我女兒曾對我講過這句話,我當時跟她說這是無可爭論的現實,死亡是不允許我們選擇的. 對事實生氣或難過是在浪費時間無法改變事實. </li>
<li><code>"你一定可以打敗它!不試怎麼知道"</code> ,這是Alice在表達她的期望. 錯誤的期望不是治療,好的化療藥劑或者解痛劑,那才是治療. </li>
<li><code>"傳聞有一些實驗性病人被醫好了"</code>,這句話讓我很想拿鎚子,還好對我講這種話的人不多. 就算真有仙丹妙藥,也要考慮費用跟找到它對其他人所造成的壓力,我們大家都知道,找到的機率像中頭彩一樣渺茫,那樣做的話很自私也沒效益. 人之為人,有生有死. </li>
<li><code>"讀聖經第幾章第幾節,會對你有幫助"</code>,這種講法是既魯莽又失禮,再加上愚蠢與傲慢. 如果Bob需要信仰幫忙的話,他自己會去找牧師,如果沒有就是他不想去. 這句話也會讓我想拿鎚子. </li>
<li><code>躡聲躡語吞吞吐吐地探問是一種消極性的騷擾</code>. 讓Bob一再反覆回答一些細微,無聊的蠢問題. 例如'我把你吵醒了嗎',很可能Bob根本沒有心情跟你作無意義的閒聊亂扯,他要麼想要人們親近他,物理性的,要麼跟他講些有趣的事情(下面會講). </li>
</ul>
<p>此外,不要打電話給他然後在電話上哭,如果你感覺快要哭了,先掛斷電話等個十分鐘後再打. 流眼淚不是問題,可是對Bob而言'感受到自己的悲哀'更令他完全陷入無盡的黑暗. 我已經知道該怎麼主導自己的情緒,然而大部分的情況下Bob的心靈還是很脆弱的. </p>
<p>以下是Alice可以對Bob交談,會令他感到快樂的事:</p>
<ul>
<li>曾經一起經歷過的陳年往事. "還記得那時候嗎?","喔!我想起來了,...,真棒!"</li>
<li>診療的細節. Bob現在困在病床上,他經歷林林總總行禮如儀的療程,醫護人員,藥物以及他罹患的疾病等等. 我會立刻靠上前去傾聽Bob跟我分享. </li>
<li>幫忙Bob處理技術性問題(譯註一). 要讓生活井然有序很麻煩,需要人出手相助與心力關照. </li>
<li>假若Bob像我一樣是個作家的話,可以跟他說"我買了你的書"這一類的話,不管是基於阿諛奉承或者真心都能讓Bob會心一笑. </li>
</ul>
<p>還有,除了快樂之外的其他情緒不必透露. 記得,不要給他出新的功課. </p>
<blockquote>
<p>譯註一:可能是指一些無關心理,情緒性層面的事情. 例如跑跑腿買點東西之類,形而下的事情. </p>
</blockquote>
<h2 id="bob">Bob的責任<a class="headerlink" href="#bob" title="Permanent link">¶</a></h2>
<p>不是全部都是Alice的事,在此協定中Bob也有他的責任,至少有以下幾件事:</p>
<ul>
<li>常喜樂. 這點聽起來有迂腐但它是必要的. 如果Bob鬱鬱寡歡,Alice每次跟他講話也會跟著心情沮喪. </li>
<li>無庸置疑,Bob必須把自己的事情處理好. 既然已經預期到來日無多,應該盡力讓自己變得可有可無. 在家庭上,這不可能做到,但是在工作上是做得到的. 我已經被認為會死好幾年了,所以這幾年來我已經把自己從活躍的ZeroMQ社群裡面抽離. </li>
<li>減少所有能減少的壓力跟花費. 例如,比利時可以安樂死,我已經告訴醫生請他們準備了. (不是現在!時機到的時候...)我會請人們當我還活著的時候來道別,不必辦喪禮. 我準備把大體捐給大學,如果他們要的話. </li>
<li>認清現實,願望不是醫療,這點我已經解釋過了. 如果你打算跟你的醫生協商,那麼討論些實用性的,讓其他人都能受惠的議題. 我已經告訴我的醫生,如果他們想在我身上實驗任何化療藥物就儘管去作. 他們獲得了數據,而我起碼也對這個讓我多活了五年以上的醫療系統作點貢獻. </li>
<li>作最壞打算. 我的腫瘤醫師當時一看到我的片子馬上打電話給我,說她研判是癌症. 左右兩邊的肺部都有,處處可見. 我放下電話,告訴孩子,隔天我也把最壞的狀況告訴孩子們的學校,然後是家庭律師,公證人. 十天之後,切片病理檢驗確認是癌症,這額外的十天讓我有時間作準備,也讓我自己有時間替自己感到悲傷. </li>
<li>坦誠,透明地面對其他人. 其他人需要有時間去悲傷,如果他們能在Bob還能講話時跟他討論的話,處理後事相對會簡單得多. 沒什麼好難以啟齒的,死亡並不是失敗. </li>
</ul>
<h2 id="_3">向孩子們解釋<a class="headerlink" href="#_3" title="Permanent link">¶</a></h2>
<p>我的小孩分別是12歲,9歲,5歲. 悲劇啊等等等,沒有父親陪著長大. 這是現實. 他們長大的時候,我活在他們的DNA裡面,活在Youtube上無盡的會議演講裡面,活在我的文章裡面. </p>
<p>這幾年來我已經慢慢地向他們解釋很多遍,終有一天我會走,或早或晚. 每個人都會死,是的,小Gregor,你也是呀. 那是生命的一部分. </p>
<p>小Gregor,想像你有一盒樂高玩具,你拼了一棟房子,留著它又一直繼續拼新的房子,舊的都不拆掉的話會發生什麼事?"盒子會變成空的,爹地",很好,這就對了,那麼你能繼續蓋新房子嗎?"不可以,不行了" . 嗯,我們就像樂高遊戲的房子,死了以後我們會被拆解,就像回到盒子裡,讓新的身體可以被生出來,這就是生死之轉輪. </p>
<p>不過,他們最常看到的是自己的老爸快樂又輕鬆(不是因為止痛劑的緣故),而且好幾個禮拜都感覺蠻正常地在跟他們說再見. 我好感恩沒有突然掛掉,我好感恩沒有像植物人那樣失去心智. </p>
<p>而且我已經告訴我的孩子們要會游泳,騎單車,溜冰跟射擊,要會煮東西,要去旅行,要去露營,要會使用新的科技不必害怕. Gregor三歲的時候就在玩麥塊(Minecraft)左手鍵盤右手滑鼠. Noemie七歲的時候就學會用手槍. 他們會講好幾種語言. 他們有自信而且學得很快,就跟他們老爸一樣. </p>
<p>每個人都應該認識死亡的意義. 構成一個完整的個體的核心之一就是接納自己生命有限的真相. 當然,我們要為活下去打拼,然而當它要成為過去的時候,我們就擁抱這個終點吧. 我很高興自己能把這門功課親自傳授給孩子們,以前從來沒有人會告訴我這些事情. </p>
<h3 id="_4">安樂死<a class="headerlink" href="#_4" title="Permanent link">¶</a></h3>
<p>我很慶幸自己最後還是沒有離開比利時. 這個國家允許臨終或生命品質已經糟糕透頂的病人自主地選擇結束生命. 後者需要經過三個醫師及一個精神科醫師的評估,以及四個禮拜的緩衝期. 若是前者則只須一個醫生的評估意見. </p>
<p>我父親是安樂死的,他選擇在週二復活節,那時我們好幾個家人陪伴他經歷一個簡單又安詳的過程. 第一劑注射讓他進入昏睡狀態,第二劑讓心臟停止跳動. 當時我覺得這樣死法不錯,雖然當時我不知道接著輪到我病了,(總之)安樂死是我已經想過的事. </p>
<p>令我感到震撼的是,都已經是2016年了依然很少國家允許安樂死,強制要求病人承受腐爛的折磨後與無效的急救(譯註二). 安樂死跟癌症特別有關係,因為癌症是主要的死因之一. 如果你所屬選區的民意代表反對的話,請他抽空讓你能跟他遊說一下,關於尊嚴地死亡才是正確的方式這件事. </p>
<blockquote>
<p>譯註二:可能是指因急救過程中,因一再的電擊造成皮膚燒焦或因插管而造成潰爛的情況. </p>
</blockquote>
<h2 id="_5">我對這整件事情的感覺<a class="headerlink" href="#_5" title="Permanent link">¶</a></h2>
<p>我從來不是一個怕事的人. 關於我成為'<a href="http://hintjens.com/blog:21">掠奪者角色</a> (Allen Ding形容得很好的那個)'這件事情,我的死亡大筆一揮讓我能淡然面對它在事業與社會上所產生的風險,也讓我們能夠在'權力遊戲 Game of Thrones'計畫結束後淡定下來. 那從來不是真正的我,只是恰巧在那個時間,那個地點我扮演了那個必須讓事情繼續運作下去的角色. </p>
<p>準備了多年好去面對這一切,親眼目睹數個精心籌劃的計畫同步進行的壯觀場面,讓我深深感到心滿意足. 從2011年開始我成為手槍射擊專家,自學彈鋼琴(還自編了幾段小曲),能親眼見到自己的小孩長成具有快樂,朝氣蓬勃的性格,寫了三本書,還指導ZeroMQ社群能具備穩重可靠的特質. Bob如我,夫復何求?</p>
<p>這裡的醫護人員很親切,我沒有任何抱怨,我只有感恩所有的朋友,這幾年來你們帶給我歡樂,也感謝那些維持我性命跟活力的藥物. </p>
<p><code>謝謝你們 ! :)</code></p>
<h1 id="_6">替孩子們著想<a class="headerlink" href="#_6" title="Permanent link">¶</a></h1>
<p>請用這篇文章來增添你的故事. 如果你把故事寫在別的地方或曾經Email給我的話,請複製/貼上在本篇下方的評論(Comments)上. 你想要寫荷蘭文或法文的話,請便,如果那是你使用的語言. 我想讓孩子們從一個地方就可以知道他們的父親在別人口中是怎樣的人,這樣會比較好.
許多想捐點給錢幫助孩子們的人在問我的Paypal帳號是: ph@imatix.com . </p>
<h1 id="_7">譯文結束<a class="headerlink" href="#_7" title="Permanent link">¶</a></h1>
<p>Pieter Hintjens 的參考資料:</p>
<ul>
<li><a href="https://en.wikipedia.org/wiki/Pieter_Hintjens">Wikipedia上關於Piter Hintjens 的條目</a></li>
<li><a href="http://hintjens.com/">hintjens.com</a> 部落格</li>
<li><a href="http://hintjens.com/blog:74">"Living Systems" 活生生的系統. </a></li>
<li><a href="http://zeromq.org/">ZeroMQ自由軟體計畫</a><ul>
<li><a href="http://rfc.zeromq.org/">ZeroMQ相關的通訊協定與規格</a></li>
<li><a href="http://theedg.es/">edgenet project</a> 這個計畫要建構完全安全但匿名的P2P網路</li>
<li><a href="http://shop.oreilly.com/product/0636920026136.do">"ZeroMQ - Messaging for Many Applications" (O'Reilly)</a></li>
</ul>
</li>
<li><a href="http://cultureandempire.com/">"Culture and Empire: Digital Revolution"</a>.(Gitbook 電子書)</li>
<li><a href="http://psychopathcode.com/">The Psychopath Code</a> 最近的著作(Gitbook 電子書)</li>
<li><a href="http://scalable-c.com/">"Scalable C"</a> 撰寫中(Gitbook 電子書)</li>
</ul>
<h2 id="_8">譯後語:<a class="headerlink" href="#_8" title="Permanent link">¶</a></h2>
<p>這篇文章的內容涉及面對臨終者的態度,生死事大,如果譯文有錯誤的地方,非常歡迎告訴我修正. </p>
<p>我們都有機會面對臨終者,遲早有一天我們也都會成為臨終者,然而在成長過程中很少有機會學習如何地去面對臨終相關問題,如果因為無知而犯錯,將會是無法彌補的,一輩子都會在良心上感覺到虧欠. </p>
<p>我翻譯這篇文章,並非主張本協定的內容可以完全原封不動地套用到每一個個別的情境. 不僅是文化差異而已,甚至不同的家庭,臨終者的性格特質,彼此的角色等等都需要列入考量(例如關於提起聖經章節這一件事),這個議題是沒有SOP的,每個個案都有屬於該個案當下的協定. 如果是家屬或者病患本人,或許可以向醫院的社工師作相關諮詢. </p>
<p>雖然具體的行動要因人,因事,因地制宜,然而,我相信這份協定的內容在原則層次是跨越文化而共通的,例如,雙方都有責任與義務坦然面對臨終這件事,以及人應該有選擇死得有尊嚴的權利,還有那些從臨終者角度出發的觀點所象徵的尊重臨終者主觀意願的態度,都是很有價值的觀點. </p>
<p>Google一下就可以發現台灣已經有很多人在倡導與臨終,安樂死相關的理念,值得我們向她/他們致敬,但我相信他們的努力還沒有受到應有的重視,對於這個議題,我們還有很多要努力的地方. </p>[大妈吐糟]Tower 之功能残念集2015-06-04T19:42:00+08:002020-07-19T12:19:44+08:00ZoomQuiettag:blog.zoomquiet.io,2015-06-04:/150604-chaos-tower.html<h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<blockquote>
<p>[大妈吐糟]Tower 之功能残念集</p>
</blockquote>
<h1 id="_1">背景<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<ul>
<li>在遥远的过去, Tower 刚刚发布时,就注册试用过...无感</li>
<li>在某个社区掺合折腾时,被指定使用 Tower …</li></ul><h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<blockquote>
<p>[大妈吐糟]Tower 之功能残念集</p>
</blockquote>
<h1 id="_1">背景<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<ul>
<li>在遥远的过去, Tower 刚刚发布时,就注册试用过...无感</li>
<li>在某个社区掺合折腾时,被指定使用 Tower</li>
</ul>
<h1 id="_2">过程<a class="headerlink" href="#_2" title="Permanent link">¶</a></h1>
<ul>
<li>于是各种坑</li>
<li>于是找到了 <code>@mycolorway.com</code> 内部关系,抓住接口人批量反馈</li>
<li>然后,没有了然后</li>
<li>今天见到推送硬广: <a href="http://mp.weixin.qq.com/s?__biz=MjM5NDY2NDM4Mw==&mid=234095089&idx=1&sn=158f84a3d329647ce6a470aa7ccf7abe&key=c468684b929d2be2db431d557f2a04cff3bbf4c4c6e4745da3e8bb4cdb32a1babf3ef1a2f9908ad3c63e48c930f7e35e&ascene=0&uin=MTg1NDU4NTY4MQ%3D%3D&devicetype=iMac+MacBookPro8%2C2+OSX+OSX+10.10.3+build(14D136)&version=11020012&pass_ticket=bLSHZyAYyQPXsSPxVnBLhpNx61u393uer5yckacn0%2ByWRINStKhBC0qoXpOSFlMp">「天涯若比邻」如何用 Tower 远程协作开发产品</a></li>
<li>以及专辑: <a href="http://www.jianshu.com/collection/0f5b8cd75ccf">Tower - 专题 - 简书</a></li>
<li>实在无法保持沉默... </li>
</ul>
<p>俺的环境:</p>
<ul>
<li>MAC O X 10.10.2</li>
<li>FireFox 36.0.4</li>
</ul>
<h1 id="s">糟点s<a class="headerlink" href="#s" title="Permanent link">¶</a></h1>
<h2 id="150331">150331<a class="headerlink" href="#150331" title="Permanent link">¶</a></h2>
<p>~有两点无法忍的问题:</p>
<ul>
<li>既然文档的起草可以选择 富文本和 markdown 格式<ul>
<li>为毛,其它各种场景中的评注/讨论/回复</li>
<li>不能支持 markdown 呢?</li>
</ul>
</li>
<li>文档当前是我们主要的协调/输出/产出 工件<ul>
<li>但是,竟然不支持多种排序</li>
<li>也不支持分目录管理</li>
<li>实在对文档加目录复杂的话,给 tag 也是个维度哪!</li>
</ul>
</li>
<li>而且,既然有 文件空间,<ul>
<li>为何不能为 markdown 格式的文档提供图片自动上传到文件目录的支持?</li>
<li>这样就不用四处折腾先发布图片再嵌入 markdown 文本了哪</li>
</ul>
</li>
</ul>
<blockquote>
<p>另外,你在文档的标题上添加 #标签# 也能对文档进行分类管理。不过,确实目前还不能对文档进行排序。</p>
</blockquote>
<p>嗯啍! 这个技巧非常好哪, got it ! 加入团队文档管理规约;
不过,这也引发另外一个不能忍:</p>
<ul>
<li>在文档的各种视图中</li>
<li>无论列表还是封面形式文档的链接都不是规范的</li>
<li>而是包含了一定正文内容的,比如说:</li>
</ul>
<blockquote>
<p>Info 鳮汤桶 # 现象 学员 1/3 一直处在桑心状态 # 分析 - 因为负基础,纯小白 - 没有自信 - 没有从开始获得正反馈 #
方案 - 学员自身也要求定期打鳮血 - 所以,在每日小报/163任务 辅助资料/列表中... - 都追加编程小故事 ## 鳮汤 ~
收集池,如果已经使用,请在头部注明在哪儿用过 - <code>150329 Week2 QA</code> Google 是两位创始人在4周里用 Python
完成的原型 - <a href="http://www.douban.com/note/491382194/">说走咱就走啊,天上的星星参北斗啊:Python之中国自驾游线路优化</a>
- <a href="http://www.guokr.com/blog/432591/">漫谈编程语言 Python .</a> - <a href="http://www.zhihu.com/question/21395276">可以用 Python
编程语言做哪些神奇好玩的事情?</a> -
<a href="http://www.jianshu.com/p/ec35c27f01b9">人生苦短,快用python.</a> ... Zoom.Quiet
5分钟前
https://tower.im/projects/61627695a74b444aa975a601e50ef6e7/docs/37f965c5b7804ae4823b4c2430d5b010</p>
</blockquote>
<p>这种链接,用浏览器工具,自动生成 md 链接是不可用的,
进一步的:</p>
<ul>
<li>在文档的具体页面中</li>
<li>页面的 title 也是不完整的,比如</li>
</ul>
<blockquote>
<h1 id="task-tower">TASK# ... - Tower<a class="headerlink" href="#task-tower" title="Permanent link">¶</a></h1>
<div class="highlight"><pre><span></span><code>https://tower.im/projects/61627695a74b444aa975a601e50ef6e7/docs/290f336fc10b441fb51c5bd522eaf36d/
</code></pre></div>
</blockquote>
<p>而明明此文档的标题是</p>
<div class="highlight"><pre><span></span><code>#TASK# OMOOC.py 学员预期管理
</code></pre></div>
<p>一点儿也不长</p>
<p>俺的建议是,既然包含了 md 格式的支持,
那么就应该从一个重度 md 用户的角度出发自,真正优化内部链接形式</p>
<p>PS:
如附件, 使用了你提醒的 标题 TAG 技巧后,
文档列表破行!</p>
<p><img alt="屏幕快照 2015-03-31 17.10.03.png" src="http://upload-images.jianshu.io/upload_images/27562-65ad1211eb6c0e8d.png"></p>
<h2 id="150401">150401<a class="headerlink" href="#150401" title="Permanent link">¶</a></h2>
<p>如截屏</p>
<p><img alt="屏幕快照 2015-04-01 20.45.18.png" src="http://upload-images.jianshu.io/upload_images/27562-4594aef5eeefaa0d.png"></p>
<p>经提醒,我们注意到 Tower 文档竟然有文档修订历史以及可视化对比的功能!</p>
<p>但是,异常期待有一个改进:</p>
<ul>
<li>如附件截屏 视图中</li>
<li>如果能将修订变更的字数/行数直接显示在版本行中,对团队有更大的提示!</li>
<li>否则,我们得逐一点击,并上下拖拉,才能发现修订之处</li>
<li>注意!<ul>
<li>随着文档的大规模使用</li>
<li>文档是能轻松突破300行,5屏以上的!</li>
</ul>
</li>
<li>进一步的:<ul>
<li>不应该在对比视图中显示全文</li>
<li>用颜色来标标识修订行为</li>
<li>这明显是对 Word 修订模式的无脑复刻!</li>
<li>我们是 Tower 文档,不是 Office 在线哪!</li>
</ul>
</li>
</ul>
<p>所以,俺建议:</p>
<ul>
<li>文档 修改历史 界面中</li>
<li>每行后面追加 修订字数,变更行数</li>
<li>点击进入后,是 diff 格式,类似: <a href="https://gitcafe.com/wiki4zq/markdoc4zq/commit/4e5f200e2a4d2d493e1cf88c0403b63469081dd5">appended YC 7.8 · 4e5f200e -
GitCafe</a></li>
</ul>
<p>再进一步的:</p>
<ul>
<li>如果文档,能提供每个项目一个文档 git 仓库</li>
<li>来给高级团队通过 git 仓库进行分布式快速修订</li>
<li>类似 github-wiki 的交互流程</li>
<li>那就太赞了!</li>
</ul>
<h2 id="150402">150402<a class="headerlink" href="#150402" title="Permanent link">¶</a></h2>
<p>~ 如截屏</p>
<p><img alt="INFO 鳮汤桶 Tower.png" src="http://upload-images.jianshu.io/upload_images/27562-08b29209611e6df4.png"></p>
<ul>
<li>现象: 团队中常用文档,稍微一积累,就超过3屏以上!</li>
<li>问题: 导致无法很快的跳转到合理的位置使用内容!</li>
<li>建议: 追加浮动 TOC !<ul>
<li>不用在 md 格式中嵌入 <code>[TOC]</code> 锚点</li>
<li>直接在渲染引擎中追加!</li>
<li>自动对 H1~3 的正文内容构建浮动的标题索引</li>
<li>并追加跳到底部评注讨论区的索引</li>
</ul>
</li>
<li>进一步的:<ul>
<li>文档创建/修订信息, 已经在相关子页面包含了</li>
<li>就不应该在底部评注区详细列出</li>
<li>应该进行相似修订记要的折叠处理</li>
</ul>
</li>
</ul>
<h2 id="150403">150403<a class="headerlink" href="#150403" title="Permanent link">¶</a></h2>
<p>今天进行多个文档编辑时,又发现一个问题:</p>
<ul>
<li>Tower 中编辑文档是弹出新页面:<ul>
<li>完成编辑后,点击,当前编辑页面消失,焦点回到哪个页面就是天知道了</li>
</ul>
</li>
<li>这不科学!反人性!<ul>
<li>参考 简书/github/medium/.... 的编辑流程?!</li>
<li>不能因为国人网站为了流量,拼命加开页面</li>
<li>Tower 也这么来哪!</li>
</ul>
</li>
</ul>
<h2 id="150408">150408<a class="headerlink" href="#150408" title="Permanent link">¶</a></h2>
<p>因为很多事务性文案,在 文档 中起草时,
其实都是在原先基础上增减的,
所以:</p>
<ul>
<li>文档应该有 复制为 功能</li>
<li>或是提供模板功能也好</li>
<li>类似 moinmoin 的特殊前缀文章视为模板,</li>
<li>在创建新文章时,可以从模板列表中选择使用哪种模板</li>
<li>这样有利于团队内部形成良好的文档一致性习惯</li>
</ul>
<p>实话讲, Tower 现在文档所有引发的不适,都是因为和现有 类似 团队文档工具的体验差异引发的!</p>
<ul>
<li>gitbook 根治所有毛病!</li>
<li>建议内建 gitbook 引擎</li>
<li>给高级团队一个 git 仓库,自动响应 push 行为,编译发布内部 gitbook 图书!</li>
</ul>
<p>很久以来, Tower 的链接设计是俺最无法理解的一个 非功能设计:</p>
<p>https://tower.im/projects/61627695a74b444aa975a601e50ef6e7/docs/6654630279f743a8972b6869cf9ea89d/</p>
<p>是的, 61627695a74b444aa975a601e50ef6e7 是我们项目名的 hash 值,另外的也看的出来,
但是,这样的 URI 对使用者而言是什么感觉呢?!
无视我们的存在哪,,,
请观察其它所有同类服务的 URI, 都是类似:</p>
<ul>
<li>[项目名].tower.im//docs/[关键字]-[短hash]</li>
<li>一般都在80个字符以内的,比如: https://techparty.hackpad.com/150310-Mini.0-c1xxk56HsTt</li>
</ul>
<p>所以,请改进吧, 为了大家喜欢上 Tower</p>FW/Code 2048 用户使用协议2015-06-04T19:42:00+08:002020-07-19T12:19:48+08:00ZoomQuiettag:blog.zoomquiet.io,2015-06-04:/150604-code2048.html<h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<h1 id="fw-code-2048">FW: Code 2048 用户使用协议<a class="headerlink" href="#fw-code-2048" title="Permanent link">¶</a></h1>
<ul>
<li>来自 <a href="https://code2048.com/topic/3/code-2048-%E7%94%A8%E6%88%B7%E4%BD%BF%E7%94%A8%E5%8D%8F%E8%AE%AE?from=timeline&isappinstalled=0">Code 2048 用户使用协议 | Code 2048</a></li>
</ul>
<p>一般用户协议(所谓TOS)是一份专业到看不懂的法律文件,但那没意义 …</p><h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<h1 id="fw-code-2048">FW: Code 2048 用户使用协议<a class="headerlink" href="#fw-code-2048" title="Permanent link">¶</a></h1>
<ul>
<li>来自 <a href="https://code2048.com/topic/3/code-2048-%E7%94%A8%E6%88%B7%E4%BD%BF%E7%94%A8%E5%8D%8F%E8%AE%AE?from=timeline&isappinstalled=0">Code 2048 用户使用协议 | Code 2048</a></li>
</ul>
<p>一般用户协议(所谓TOS)是一份专业到看不懂的法律文件,但那没意义。这里没有复杂到看不懂的东西,只是一些简单的规则。</p>
<ul>
<li>这是扩展自《神秘的程序员们》系列漫画的讨论区。主要话题包括程序员漫画相关讨论、所有技术相关话题及互联网、创业、项目管理、设计、产品、职业和职场、科幻、游戏话题。</li>
<li>在这些话题之外的内容,可能会不受欢迎,或被移出主要讨论区甚至直接删除,并且有可能导致相关帐号被封。</li>
<li>保持礼貌,禁止人身攻击/种族/地域/宗教/职业歧视之类令人不快的内容。</li>
<li>禁止发布违法内容。违法的定义:目前本站位于美国加州,请遵守美国互联网相关法律法规。包括但不限于“COPPA“、“DMCA”等。服务器所在国家的变化会导致“违法”定义发生变化,但变化之前会在主要讨论区明显位置通知即将发生的改动。</li>
<li>禁止一切干扰用户正常阅读的行为,包括但不限于利用系统Bug发布破坏格式,大量重复内容,对用户浏览器造成伤害等行为。</li>
<li>所有禁止类内容会被直接删除,并且有可能导致相关帐号被封。</li>
<li>请使用投票功能(每个主题的右上角的箭头图标)来表达支持和反对,不用简单回帖”顶“、”支持”,本站设置最少发帖内容长度是8个字。</li>
<li>考虑微信登录等需要已备案网站,未来本站存在转移到中国大陆的可能性,转移之前会在主要讨论区明显位置另行通知。这种情况发生时,可能会导致本站部分内容被删除。</li>
<li>欢迎转贴你喜欢的,符合本站主要讨论话题的内容。任何转贴必须保留原始链接和原始作者,如果可以取得原著作权人授权,可以转贴全文以方便阅读。在不能取得授权的情况下,只允许转贴链接供讨论。位于访问困难或可能消失的网站内容,允许做为特殊例外情况直接转贴全文,但如果著作权持有人要求删除,本站会立即删除相关内容,只保留链接。</li>
<li>禁止用发帖的方式发布一切"硬广告"。但如果专门为本站用户制作的广告,让本站用户感觉有趣,精彩,愉悦或者赠予本站用户特殊权利、利益,并且因此得到本站用户欢迎,就会被当作正常发布的内容允许存在。</li>
<li>和大多数网站不同,本站不要求获得用户创造内容的"非独占性、全球性、永久性、不可撤回"的权利。在本站,用户创造内容的全部权利仍然属于用户本人,发表于本站只意味着用户授权本站发表。用户随时有权利删除,撤回,修改自己发布过的内容。不过考虑到内容的历史意义和讨论价值,本站希望在正常情况下,用户发表之后的内容尽量不要被大量修改或删除。</li>
<li>本站内容禁止其他任何媒体、网站通过数字及非数字形式转载,除非获得作者直接授权。如果用户提出协助要求,本站愿意尽一起努力帮助用户维护著作权。</li>
<li>本协议随时有可能修改,但任何修改都会在主要讨论区明显位置给予提示。如果用户不同意修改,可以停止使用本站服务并且删除自己的帐号和发表过的内容。否则视为同意协议内容。</li>
</ul>
<h2 id="_1">是也乎,( ̄▽ ̄)<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<p>很明显, 2048 以及西乔,并不是想作中国的 XKCD ,
而是想走出自个儿的话题文化来.</p>
<p>支持,以及坚持吐糟,吐有品质的糟!</p>14小时反省分析2015-05-14T19:42:00+08:002020-07-19T12:19:40+08:00ZoomQuiettag:blog.zoomquiet.io,2015-05-14:/150514-14hourstory.html<h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<h1 id="14">14小时反省分析<a class="headerlink" href="#14" title="Permanent link">¶</a></h1>
<p>~ 记录一次失败的神烦</p>
<h2 id="_1">事发现场<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<p>大妈整理了我的草案然后发布到zhgdg的wiki,接着填坑时间到 :) </p>
<p>大妈说这个坑是: </p>
<ul>
<li>规章文案中都 …</li></ul><h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<h1 id="14">14小时反省分析<a class="headerlink" href="#14" title="Permanent link">¶</a></h1>
<p>~ 记录一次失败的神烦</p>
<h2 id="_1">事发现场<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<p>大妈整理了我的草案然后发布到zhgdg的wiki,接着填坑时间到 :) </p>
<p>大妈说这个坑是: </p>
<ul>
<li>规章文案中都有的元素 </li>
<li>GitHub上Fork数超过的100的项目的README中可以找到的 </li>
<li>要给大家共同完善的流程 </li>
</ul>
<h2 id="_2">折腾过程<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<ul>
<li>Google规章文案要素 </li>
<li>浏览了zhgdg在Gitcafe上的README文档 </li>
<li>浏览了十几个Fork超过一千的Github开源项目的README文档 </li>
</ul>
<h2 id="_3">思想斗争<a class="headerlink" href="#_3" title="Permanent link">¶</a></h2>
<ul>
<li>显然看到了每个项目都有明显的Overview,于是自觉添加 </li>
<li>看到每个项目的README结尾都有license,添加? </li>
<li>想到这是一份类似教程的文档,那么必须图文并茂? </li>
<li>既然是教程,那么就要有一些FAQ的解答? </li>
<li>想到让大家可以来修订,Github地址已放出,专用邮件列表地址也已放出,大家有什么反馈的应该都能找到道,放弃. </li>
</ul>
<p>以上↑是痛苦的思想斗争,无比纠结 </p>
<h2 id="_4">大妈解救<a class="headerlink" href="#_4" title="Permanent link">¶</a></h2>
<p>于是大妈看不下去了 XD </p>
<ul>
<li>痲婷你要逐一剖析你的思维盲点,每一点都要引发思考 </li>
<li>痲婷你书看的太少了,从来不为他人着想 </li>
<li>痲婷你女票谈的太少的,要多谈(根本没谈) </li>
<li>痲婷我不能再提示更多了 XD </li>
<li>这是一个提供大家共同完善的流程,那么大家如何共同完善? </li>
</ul>
<p>于是顿悟,妈蛋不就是被我忽略的FeedBack么?-.- </p>
<h2 id="_5">事后烟<a class="headerlink" href="#_5" title="Permanent link">¶</a></h2>
<ul>
<li>没错,经历了让自己反省的事件时候,要先吸根事后烟冷静一下 </li>
<li>其实这事儿,只能说我没有真正地去写过一份README文档,或者说我没有真正地参加过开源项目流程 </li>
<li>还有就是大妈所说:图样图森破,没有从更高的角度去思考一个问题,如果一篇文章放到别的地方而不是Github呢?为何不提供一个完整反馈方式呢? </li>
<li>这思维方式的问题,没法一时就解决哪,只能说不断地戳,不断地反省吧.... </li>
</ul>
<p>这事儿,也不能怪没有女票,只能怪没EQ. 因为没EQ导致没女票,没女票导致没EQ,嗯. . . </p>
<h1 id="_6">是也乎,( ̄▽ ̄)<a class="headerlink" href="#_6" title="Permanent link">¶</a></h1>
<p>事件的根源是这样的:</p>
<ul>
<li>有位很上进的珠海在校美少年,上门来求虐</li>
<li>于是,给了个任务: 48 小时里给出一份可用可传播的开源社区式任务说明书</li>
<li>然后,没有了然后,各种纠结,不知所言</li>
<li>于是, 好心写了个框架, 留了个扣儿<ul>
<li>要求, 14 小时里找到并 fixed 这个扣儿</li>
<li>然后, 就有以上的然后了</li>
</ul>
</li>
<li>其实,根本原因在:<ul>
<li>几乎不可能让一位从来没有作过菜的好人</li>
<li>当场折腾出一个能令岳母基本满意的席面儿来</li>
<li>无它, 根本对任务理解不能哪...</li>
<li>人家考的不是你的厨艺,而是看你是否有意识来尊重未来的领导...</li>
<li>嗯啍?! 好象又偏离了,,,</li>
</ul>
</li>
<li>总之:<ul>
<li>一篇</li>
<li>可用的</li>
<li>可传播的</li>
<li>可持续改进的</li>
<li>文档!</li>
<li>从宏观上看只应该有最小内容核心者三:<ul>
<li>为毛</li>
<li>怎么作</li>
<li>怎么共同改进</li>
</ul>
</li>
</ul>
</li>
</ul>[大妈吐糟] 虾米音乐的系列猜想2015-02-05T19:42:00+08:002020-07-19T12:19:35+08:00ZoomQuiettag:blog.zoomquiet.io,2015-02-05:/150205-chaos-xiami.html<h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<blockquote>
<p>[大妈吐糟] 虾米音乐的系列猜想</p>
</blockquote>
<ul>
<li>原发: <a href="http://segmentfault.com/blog/zoomquiet/1190000002538467">[大妈吐糟] 虾米音乐的系列猜想 - SegmentFault</a></li>
</ul>
<p><img alt="吐糟,忍受不能的吐糟..." src="http://img1.gtimg.com/digi/pics/hv1/227/104/1364/88720847.jpg"></p>
<h1 id="_1">背景<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<p>习惯泛听的<code>专辑顺序强迫症重症患者</code>!</p>
<ul>
<li>喜欢 …</li></ul><h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<blockquote>
<p>[大妈吐糟] 虾米音乐的系列猜想</p>
</blockquote>
<ul>
<li>原发: <a href="http://segmentfault.com/blog/zoomquiet/1190000002538467">[大妈吐糟] 虾米音乐的系列猜想 - SegmentFault</a></li>
</ul>
<p><img alt="吐糟,忍受不能的吐糟..." src="http://img1.gtimg.com/digi/pics/hv1/227/104/1364/88720847.jpg"></p>
<h1 id="_1">背景<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<p>习惯泛听的<code>专辑顺序强迫症重症患者</code>!</p>
<ul>
<li>喜欢复合类型的音乐,追踪创作型音乐人/团队</li>
<li>只听专辑,而且一定要按顺序来听</li>
<li>习惯根据当前心态快速形成有针对性的播放列表</li>
</ul>
<p>音乐历史:</p>
<ul>
<li>从有条件配置录音机开始</li>
<li>上百盒带,几百CD,MP3CD</li>
<li>硬盘常备 30G+ APC</li>
<li>以往移动音乐习惯:<ul>
<li>iOS 用 podcast 下载有关频道的音乐</li>
<li>Android 用自行上传的音乐,以 <code>类别/音乐人/专辑</code> 为目录形式组织</li>
<li>用内置播放器以目录为线索播放</li>
<li>管理/播放 流程继续电脑中 <a href="http://cmus.github.io/">cmus</a> 的习惯</li>
</ul>
</li>
<li>为制作 <a href="http://momoko.in/family/family-timeline.html">大小丸子🐒:"情人节快乐;-)"</a> 才知道 xiami <ul>
<li>变成移动音乐主力陪伴平台</li>
<li>下载过 900+ 专辑</li>
<li>播放 20000+ 首音乐</li>
</ul>
</li>
</ul>
<h1 id="_2">现象<a class="headerlink" href="#_2" title="Permanent link">¶</a></h1>
<p>实际上定心使用 xiami 音乐应用,也经过了很长时间的折腾:</p>
<ul>
<li>从 Play 市场上安装了所有高分音乐播放器, 没有一个超过 winamp 的尿性</li>
<li>从 碗豆茄 下载安装了所有高分音乐应用, 发现都一个尿性:<ul>
<li>在播放界面中没有当前播放列表的快速入口</li>
<li>播放清单界面没有专辑封面缩图</li>
<li>无法从当前播放快速进入 专辑/艺人/相关艺人 页面,并进行快速下载</li>
<li>只有乱序播放,没有顺序播放的快捷方式</li>
<li>...</li>
</ul>
</li>
<li>相比下来,只有 xiami 还能忍受</li>
<li>但是,当本地音乐 下载3000+音乐, 艺人超过5屏,专辑超过100时</li>
<li>各种杯具开始了:<ul>
<li>下载/播放/删除 同时进行时,闪退</li>
<li>任何界面中,批量删除时,闪退, 恢复时总是删不干净</li>
<li>经常专辑/艺人封面丢失, 一片空白无法要求强行同步/重新下载</li>
<li>批量操作,经常定住,无反应</li>
<li>每次启动,进入本地音乐界面时,有一定比例闪退</li>
<li>每次启动进入本地音乐时, 每次都要消耗几十秒重新加载</li>
<li>...</li>
</ul>
</li>
</ul>
<h1 id="_3">问题<a class="headerlink" href="#_3" title="Permanent link">¶</a></h1>
<p>基本上,俺对手机上的音乐品质已经不报希望了,
只要求:</p>
<ul>
<li>可以快速选中想听的艺人</li>
<li>能快速追加其它下载的指定艺人所有专辑到当前播放清单中</li>
<li>快速按照下载的专辑以及专辑内顺序依次播放</li>
</ul>
<p>但是,以上三个基本需求,无一能在当前已知所有移动播放器中作到:</p>
<ul>
<li>选择艺人, 只有 Google Play音乐 基本作到舒心了:<ul>
<li><img alt="150205-gplayer-lib.png(PNG 图像,370x489 像素)" src="http://zoomq.qiniudn.com/ZQCollection/snap/150205-gplayer-lib.png"></li>
<li>点击进入 <code>我的乐库</code> 优先进入 音乐人, 而不是 其它 tab</li>
<li>所有卡片用的是现有专辑的拼贴</li>
<li>杯具的是, 从本地导入音乐的过程,以及目录 是无法控制的</li>
<li>如果通过其它应用删除了相关音乐, GPlayer 是不知道何时能更新的</li>
</ul>
</li>
<li>快速根据需要组合出当前播放清单, 没有应用能满足:<ul>
<li>多数强行要求创建 播放列表/精华 没有7次以上的操作不可能完成</li>
<li>xiami 还限定只能有 50 首音乐的上限制</li>
<li>这就很杯具了: 俺播放本地的音乐,为毛要限制俺的 playlist 长度?!</li>
</ul>
</li>
<li>按照一张专辑接一张专辑,音乐依从专辑原有顺序播放<ul>
<li>这应该是最吻合音乐人当初创意的音乐收听顺序了</li>
<li>但是,这竟然成为所有 音乐类应用 最不愿意实现的功能?!</li>
<li>为什么呢?! 细思恐极....</li>
</ul>
</li>
</ul>
<h2 id="_4">分析<a class="headerlink" href="#_4" title="Permanent link">¶</a></h2>
<h3 id="mp3-meta">MP3 meta信息<a class="headerlink" href="#mp3-meta" title="Permanent link">¶</a></h3>
<p>参考:</p>
<ul>
<li><a href="http://tools.ietf.org/html/rfc3003">RFC 3003 - The audio/mpeg Media Type</a></li>
<li><a href="http://tools.ietf.org/html/rfc3119">RFC 3119 - A More Loss-Tolerant RTP Payload Format for MP3 Audio</a></li>
<li><a href="http://en.wikipedia.org/wiki/ID3">ID3 - Wikipedia, the free encyclopedia</a></li>
<li><a href="http://en.wikipedia.org/wiki/MP3#ID3_and_other_tags">MP3 - Wikipedia, the free encyclopedia</a></li>
<li>...</li>
</ul>
<p>从 mpeg-1 时代开始, 音乐文件中就已经能包含完备的专辑/艺人/播放顺序 的信息!</p>
<h3 id="_5">但是!<a class="headerlink" href="#_5" title="Permanent link">¶</a></h3>
<p>xiami 也好,其它音乐应用也好, 走的都是 ucg 模式,以便避开版权纠纷;</p>
<ul>
<li>这就导致各家音乐库中的音乐文件本身 meta 信息混乱/不全</li>
<li>进一步的,为了避免在移动设备上进行大量的目录操作, 大家都将下载文件放在一个目录中</li>
<li>更加可悲的, 为了快速开发使用 SQLite 来管理所有音乐 meta 信息</li>
<li>综上, 导致了:<ul>
<li>无法合理的触发 下载/meta提取/刷新/使用 时机</li>
<li>人为形成多重等待</li>
<li>并在错误的信息基础上,几乎无法进行合理的控制识别</li>
</ul>
</li>
<li>最终形成类似情景:<ul>
<li><img alt="150205-xiami-local-chaos.jpg(JPEG 图像,720x1280 像素) - 缩放 (59%)" src="http://zoomq.qiniudn.com/ZQCollection/snap/150205-xiami-local-chaos.jpg?imageView2/2/w/360"></li>
<li>根据音乐人信息, 从专辑列表,下载多个专辑后</li>
<li>在音乐人界面, 看到的就是这种专辑顺序混杂的情景</li>
<li>实际播放时,可以想象是多么难受的事儿</li>
</ul>
</li>
<li>xiami 中还有一个诡异的现象是:<ul>
<li>即使相关专辑都下载到了本地</li>
<li>但是,在一个专辑播放过程中</li>
<li>动态的从其它本地专辑界面,点击加入当前播放列表后</li>
<li>当播放追加专辑音乐时, xiami 不从本地播放,而是无视音乐已经下载的状态,尝试从网络中下载播放!</li>
<li>这得是什么样的脑洞经理,才作的出这种产品决策呢...</li>
</ul>
</li>
</ul>
<h1 id="_6">建议<a class="headerlink" href="#_6" title="Permanent link">¶</a></h1>
<ul>
<li>基于用户上传的音乐文件表直接使用:<ul>
<li>根据官方的信息, 在服务端统一刷一下 meta 信息吧</li>
<li>并将相关 meta 信息,独立保存一下</li>
<li>在其它用户下载音乐文件的同时, 直接向客户端 push 对应的meta 信息, 就别生从本地文件中再遍历读取了吧</li>
</ul>
</li>
<li>下载/管理/播放, 用多线程/进程来处理吧<ul>
<li>最简单的,别将 meta 信息和其它控制信息放在同一 DB 中哪</li>
</ul>
</li>
<li>SQLite 这货就是单用户单线程最轻量级DB<ul>
<li>对于这种专辑信息,又不涉及交叉关系索引</li>
<li>就是用个内存 KV 效率也比用 SQL 高哪</li>
</ul>
</li>
</ul>
<p>总之, 亲, 大家喜欢 xiami 的音乐库, 努磨 SD 卡拼命下载了几千音乐到本地了</p>
<p>就让俺们愉快的自由播放 ,不好嘛?!</p>
<h1 id="_7">进展<a class="headerlink" href="#_7" title="Permanent link">¶</a></h1>
<ul>
<li>150205 整理以往的吐糟, 结集纪念发布,永备,看 xiami 何时修订上</li>
<li>141121 <a href="http://www.xiami.com/g/thread-918973?spm=0.0.0.0.aq4pjq">[大妈吐糟] 自杀现象分析 - 虾米音乐讨论区</a></li>
<li>141030 <a href="http://www.xiami.com/g/thread-917351?spm=0.0.0.0.aq4pjq">[大妈吐糟] 无法理解的本地播放行为! - 虾米音乐讨论区</a></li>
</ul>论如何艺术的骂人2014-12-12T19:42:00+08:002020-07-19T12:02:09+08:00ZoomQuiettag:blog.zoomquiet.io,2014-12-12:/141212-art-for-diss.html<h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<h1 id="_1">论如何艺术的骂人<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<p><img alt="141212-ask-binghe.lisp.jpg(JPEG 图像,1024x650 像素)" src="http://zoomq.qiniudn.com/ZQCollection/snap/141212-ask-binghe.lisp.jpg?imageView2/2/w/512"></p>
<p>人称伞哥的传奇人物: <a href="http://www.ituring.com.cn/article/553">田春</a>
怎么应对的呢?...</p>
<p>来源: <a href="http://weibo.com/1929185323/BAfMov9Vt?type=comment#_rnd1418287455937">田春冰河 's Weibo_Weibo</a></p>
<p>揭晓答案前, 俺忍不住, 得推荐一下古今 …</p><h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<h1 id="_1">论如何艺术的骂人<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<p><img alt="141212-ask-binghe.lisp.jpg(JPEG 图像,1024x650 像素)" src="http://zoomq.qiniudn.com/ZQCollection/snap/141212-ask-binghe.lisp.jpg?imageView2/2/w/512"></p>
<p>人称伞哥的传奇人物: <a href="http://www.ituring.com.cn/article/553">田春</a>
怎么应对的呢?...</p>
<p>来源: <a href="http://weibo.com/1929185323/BAfMov9Vt?type=comment#_rnd1418287455937">田春冰河 's Weibo_Weibo</a></p>
<p>揭晓答案前, 俺忍不住, 得推荐一下古今中外有关骂人相关的经验了:</p>
<ul>
<li><a href="http://www.ccview.net/htm/xiandai/wen/liangshiqiu009.htm">梁实秋《骂人的艺术》- 现代散文</a></li>
<li><a href="http://www.zhixuan.com/toutiao/article/5431">如何优雅的对待他人的批评 - MacTalk By 池建强</a></li>
<li><a href="http://phiphicake.blogspot.hk/2012/01/paul-graham.html">Paul Graham的如何嘴炮 金字塔</a><ul>
<li>解读: <a href="http://www.zreading.cn/archives/4137.html">反驳别人的七个层次 | 左岸读书</a></li>
<li>原文: <a href="http://www.paulgraham.com/disagree.html">How to Disagree</a></li>
</ul>
</li>
</ul>
<p>再来看 伞哥 的回复:</p>
<p><img alt="141212-answer-binghe.lisp.jpg(JPEG 图像,1024x713 像素)" src="http://zoomq.qiniudn.com/ZQCollection/snap/141212-answer-binghe.lisp.jpg"></p>
<p>对比学术化的 "反驳的层级" 分析图谱</p>
<p><img alt="hierarchy_of_disagreement.jpg(JPEG 图像,640x554 像素)" src="http://zoomq.qiniudn.com/ZQCollection/snap/hierarchy_of_disagreement.jpg"></p>
<p>可以清晰的感受到:</p>
<ul>
<li>用对方的观点来不动声色的转移了论点, 无视了对方的指责</li>
<li>并用温润的态度指出:<ul>
<li>哥现在意大利吖</li>
<li>都有能力拯救外国MM了</li>
<li>E文翻译这点不算事儿,实在是没时间哪...</li>
</ul>
</li>
<li>已经是极其自然而又低姿态的站在各种高度, 完美的反驳了对方无法理解的智商</li>
<li>达到了 paul氏金字塔的 6.5 级,除了开头第一句,有点怨气外, 几近完美</li>
</ul>
<h2 id="_2">是也乎<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<p>所以, 至少俺学习到的:</p>
<ul>
<li>绝对的实力为基础</li>
<li>根本不用反驳各种低层次的东西</li>
<li>有事儿说事儿,不冲人去,冲人家灵魂深处去</li>
<li>才给力.</li>
</ul>
<h2 id="change-log">Change log<a class="headerlink" href="#change-log" title="Permanent link">¶</a></h2>
<ul>
<li>141212 有感速发</li>
</ul>流行之恶2014-12-12T19:42:00+08:002020-07-19T12:02:45+08:00ZoomQuiettag:blog.zoomquiet.io,2014-12-12:/141212-evil4pop.html<h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<h1 id="_1">流行之恶<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<p><img alt="popular_science_logo.png" src="http://zoomq.qiniudn.com/ZQCollection/logo/popular_science_logo.png?watermark/2/text/Wm9vbS5RdWlldA==/fill/V2hpdGU=/fontsize/320/dissolve/85|imageView2/2/w/320"></p>
<div class="highlight"><pre><span></span><code>hello,
你觉得有生命力流行的东西就是好的么,
俗话说祸害遗千年...
从汉语来看,楚辞也很棒,可是也式微了,
你怎么 …</code></pre></div><h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<h1 id="_1">流行之恶<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<p><img alt="popular_science_logo.png" src="http://zoomq.qiniudn.com/ZQCollection/logo/popular_science_logo.png?watermark/2/text/Wm9vbS5RdWlldA==/fill/V2hpdGU=/fontsize/320/dissolve/85|imageView2/2/w/320"></p>
<div class="highlight"><pre><span></span><code>hello,
你觉得有生命力流行的东西就是好的么,
俗话说祸害遗千年...
从汉语来看,楚辞也很棒,可是也式微了,
你怎么想?
</code></pre></div>
<h2 id="_2">背景<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<p>俺被推荐加入了一个有海量学霸的微信群, 每天被越量新知轰炸,
而且经常有非常尖锐的问题戳过来,</p>
<p>为了保持心意通达, 决定尽可能公开竭力回答则个,
以能忘记...</p>
<p>那种心塞的感觉!</p>
<h2 id="_3">厘定<a class="headerlink" href="#_3" title="Permanent link">¶</a></h2>
<p>作为一头工科狗, 对问题一向抱有最深的恶意,
必须厘凊 问题边界/背景/意图,
否则,就感觉无从回答的样纸.</p>
<p>目测:</p>
<ul>
<li><code>生命力</code>-<code>流行</code>-<code>好</code> 是设问关键词<ul>
<li><code>生命力</code> ~ 徦借生物学中的专有名词, 应该代表一种文化现象能够随着时代的发展,不断契合当下风气,嵌入持续发生的社会事件中,为人们不断的运用, 从而形成生物不断传承的观感</li>
<li><code>流行</code> ~ 是标准的社会学名词了,简单的说就是在主流媒体中,突然海量出现,又快速消失的一种人类社会类型化信息涌动的现场</li>
<li><code>好</code> ~ 介个忒泛了,没法儿理性界定,从发问者的教育背景设想,只能先假定为当前的 <code>普世价值观</code> 所谓正向的取向</li>
</ul>
</li>
<li><code>祸害遗千年</code> 是反诘<ul>
<li>已经说是俗语了, 应该不是设问的论点</li>
<li>因为已经是俗语了哪,有相对公认的阐述结构:<ul>
<li><code>好人不长命, 祸害遗千年</code></li>
<li>标准的中式反转,多层矛盾统一体</li>
<li>现代社会认同的是: 好人应对坏人着意祸害时,一般是无力自保的</li>
<li>但是,历史对善恶的评定总是倾向公允的</li>
<li>所以,好人虽然早死,但是,比祸害遗臭千年,也算得其所哉了</li>
</ul>
</li>
</ul>
</li>
<li><code>汉语</code>-<code>楚辞</code>-<code>式微</code> 是连带伤害<ul>
<li><code>汉语</code> 这是探讨主体, 不过,已经不是学术意义上的 语言学中的汉语言了<ul>
<li>主要关注,当前在互联网中,疯狂演进的网络中文</li>
<li>从 <code>人艰不拆</code> 到 <code>地命海心</code> 再到 <code>撕逼大战</code></li>
<li>无方向/无底线/无逻辑/无结构 的 再造/自造/强造</li>
</ul>
</li>
<li><code>楚辞</code> 是列举的一个比较对象<ul>
<li>这倒变成了严格的文学分类上的特定文体</li>
<li>而且应该有配合专曲牌才能正当诵出的</li>
</ul>
</li>
<li><code>式微</code> 太文雅的一种形容了<ul>
<li>好象 楚辞 从汉以后就根本没有流行过</li>
<li>因为 楚辞 本身一经发表,就已经完美</li>
<li>后人 也就是在传诵/吟哦/分析 没有再创作的余地了</li>
<li>不是第一种也不会是最后一种,将自个儿写死了的体裁 ;-)</li>
</ul>
</li>
</ul>
</li>
</ul>
<h2 id="_4">分析<a class="headerlink" href="#_4" title="Permanent link">¶</a></h2>
<p>综上,俺只能将问题翻译为以下这组递进的分析,以期表明私人态度:</p>
<ul>
<li>有<code>生命力</code>才<code>流行</code>所以是<code>好的</code> ~ 这本身不是俺的态度</li>
<li>之所以能流行, 必定有其生命力所在</li>
<li>生命力是指能同现行社会主体 情绪/意识/公知 持久绑定的结合点<ul>
<li>这才导致可以跟随不断发生/传播 的社会事件,被媒体引用</li>
<li>形成流行起来的现象</li>
</ul>
</li>
<li>但是:<ul>
<li>流行的当然不一定是好的, 比如说 流行性感冒</li>
<li>但是,能流行的这种内在能量是值得分析/尊敬的</li>
<li>毕竟这是社会主体意识自身无意识的选择</li>
<li>刚好有这种形式/模式的阐述结构, 可以用精练的文字包含/代表/传达越来越丰富的多方面情绪和态度</li>
</ul>
</li>
<li>进一步的, 这种生命力来自社会岐化情绪的表述愿望<ul>
<li>本身就很不稳定</li>
<li>因为社会变化的加速</li>
<li>很难保持一组相同情绪的组合</li>
<li>同时,一组相似情绪的流行性表述,也很难持续的引发大众的消费|被消费兴趣</li>
</ul>
</li>
<li>更何况,是否为 <code>好</code><ul>
<li>这种评定不能太过上帝视角 来判别</li>
<li>从俺积极运用 <code>走的了心</code> 的网络用词过程中</li>
<li>肯定的/感叹的 是中文, 当代汉语, 在互联网中能够如此鲜亮的自行变化的能力</li>
<li>普通/平常/简单/相同 的文字,只是简单组合一下,就能包容如此多层蕴意</li>
<li>好比盗梦空间中的多层梦境:<ul>
<li>字面含义多数只是进行现实描述</li>
<li>次层表述了造辞者的态度和倾向</li>
<li>再层通过历史事件的联想,指代了一大批同类社会现象</li>
<li>最后进入了 Limbo 已经不能简单的 Kick 回到现实描述<ul>
<li>即所谓激发了读者自身的脑补程序,进行持续的自发的吻合最新社会事件的再匹配再契合再感动</li>
<li>从而驱使受众再次选择使用这一网络词组</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>经典的例子: <code>喂人民服雾</code></li>
</ul>
<h2 id="_5">是也乎<a class="headerlink" href="#_5" title="Permanent link">¶</a></h2>
<p>综上, 俺对此问题的私人无责任回答,可以总结为:</p>
<ul>
<li>能流行的不一定是好的</li>
<li>但是有生命力本身是值得肯定的</li>
<li>中文在互联网时代这种精彩的自我演变基因是令人自豪的</li>
<li>不过,是否提倡这种尝试?<ul>
<li>从教育角度,再议</li>
<li>从国学角度,再议</li>
<li>从文学角度,再议</li>
<li>从私人角度,点赞</li>
<li>从其它方面,再议</li>
</ul>
</li>
</ul>
<h2 id="change-log">Change log<a class="headerlink" href="#change-log" title="Permanent link">¶</a></h2>
<p>原稿: <a href="http://blog.zoomquiet.io/141212-pop-is-evil.html">流行之恶</a></p>
<ul>
<li>141212 后台运算了两天,尝试输出第一次</li>
<li>141210 被戳提问</li>
</ul>流行之恶2014-12-12T18:18:18+08:002020-01-31T16:42:10+08:00Zoom.Quiettag:blog.zoomquiet.io,2014-12-12:/141212-pop-is-evil.html
<p><img alt="popular_science_logo.png" src="http://zoomq.qiniudn.com/ZQCollection/logo/popular_science_logo.png?watermark/2/text/Wm9vbS5RdWlldA==/fill/V2hpdGU=/fontsize/320/dissolve/85|imageView2/2/w/320"/></p>
<div class="highlight"><pre><span></span><code>hello,
你觉得有生命力流行的东西就是好的么,
俗话说祸害遗千年...
从汉语来看,楚辞也很棒,可是也式微了,
你怎么想?
</code></pre></div>
<!--more-->
<h2 id="_1">背景<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<p>俺被 …</p>
<p><img alt="popular_science_logo.png" src="http://zoomq.qiniudn.com/ZQCollection/logo/popular_science_logo.png?watermark/2/text/Wm9vbS5RdWlldA==/fill/V2hpdGU=/fontsize/320/dissolve/85|imageView2/2/w/320"/></p>
<div class="highlight"><pre><span></span><code>hello,
你觉得有生命力流行的东西就是好的么,
俗话说祸害遗千年...
从汉语来看,楚辞也很棒,可是也式微了,
你怎么想?
</code></pre></div>
<!--more-->
<h2 id="_1">背景<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<p>俺被推荐加入了一个有海量学霸的微信群, 每天被越量新知轰炸,
而且经常有非常尖锐的问题戳过来,</p>
<p>为了保持心意通达, 决定尽可能公开竭力回答则个,
以能忘记...</p>
<p>那种心塞的感觉!</p>
<h2 id="_2">厘定<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<p>作为一头工科狗, 对问题一向抱有最深的恶意,
必须厘凊 问题边界/背景/意图,
否则,就感觉无从回答的样纸.</p>
<p>目测:</p>
<ul>
<li><code>生命力</code>-<code>流行</code>-<code>好</code> 是设问关键词<ul>
<li><code>生命力</code> ~ 徦借生物学中的专有名词, 应该代表一种文化现象能够随着时代的发展,不断契合当下风气,嵌入持续发生的社会事件中,为人们不断的运用, 从而形成生物不断传承的观感</li>
<li><code>流行</code> ~ 是标准的社会学名词了,简单的说就是在主流媒体中,突然海量出现,又快速消失的一种人类社会类型化信息涌动的现场</li>
<li><code>好</code> ~ 介个忒泛了,没法儿理性界定,从发问者的教育背景设想,只能先假定为当前的 <code>普世价值观</code> 所谓正向的取向</li>
</ul>
</li>
<li><code>祸害遗千年</code> 是反诘<ul>
<li>已经说是俗语了, 应该不是设问的论点</li>
<li>因为已经是俗语了哪,有相对公认的阐述结构:<ul>
<li><code>好人不长命, 祸害遗千年</code></li>
<li>标准的中式反转,多层矛盾统一体</li>
<li>现代社会认同的是: 好人应对坏人着意祸害时,一般是无力自保的</li>
<li>但是,历史对善恶的评定总是倾向公允的</li>
<li>所以,好人虽然早死,但是,比祸害遗臭千年,也算得其所哉了</li>
</ul>
</li>
</ul>
</li>
<li><code>汉语</code>-<code>楚辞</code>-<code>式微</code> 是连带伤害<ul>
<li><code>汉语</code> 这是探讨主体, 不过,已经不是学术意义上的 语言学中的汉语言了<ul>
<li>主要关注,当前在互联网中,疯狂演进的网络中文</li>
<li>从 <code>人艰不拆</code> 到 <code>地命海心</code> 再到 <code>撕逼大战</code></li>
<li>无方向/无底线/无逻辑/无结构 的 再造/自造/强造</li>
</ul>
</li>
<li><code>楚辞</code> 是列举的一个比较对象<ul>
<li>这倒变成了严格的文学分类上的特定文体</li>
<li>而且应该有配合专曲牌才能正当诵出的</li>
</ul>
</li>
<li><code>式微</code> 太文雅的一种形容了<ul>
<li>好象 楚辞 从汉以后就根本没有流行过</li>
<li>因为 楚辞 本身一经发表,就已经完美</li>
<li>后人 也就是在传诵/吟哦/分析 没有再创作的余地了</li>
<li>不是第一种也不会是最后一种,将自个儿写死了的体裁 ;-)</li>
</ul>
</li>
</ul>
</li>
</ul>
<h2 id="_3">分析<a class="headerlink" href="#_3" title="Permanent link">¶</a></h2>
<p>综上,俺只能将问题翻译为以下这组递进的分析,以期表明私人态度:</p>
<ul>
<li>有<code>生命力</code>才<code>流行</code>所以是<code>好的</code> ~ 这本身不是俺的态度</li>
<li>之所以能流行, 必定有其生命力所在</li>
<li>生命力是指能同现行社会主体 情绪/意识/公知 持久绑定的结合点<ul>
<li>这才导致可以跟随不断发生/传播 的社会事件,被媒体引用</li>
<li>形成流行起来的现象</li>
</ul>
</li>
<li>但是:<ul>
<li>流行的当然不一定是好的, 比如说 流行性感冒</li>
<li>但是,能流行的这种内在能量是值得分析/尊敬的</li>
<li>毕竟这是社会主体意识自身无意识的选择</li>
<li>刚好有这种形式/模式的阐述结构, 可以用精练的文字包含/代表/传达越来越丰富的多方面情绪和态度</li>
</ul>
</li>
<li>进一步的, 这种生命力来自社会岐化情绪的表述愿望<ul>
<li>本身就很不稳定</li>
<li>因为社会变化的加速</li>
<li>很难保持一组相同情绪的组合</li>
<li>同时,一组相似情绪的流行性表述,也很难持续的引发大众的消费|被消费兴趣</li>
</ul>
</li>
<li>更何况,是否为 <code>好</code><ul>
<li>这种评定不能太过上帝视角 来判别</li>
<li>从俺积极运用 <code>走的了心</code> 的网络用词过程中</li>
<li>肯定的/感叹的 是中文, 当代汉语, 在互联网中能够如此鲜亮的自行变化的能力</li>
<li>普通/平常/简单/相同 的文字,只是简单组合一下,就能包容如此多层蕴意</li>
<li>好比盗梦空间中的多层梦境:<ul>
<li>字面含义多数只是进行现实描述</li>
<li>次层表述了造辞者的态度和倾向</li>
<li>再层通过历史事件的联想,指代了一大批同类社会现象</li>
<li>最后进入了 Limbo 已经不能简单的 Kick 回到现实描述<ul>
<li>即所谓激发了读者自身的脑补程序,进行持续的自发的吻合最新社会事件的再匹配再契合再感动</li>
<li>从而驱使受众再次选择使用这一网络词组</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>经典的例子: <code>喂人民服雾</code></li>
</ul>
<h2 id="_4">是也乎<a class="headerlink" href="#_4" title="Permanent link">¶</a></h2>
<p>综上, 俺对此问题的私人无责任回答,可以总结为:</p>
<ul>
<li>能流行的不一定是好的</li>
<li>但是有生命力本身是值得肯定的</li>
<li>中文在互联网时代这种精彩的自我演变基因是令人自豪的</li>
<li>不过,是否提倡这种尝试?<ul>
<li>从教育角度,再议</li>
<li>从国学角度,再议</li>
<li>从文学角度,再议</li>
<li>从私人角度,点赞</li>
<li>从其它方面,再议</li>
</ul>
</li>
</ul>
<h2 id="change-log">Change log<a class="headerlink" href="#change-log" title="Permanent link">¶</a></h2>
<p>原稿: <a href="http://blog.zoomquiet.io/141212-pop-is-evil.html">流行之恶</a></p>
<ul>
<li>141212 后台运算了两天,尝试输出第一次</li>
<li>141210 被戳提问</li>
</ul>论如何艺术的骂人2014-12-12T12:12:12+08:002020-01-31T16:42:10+08:00Zoom.Quiettag:blog.zoomquiet.io,2014-12-12:/141212-hierarchy-of-disagreement.html
<p><img alt="141212-ask-binghe.lisp.jpg(JPEG 图像,1024x650 像素)" src="http://zoomq.qiniudn.com/ZQCollection/snap/141212-ask-binghe.lisp.jpg?imageView2/2/w/512"/></p>
<p>人称伞哥的传奇人物: <a href="http://www.ituring.com.cn/article/553">田春</a>
怎么应对的呢?...</p>
<!--more-->
<p>来源: <a href="http://weibo.com/1929185323/BAfMov9Vt?type=comment#_rnd1418287455937">田春冰河 's Weibo_Weibo</a></p>
<p>揭晓答案前, 俺忍不住, 得推荐一下古今中外有关骂人相关的 …</p>
<p><img alt="141212-ask-binghe.lisp.jpg(JPEG 图像,1024x650 像素)" src="http://zoomq.qiniudn.com/ZQCollection/snap/141212-ask-binghe.lisp.jpg?imageView2/2/w/512"/></p>
<p>人称伞哥的传奇人物: <a href="http://www.ituring.com.cn/article/553">田春</a>
怎么应对的呢?...</p>
<!--more-->
<p>来源: <a href="http://weibo.com/1929185323/BAfMov9Vt?type=comment#_rnd1418287455937">田春冰河 's Weibo_Weibo</a></p>
<p>揭晓答案前, 俺忍不住, 得推荐一下古今中外有关骂人相关的经验了:</p>
<ul>
<li><a href="http://www.ccview.net/htm/xiandai/wen/liangshiqiu009.htm">梁实秋"骂人的艺术"- 现代散文</a></li>
<li><a href="http://www.zhixuan.com/toutiao/article/5431">如何优雅的对待他人的批评 - MacTalk By 池建强</a></li>
<li><a href="http://phiphicake.blogspot.hk/2012/01/paul-graham.html">Paul Graham的如何嘴炮 金字塔</a><ul>
<li>解读: <a href="http://www.zreading.cn/archives/4137.html">反驳别人的七个层次 | 左岸读书</a></li>
<li>原文: <a href="http://www.paulgraham.com/disagree.html">How to Disagree</a></li>
</ul>
</li>
</ul>
<p>再来看 伞哥 的回复:</p>
<p><img alt="141212-answer-binghe.lisp.jpg(JPEG 图像,1024x713 像素)" src="http://zoomq.qiniudn.com/ZQCollection/snap/141212-answer-binghe.lisp.jpg"/></p>
<p>对比学术化的 "反驳的层级" 分析图谱</p>
<p><img alt="hierarchy_of_disagreement.jpg(JPEG 图像,640x554 像素)" src="http://zoomq.qiniudn.com/ZQCollection/snap/hierarchy_of_disagreement.jpg"/></p>
<p>可以清晰的感受到:</p>
<ul>
<li>用对方的观点来不动声色的转移了论点, 无视了对方的指责</li>
<li>并用温润的态度指出:<ul>
<li>哥现在意大利吖</li>
<li>都有能力拯救外国MM了</li>
<li>E文翻译这点不算事儿,实在是没时间哪...</li>
</ul>
</li>
<li>已经是极其自然而又低姿态的站在各种高度, 完美的反驳了对方无法理解的智商</li>
<li>达到了 paul氏金字塔的 6.5 级,除了开头第一句,有点怨气外, 几近完美</li>
</ul>
<h2 id="_1">是也乎<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<p>所以, 至少俺学习到的:</p>
<ul>
<li>绝对的实力为基础</li>
<li>根本不用反驳各种低层次的东西</li>
<li>有事儿说事儿,不冲人去,冲人家灵魂深处去</li>
<li>才给力.</li>
</ul>
<h2 id="change-log">Change log<a class="headerlink" href="#change-log" title="Permanent link">¶</a></h2>
<ul>
<li>141212 有感速发</li>
</ul>熟练使用文学编程(literate programming)是怎样一番体验?2014-12-09T21:21:21+08:002020-01-31T16:42:10+08:00Zoom.Quiettag:blog.zoomquiet.io,2014-12-09:/141209-leo-literate-programming.html
<p><img alt="Literate_Programming_book_cover" src="http://upload.wikimedia.org/wikipedia/en/thumb/6/62/Literate_Programming_book_cover.jpg/220px-Literate_Programming_book_cover.jpg"/></p>
<p><a href="http://www.zhihu.com/question/26978956">熟练使用文学编程(literate programming)是怎样一番体验? - 知乎</a></p>
<p>然后有人戳了俺...</p>
<!--more-->
<h2 id="_1">有关文学化编程<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<p>参考:<a href="http://wiki.woodpecker.org.cn/moin/LeoEnvironment">LeoEnvironment</a></p>
<p>以及相关链接,</p>
<p>有关使用 Leo 进行文 …</p>
<p><img alt="Literate_Programming_book_cover" src="http://upload.wikimedia.org/wikipedia/en/thumb/6/62/Literate_Programming_book_cover.jpg/220px-Literate_Programming_book_cover.jpg"/></p>
<p><a href="http://www.zhihu.com/question/26978956">熟练使用文学编程(literate programming)是怎样一番体验? - 知乎</a></p>
<p>然后有人戳了俺...</p>
<!--more-->
<h2 id="_1">有关文学化编程<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<p>参考:<a href="http://wiki.woodpecker.org.cn/moin/LeoEnvironment">LeoEnvironment</a></p>
<p>以及相关链接,</p>
<p>有关使用 Leo 进行文学化编程, 参考:
- 幻灯: <a href="http://s5.zoomquiet.io/060730-abtLeo">啄木鸟/CPUG 会课06年度第九次 (built by S5)</a> ; <a href="http://s5.zoomquiet.io/131101-leo-china">131101-leo-china</a>
- 录音: <a href="http://zoomq.qiniudn.com/CPyUG/060731-bpyug-leo/cpug_2006_07_30_01.ogg">cpug_2006_07_30_01.ogg</a>
+ <a href="http://zoomq.qiniudn.com/CPyUG/100716-Leo-LiterateProgramming">Index of /CPyUG/100716-Leo-LiterateProgramming {gen. by gen4idx.py v13.4.18}</a>
- 录像: Leo 创始人 令德华的演讲
- <a href="http://v.youku.com/v_show/id_XNjQ1OTM3MDk2.html">PyConChina2013-Leo-final-v2</a></p>
<p>俺知道 文学化编程是在 2005 年,开始使用 Leo 尝试进行 文学化编程则是到了 2006 年,
之后,一直尽可能的使用 Leo 作为主要的编辑/编程环境;
其它包含 Emacs/Vim 中都有 文学化编程扩展,
不过, 俺一直没有用起来,所以,俺的体验比较偏激;
在 Leo 中俺进行过各种语言的编程包含:</p>
<ul>
<li>php</li>
<li>css/js</li>
<li>xslt</li>
<li>python</li>
<li>golang</li>
<li>...</li>
</ul>
<h1 id="_2">总体上<a class="headerlink" href="#_2" title="Permanent link">¶</a></h1>
<p>对比各种 IDE 或是 subl 中的编程体验,
简单的说:</p>
<blockquote>
<p>随心小累</p>
</blockquote>
<h2 id="_3">随心<a class="headerlink" href="#_3" title="Permanent link">¶</a></h2>
<ul>
<li>目录/文件/模块/函式/代码块/片段/配置/测试数据.... 一切都在一个界面中可以快速编辑</li>
<li>保存到哪儿也只是一行声明的事儿</li>
<li>所有代码的 提纲结构, 就是我对程序的理解, 完全无视所有语法结构,可以任意随手设定</li>
<li>无论何时回到思考场景,上次对程序的思考进展都以 提纲节点树的形式存在着</li>
<li>同时, "混出" 的代码又完全干净, 标准的代码文本, 不影响任何环境中的运行</li>
</ul>
<h2 id="_4">小累<a class="headerlink" href="#_4" title="Permanent link">¶</a></h2>
<ul>
<li>Leo 是 纯 Python 编写的编辑环境, 加载/迁移都有点小麻烦</li>
<li>而且没有很多现代 IDE 的各种自动化功能, 就连语法颜色也无法 0配置的完美表达各种语法单元</li>
<li>最累的是和团队其它成员协同时, 其它人都是线性编辑环境,只有俺是多维表述的 文学化编程</li>
<li>所以, 有代码修订合并时,俺都要手工合并差异,以免破坏了俺的程序表述结构.</li>
</ul>
<h1 id="_5">是也乎<a class="headerlink" href="#_5" title="Permanent link">¶</a></h1>
<p>其实,无论俺怎么分析/回答/解释,
都无法替代大家自行去体验,
文学化编程,
是真正的将思维对应到代码内在结构上,
而不是语法结构,
这对程序员而言,是种极大的解放.</p>
<h2 id="changlog">Changlog<a class="headerlink" href="#changlog" title="Permanent link">¶</a></h2>
<ul>
<li>141209 受邀回答</li>
</ul>re/熟练使用文学编程(literate programming)是怎样一番体验?2014-12-09T19:42:00+08:002020-07-19T12:01:27+08:00ZoomQuiettag:blog.zoomquiet.io,2014-12-09:/141209-feeling-leo.html<h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<h1 id="re-literate-programming">re: 熟练使用文学编程(literate programming)是怎样一番体验?<a class="headerlink" href="#re-literate-programming" title="Permanent link">¶</a></h1>
<p><img alt="Literate_Programming_book_cover" src="http://upload.wikimedia.org/wikipedia/en/thumb/6/62/Literate_Programming_book_cover.jpg/220px-Literate_Programming_book_cover.jpg"></p>
<p><a href="http://www.zhihu.com/question/26978956">熟练使用文学编程(literate programming)是怎样一番体验? - 知乎</a></p>
<p>然后有人戳了俺...</p>
<h2 id="_1">有关文学化 …</h2><h2 id="toc">[TOC]<a class="headerlink" href="#toc" title="Permanent link">¶</a></h2>
<h1 id="re-literate-programming">re: 熟练使用文学编程(literate programming)是怎样一番体验?<a class="headerlink" href="#re-literate-programming" title="Permanent link">¶</a></h1>
<p><img alt="Literate_Programming_book_cover" src="http://upload.wikimedia.org/wikipedia/en/thumb/6/62/Literate_Programming_book_cover.jpg/220px-Literate_Programming_book_cover.jpg"></p>
<p><a href="http://www.zhihu.com/question/26978956">熟练使用文学编程(literate programming)是怎样一番体验? - 知乎</a></p>
<p>然后有人戳了俺...</p>
<h2 id="_1">有关文学化编程<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<p>参考:<a href="http://wiki.woodpecker.org.cn/moin/LeoEnvironment">LeoEnvironment</a></p>
<p>以及相关链接,</p>
<p>有关使用 Leo 进行文学化编程, 参考:</p>
<ul>
<li>
<p>幻灯: <a href="http://s5.zoomquiet.io/060730-abtLeo">啄木鸟/CPUG 会课06年度第九次 (built by S5)</a> ; <a href="http://s5.zoomquiet.io/131101-leo-china">131101-leo-china</a></p>
</li>
<li>
<p>录音: <a href="http://zoomq.qiniudn.com/CPyUG/060731-bpyug-leo/cpug_2006_07_30_01.ogg">cpug_2006_07_30_01.ogg</a></p>
</li>
<li>
<p><a href="http://zoomq.qiniudn.com/CPyUG/100716-Leo-LiterateProgramming">Index of /CPyUG/100716-Leo-LiterateProgramming {gen. by gen4idx.py v13.4.18}</a></p>
</li>
<li>
<p>录像: Leo 创始人 令德华的演讲</p>
</li>
<li>
<p><a href="http://v.youku.com/v_show/id_XNjQ1OTM3MDk2.html">PyConChina2013-Leo-final-v2</a></p>
</li>
</ul>
<p>俺知道 文学化编程是在 2005 年,开始使用 Leo 尝试进行 文学化编程则是到了 2006 年,</p>
<p>之后,一直尽可能的使用 Leo 作为主要的编辑/编程环境;</p>
<p>其它包含 Emacs/Vim 中都有 文学化编程扩展,</p>
<p>不过, 俺一直没有用起来,所以,俺的体验比较偏激;</p>
<p>在 Leo 中俺进行过各种语言的编程包含:</p>
<ul>
<li>
<p>php</p>
</li>
<li>
<p>css/js</p>
</li>
<li>
<p>xslt</p>
</li>
<li>
<p>python</p>
</li>
<li>
<p>golang</p>
</li>
<li>
<p>...</p>
</li>
</ul>
<h1 id="_2">总体上<a class="headerlink" href="#_2" title="Permanent link">¶</a></h1>
<p>对比各种 IDE 或是 subl 中的编程体验,</p>
<p>简单的说:</p>
<blockquote>
<p>随心小累</p>
</blockquote>
<h2 id="_3">随心<a class="headerlink" href="#_3" title="Permanent link">¶</a></h2>
<ul>
<li>
<p>目录/文件/模块/函式/代码块/片段/配置/测试数据.... 一切都在一个界面中可以快速编辑</p>
</li>
<li>
<p>保存到哪儿也只是一行声明的事儿</p>
</li>
<li>
<p>所有代码的 提纲结构, 就是我对程序的理解, 完全无视所有语法结构,可以任意随手设定</p>
</li>
<li>
<p>无论何时回到思考场景,上次对程序的思考进展都以 提纲节点树的形式存在着</p>
</li>
<li>
<p>同时, "混出" 的代码又完全干净, 标准的代码文本, 不影响任何环境中的运行</p>
</li>
</ul>
<h2 id="_4">小累<a class="headerlink" href="#_4" title="Permanent link">¶</a></h2>
<ul>
<li>
<p>Leo 是 纯 Python 编写的编辑环境, 加载/迁移都有点小麻烦</p>
</li>
<li>
<p>而且没有很多现代 IDE 的各种自动化功能, 就连语法颜色也无法 0配置的完美表达各种语法单元</p>
</li>
<li>
<p>最累的是和团队其它成员协同时, 其它人都是线性编辑环境,只有俺是多维表述的 文学化编程</p>
</li>
<li>
<p>所以, 有代码修订合并时,俺都要手工合并差异,以免破坏了俺的程序表述结构.</p>
</li>
</ul>
<h1 id="_5">是也乎<a class="headerlink" href="#_5" title="Permanent link">¶</a></h1>
<p>其实,无论俺怎么分析/回答/解释,</p>
<p>都无法替代大家自行去体验,</p>
<p>文学化编程,</p>
<p>是真正的将思维对应到代码内在结构上,</p>
<p>而不是语法结构,</p>
<p>这对程序员而言,是种极大的解放.</p>
<h2 id="changlog">Changlog<a class="headerlink" href="#changlog" title="Permanent link">¶</a></h2>
<ul>
<li>141209 受邀回答</li>
</ul>论 Shooter 的关闭2014-11-22T11:11:11+08:002020-01-31T16:42:10+08:00Zoom.Quiettag:blog.zoomquiet.io,2014-11-22:/141122-shotter-death.html
<p><img alt="529.jpg (175×260)" src="http://m.ms10010.com/image/pic/201205/thumb/529.jpg"/></p>
<div class="highlight"><pre><span></span><code>And in the naked light I saw ten thousand people, maybe more.
People talking without speaking, people hearing without listening.
People writing songs that voices never shared, no one dared disturb the sound of silence.
--- The sound of silence 美利坚合众国,2015年,纽约.
</code></pre></div>
<!--more-->
<p><img alt="53809965gw1emk7au8650j20xr0w3tat" src="http://ww4.sinaimg.cn/large/53809965gw1emk7au8650j20xr0w3tat.jpg"/></p>
<h2 id="_1">慢慢 …</h2>
<p><img alt="529.jpg (175×260)" src="http://m.ms10010.com/image/pic/201205/thumb/529.jpg"/></p>
<div class="highlight"><pre><span></span><code>And in the naked light I saw ten thousand people, maybe more.
People talking without speaking, people hearing without listening.
People writing songs that voices never shared, no one dared disturb the sound of silence.
--- The sound of silence 美利坚合众国,2015年,纽约.
</code></pre></div>
<!--more-->
<p><img alt="53809965gw1emk7au8650j20xr0w3tat" src="http://ww4.sinaimg.cn/large/53809965gw1emk7au8650j20xr0w3tat.jpg"/></p>
<h2 id="_1">慢慢的,它们就没有了,就像从未存在过<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<p>(原文: http://www.douban.com/note/456932116 出于压力,已经被作者关闭 ;-()</p>
<p>几年以前,我曾经嘲笑过某科技界大佬. 当时他说:也许90后,95后会慢慢不知道谷歌是什么网站. </p>
<p>那一年,这对于我来说简直就是世界上最好笑的笑话. 谷歌,全世界最卓越的互联网公司,活在互联网的一代中国人,会不知道他们的网站?</p>
<p>今天,我收回这句嘲笑. 因为这件不可能的事,它慢慢变成了现实. </p>
<p>没有人再关注什么谷歌不谷歌. 对他们来说,百度也蛮好用的,反正他们几乎没用过谷歌. 没有谷歌又怎样?大家还是开心的刷微博,看微信,听歌,看娱乐节目. 对于从来就不知道谷歌的人来说,少了谷歌又有什么影响?</p>
<p>多年前,我们也是可以登陆Facebook的. 其实这个网站和校内一样,也挺蠢的. 可在上面你能看到老外们的生活,可以轻易的跟一万公里以外的人互相拜访,可以看到很多根本不会开到校内上的主页. 你用汉语回复,下面给你聊起来的可能是香港仔,可能是台湾人. 你用英语回复,说不定有比你英语用的更蹩脚的寂寞的北欧人来跟你搭讪. 你感觉地球真的变成了地球村,你还没拉门走出去,别人就推门走了进来. </p>
<p>然后,它就没有了. 起初,它的失踪激起了很大的声音,后来,声音就消失了. </p>
<p>多年前,我们也是可以登陆Twitter的. 其实这个网站和微博一样,也不过是些信息流,刷上一整天,也不见得有什么用处. 但至少,你可以以最快速度获取你想知道的任何新事,你会真正了解什么事情在全世界是流行的,而不是经过各种截图,翻译,转发,甚至曲解,断章取义,黑白颠倒的东西. 你知道的是真相,赤裸裸的,也许有点太短的真相. 但至少中间不会有无数人的加工与再加工,偏激,片面,就在这个过程中产生了,不管后来者有意还是无意. </p>
<p>然后,它就没有了. 首先是它的本体没有了,然后它的模仿者也没有了,模仿者的模仿者也没有了. 只剩一个模仿者的模仿者的模仿者,现在你每天能在上面看到无数广告. </p>
<p>多年前,我们也是可以登陆YouTube的. 对于有的人来说,这个网站就是个大型优酷,当年有人信誓旦旦的说,没有YouTube,我们中国人会很快让优酷超过YouTube. 可这么多年过去了,视频还是那么卡,内容还是那么垃圾,原创还是那么容易被盗窃,视频丰富度还是那么的可怜. 在YouTube上,你能看到全世界最棒的手艺人,最逗乐的笑话,最天马行空的创意,最激荡人心的音乐,最美好的完美瞬间,可在优酷上,你想看一分钟视频,请先看半分钟广告. </p>
<p>哦,对了. Instagram,有些人可能感觉它和QQ空间也差不多. 可我在上面关注了六百多个摄影师,它们都是顶好顶好的影像记录者,每天看他们的作品,我感觉到很幸福,那种即使没有到那里去,也身临其境的幸福. 我还在上面认识了一个日本的爱自拍的帅小伙,一个爱喝酒的韩国大叔,一个十年前到过中国今天会在每张我发的紫禁城照片下点赞的美国大爷,一个美丽无比的俄罗斯妹子,我和他们基本上都难以交流,语言是很大的障碍,但几个简单的单词,心意也就到了,这种感觉,有时候比多年老友相聚还兴奋. 因为这是人类不同族群自由交流互相沟通的过程,这种过程很神奇,真的很神奇. </p>
<p>可现在,它没有了,它之所以没有就因为在某个特定的时间你在搜索特定的词汇时,会搜出来特定的照片. 虽然这么搜的人并不多,虽然看到的人也不会大惊小怪,也不会觉得天黑了,天亮了,天要塌了,天要变了. 可它就是没了,Instagram,就这么没了. 谷歌也是这么没的,Twitter也是这么没的,Facebook也是这么没的. 不知道是什么人,在什么场合,说了什么话,下了什么决定. 就要有超过十亿人像陷于哥谭市的孤岛里一样,看着一座又一座桥梁被炸掉,又被炸掉,又被炸掉,然后,就什么都没了. </p>
<p>我时常觉得悲哀,真的好悲哀,一个我根本不认识也不知道是谁的人,也许是一个群体,在不断抢走我身边的东西,而我却无能为力. 我抱怨一声,他听不到,任何人都听不到. 我怒吼一句,身边的大多数人却像看疯子一样的看着我. 我哀嚎一声,这声音被阻碍在黑黑的幕墙以里. 我发出尖锐的嘶吼,这声音传不了多远,就和我那被抢走的东西一样,消失了,不见了,就像从来没存在过一样. </p>
<p>对于本来就没存在过的东西,有谁又会觉得在意呢?那些本来拥有又被掠夺的人的哀愁,后来的人又怎么懂呢?我曾经是拥有一切的,我曾经是拥有世界的,我站在这片土地上,呼吸的是自由的空气,饮下的是自由的琼浆玉液. 就在长的无法计数的时间里,我自由生命的一部分又一部分就这么被杀死了,突然就杀死了. 可我还始终觉得,它们还奄奄一息的活着,就像它们是慢慢的死去的一样. </p>
<p>可它们终归是死了,而且随着它们的死,愈来愈多的事情慢慢的发生了,很慢很慢,几乎不被人察觉,可还是发生了. </p>
<p>没有谷歌,我可以用百度呀. 可某些结果被越挪越后,越挪越后,最后就不见了. 就像本来就不该搜出这个结果一样. </p>
<p>没有Facebook,我可以用校内呀. 可你想发只有在Facebook上能发的文章,很快在校内上就失踪了. 接着,校内变成了人人,话题变成了人人都关心的话题. 大家都在抢着看星座,明星,八卦,娱乐. 没有人会关心什么消失了,反正它们本来也没多少存在感. </p>
<p>没有YouTube,我可以用优酷呀. 可你却经常只能在优酷上看到抄袭别人的作品,而且还不署名,而且还洋洋得意,而且还自我陶醉,就好像那个idea本来属于他自己一样. 你看了还要惊呼,他是如此的有创意!好一个抄袭的创意,可你却不知道,因为你不知道这个世界上有个网站叫YouTube. </p>
<p>没有Twitter,我还可以用微博呀. 可你想知道最近发生了什么,你搜的越勤快,越能看到越明显的"根据相关法律法规,相关搜索结果不予显示". 时间长了,你想,反正知道了也没什么用,不如不看了. </p>
<p>慢慢的,一扇又一扇的门关上了. 今天你打开世界上最大的博客网站,发现它没了. 明天你一看,世界上最好的设计师分享网站没了,一开始是刷新的很慢很慢,后来它就没了. 过两天再一看,平常每天都会读两篇文章的媒体网站没了,那里的文章缤纷多彩,最后都变成了该页无法显示几个字. 再过几个月,大学的网站不让上了,摄影师的网站不让上了,就连百度日本这种自家网站,也没了. </p>
<p>接着,漫画看不了了,接着,动画看不成了. 接着,美剧英剧失踪了. 下载美剧英剧的网站又又又又又失踪了. 尊重正版,保护权益,行吧,然后字幕网站也没了. </p>
<p>游戏没了,你习惯性登陆的游戏网站,发现下载栏正在整治中. 论坛关了,天天都在看的论坛,突然接到相关部门的电话,因为"报备问题"不让办了. 个人网站,私人博客,对不起,说没就没有,你在上面存了多少多年辛勤耕耘的东西都没用. </p>
<p>你关注的人,有一天你登陆微博,发现他怎么好久都没说话了,然后你搜索了一下,发现他的账号不存在了,而且你搜他的名字,他的名字未予显示. </p>
<p>一盏一盏的灯,灭了. 四面八方的光源,消失了. 我们生活的五光十色的世界,变成了一片黑色. </p>
<p>天黑了,那么睡觉吧,但愿长醉不复醒,卧槽泥马勒戈壁. </p>
<p>最后,我们变成了一群做梦的人,这个梦的名字,叫根据相关法律法规,相关搜索结果不予显示梦. </p>
<h2 id="_2">是也乎<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<p>不由的想到了 <a href="http://www.douban.com/group/topic/8948067/">寂静之城 (无删节版)</a></p>
<p>'''
...
两个人互相对视了一阵,他终于木然走到她身边,张了张嘴唇,想对她说些什
么. 但是他掏出今天新发布的健康词汇列表,发现上面是一片空白---终于连最后
一个词组也被有关部门屏蔽了. </p>
<p>于是阿瓦登只好保持着沉默,默默地与面无表情的她擦肩而过,继续向前走去
. 他的身影逐渐融入同样安静的灰色人群之中,整个城市都显得寂静极了.
'''</p>
<h2 id="changlog">Changlog<a class="headerlink" href="#changlog" title="Permanent link">¶</a></h2>
<ul>
<li>141125 没忍住...</li>
<li>141121 起意</li>
</ul>论 OhLife 的倒掉2014-09-21T11:11:11+08:002020-01-31T16:42:10+08:00Zoom.Quiettag:blog.zoomquiet.io,2014-09-21:/140921-ohlife-death.html
<p><img alt="ohlife" src="http://a.36krcnd.com/photo/5dfa0868b7808b19b22eb4617a374923.jpg"/></p>
<h2 id="_1">背景<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<p><a href="http://www.36kr.com/p/2934.html">OhLife:抛弃你的日记本吧!来自Y Combinator的第三个项目 | 36氪</a></p>
<p>当年 36Kr 就分析 OhLife 面临着几大问题:</p>
<ul>
<li>由于网站内容涉及隐私,完全保密,因此该网站很 …</li></ul>
<p><img alt="ohlife" src="http://a.36krcnd.com/photo/5dfa0868b7808b19b22eb4617a374923.jpg"/></p>
<h2 id="_1">背景<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<p><a href="http://www.36kr.com/p/2934.html">OhLife:抛弃你的日记本吧!来自Y Combinator的第三个项目 | 36氪</a></p>
<p>当年 36Kr 就分析 OhLife 面临着几大问题:</p>
<ul>
<li>由于网站内容涉及隐私,完全保密,因此该网站很难通过正常的网络推广方式吸引来很大的流量. </li>
<li>简单的功能很容易被复制,除了创业公司可以轻松复制外,如果 Google,腾讯这样的公司复制了这个模式,Ohlife 的竞争力就很不明显了. </li>
<li>简单的功能也很难实现 freemium,因为没有什么高级功能可以单独列出来吸引客户付费.
不过也未必,或许 OhLife 会专注于做好这一件事,并且能把它做得出人意料之外的好,就如 evernote 一样. </li>
</ul>
<p>果然...四年后:</p>
<h3 id="ohlife-is-shutting-down">OhLife is shutting down<a class="headerlink" href="#ohlife-is-shutting-down" title="Permanent link">¶</a></h3>
<div class="highlight"><pre><span></span><code><span class="n">from</span><span class="o">:</span><span class="w"> </span><span class="n">OhLife</span><span class="w"> </span><span class="o"><</span><span class="n">post</span><span class="o">+</span><span class="mi">4</span><span class="n">cc6632387657</span><span class="err">@</span><span class="n">ohlife</span><span class="o">.</span><span class="na">com</span><span class="o">></span>
<span class="n">to</span><span class="o">:</span><span class="w"> </span><span class="n">Zoom</span><span class="o">.</span><span class="na">Quiet</span><span class="err">@</span><span class="n">gmail</span><span class="o">.</span><span class="na">com</span>
<span class="n">date</span><span class="o">:</span><span class="w"> </span><span class="n">Sun</span><span class="o">,</span><span class="w"> </span><span class="n">Sep</span><span class="w"> </span><span class="mi">21</span><span class="o">,</span><span class="w"> </span><span class="mi">2014</span><span class="w"> </span><span class="n">at</span><span class="w"> </span><span class="mi">7</span><span class="o">:</span><span class="mi">10</span><span class="w"> </span><span class="n">AM</span>
<span class="n">subject</span><span class="o">:</span><span class="w"> </span><span class="n">OhLife</span><span class="w"> </span><span class="k">is</span><span class="w"> </span><span class="n">shutting</span><span class="w"> </span><span class="n">down</span>
</code></pre></div>
<p><a href="https://ohlife.com/shutdown">OhLife helps you remember what's happened in your life</a></p>
<p>We'll unfortunately be shutting OhLife down on October 4, 2014.</p>
<p>We started OhLife to help people remember what's happened in their life. But since then we haven't been able to grow our user base or make OhLife financially stable. Because of both these reasons we've decided to shut OhLife down. We appreciate everyone that's used OhLife and supported us.</p>
<p>We're extremely sorry for shutting the site down.</p>
<p>We have some FAQs below to help out. Thank you for all your support.</p>
<p>Thank you,
The OhLife Team</p>
<p>How do I export my entries?
You can save your entries to a text file here: https://ohlife.com/export
Please export them before we shut down and delete them on October 4, 2014.</p>
<p>How do I save photos?
The Past page (https://ohlife.com/past) has a list of all your entries, so you can quickly scroll through them to find your photos. If you click a photo it will take you to the original version.</p>
<p>What if I had a premium account?
If you had the premium version, a few weeks after we shut OhLife down we'll refund you a prorated amount.</p>
<h2 id="_2">分析<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<p>作为 YC 出身路演成功的创业项目,
为毛没有坚持到成功上岸?</p>
<ul>
<li>技术/产品/功能 大妈用下来都没有问题</li>
<li>那么有问题的只有: <code>为毛没能赚下来銭泥?</code></li>
</ul>
<p>官方曰: <code>用户量增长速率没能保持住</code></p>
<p>言下之意,就是</p>
<div class="highlight"><pre><span></span><code>銭赚没赚到
不重要
重要的是
用户量的增长
没能支撑一个大故事
</code></pre></div>
<p>那又是为什么呢?</p>
<p><code>OhLife</code> :</p>
<ul>
<li>的整个儿创意是: <code>以一种创意促动方式,来引导/加强/支持 人们愉快的写日志</code></li>
<li>此创意的伦理基点是: <code>生活值得记录</code></li>
</ul>
<p>但是,这一逻辑线缺少了一个关键爆点, 之于移动/互联网 而言,那就是:</p>
<ul>
<li><code>生活值得记录</code> 这一认知如何变成一个 <code>COOL</code> 的事件,成为互联网公识?</li>
<li><code>OhLife</code> 产品形态的成功在于 无干挠/私密性, 从而产生了一种只面对本我的直述心声的亲切感</li>
<li>但是,这一形态,也导致了,初始用户对 <code>OhLife</code> 的认同感,无法简单的分享/扩散/爆发出来</li>
<li>因为,一种秘密的安全/舒适感,是无法分享的,一但分享出来就变味儿了</li>
<li>以致, Gmail 病毒式的扩散手法无法在 <code>OhLife</code> 场景中复制</li>
<li>最终, <code>OhLife</code> 聚集了一批忠诚用户后,就没有然后了.</li>
<li>虽然,在此基础上进行了专业备份等收费尝试</li>
<li>可惜,都没有找到痒点,或是说即使作为一个小众服务, <code>OhLife</code> 最终也没有形成足够数量的用户基数.</li>
</ul>
<h2 id="_3">思考<a class="headerlink" href="#_3" title="Permanent link">¶</a></h2>
<p>不禁想到了另外一个类似的服务: </p>
<ul>
<li>http://dailythem.es/</li>
<li>一个以短篇写作来提高 E文 水平的自学督导服务.</li>
<li>其成功之处,就是将一种成功的自学方法,转换成了一种很 <code>COOL</code> 的社会性游戏</li>
<li>而且,从中自然挖掘出了合理的收费服务:<ul>
<li><code>真人批改作文</code></li>
<li>自动单词修正</li>
<li>...etc.</li>
</ul>
</li>
</ul>
<p><code>OhLife</code> 未来有机会上位的:</p>
<ul>
<li>保持原先独创的无感引导机制: <code>定制邮件提醒,回复就好</code></li>
<li>针对不同需求的用户,演化出不同的服务:<ul>
<li>表现欲强的,就给自动发布,以及相应订阅推荐服务</li>
<li>常规生活日志用户,提供更多入口,随时日志,以及收费的专业私人出版支持...</li>
<li>人性化事件理解,可以通过日志,自动提醒未来自个儿作什么事儿...</li>
<li>... etc.</li>
</ul>
</li>
</ul>
<p>只是,目测关键的关键,还是没有放开心神,尝试更多的可能性...?</p>
<p>可惜了, 和 Google reader 不同,这是一个封闭的好服务,
没有快速发展到足够的体量,供给团队足够的资源,转型出更多好服务.</p>
<h2 id="changlog">Changlog<a class="headerlink" href="#changlog" title="Permanent link">¶</a></h2>
<ul>
<li>140921 官方通知邮件引发直觉思考</li>
</ul>Pythonic口号的Pivot2014-09-16T19:42:42+08:002020-01-31T16:42:10+08:00Zoom.Quiettag:blog.zoomquiet.io,2014-09-16:/140916-pycon-slogen.html
<p><img alt="SimpleIsBeautiful(PNG 图像,731x681 像素)" src="http://wiki.woodpecker.org.cn/moin/SimpleIsBeautiful?action=AttachFile&do=get&target=130416-zq-simple-is-beautiful.png"/></p>
<p>可记得去年的<a href="http://python-china.org/topic/544#reply5">蠎年蠎衫(PythonisT-shirt)设计大赛! — Python China</a>
?</p>
<p>今年又来尝试了....</p>
<h2 id="_1">背景<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<ul>
<li><a href="http://sebsauvage.net/python/">"Life is short
(You need Python)"~sebsauvage.net - Python</a></li>
<li><a href="http://www.zhihu.com/question/20830223">"Life is short, use Python" 最初是谁在什么情况下 …</a></li></ul>
<p><img alt="SimpleIsBeautiful(PNG 图像,731x681 像素)" src="http://wiki.woodpecker.org.cn/moin/SimpleIsBeautiful?action=AttachFile&do=get&target=130416-zq-simple-is-beautiful.png"/></p>
<p>可记得去年的<a href="http://python-china.org/topic/544#reply5">蠎年蠎衫(PythonisT-shirt)设计大赛! — Python China</a>
?</p>
<p>今年又来尝试了....</p>
<h2 id="_1">背景<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<ul>
<li><a href="http://sebsauvage.net/python/">"Life is short
(You need Python)"~sebsauvage.net - Python</a></li>
<li><a href="http://www.zhihu.com/question/20830223">"Life is short, use Python" 最初是谁在什么情况下说的? - 知乎</a></li>
</ul>
<p>是的,一句无意间的代码注释,在 2007年,演化为 CPyUG 社区纪念TEE 的设计出处:</p>
<ul>
<li>演化成了: <code>Life is short, use Python!</code> </li>
<li>Gudio 那年也穿上了身
<a href="http://wiki.woodpecker.org.cn/moin/ObpLovelyPython/LpyAttachZoomq?action=AttachFile&do=get&target=beginning-1-zeuux-fashion-guido.jpg">LpyAttachZoomq(JPEG 图像,800x533 像素)</a></li>
</ul>
<p>然后,就没有然后了,,,因为 ZEUUX 的沉默,
做到 2013年, PyConChina 才在北京/珠海场的纪念TEE 上重构了设计,并发布为:</p>
<p><img alt="BdUGedICAAAzki7" src="http://zoomq.qiniudn.com/CPyUG/PyCon2013China/140106-@gvanrossum-BdUGedICAAAzki7.jpg-large.jpg"/>
<a href="https://twitter.com/gvanrossum/status/420249260961968128">Guido老爹也上过身</a></p>
<h2 id="_2">激发<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<p>今年呢? 依然有独家赞助可以重制,
虽然当初 ZEUUX 承诺绝版设计,永不复刻...</p>
<p>但是, <code>不折腾要死星人们</code> 是无法被阻止的!</p>
<p>首轮讨论记要如下:</p>
<h3 id="140916">140916 京蠎活动群<a class="headerlink" href="#140916" title="Permanent link">¶</a></h3>
<ul>
<li><code>@ZoomQuiet</code></li>
</ul>
<div class="highlight"><pre><span></span><code><span class="mf">2007</span><span class="o">-></span><span class="w"> </span><span class="n">Life</span><span class="w"> </span><span class="n">is</span><span class="w"> </span><span class="n">short</span><span class="p">,</span><span class="w"> </span><span class="n">use</span><span class="w"> </span><span class="n">Python</span><span class="err">!</span>
<span class="mf">2013</span><span class="o">-></span><span class="w"> </span><span class="n">Life</span><span class="w"> </span><span class="n">is</span><span class="w"> </span><span class="n">shit</span><span class="p">,</span><span class="kr">go</span><span class="w"> </span><span class="n">Pythonic</span><span class="err">!</span>
<span class="mf">2014</span><span class="o">-></span><span class="w"> </span><span class="n">Life</span><span class="w"> </span><span class="n">is</span><span class="w"> </span><span class="n">short</span><span class="p">,</span><span class="n">suck</span><span class="w"> </span><span class="n">Python</span><span class="err">!</span>
<span class="n">今年</span><span class="w"> </span><span class="n">PyCon</span><span class="w"> </span><span class="n">纪念</span><span class="w"> </span><span class="n">TEE</span><span class="w"> </span><span class="n">的文案</span><span class="p">,</span><span class="n">修订为</span><span class="p">:</span>
<span class="n">Life</span><span class="w"> </span><span class="n">such</span><span class="w"> </span><span class="n">short</span><span class="p">,</span><span class="n">be</span><span class="w"> </span><span class="n">Pythonic</span><span class="w"> </span><span class="err">!</span>
<span class="n">有妺纸说</span><span class="p">,</span><span class="n">人生苦短应该翻译为</span>
<span class="n">Life</span><span class="w"> </span><span class="n">such</span><span class="w"> </span><span class="n">suck</span>
<span class="n">很认同</span><span class="p">,</span><span class="n">但是</span><span class="p">,</span><span class="n">不敢用</span><span class="p">,,,</span>
<span class="n">Life</span><span class="w"> </span><span class="n">is</span><span class="w"> </span><span class="n">short</span><span class="p">,</span><span class="n">be</span><span class="w"> </span><span class="n">Pythonic</span><span class="err">!</span>
<span class="n">人生苦短</span><span class="w"> </span><span class="n">得Pythonic</span><span class="err">?</span>
</code></pre></div>
<ul>
<li><code>@AlbertLee</code></li>
</ul>
<div class="highlight"><pre><span></span><code><span class="nv">Life</span><span class="w"> </span><span class="nv">is</span><span class="w"> </span><span class="nv">short</span>,<span class="w"> </span><span class="nv">suck</span><span class="w"> </span><span class="nv">py</span>
<span class="nv">I</span><span class="w"> </span><span class="nv">never</span><span class="w"> </span><span class="nv">stopped</span><span class="w"> </span><span class="nv">pythonic</span>,<span class="w"> </span><span class="nv">I</span><span class="w"> </span><span class="nv">just</span><span class="w"> </span><span class="nv">stop</span><span class="w"> </span><span class="nv">showing</span><span class="w"> </span><span class="nv">it</span>
<span class="k">If</span><span class="w"> </span><span class="nv">you</span><span class="w"> </span><span class="nv">don</span><span class="s1">'t python,you don'</span><span class="nv">t</span><span class="w"> </span><span class="nv">python</span>
<span class="nv">Pythonic</span><span class="w"> </span><span class="nv">than</span><span class="w"> </span><span class="nv">pythonic</span><span class="w"> </span>
<span class="w"> </span>定要难受死处女座的...
</code></pre></div>
<ul>
<li><code>@Lothar</code></li>
</ul>
<div class="highlight"><pre><span></span><code>life's pathetic, let's pythonic
</code></pre></div>
<ul>
<li><code>@Adam:</code></li>
</ul>
<div class="highlight"><pre><span></span><code><span class="k">go</span><span class="w"> </span><span class="n">pythonic</span><span class="p">,</span><span class="w"> </span><span class="k">no</span><span class="w"> </span><span class="n">pathetic</span><span class="p">...</span><span class="w"> </span><span class="p">..</span>
<span class="n">人生苦短</span><span class="w"> </span><span class="n">Pythonic欢</span>
<span class="n">苦海无涯</span><span class="p">,</span><span class="n">python是岸</span>
<span class="n">人生苦短</span><span class="w"> </span><span class="n">Pythonic绽</span>
<span class="n">总是我就是强迫症想押韵</span><span class="p">..</span>
</code></pre></div>
<ul>
<li>为什么python程序员都这么短命... 还都这么痛苦... (逃)</li>
</ul>
<h2 id="_3">暂定<a class="headerlink" href="#_3" title="Permanent link">¶</a></h2>
<div class="highlight"><pre><span></span><code> life's pathetic, let's pythonic
人生苦短 得Pythonic?
</code></pre></div>
<h2 id="_4">思考<a class="headerlink" href="#_4" title="Permanent link">¶</a></h2>
<p>为什么 程序猿 就是如此纠结呢? 一个单词就可以引发这么多的情绪?
果断那谁无意间道出了真相?</p>
<div class="highlight"><pre><span></span><code>为什么python程序员
都这么短命...
还都这么痛苦...
</code></pre></div>
<h2 id="changlog">Changlog<a class="headerlink" href="#changlog" title="Permanent link">¶</a></h2>
<ul>
<li>140916 微信群引发</li>
</ul>电邮的自我防护2014-08-03T00:00:00+08:002020-01-31T16:42:10+08:00Zoom.Quiettag:blog.zoomquiet.io,2014-08-03:/140718-fsf-emailselfdefense-mac.html
<p><img alt="infographic" src="https://static.fsf.org/nosvn/enc-dev0/img/en/infographic-button.png"/></p>
<p><a href="https://emailselfdefense.fsf.org/en/mac.html">Email Self-Defense - a guide to fighting surveillance with GnuPG encryption</a></p>
<p>原主忒啰嗦了!</p>
<p>果断使用汉化信息图!</p>
<p><img alt="gnupg-infographic1" src="https://tonghuix.io/wp-content/uploads/2014/06/gnupg-infographic1.png"/></p>
<h2 id="changlog">Changlog<a class="headerlink" href="#changlog" title="Permanent link">¶</a></h2>
<ul>
<li>140916 转发 <a href="https://tonghuix.io/2014/06/email-selfdefence-gnupg/#">使用 GnuPG 进行电子邮件的自我防御[FSF信息图中译] » Open Source Geek | 爱开源 …</a></li></ul>
<p><img alt="infographic" src="https://static.fsf.org/nosvn/enc-dev0/img/en/infographic-button.png"/></p>
<p><a href="https://emailselfdefense.fsf.org/en/mac.html">Email Self-Defense - a guide to fighting surveillance with GnuPG encryption</a></p>
<p>原主忒啰嗦了!</p>
<p>果断使用汉化信息图!</p>
<p><img alt="gnupg-infographic1" src="https://tonghuix.io/wp-content/uploads/2014/06/gnupg-infographic1.png"/></p>
<h2 id="changlog">Changlog<a class="headerlink" href="#changlog" title="Permanent link">¶</a></h2>
<ul>
<li>140916 转发 <a href="https://tonghuix.io/2014/06/email-selfdefence-gnupg/#">使用 GnuPG 进行电子邮件的自我防御[FSF信息图中译] » Open Source Geek | 爱开源未来</a></li>
<li>140803 偶遇抄转</li>
</ul>How to argue for Python's use2014-07-18T00:00:00+08:002020-01-31T16:42:10+08:00Zoom.Quiettag:blog.zoomquiet.io,2014-07-18:/140718_Brett_Cannon-How2argue4Python-use.html
<p><a href="http://nothingbutsnark.svbtle.com/how-to-argue-for-pythons-use">How to argue for Python's use</a></p>
<p>Recently I wrote a blog post about how I don't worry about Python losing users. Within minutes I had people asking about Python's usage, which the post was not about and is a very different thing to worry about. See, it looks like the …</p>
<p><a href="http://nothingbutsnark.svbtle.com/how-to-argue-for-pythons-use">How to argue for Python's use</a></p>
<p>Recently I wrote a blog post about how I don't worry about Python losing users. Within minutes I had people asking about Python's usage, which the post was not about and is a very different thing to worry about. See, it looks like the number of people using Python will continue to be high into the future, but whether Python will be used for as many projects is not guaranteed; the number of users is great and seems secure, but the number of uses of Python in projects is not nearly as certain.</p>
<p>This blog post is meant to help show how Python is still very much viable for most software projects out there. I'm not going to worry about selling Python to people going up against other dynamic languages like Ruby as I think those battles tend to come down to personal taste. What this is meant for is people dealing with teammates trying to sell statically typed languages. Specifically, this post is going to be geared towards arguing against Go, but it could be any statically typed language.</p>
<p>"Why Go?", you might ask. Well, because Go is actually gaining users at Python's expense. Ever since Python's growth trajectory went hockey stick starting between 2003-2005, Python itself has not been the king of the hill to unseat; it was the underdog. Traditionally Python has captured users from languages like Java and then kept them (I'm not going to argue about C++ users because typically they are have severe performance needs, need a systems language, or performance addicts and need to go into rehab). But things are different with Go. Python is now one of the top languages in terms of use out there, taking away our underdog stance. And for once there is another language out there coming from the statically typed programming language community whose productivity/performance tradeoff is good enough to convince some Python programmers to choose Go over Python.</p>
<h2 id="go-today">Go, today<a class="headerlink" href="#go-today" title="Permanent link">¶</a></h2>
<p>I should start out saying that Go is currently my second favourite language. If I were asked to start a new project today and I couldn't convince people to use Python I would argue for Go's usage instead. Do not read this blog post as me saying that Go is a bad language. The key point of this blog post is to convince others that Python is very much a viable alternative to Go in the productivity/performance tradeoff game, not that Go is bad. Read this blog post as anti-Go and you're taking something personally that you shouldn't.</p>
<p>I should mention that I use Go at work on occasion and try to follow the language's community somewhat. Now this does not make me an expert in Go by any stretch of the imagination, but I'm not pulling knowledge out of docs and blogs posts alone either. But I am on the Python development team, so do realize that no matter how fair I try to be, inherent bias will be there to some extent.</p>
<p>So, with those caveats out of the way, let's look at what Go offers a programmer.</p>
<h3 id="productivity">Productivity<a class="headerlink" href="#productivity" title="Permanent link">¶</a></h3>
<p>The way I like to view Go is take your favourite dynamic programming language, start removing features that make speeding it up hard, and you end up with Go. Static typing is kept to to a minimum as it is typically only in your face at API boundaries. Structural typing also makes things easier to work with (think of it much like duck typing). The syntax isn't heavy-handed (although it does use curly braces). Don't view Go as C/C++ with unsafe features removed and some productive bits added on or else you will end up frustrated (e.g. "why can't I use the make() built-in or have varying return value counts like the map type?" is the wrong way to view the language; this is a reason why C++ programmers have not switched to Go). Really fast compile times also makes the development cycle feel more like a dynamic language than a compiled one. And some people actually prefer the verbosity gained from not having exceptions as it forces you to deal with exceptional cases instead of (accidentally) ignoring them (this is an instance of Go's initial systems programming design showing through). Add on that the language itself is rather small and fits in your head and has strict forward-compatibility requirements for itself (you are not getting generics any time soon), and coding in Go is basically pleasant to work with.</p>
<p>Being statically typed, Go gets to have tooling support fairly cheaply (it also helps the language was somewhat designed for it early on). In a shrewd move, Go made sure the core tooling needs actually come with Go itself. go fmt enforces Go's style guidelines and also allows for refactorings through custom rules (which also make the whole "use tabs for indent" thing a non-issue since it means you set up your editor to represent tabs however you want and then go fmt makes it universally tabs for your VCS). go fix updates code to meet changes made to the language since the last release. go get fetches dependencies and installs them.</p>
<p>The last productivity perk of Go is that it statically compiles everything, making deployment simpler. This isn't quite a big deal, though, if you are using containerization for your development and deployment. This is a big deal, though, if distribute a command-line tool as it becomes just a single file to ship instead of a collection of dependencies plus your code.</p>
<h3 id="performance">Performance<a class="headerlink" href="#performance" title="Permanent link">¶</a></h3>
<p>In terms of raw performance, Go does well. It's hard to point to any one benchmark that definitely shows that Go is always the fastest choice since even the The Computer Language Benchmarks Game show some benchmarks where CPython 3 is faster. But in general you should consider Go fast enough for your needs no matter the work.</p>
<p>But where Go really shines is with concurrency. Now do realize that concurrent code does not mean parallelized code which is a common misconception; concurrent code can still be single-threaded, it just makes task switching easier/better. Go has goroutines which make it dead simple to fire off code to execute concurrently. The language provides communication channels which allows for very clean message-passing style of concurrent programming if you don't want to go down the shared memory route which is also supported. And with all of this integrated into the language it makes it second nature to write concurrent code where (easily) possible. In other words Go programs can be fast and the language tries to empower you to do that in a reasonable fashion.</p>
<h2 id="python-today">Python, today<a class="headerlink" href="#python-today" title="Permanent link">¶</a></h2>
<p>Hopefully I have convinced you that Go is a good programming language, if for any other reason it will help dispel some people from thinking I poorly portrayed Go in this whole discussion. But let's now discuss how the productivity/performance tradeoff looks for Python.</p>
<h3 id="productivity_1">Productivity<a class="headerlink" href="#productivity_1" title="Permanent link">¶</a></h3>
<p>First and foremost, Python is very easy to learn. There's a reason why Python is currently the top choice for a teaching language at top-rated US universities. That equates to a steady stream of new programmers already versed in the language as well as showing it's easy to teach other programmers. I also don't think it's hard to convince people that you can definitely get a lot done in a few lines of Python code (the Go/Python 3 comparison shows that Python can accomplish solutions in less code than Go every time). So I would argue no one should disagree that you can be highly productive in Python, even compared to Go.</p>
<p>Where people typically start to argue against Python is in tooling support. But if you look at the various tools I pointed out for Go – fmt, fix, and get – there is a Python equivalent found from the community. For style formatting that follows PEP 8, there is pep8 for commit-check time or autopep8 if you want more go fmt style automatic rewriting. For go fix or go fmt for refactoring you could argue that 2to3 performs the same function. As for go get, Python has pip. And instead of statically compiled binaries we have venv/virtualenv or code freezing like cx_Freeze (on top of containerization like anything else). There's even code analysis through projects like pylint. Arguing that Python can't work for large projects due to the lack of tooling support has always seemed like a shallow argument to me.</p>
<p>And if there is one place where Python definitely does well, it is in the breadth and depth of the third-party libraries and tools available as seen on PyPI (I'm sure someone somewhere is snickering that "not all of those run on Python 3", which is true but the support is pretty darn good for Python 3 and simply continues to improve so I don't worry about that argument, plus you can code targetting Python 2/3 simultaneously and then really not care about which version you aim for). While looking at godoc.org shows that Go is not exactly lacking in community support, Python's age alone guarantees it has more third-party libraries available to it and will continue to do so.</p>
<h3 id="performance_1">Performance<a class="headerlink" href="#performance_1" title="Permanent link">¶</a></h3>
<p>Because Python has been around for so long and become so big, simply saying "Python is fast enough" doesn't tell the whole story thanks to the various implementation options and speed-ups that are available. But before diving into VM-level options, it should be mentioned that Python's stdlib offers options to gain speedups. For instance, concurrent.futures a dead-simple way to execute embarrassingly parallel code concurrently. And the new asyncio makes writing asynchronous code in Python 3.3 and newer much easier. While it might not be integrated into the language like it is with Go, concurrent programming in Python is doable and not necessarily in a painful way.</p>
<p>But one of the biggest ways you can influence the performance of your Python code is in your selection of VM.</p>
<h3 id="cpython-cython">CPython + Cython<a class="headerlink" href="#cpython-cython" title="Permanent link">¶</a></h3>
<p>If you are working with a C extension module, then CPython is your best option (and if you don't know the nomenclature, CPython is the interpreter you get at python.org). Performance is at least reasonable for most things – for some reason some people think the Python development team doesn't care about performance which is a lie – and it is obviously going to have the newest features as CPython also acts as the language specification.</p>
<p>If you do find yourself wanting a bit more speed for some inner loop code, Cython is an option with CPython. Cython will transpile your Python code into C extension code as best as possible. There are supported ways to make it allow for better C code, so it all depends on how Cython-specific you want to get. Cython also makes it easier to write C extension modules (but keep reading for an alternative that supports more than CPython).</p>
<h3 id="pypy-cffi">PyPy + cffi<a class="headerlink" href="#pypy-cffi" title="Permanent link">¶</a></h3>
<p>If you are not reliant on a pre-existing C extension module, then PyPy will give you the best overall performance. Its JIT is great and the team welcomes the challenge of code that runs faster in CPython as they hate being slower as shown by speed.pypy.org. Honestly, unless PyPy doesn't support a version of Python you really want to use – since PyPy typically lags behind by 2 versions, e.g. pypy3 currently supports Python 3.2 while 3.4 is the latest CPython release; they are always looking for donations to help with this – I would only consider not using PyPy because you rely on a pre-existing C extension module (numpy is a common reason, but even there PyPy is looking for donations to fix that problem).</p>
<p>That doesn't mean, though, that if you need to wrap some C code you can't use PyPy. The PyPy project has another project called cffi which is meant to facilitate the wrapping of C code for use by Python code. The key benefit to using cffi is that if you use it then the C code can be used in CPython and PyPy (IronPython and Jython I believe are also working on adding support for cffi). So if you are wrapping C code I would strongly suggest you look at cffi over a hand-crafted C extension module or Cython so you can have better Python implementation support and be able to use PyPy.</p>
<h2 id="numba">Numba<a class="headerlink" href="#numba" title="Permanent link">¶</a></h2>
<p>If you're doing numeric work, then Numba is an option you should definitely consider. Economists are noticing its performance when it comes to scientific computing. While it won't necessarily help out when it comes to general Python programming, Numba's use of LLVM to perform JIT does help when using things such as numpy or other module in Python's very strong scientific computing stack.</p>
<h2 id="python-tomorrow">Python, tomorrow<a class="headerlink" href="#python-tomorrow" title="Permanent link">¶</a></h2>
<p>With all of that taken into account, Python is definitely not standing still (nor is Go, e.g. they are busy rewriting their compiler in Go and shifting things out of the linker into the compiler for even faster compilation speed). Python's future continues to look bright.</p>
<h3 id="productivity_2">Productivity<a class="headerlink" href="#productivity_2" title="Permanent link">¶</a></h3>
<p>Python is an evolving language. Unlike Go, Python is willing to change the language, even in ways that won't be backwards-compatible forever. This means Python can become even more productive over time at a faster rate than Go typically can (although until a Go 2 begins development it is unknown what kind of stance the Go team will take for language evolution).</p>
<p>On the tooling front, there is work to standardize a set of function annotations for declaring types. This came up during the PyCon 2014 language summit where there was agreement that enough projects were now wanting a way to declare the expected types for function parameters and return values that using function annotations to think about standardizing on something that could maybe end up in the stdlib would be useful. The discussions have not started yet on the pytypedecl mailing list, but I know a PEP is about to be started. This could be beneficial to not just projects like Cython and Numba where the type information could be used, but also in tooling like code analysis, refactoring, etc.</p>
<h3 id="performance_2">Performance<a class="headerlink" href="#performance_2" title="Permanent link">¶</a></h3>
<p>Long-term, there are two projects that could help with Python's performance. One is a new Python VM called Pyston. It's very new, but its goal is to use LLVM's JIT (yes, this sounds like Unladen Swallow, but LLVM's JIT is better than it was back in 2009 so there's hope the project will lead to some good results).</p>
<p>But the project that really has me excited is the PyPy-STM project. The "STM" stands for "software transactional memory" and it basically allows Python to ditch the GIL. The performance is now 1.2x-3x slower than PyPy which is very respectable. They are currently looking for donations to continue the work to reach the goal of pypy-stm with 2 threads is universally worth running over vanilla PyPy.</p>
<h2 id="making-the-choice-at-least-murky">Making the choice at least murky<a class="headerlink" href="#making-the-choice-at-least-murky" title="Permanent link">¶</a></h2>
<p>Hopefully one comes out of this blog post realizing that Go is not the end-all, be-all answer to the productivity/performance tradeoff. Python definitely has great productivity perks and it is no slouch in the performance realm either, making it still my language of choice. If you find yourself potentially choosing something other than Python for a project, please make sure to stop and think about the productivity loss from not using Python and then look at the various options you have for making Python execute quickly so that you make an informed choice as to whether Python will work for your project.</p>
<h2 id="changlog">Changlog<a class="headerlink" href="#changlog" title="Permanent link">¶</a></h2>
<ul>
<li>1406?? </li>
<li>140728 偶遇抄转</li>
</ul>On object-oriented programming2013-12-24T00:00:00+08:002020-01-31T16:42:10+08:00Zoom.Quiettag:blog.zoomquiet.io,2013-12-24:/131224-yw-on-oop.html
<h1 id="_1">翻越分享原文<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<ul>
<li>via: http://yinwang0.wordpress.com/2013/12/24/on-object-oriented-programming/</li>
<li>Posted by Yin Wang in <a href="http://yinwang0.wordpress.com/category/oop/">oop</a>,<a href="http://yinwang0.wordpress.com/category/programming-languages/">programming languages</a></li>
</ul>
<p><img alt="yw_dark_age_battle.jpg" src="http://zoomq.qiniudn.com/ZQCollection/img/yw_dark_age_battle.jpg"/></p>
<p>[written at the end of 2013 AD, during the Dark Ages of programming]</p>
<p>The programmer's world is full of fads and superstitions. Every now and then there …</p>
<h1 id="_1">翻越分享原文<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<ul>
<li>via: http://yinwang0.wordpress.com/2013/12/24/on-object-oriented-programming/</li>
<li>Posted by Yin Wang in <a href="http://yinwang0.wordpress.com/category/oop/">oop</a>,<a href="http://yinwang0.wordpress.com/category/programming-languages/">programming languages</a></li>
</ul>
<p><img alt="yw_dark_age_battle.jpg" src="http://zoomq.qiniudn.com/ZQCollection/img/yw_dark_age_battle.jpg"/></p>
<p>[written at the end of 2013 AD, during the Dark Ages of programming]</p>
<p>The programmer's world is full of fads and superstitions. Every now and then there will be somebody who come up and announce: "I can save the world!" No matter whether the ideas are good or not, there will always be followers, and the ideas soon become their religion. They then develop their community or camp, try to let those ideas dominate the world, and try to make the ideas live forever.</p>
<p>Object-oriented programming (OOP) is such a religion which claimed to be able to save the world from the so-called "software crisis". As a hindsight after so many years since it was introduced, not only didn't OOP save us, it brought us more confusion and harm than benefits. Unfortunately its dogmas and mispractices have become wide-spread and deeply intrenched. In this article, I hope to provide my viewpoint into this matter and try to find out the lessons that we can learn.</p>
<p>Like every article on my blog, the opinions are completely personal and not representing my employers or professors.</p>
<h2 id="is-everything-an-object">Is everything an object?<a class="headerlink" href="#is-everything-an-object" title="Permanent link">¶</a></h2>
<p>"Everything is an object" is the core dogma of OOP and deemed as the highest standards of OO language design. Now let's take a careful look to see if it is true, or if it is a good idea to make things that way.</p>
<p>Many people take "everything is an object" for granted because when this sentence is taken literally it matches their everyday experience. Since the word "object" in English basically means "a thing", how can "everything is an object" be not true? But be careful since the definition of an "object" in OOP has a specific meaning which is very different from what it means in English.</p>
<p>OOP's definition of an
<a href="http://en.wikipedia.org/wiki/Object-oriented_programming">object</a>
is "a combination of
<a href="http://en.wikipedia.org/wiki/Field_(computer_science)">data fields</a>
(attributes that describe the object) and associated procedures known as
<a href="http://en.wikipedia.org/wiki/Method_(computer_science)">methods</a>
". Can you really fit everything into this model?</p>
<p>First let's look at the real world and see if this definition can capture everything. Cars, trees, animals may sometimes be thought of as objects, but what about a change of the objects' position, its velocity and duration? What methods do they have? Well, you may define classes called Velocity or Time, with methods such as addition, but do velocity and time really contain the things that you call "methods"? They don't. They are just your imagination. You can add the velocities or time, but how can velocities or time contain the addition procedure? This is like saying that the bullets contain the gun.</p>
<p>So the most you can say is that "everything is an object" is a good way of thinking, but that is not true either. The definition of an object implies that a method can only belong to one object, but most of the time it doesn't make sense thinking of functions as belonging to any object. Say we have the expression 1+2, does the operator '+' belong to 1, or does it belong to 2? You have to make some arbitrary choice. Since you can make a choice, this means the '+' operator doesn't really belong to either of them. It is inherently outside of the objects.</p>
<p>So thinking of some things as objects may be helpful, but thinking of
<code>everything</code> as an object is neither true nor useful. Unfortunately "everything is an object" has been taken as a dogma and the highest standard of OO language design. Some OO languages claim that everything is an object in them. Whenever you notice that something is not an object, somebody will try to make it one. They may succeed in that, but things get very complicated that way, because that's not how things work.</p>
<p>The idealism of "everything is an object" is similar to "everything is a function" in the functional programming world and "everything is a set" in the math world. Before computer science was conceived there was a thing called the
<a href="http://en.wikipedia.org/wiki/Lambda_calculus">lambda calculus</a>
. Some people encoded everything including numbers and their operations, various data structures and control structures, ... all in lambdas. One of the encodings of numbers is called the
<a href="http://en.wikipedia.org/wiki/Church_encoding">Church numeral</a>
. Every programming language researcher has played with them during their training. But unlike "everything is an object", "everything is a function" has never become a dogma or marketing phrase. Those formulations sometimes provide mental exercises and inspirations to the researchers but nobody really use them for actual computation, because they are inefficient and they are not really how things work. They are just approximations (models) to some essence of computation that we can't see. If you really use them for practical projects, things become complicated.</p>
<p>Mathematicians have a similar thing: set theory. Some geniuses encoded everything — numbers, operations on numbers, mathematical structures, ... all in sets. Everything is just sets containing sets containing sets and so on. What's the problem? But when they really tried to do their proofs using those sets, the proofs fell under their own weights. Too complicated. Even with the complexity, set theory is not expressive enough to capture whatever the mathematicians have to say. Many people tried to fix it, but they all failed.</p>
<p>So "everything is an object" is in some sense on the same track of "everything is a function" and "everything is a set". Good thought exercise, but doesn't really work well in practice. I don't think that there is some "one true language", but this model of OOP is too far from correct or practical. It's somewhat like the
<a href="http://en.wikipedia.org/wiki/Flat_Earth">flat earth theory</a>
. Until today
<a href="http://theflatearthsociety.org/">some people</a>
still believe that the earth is flat and make all kinds of theories to prove it. Some of their arguments look very scientific, but do you believe in their formulas or a picture of the earth from the ISS? When you get the fundamental things wrong and don't throw them away, you have to patch them endlessly with even more complicated theories. And that's what happened to OOP.</p>
<p><img alt="yw_flat-earth.png" src="http://zoomq.qiniudn.com/ZQCollection/img/yw_flat-earth.png"/></p>
<h2 id="are-functions-objects">Are functions objects?<a class="headerlink" href="#are-functions-objects" title="Permanent link">¶</a></h2>
<p>From what I know, the original motivation of putting functions inside objects was to support GUI applications. You click on a button and some function (a callback) will be invoked. For the convenience of referring to the button, the callback takes the triggered object as its first argument. Since the callback does nothing more than this, it seems to be convenient to just store it inside the button. And thus we had an "object" which combines the attributes of the button and a method (the callback). Indeed this is a good idea, but this limited usage case can't really justify a universal notion of "everything is an object", just like a two-mile walk can't prove that the earth is flat.</p>
<p>If you really understand what is abstraction, you may have noticed that even the above story contains a subtle mistake: the callback in the button is not really a method. The true purpose of a method is to provide abstraction to the attributes, but the callback's purpose is not to provide abstraction. It is just a usual function triggered by the button, which happens to take the button as its first argument.</p>
<p>Very few functions should be considered methods of an object. If you look carefully, most of the time the objects just serve as a namespace (or module) in which you can store attributes and functions, but those functions don't logically belong to the objects. They just take the objects as inputs and produce some output. Only the functions that are most intimately connected to the attributes and provide an abstraction layer to them should be considered methods. Most of those are called "getters", "setters" or "iterators".</p>
<p>In some languages such as Scala or Python, functions are also treated as objects. But actually they just wrapped the functions into an object, give them some name such as "apply" or "<strong>call</strong>", so that when the objects are "invoked" you know which functions to call. But putting a function into an object doesn't really mean that functions are also objects, just like inviting friends to your house doesn't make them your family.</p>
<p>Functions are fundamental constructs. They don't belong to objects. They describe a change, transition or transformation of objects. They are not objects and can't be simulated by objects. They are like a base case of an inductive definition. They are where the illusion of "everything is an object" ends.</p>
<h2 id="the-cost-of-excessive-abstraction">The cost of excessive abstraction<a class="headerlink" href="#the-cost-of-excessive-abstraction" title="Permanent link">¶</a></h2>
<p>The major appeal of OOP is abstraction (and thus code reusing and DRY), but actually most of those abstraction facilities are already provided by traditional procedural languages and functional languages. Some of them do it even better than OO languages. OO claims its originality by emphasizing abstraction much more strongly than other languages. The result is that OO programmers usually overdo it. Some of them pursue abstraction and code reusing to the degree as if they are everything about programming.</p>
<p><img alt="yw_screen-shot-2014-01-02-at-2-02-38-am.png" src="http://zoomq.qiniudn.com/ZQCollection/img/yw_screen-shot-2014-01-02-at-2-02-38-am.png"/></p>
<p>For the purpose of code reusing, OO encourages a level of abstraction which makes programs hard to understand and hard to analyze. I often see Java programs with multiple levels of inheritance, overloading and design patterns, but actually doing very little. And because there is so much code that doesn't do useful things, it is really hard to find out which part of the code is doing the thing you want. It is like going through a maze. Another nice word for this is "robustness". If I have to go into all this trouble to make code reusable or robust, I'd rather just make copies of the code and modify them, but keep each copy simple and easy to understand.</p>
<p>Whenever you criticize Java or C++ for their verbosity, OO proponents will tell you that they are not authentic OO languages. They would ask you to look at Smalltalk. If Smalltalk's ways are that good, why almost nobody is using Smalltalk now? Because there are real problems in its approach. I think Smalltalk is the origin of over-abstraction and over-complication you find in other OO languages.</p>
<p>The "authentic" OO style of Smalltalk promotes the notion of "extremely late binding", which basically means that the meaning of the program constructs is determined as late as possible. Late binding gives you a chance to swap out the underlying implementation without forcing the upper levels to change, but this also means that you are no longer sure what a piece of code means. When I look at expressions such as '1+2′ and 'if (t) then ... else ... ' in Java or C++, I at least know for sure that they mean an integer addition and an usual conditional. But I'm no longer sure about this in an "extremely late binding language", because the meaning of '+' and 'if" can be redefined. Giving the programmers the power of defining control structures is a bad idea, because soon your language will be abundant of quirky control structures designed by programmers who try to be clever. It will no longer be the language that you used to know.</p>
<p>An example for this feature is Smalltalk's conditional structure, which looks like this:</p>
<div class="highlight"><pre><span></span><code><span class="nv">result</span> <span class="o">:=</span> <span class="nv">a</span> <span class="nf">></span> <span class="nv">b</span>
<span class="nb">ifTrue:</span>[ <span class="s">'greater'</span> ]
<span class="nb">ifFalse:</span>[ <span class="s">'less or equal'</span> ]
</code></pre></div>
<p>You send a message ifTrue: to a Boolean object, passing as an argument a block of code to be executed if and only if the Boolean receiver is true.</p>
<p>First of all, if you really have a well-designed language, you shouldn't be wanting to define your own control structures. As a seasoned Lisp/Scheme programmer, I have seen many custom-designed control structures (such as the various looping macros) over the years, but none of them turned out to be good ideas. I'd rather write slightly longer and more verbose code in the vanilla language than to learn those weird control structures. Second, if you are really genius enough to have invented another good control structure, the late binding feature of Smalltalk probably won't provide you the necessary power for defining it. The power of functions as an abstraction tool is limited. It is strictly less powerful than Lisp/Scheme's macros. Third, this feature of Smalltalk is not really a novel approach and it has a big problem. A similar but more beautiful conditional construct had been defined in lambda calculus since before computer science was born:</p>
<div class="highlight"><pre><span></span><code><span class="nv">TRUE</span><span class="w"> </span><span class="nb">=</span><span class="w"> </span><span class="nv">λx.λy.x</span>
<span class="nv">FALSE</span><span class="w"> </span><span class="nb">=</span><span class="w"> </span><span class="nv">λx.λy.y</span>
<span class="nv">IF</span><span class="w"> </span><span class="nb">=</span><span class="w"> </span><span class="nv">λb.λt.λf.b</span><span class="w"> </span><span class="no">t</span><span class="w"> </span><span class="nv">f</span>
</code></pre></div>
<p>This is very beautiful and can be done in any functional language, but why none of the functional languages implement conditionals this way? Because when you see an expression IF b t f, you will have no idea whether it is a conditional or not, because IF can be redefined in the program. Also because IF is just a function, it may also accept unexpected values other than TRUE or FALSE. This may happen to make the conditional construct work but cause trouble later on. This is called "unintentional semantics". This kind of bug can be very hard to track down.</p>
<p>This approach also makes compiler and static analysis hard. When the compiler sees IF b t f, it no longer knows that it is a conditional and thus optimize it that way. It has to treat it as a usual function call. Similarly when the type checker sees it, it doesn't know what type to expect for b, because it may not be a conditional at all. The above argument against the lambda calculus can easily be adapted to Smalltalk.</p>
<p>So abstraction is a powerful weapon when used moderately, but when you do it in excess, it backfires. Not only does it make it hard for humans to understand the code, it makes automated analysis tools and compiler optimizations difficult or impossible to make.</p>
<h2 id="design-patterns-the-brain-eater">Design patterns, the brain eater<a class="headerlink" href="#design-patterns-the-brain-eater" title="Permanent link">¶</a></h2>
<p>Although OO languages are touted for their ways of abstraction, they are actually not strong in terms of abstraction ability and expressiveness. There are certain things that are very easy to do in traditional procedural languages and functional languages, but was made unnecessarily hard in OO languages. This is why design patterns appeared. Design patterns' origin was mostly due to the dogma of "everything is an object", the lack of high-order functions (or the correct implementation of them) and OO's tendency of mystifying things.</p>
<p>When I first heard about design patterns I was already a PhD student at Cornell doing some PL research. I mostly used Standard ML and Haskell. After hearing my friends' high opinions of the
<a href="http://en.wikipedia.org/wiki/Design_Patterns">Design Patterns</a>
book (nicknamed the "GoF" book), I developed curiosity about its fame, so I borrowed one from the library. Within a few hours I found a mapping from all the weird names it introduced to the programming techniques I had been using all the time. Some of them are so fundamental and exist in every high-level language, so they don't really need names. Most of the advanced ones (such as visitor) are transcriptions of functional programming concepts into a convoluted form in order to get around OO language's limitations. Later on I found that Peter Norvig already gave a
<a href="http://norvig.com/design-patterns">talk</a>
on design patterns as early as 1998, pointing out that almost all of the design patterns will be "transparent" once you have first-class functions. This confirmed my observations — I don't need them.</p>
<p>I have to admit that some of the design patterns are cleverly designed and contain some ingenuity. You really need to get to the essence of the OO languages' internal designs and also understand lots of functional programming techniques in order to create them. But intelligence =/= wisdom. Even if they can achieve what functional languages can do, they are usually a lot more complicated. Choosing the hard ways can't really prove your genius. When you have first-class functions, things become so much easier and you won't even notice the design patterns' existence. Like Peter Norvig said, they will become transparent. So what a good language designer should do is to add first-class functions into the language instead of proposing design patterns as workarounds.</p>
<p>Every time I remove a design pattern (some other people wrote), the code becomes simpler and more manageable. I just removed the last visitor pattern from my Java code a few days ago and I felt so relieved. They gave me nothing but extra work when they existed. They hindered my progress. By deeply understanding how OO languages are implemented, you can write more advanced things than those provided by visitor patterns but without actually using them. I owe these insights into design patterns to some functional programming people. If you really want to understand the essence of OO design patterns and how NOT to use them,
<a href="http://www.amazon.com/Little-Java-Few-Patterns/dp/0262561158">this little book</a>
may be a good starting point.</p>
<p>Unfortunately design patterns somehow got really popular in companies, to the degree of unbearable. I saw the GoF book on almost every bookshelf when I interned at Google. Even if you don't write them yourself, there was almost no way you could avoid other people slipping design patterns into your code. Design patterns' marketing strategy as I perceived was much like weight loss products: "It can burn your fat without you doing any work!" They appeal to some new programmers' hope that they can write programs without understanding the fundamental concepts of computer science. Just by applying several patterns and patching things together, they hope to have a good program. This is too good to be true. You end up doing more work than you hoped to avoid. Design patterns eat programmers' brains. After using design patterns for some time, they no longer see things or write programs in clear and straightforward ways.</p>
<h2 id="what-is-an-oo-language-any-way">What is an OO language any way?<a class="headerlink" href="#what-is-an-oo-language-any-way" title="Permanent link">¶</a></h2>
<p>To this point we haven't yet talked about what makes a language an "OO language" and what makes it not. Is it an OO language just because I can put both data fields and functions into a record? Or is it an OO language only if it also provides extremely late binding? How about inheritance, overloading, etc etc? Must I have all of them? Any of them?</p>
<p>It turns out that there is no good answer to this question. There really is no such thing as an "object-oriented language". Objects can be part of a language, but it is just a small part of it. You can't really say that a language is object-oriented just because it provides objects as a feature. The so-called OO languages are solidly rooted in traditional procedural programming (PP). OOP basically stole everything from PP, renamed the terminologies and acted as if the ideas were its own.</p>
<p>Historically the term OO was mainly used for marketing reasons. It could give a language some advantages of attracting people if you claim it to be an OO language, but now this advantage is diminishing because more and more people have realized the problems of OO's methodology.</p>
<h2 id="harm-in-education-and-industry">Harm in education and industry<a class="headerlink" href="#harm-in-education-and-industry" title="Permanent link">¶</a></h2>
<p>Although OO has lots of problems, it is very successful in marketing and has risen to a dominant position over the years. Under social and market pressure, many colleges started using OO languages such as Java as their introductory language, replacing traditional procedural languages such as Pascal and functional languages such as Scheme. This in a large degree caused the students' failure to learn the most essential concepts of programming. The only thing that OO emphasizes is code reusing, but how can you teach it to the students who can't even write usable code, not to mention that code reusing is not really as important as some people believe.</p>
<p>At both Cornell and Indiana, I have been a TA for introductory programming courses in Java. I did it for multiple semesters. I still remember how confused the students were. Most of them had trouble understanding things such as the meaning of "this", why everything needs to be put inside classes, why make every field private and use getters, the difference between a method and a static method, etc etc.</p>
<p>There is a good reason that they don't understand — because OO is not how things work. Most of the time I feel that I was teaching design flaws and dogmas. Many of them learned very little in the end. Worse, some of those students really believed in OO. They ended up being proud of writing over-engineered and convoluted code. They no longer see things or write programs in straightforward ways. This is sad. I feel that we are no longer educating students as creative and critical thinkers, but mindless assembly line workers.</p>
<p><img alt="yw_modern-times.jpg" src="http://zoomq.qiniudn.com/ZQCollection/img/yw_modern-times.jpg"/></p>
<p>In industry, OO hasn't really proved its effectiveness with evidence. Good systems may be built in a "OO language", but the code is often written by people who understand the problems of OO and don't embrace "everything is an object" or "design patterns". Good programmers usually use workarounds in OO languages and are essentially writing in a traditional procedural style combined with bits from functional programming. So some OO languages and their tools may be pretty widely used, but the OO style doesn't really have much influence on the advancements of programming as a field.</p>
<h2 id="final-word">Final word<a class="headerlink" href="#final-word" title="Permanent link">¶</a></h2>
<p>So what does this post has to say? A jihad against OO languages? Advocate functional programming? Neither. As I said, there is no such thing as an "OO language", so where is the war? Every so-called OO language also contains good elements that it borrowed (or stole) from procedural languages or sometimes functional languages, so they are not completely useless.</p>
<p>But honestly, it is the extra features added by OO (in addition to procedural programming, PP) that are causing most of the problems. There is no denial of PP's value. Those extra "true OO techniques" contain way more confusion than real value, to the point that their value is negligible. In my experience, accepting even one or two of those ideas may put you into a series of troubles and wrong ways of thinking which may take a long time to examine and recover.</p>
<p>Thus I suggest not to buy OO's way of thinking and don't try to exploit its "features". They are usually brain eaters that you want to stay away from. By eschewing those problematic features, you can still produce acceptable programs in an "OO language", because you are basically using it as an non-OO procedural language.</p>
<h1 id="-">试理解 ;-) 快译畅读<a class="headerlink" href="#-" title="Permanent link">¶</a></h1>
<p><img alt="yw_dark_age_battle.jpg" src="http://zoomq.qiniudn.com/ZQCollection/img/yw_dark_age_battle.jpg"/></p>
<p>[写在2013年尾,编程的黑暗时代.]</p>
<p>程序猿的世界充斥着各种时髦迷信.不时就有人跳出来吼:"俺能拯救世界!"诡异的是,无论多不靠谱的想法,总有追随者,并快速打造成全站的宗教,结成社区,尽量迫使其它所有人认同,以使这想法永存下去.</p>
<p>面向对象编程(OOP)就是宣称能将世界从所谓:"编程危机"中拯救出来的宗教.
然而,
即便在其引入这么多年以后,
OOP 不仅没有拯救世界,相比它宣称带来的好处, 带来了更多的混乱以及伤害,
不幸的是,其教条以及错误,
已经 根深蒂固的广泛植根于这世界.
本文,俺希望就此提出俺的观战,
并尝试指出值得学习的教训.</p>
<p>正如我的所有blog文章,
仅仅代表俺个人的意见,
并不代表我的教授以及雇主的态度.</p>
<h2 id="_2">一切皆对象 ?<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<p>~ Is everything an object? </p>
<p><code>一切皆对象</code> 这是OOP 的核心教条,
并视为OO语言的最高设计准则.
现在,让俺,来谈谈这货是否真如其宣称的这么好.</p>
<p>很多人将
<code>一切皆对象</code>
视为理所当然的,
因为这话从字面儿上是吻合日常经验的.
因为,英语中 <code>对象</code> 的基本意思就是 <code>事物</code>,
那么 <code>一切皆事物</code> 当然正确了.
图样图森破,
在 OOP 中 <code>对象</code> 可是特殊定义的,和生活英语可是没一毛钱关系.</p>
<p>OOP中
通常接受的
<a href="http://en.wikipedia.org/wiki/Object-oriented_programming">对象</a>
定义是: "
<a href="http://en.wikipedia.org/wiki/Field_(computer_science)">数据字段</a>
(描述对象的属性)以及关联方法 的结合体.
"
你真能在所有情景中适应这种模式嘛?</p>
<p>首先来设想一下OOP 模式是否能对真实世界加以解释. 汽车/树木/动物 视作对象的话, 那么它们的位置/速度/时间的 变化 乍说? 有什么对应的方法? 好吧, OOP 信徒可能叫你将类称为 速度 或是 时间 然后将方法增加进去. 可是速度/时间真的含有这种称为"方法"的东西 ? 当然没有, 这不过是想象罢了.
你可以追加速度/时间,但是,怎么令其包含<code>加</code>处理?
这就好比说:<code>子弹包含了枪</code>.</p>
<p>哪,信徒们最常说的:"一切皆对象"只是种好的思维方法,但事实并非如此. 一个对象的定义意味着一个方法只能属于一个对象,但大部分时间此思想并没有作用于任何对象. 当我们论及表达式: 1+2 , 是否得说 "+" 属于 1 ,或是算 2 的? 你必须作出属性方法归属的选择,而选择本身就已经意味着 "+" 操作其实并不真正属于任何一个对象,而是固有在对象之外的.</p>
<p>只能说 <code>有些</code> 事儿上对象是有帮助的,而 一切 皆对象这事儿即不真实也无用.
悲摧的是, <code>一切皆对象</code> 已经成为面向对象语言设计的最高教条.
一些面向对象语言声称在其内部真的一切都是对象.
若你意识到什么不是对象时,就有人会跳出来将其折腾成对象.
当然聪明人可以作到这点,只是事儿就变的复杂起来,
因为原本事物不是这么工作的.</p>
<p><code>一切皆对象</code> 的理想完全类似 FP 世界里 <code>一切皆函式</code> .
以前计算机科学称这种构想叫 lambda算子(<a href="http://en.wikipedia.org/wiki/Lambda_calculus">lambda calculus</a>). </p>
<p>有人就在编码时,将所有数字/数据结构都给包含在 lambda 中了.
而这种包含了一切的东西叫
<a href="http://en.wikipedia.org/wiki/Church_encoding">Church numeral</a>
. 但是,相比 <code>一切皆对象</code> ,
<code>一切皆函式</code> 好歹没有没有教条化过. 这只是在理论上是可行的,
但是,在实际工程中没有人这么折腾,因为这会令事儿变的复杂,而且效率低下.
因为,实际上并不是这么工作的,
它们只是近似描述(模式)计算机在我们视野外是如何计算的.
如果你真的将它们用在项目中,只能让事情变的复杂.</p>
<p>数学家们其实也有类似的宗教:
<a href="http://en.wikipedia.org/wiki/Set_theory">集(合)论</a>.</p>
<p>有些天才试图编码掉一切:</p>
<ul>
<li>数字</li>
<li>运算数字</li>
<li>数学结构</li>
<li>...</li>
</ul>
<p>都能 <code>集合</code> 了.
一切都想是
集合包含集合包含集合等等....
这有什么问题嘛?
就是当他们真正尝试使用这些 集合 来进行证明时,
证明自身被掩盖了.
因为复杂性,
数学家无法用集合理论进行足够的表述.
很多人试图修复集合论,但都失败了.</p>
<p>因此<code>一切皆对象</code> 在某种意义上
和
<code>一切皆函式</code>
以及
<code>一切皆集合</code>
是相同的,
都是看起来是美的,却从未在实际工程中很好的工作过.</p>
<p>俺不认为存在: <code>唯一正当语言</code> (one true language),
何况 OOP 的模式和现实相差太远.
这有点儿象
<a href="http://en.wikipedia.org/wiki/Flat_Earth">地球扁平论</a>,
.时植今日,依然
<a href="http://theflatearthsociety.org/">有人</a>
认为地球是平的,
而且用各种理论来证明.
他们一些论点看起来也很科学,
但是对比从国际空间站拍下来的照片,你愿意相信他们嘛?
而每当你发现有根本的东西错了,
又不想丢弃,
你就必须用更复杂的理论修补理论本身.</p>
<p>而这,正是 OOP 世界正在进行的事儿.</p>
<p><img alt="yw_flat-earth.png" src="http://zoomq.qiniudn.com/ZQCollection/img/yw_flat-earth.png"/></p>
<h2 id="_3">对象方法 ?<a class="headerlink" href="#_3" title="Permanent link">¶</a></h2>
<p>~ Are functions objects?</p>
<p>据俺所知,将函式塞到对象中的原始动机是为了支持 GUI 开发.
点击一个按钮时,一些代码(回调)就应该被触发. 为了指明按了具体哪个按钮,回调的函式就需要触发的对象作为其一个参数.
因为回调就这么单纯,看起来将其存储在按钮中没有什么不好.
于是我们有了个"对象", 包含了按钮的属性以及方法(回调). 的确挺方便.
但 GUI 应用只是个非常有限的情景,并不能真正证明 "一切皆对象"的普世性.
就象用两里路的平坦是不能证明地球是平的.</p>
<p>如果你真的理解什么是抽象,
可能已经注意到,上述故事包含一个微妙的错误:</p>
<div class="highlight"><pre><span></span><code>按钮的回调是不是一个真正的方法.
</code></pre></div>
<p>方法的本质目的是提供抽象的属性,但回调的目的不是为了提供抽象.
在这儿,只是刚好按钮包含了一个触发功能.</p>
<p>只有极少数功能应当视作对象的方法.
如果仔细观察,大部分情况中,对象只是作为一个命名空间(模块),
以便在其中存储相关属性和功能,
但是,这些功能在逻辑上并不属于对象.
他们只是将对象视为输入,并产生一些输出.
只有那些关系最密切,
并提供一个抽象层的功能,才应该考虑使用对象方法来封装.
其中大部分即所谓:
"getters"/"setters"/"iterators"</p>
<p>在一些语言,比如 Scala/Python, 函式也被视作对象.
而实际上,只是将一个函式包装成对象,
然后给予类似 <code>apply</code> 或是 <code>__call__</code> 的名称,
对象就酱紫能 <code>invoked</code> 了,而大家都知道函式只是调用了而已.</p>
<p>但是,将函式塞到对象中,并不等于函式也是对象,
好比,邀请朋友到家里来也不能令他们变成家人.</p>
<p>函式为程序的基本结构.
他们不属于对象.
他们描述变化,转变或是传送对象.
他们不是对象,也不能抽象为对象.
他们就像一种基本情况的归纳定义.
他们是<code>一切皆对象</code>的幻相的破灭.</p>
<h2 id="_4">过度抽象的代价<a class="headerlink" href="#_4" title="Permanent link">¶</a></h2>
<p>~ The cost of excessive abstraction </p>
<p>OOP 的主要吸引力就是抽象(以便代码重用以及DRY),
然而,传统的程序语言以及函式语言提供的抽象设施足够了.
甚至于,他们中的一些比 OO语言抽象能力还要好.
OO信徒总是比其它语言更加强调抽象,好象这是OO 独创的.
结果是, OO程序猿总是作过头.
他们中有些人追求抽象以及代码复用的程度,就好象编程只是为了抽象.</p>
<p><img alt="yw_screen-shot-2014-01-02-at-2-02-38-am.png" src="http://zoomq.qiniudn.com/ZQCollection/img/yw_screen-shot-2014-01-02-at-2-02-38-am.png"/></p>
<p>出于代码重用的目标,鼓励以OOP的形式来抽象,其结果却是令程序难以理解/分析.
俺经常见到有 JAVA 程序动用多层继承/重载,但实际作的事儿不多.
更糟的是,正因堆砌了如此多的代码,却没有真正在作事儿,
以至于难以找到哪部分是你真正想作的东西.就象穿越一个迷宫.
而对这,有另外一个漂亮的形容词是 "<a href="http://zh.wikipedia.org/wiki/%E9%B2%81%E6%A3%92%E6%80%A7_(%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%A7%91%E5%AD%A6)">鲁棒性</a>" (健壮性,Robustness)</p>
<p>如果俺为了复用以及健壮,宁愿只用代码复制,再修订,
只要确保每个副本简单,容易理解.</p>
<p>每当你抱怨 JAVA/C++ 的冗长时, OO程序猿就会告诉你,那些不是真正的 OO 语言.
一准向你推荐 Smalltalk 的.
但是,如果 Smalltalk 是好的,为毛现在几乎没有人使用 Smalltalk 进行工程开发?
俺认为, Smalltalk 就是其它 OO 语言中
过度抽象以及过度复杂的发源.</p>
<p>在"正宗"OO 语言 Smalltalk 中,
提倡的风格是 "极迟绑定" (extremely late binding),
意味着,要尽可能晩的确定概念的意义再进行构建.</p>
<p>这样,你有机会换出(swap out)底层实现,
而不用强制变更上层.
但是,同时也意味着你也无法及时明确一段代码究竟会作什么!
比如,在 JAVA 或是 C++ 中看到诸如
<code>1+2</code> 或是 <code>if (t) then ... else ...</code> 的表达式时,
至少俺知道是作整数相加,以及往常一般的条件判别.
但是,若在"极迟绑定"语言中就完全一头雾水了!
因为 <code>+</code> 和 <code>if</code> 都是可以重新定义的.
类似问题也出现在 Lisp 家族语言的宏体系中.
事实证明,给予程序猿定义控制结构的能力,
这主意其实很囧,
因为立即就会发现,自作聪明的程序猿都在努力向语言里塞满各种特殊的控制结构.</p>
<p>这一特性,可以举个 Smalltalk 的著名条件结构为例:</p>
<div class="highlight"><pre><span></span><code><span class="nv">result</span> <span class="o">:=</span> <span class="nv">a</span> <span class="nf">></span> <span class="nv">b</span>
<span class="nb">ifTrue:</span>[ <span class="s">'greater'</span> ]
<span class="nb">ifFalse:</span>[ <span class="s">'less or equal'</span> ]
</code></pre></div>
<p>你发送一消息 <code>ifTrue:</code> 给一个布尔对象,作为参数传递的代码,
当且仅当布尔接收器为真时,才执行.</p>
<p>首先,如果你真正拥有一个良好设计的语言,
但是,不想设计自个儿的条件控制结构.作为一名经验丰富的 Lisp/Scheme 程序员,
多年来俺见过各种定制的控制结构(如各种循环宏),
但是,没有一个证明是靠谱的.
俺宁愿在更好的语言中写稍稍长点的详细代码,也不愿没接没够的折腾无尽的奇葩控制结构.</p>
<p>其次,即使你天才到发明了另一种更好的控制结构,
Smalltalk 的延迟绑定功能,也难以提供足够的能力来定义它.
函式作为一个抽象工具的能力是有限的.
比Lisp/Scheme 的宏还要不如.</p>
<p>第三,Smalltalk 这一特性并不是新东西,而且包含了一个重大问题.
类似的但更加优美的控制结构,
在计算机科学诞生前就已经由 lambda演算科学定义出来了:</p>
<div class="highlight"><pre><span></span><code><span class="nv">TRUE</span><span class="w"> </span><span class="nb">=</span><span class="w"> </span><span class="nv">λx.λy.x</span>
<span class="nv">FALSE</span><span class="w"> </span><span class="nb">=</span><span class="w"> </span><span class="nv">λx.λy.y</span>
<span class="nv">IF</span><span class="w"> </span><span class="nb">=</span><span class="w"> </span><span class="nv">λb.λt.λf.b</span><span class="w"> </span><span class="no">t</span><span class="w"> </span><span class="nv">f</span>
</code></pre></div>
<p>这是非常漂亮的,可以用任何语言实现的,
但是为毛没有任何一个函式语言以这种方式来实现条件语句?
因为当你看着表达式 <code>IF b t f</code> ,
是无法明确这是否为一个条件, 因为 <code>IF</code> 是能在程序中重定义的.
又,如果 <code>IF</code> 是个函式,
它也可以接受额外的值比如 <code>TRUE</code> 或是 <code>FALSE</code>.
这样的条件构造可以工作,但是最后总是造成麻烦.
这就是所谓 "无意语义"(unintentional semantics).
而且这种 bug 最难以追查.</p>
<p>这种实现,也令编译器或是静态分析器以及奏效.
设想当编译器遇到 <code>IF b t f</code> 时,它无法得知这是否条件判定,从而进行优化.
它只能将其视作普通的函式调用.
同样类型检查器遇到时,它也无从期待 <code>b</code> 应该是什么类型,
因为不应该是个条件.
lambda 演算以上参数形式却是可以对应到 Smalltalk 的.</p>
<p>因此,适度使用时,抽象是个好主意,
一但过了,就会事与愿违.</p>
<p>(<code>译注:</code>其实什么事儿不是酱紫的呢?)</p>
<p>过度抽象,不仅令代码难以为人理解,
更加令自动分析工具以及编译器难有作为.</p>
<h2 id="_5">食脑魔:设计模式<a class="headerlink" href="#_5" title="Permanent link">¶</a></h2>
<p>~ Design patterns, the brain eater</p>
<p>OO 语言自我吹嘘他们的抽象弄清,其实抽象以及表述能力都很一般.
很多事儿,使用传统程序语言或是函式语言中很容易作到,
但是在 OO 语言中就变得的很折腾.
这才是为毛出现了 <code>设计模式</code>.
其起源的主要原因,就是 <code>一切皆对象</code> 的教条以及缺乏高阶函式
(或正确的执行它们),
还有 OO 的神秘主义倾向.</p>
<p>头一次听说它们时,
俺已经在康奈尔大学作为博士生在进行一些 PL 研究了.
平时主要使用 ML 以及 Haskell 语言.
在听到朋友有关
<a href="http://en.wikipedia.org/wiki/Design_Patterns">设计模式(Design Patterns)</a>
(这书绰号<code>GoF</code> ~Gang of Four, 即 <code>四人帮</code>)
的高见后,好奇这书的名气,
所以从图书馆借来的.
几个小时内,就发现书里那堆古怪的名称,
可以逐一对应到俺一直在使用的各种编程技术上.
有此是如此基础,其实是存在于每一个高级程序语言中的, 并不需要被命名.
很多高级模式(比如 访问者)只是将函式编程概念变成一个令人费解的形式,
以便避开OO 语言的固有局限性.
后来又发现,
<a href="http://en.wikipedia.org/wiki/Peter_Norvig">Peter Norvig</a>
早在1998年就指出,
一但你完成了 <code>高阶函数</code>(first-class function) ,
大部分设计模式对你将是 "透明的".
这证实了俺的发现 - <code>我不需要它们</code>.</p>
<p>俺也得承认,有些设计模式的确精巧.
你真的必须理解 OO 语言的内部设计精髓,
同时也必须理解许多函式编程技术,才足以创建模式.
但是, 智力=/=智慧.
即便它们能作到函式语言作到的,也通常要复杂的多.
选择艰难模式并不能真正证明自个儿的天才.
当你完成了 <code>高阶函数</code>(first-class function) ,事儿就变得容易很多,
你甚至于不会注意到用了什么设计模式.
就象
<a href="http://en.wikipedia.org/wiki/Peter_Norvig">Peter Norvig</a>
形容的,它们会变得的"透明".
那么,良好的语言设计者,应该作的是尽可能增加 <code>高阶函数</code>(first-class function) 到语言,
而不是提出设计模式作为解决方案.</p>
<p>(<code>译注:</code>无法同意更多!只有减少程序员心智负担的开发语言才是有良心的.)</p>
<p>每次俺从代码中中清除一个设计模式时(其它人写进去的),
代码就变得的更加简洁,易于管理.
前几天,俺终于很欣慰的将最后一个 访问者模式 从俺的 java 代码中给清除了.</p>
<p>(<code>译注:</code>指 <a href="https://github.com/yinwang0/pysonar2">PySonar</a> 工程)</p>
<p>设计模式除了额外的工作,没有赋予俺任何好处.
俺可以作任何事儿,
包括所谓 访问者模式 提供的所有先进东西,
但是,不通过使用神马模式.
另外,俺欠函式编程者有关设计模式一个说法.
如果你真想了解设计模式的精髓,以及如何能不用它们,
<a href="http://www.amazon.com/Little-Java-Few-Patterns/dp/0262561158">这本分书</a>
是个不错的开始.</p>
<p>(<code>译注:</code>指 Dan Friedman 的小字辈儿好书,
参考:<a href="http://www.yinwang.org/blog-cn/2012/07/04/dan-friedman/">GTF - Great Teacher Friedman</a>)</p>
<p>摧悲的是, 设计模式在企业里得到了某种程度上无法忍受的追捧.
当俺在 Google 实习时,在每一个书架上都见到了 <code>GoF</code>!
即使你自个儿不用它们,
但是几乎不可能避免其它人向你的代码中倾倒设计模式代码.
其营销战略非常象减肥产品:
"即使你不动,它一样燃烧你的脂肪!"
他们很是蛊惑了一大批新手,
以为无需理解计算机科学的基本概念,只要将几种模式折腾在一起,
就获得了一个漂亮的解决方案.
这看起来美好的象真的似的!
而最终,你将作比希望避免的更多的事儿.
设计模式食空了程序员的大脑!
一但使用设计模式一段时间,
他们就再也看不到其它东西,不会使用明确而直接的方式来写代码了.</p>
<h2 id="oo">乜系OO语言?<a class="headerlink" href="#oo" title="Permanent link">¶</a></h2>
<p>~ What is an OO language any way?</p>
<p>有关这方面,咱还没有论及什么使一门语言 "面向对象",
又或什么使之不是.
称其为OO语言,只是因为俺能将两个数据字段和一个方法塞到一个记录中?
又或是只有当其也提供 <code>极迟绑定</code> 时才算 OO?
那么 继承/重载/等等,等等呢?
是必须同时具有所有特性?还是有任何一个就算OO 了?</p>
<p>事实上,这一命题没有好答案.
本质上根本就不存在 "面向对象语言".
对象可以是语言的一部分,而且只是一小部分.
你真心不能说因为提供了对象的支持,语言就是面向对象的.
所谓的 OO语言是深深植根于传统的过程化编程(PP).
本质上 OOP 的一切都是从 PP 偷走的,
只是加以改名假装是自个儿创造的.</p>
<p>历史上鼓吹OO一直只是市场营销的需要.
一种语言想吸引人注目,就得宣称是 OO 的,
目测现在这点在慢慢改变,
因为越来越多的人意识到了 OO 的问题.</p>
<h2 id="oo_1">OO对教育和产业的伤害<a class="headerlink" href="#oo_1" title="Permanent link">¶</a></h2>
<p>~ Harm in education and industry</p>
<p>虽然OO 有很多硬伤,但它在市场上非常成功,而且多年来都处于主导地位.
因为社会以及市场的压力,许多高校也开始使用 OO语言,
如JAVA 作为入门语言, 来取代传统的过程语言,比如 Pacsal,
又或是函式语言,比如 Scheme .
这在很大程度上造成了学生根本没有接触到编程最重要的概念.
OO 强调的唯一重要的事儿就是重用,
但是,怎么能教无法写出可用代码的学习重用?
更何况复审并不是如某些人物所言的那么重要.</p>
<p>在康奈尔和印第安纳大学,俺都作为 TA 使用JAVA 来进行编程入门课程.
用了好几个学期.
清楚的记得学生们是怎么被绕晕的.
他们多数无法理解什么是 <code>"this"</code>,
为毛一切都要塞进类里,
为毛每个字段都要私有并使用 <code>getters</code>,
方法和静态方法的差异,等等等等...</p>
<p>他们无法理解的一个正当理由是 - OO 并不是描述事情怎么运作的.
多数时候,俺感觉,俺在教授设计上的缺陷和教条.
最终他们只能学到些皮毛.
更杯具的是,那些真心相信OOP 的学生,
将以为能写出令人费解的代码而自豪.
他们再也无法用简洁直接的方式来编写程序了.
这是可悲的.
俺感觉,我们不再教导学生拥有创造性和批判性思维,
而只是批量制造流水线工人.</p>
<p><img alt="yw_modern-times.jpg" src="http://zoomq.qiniudn.com/ZQCollection/img/yw_modern-times.jpg"/></p>
<p>工程方面,OO 并没有证实它宣称的威力.
良好的系统,可能用 "OO 语言"来实现,
但是,往往代码出自真正理解 OOP 的问题,
不盲从 <code>一切皆对象</code>或是<code>设计模式</code> 的工程师.
优秀程序员,通常在 OO 语言中进行变通,基本上只写传统的过程式的代码,
并结合函数式编程风格.
因此,一些 OOP 语言及其工具可能有非常广泛的应用,
但是,OO风格其实并没有真正对编程领域施加什么大太的推动.</p>
<h2 id="_6">终言<a class="headerlink" href="#_6" title="Permanent link">¶</a></h2>
<p>~ Final word</p>
<p>那么终究这篇文章想说什么?
对OO语言的圣战?
提倡函数式编程?
都不是,如俺所言, 根本没有所谓 <code>"面向对象语言"</code>,
所以,神马战争,是不存在的.
每一个 OO语言,都包含从过程式语言或是函数式语言借(或偷)来的好东西,
所以,它们也不算完全无用.</p>
<p>但是实话哪,大部分问题究其根源,就是追加的那些个 OO 特性
(死塞到过程编程, PP).
而这些额外的 "真OO技术" 带来的混乱比价值要多的多.
从这点看其价值是微不足道的.
根据俺的经验,
一但接受了哪怕只有一两个 OO 思想,
就将引发一系列麻烦和思维错误中,
且需要很长时间才能醒悟并摆脱.</p>
<p>因此,俺严正建议,表再接受任何 OO方面的想法,
也表试图使用它的 "特性".
OO 就是<code>食脑魔</code>,能躲多远躲多远.
但,你依然可以使用 "OO语言" 来生产可用程序,
因为你基本上是以非OO语言来使用它的.</p>
<h1 id="_7">是也乎<a class="headerlink" href="#_7" title="Permanent link">¶</a></h1>
<p>对于 <code>王珢</code> , 关注了太久了,久到成为习惯了...
但是,认真翻译他翻越后的技术思考成果,还是第一次,可惜也只能用自个儿的语气来快译,真正涉及的所有技术细节,俺还没有能力逐一印证,俺也只是个期望简洁的结论,记忆下来,直接使用的那种知其然,不知所以然的家伙... </p>
<p>但是,不得不说,对于 OOP 从第N次使用JAVA 败退后,
就一直对 OOP 的编程思想抱有深深的焦虑,
原先总是对自个儿为毛无法自然的对象化所有事物而自我嫌弃,
然后是奇怪为毛不用 OOP 编程反而更加自然,
到最后,沈游侠向俺演示,怎么通过清除 class 令Python代码更短,运行更快... </p>
<p>这才,从俺的世界观里彻底放弃了 OOP ,但是,一直没有找到为毛这样的根因,现在 王珢完成了这一结论性描述,收藏之!严正推荐之!</p>
<p>PS:</p>
<ul>
<li>有关 <code>first-class function</code> 的翻译</li>
<li>最初俺是图样图森破的译为 <code>一流功能</code></li>
<li>王珢看了, 建议修订为 <code>高阶函数</code></li>
<li>很多朋友指出,不对! 应该是 <code>第一类</code>/<code>头等</code>/<code>第一级</code>/<code>一等公民</code>...函数</li>
<li>我们大汉语的问题,就这样爆发了,多样可重载性...</li>
<li>参考:<a href="http://en.wikipedia.org/wiki/First-class_function">First-class function - Wikipedia, the free encyclopedia</a><ul>
<li>以及 <a href="http://www.webdevelopmentmachine.com/blog/%E9%AB%98%E9%98%B6%E5%87%BD%E6%95%B0%E4%B8%8E%E7%AC%AC%E4%B8%80%E5%9E%8B_higher-order-function-and-first-class-object/">高阶函数与第一型_Higher-order function and First-class object | Web Development Machine</a> 等等吧</li>
</ul>
</li>
<li>俺个人感觉, <code>高阶函数</code> 的意向在这儿没有问题,只是我们过往的翻译习惯感觉哪儿有不对了...</li>
</ul>
<h1 id="changlog">Changlog ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<a class="headerlink" href="#changlog" title="Permanent link">¶</a></h1>
<ul>
<li>160322 发现 <code>王珢</code> 在原文中给出了俺的翻译链接!<ul>
<li><a href="https://yinwang0.wordpress.com/2013/12/24/oop/"><img alt="131224_oop_linkback" src="http://zoomq.qiniudn.com/ZQCollection/snap/yw/131224_oop_linkback.png"/></a></li>
<li>是也乎,( ̄▽ ̄) 感动!</li>
</ul>
</li>
<li>140109 获得<code>王珢</code>授权,得以进行传播.</li>
<li>140108 前后7.42小时完成快译.</li>
<li>131224 翻越抄录在 medium.com</li>
</ul>
<h2 id="-o">增订:-o回收<a class="headerlink" href="#-o" title="Permanent link">¶</a></h2>
<p>review 时发现 yw 增补了原blog ,有些段落已经发生了调整,只有回收了:</p>
<p>The programmers' world is full of fads and superstitions. Every now and then there will be somebody come up and announce: "I can save the world!" No matter how bad the ideas are, there will always be followers, and the ideas soon become their religion. They then develop their community or camp, try to make the rest of the world adopt those ideas, and try to make the ideas live forever.</p>
<p>程序猿的世界充斥着各种时髦迷信.不时就有人跳出来吼:"俺能拯救世界!"诡异的是,无论多不靠谱的想法,总有追随者,并快速打造成全站的宗教,结成社区,尽量迫使其它所有人认同,以史这想法永存下去.</p>
<p>Whenever you criticize a programming language or paradigm, people would think you are a proponent of some other language or paradigm. Since I wrote the article pointing out the drawbacks of purely functional programming and monads, some people have apparently taken me as a proponent of object-oriented programming. That's far from the case. I don't like OO at all. I use almost none of the OO techniques even when I write programs in Java.</p>
<p>当你开始批评某编程语言或是范式时,人们就认为你一定是另外某某党的拥趸. 自从俺写文章黒 纯函式 编程以及单子的问题后, 有的就以为俺已经投入到 OOP 的怀抱中了. 图样图森破,俺从来就没有尿过 OOP, 即便在使用JAVA 编程时.</p>
<p>I have a scientific mind. I do research on programming languages and I make some of my own. I have implemented almost every feature in every language. So programming languages have no power upon me. I play with them like toys. I never see a language or a paradigm as a whole. I can dissect them and take the good parts that I liked, and discard the parts that don't work well.</p>
<p>俺具备科学思想.进行过编程语言的研究,而且自行实现过一些. 在任何语言上俺都能实现几乎所有语言特性. 因此,编程语言已经蒙不住俺了.俺能象玩具一般把玩它们, 在俺眼中它们只是一堆零件,可以任意折腾,提取俺喜欢的,丢弃俺不屑的.</p>
<p>Actually in the first version of the previous article I also criticized OOP, but I soon realized that it may not be an interesting topic. I have known the shortcomings of OOP and associate design pattens etc for many years and I thought that most programmers know them, and there is no need to write about them. It turns out that I was wrong. I have lived in my nice little world for too long and forgot how confusing the world can be.</p>
<p>其实以往文章有部分已经对 OOP 吐糟过了,但是,很快反应过来这可能不是个有趣的话题. 俺以为大多数程序猿已经对 OOP 以及关联的设计模式的缺陷,没必要强调了. 然而,事实证明是俺图样图森破了,在自个儿可爱的小世界中呆久了,容易忘记外面的混沌.</p>
<p>I just saw this InfoQ talk by Gilad Bracha today. He dislikes the purely functional cult as much as I do, but unlike me, he has subscribed to another cult that is OOP. Although he made some good points, the general message I got from the talk was that OOP the "one true king" is going to rule the world, and FP will be deconstructed and serve as a subordinate of it. OOP will live forever. This is ridiculous.</p>
<p>刚看到今天 InfoQ 上 Gilad Bracha 的访谈 . 他象俺一样不是性能崇拜者, 但是,他已经是邪恶的OOP 教派成员了, 虽然传达了一些很好的意见,但是,整体上对于 OOP 是"真圣", FP 将解构为 OOP 的下属, 而 OOP 将永存. 这就过了吼!</p>
<p>FP has its problems, but it deserves a lot more respect than this. Although I dislike some purely functional language's cult-like culture, FP in general is highly valued. FP taught me a lot more and contains a lot more value than OOP. The education I received from some of the best FP people made me a better programmer. Even when I use a OO language, I avoid its shortcomings and write in a much cleaner way than the usual OO style. Some OO languages have been learning (or stealing) from FP languages for long and benefitted from it. To make a living, some highly educated FP people work on OO languages, make good compilers or tools for them. I feel terrible that somebody talks about FP that way.</p>
<p>FP 当然有自身的固有问题,但是它值得更多的尊重. 虽然俺不喜欢一些 纯函式 语言邪教般的文化, 但是 FP 具有很高的价值. FP 教了俺很多好东西,含有比 OOP 更多价值. 从那些 FP 程序员身上接受的教导令俺成为更好的程序员. 甚至当我使用一个 面向对象 的语言时, 俺也习惯性的在躲避其缺点, 使用更加简洁的方式来完成功能. 一些 面向对象的语言,其实一直在向 FP 窃取思想而从中受惠. 限于生计, 有些受过 FP 高级教育的程序员,却在为 面向对象的语言工作,为其编写更好的编译或其它工具. 这令俺细思恐极.</p>
<p>Gilad criticized some bad designs in FP, but highly promoted the bad designs from OOP, to the degree of calling them "the one true way". Many aspects of OOP have been bringing harm to the software industry and computer science education for long, but he didn't mentioned them. The more I forget about those ideas from OO, the simpler and better my code becomes. I thought many people have learned these lessons, but it looks that's not true.</p>
<p>Gilad 批评了一些FP 中不好的设计, 但鼓吹 OOP 的设计模式是 "唯一正当"的,这更加要命. 事实上 OOP 对计算机科学的教育以及软件产业已经造成了深远的伤害. 虽然俺自觉的忘记 OOP ,用更加简洁的方式改善代码. 原本以为大家都跟俺一样,但看来现实并非如此.</p>
<p>Thus I realized that my original criticism of OOP had some value, and I decided to write a dedicated article about it.</p>
<p>故此,俺意识到,俺对OOP 的批评具有一定的价值,决定写下来, 好好聊聊.</p>
<p>...</p>
<h3 id="_8">过度抽象的代价<a class="headerlink" href="#_8" title="Permanent link">¶</a></h3>
<p>~ The cost of excessive abstraction </p>
<p>The major appeal of OOP is abstraction, but OO programmers usually overdo it. I know the value of abstraction. I build abstractions every day, in all kinds of languages. But OOP advocates a level of abstraction which makes programs hard to understand and hard to analyze. I often see Java programs with multiple levels of inheritance and overloading but doing very little. And worse, because there are so much code that doesn't do real things, it is very hard to find out which part of the code is doing the thing you want.</p>
<p>OOP 的主要吸引力就是抽象,
但是, OO程序猿总是作过头.
俺明白抽象的价值.
每天俺都在各种语言中实践着抽象.
但, OOP 主张构建抽象层,这通常使程序难以理解/分析.
俺经常见到有 JAVA 程序动用多层继承/重载,但实际作的事儿不多.
更糟的是,正因堆砌了如此多的代码,却没有真正在作事儿,
以至于难以找到哪部分是你真正想作的东西.</p>
<p>Whenever you complain about Java or C++, OO proponents will tell you that they are not authentic OO languages. They would ask you to take a look at Smalltalk. If Smalltalk's ways are that good, why almost nobody is using Smalltalk now? Because there are real problems in its approach. The "authentic" OO style of Smalltalk promotes the notion of "extremely late binding", which basically means that the meaning of the program constructs is determined as late as possible.</p>
<p>每当你抱怨 JAVA/C++ 时,OO程序猿就说,那些不是真正的 OO 语言.
一准向你推荐 Smalltalk 的.
但是,如果 Smalltalk 是好的,为毛现在几乎没有人使用 Smalltalk 进行工程开发?
在"正宗"OO 语言 Smalltalk 中,
提倡的风格是 "极迟绑定" (extremely late binding),
意味着,要尽可能晩的确定概念的意义再进行构建.</p>
<p>Late binding means that you have a chance to swap out the underlying implementation without forcing the upper levels to change, but it also means that you are no longer sure what a piece of code means! When I look at expressions such as '1+2′ and 'if (t) then ... else ... ' in Java or C++, I at least know for sure that they mean an integer addition and an usual conditional. But I'm not sure about this in an "extremely late binding language", because even the meaning of '+' and 'if" can be redefined. A similar problem happens to Lisp family languages' macro systems. It is bad idea of giving the programmers the power of defining control structures, because soon your language will be abundant of quirky control structures designed by programmers who try to be clever.</p>
<p>这样,你有机会换出(swap out)底层实现,
而不用强制变更上层.
但是,同时也意味着你也无法及时明确一段代码究竟会作什么!
比如,在 JAVA 或是 C++ 中看到诸如
<code>1+2</code> 或是 <code>if (t) then ... else ...</code> 的表达式时,
至少俺知道是作整数相加,以及往常一般的条件判别.
但是,若在"极迟绑定"语言中就完全一头雾水了!
因为 <code>+</code> 和 <code>if</code> 都是可以重新定义的.
类似问题也出现在 Lisp 家族语言的宏体系中.
事实证明,给予程序猿定义控制结构的能力,
这主意很囧,因为立即就会发现,自作聪明的程序猿都在努力向语言里塞满各种特殊的控制结构.</p>
<p>Abstraction is a good idea when used moderately, but when you do it in excess, it backfires. Not only does it make it hard for humans to understand the code, it makes automated analysis tools and compiler optimizations difficult or impossible to make. I built an advanced static analysis tool for Python called PySonar. It works okay in general, but under the premise that the programs don't use the "deep magic" of Python (which are possibly learned from Smalltalk). If you do, there are all sorts of ways you can confuse the analysis, but for that I can do nothing to help. Nothing can analyze or optimize the code if you put expensive or undecidable computations into the abstraction layer.</p>
<p>适度使用时,抽象是个好主意,
一但过了,就会事与愿违.(其实什么事儿不是酱紫的呢?)
过度抽象,不仅令代码难以为人理解,
更加令自动分析工具以及编译器难有作为.
俺创建的先进静态分析工具,
对 Python 的叫 <a href="https://github.com/yinwang0/pysonar2">PySonar</a>.
其一般工作起来还成,
只要没用 Python 玩一些 <code>深度魔术</code>(deep magic)
(即前述Smalltalk 中能玩的).
如果你一定要玩,有太多方法可以弄晕分析器,
这时,俺也帮不了你什么了.
你一但将华丽的无法理解的东西塞到抽象层,
那就没有任何东西能帮你分析或是优化代码了!</p>
<p>So is there any value of making those deep abstractions an option but not encouraged to use by usual programmers? There might be, but probably too little to offset the lost safety guarantee and performance.</p>
<p>那么,不鼓励普通程序猿使用深层抽象,有什么价值会丧失?
可能有,但是,一定无法抵消代码失去安全以及性能保障!</p>
<p>...</p>
<h3 id="are-functions-objects_1">Are functions objects?<a class="headerlink" href="#are-functions-objects_1" title="Permanent link">¶</a></h3>
<p>The original motivation of putting functions inside objects was to support GUI applications. You click on a button and some code (a callback) will be invoked. For the convenience of referring to the button that gets clicked, the callback takes the triggered object as its first argument. Since the callback does nothing more than this, it seems to be convenient to just store it inside the button. And thus we had an "object" which combines the attributes of the button and its method (the callback). Indeed it is convenient and a good idea. But the limited usage case of GUI applications can't really justify a universal notion of "everything is an object". Computer science often suffers from such over-generalizations.</p>
<p>将函式塞到对象中的原始动机是在 GUI 开发中.点击一个按钮时,一些代码(回调)就应该被触发. 为了指明按了具体哪个按钮,回调的函式就想要一个指代的对象. 因为回调就这么单纯,看起来将其存储在按钮中没有什么不好. 于是我们有了个"对象". 的确挺方便. 但 GUI 应用只是个非常有限的情景,并不能真正证明 "一切皆对象"的普世性. 可惜计算机科学这种过度概括是常态.</p>
<p>But even the above contains a subtle mistake: the callback in the button is not really a method. It is just a usual function. Very few procedures should be considered methods of an object, and most others are just functions. If you look carefully, most of the time the objects just serve as a namespace (or module) in which you can put data fields and functions. But those functions can also live on their own (such as addition of velocities or time). They just take the objects as inputs and produce some output. Only the functions that are most intimately connected to the fields and provide an "abstraction layer" should be considered methods. Most of those are "getters", "setters" or "iterators". Functions don't necessarily belong to objects. They are not objects. They describe a change, transition or transformation of objects. They are external to the objects.</p>
<p>但是,即使上述包含一个微妙的错误:在按钮的回调是不是一个真正的方法. 这只是一个平常的功能. 很少有程序应被视为一个对象的方法,而大多数人都只是功能. 如果你仔细观察,大部分时间的对象只是作为一个命名空间(或模块)中,你可以把数据域和功能. 但是,这些功能也可以生活在他们自己的(如加速度或时间). 他们只是把对象作为输入,并产生一些输出. 只有那些最密切相关的领域,并提供了一个"抽象层"的功能,应考虑方法. 其中大部分是"干将","二传手"或"迭代器". 功能不一定属于对象. 他们不是对象. 他们描述的改变,转变或物体的转型. 它们是外部的对象. </p>
<p>In some languages such as Scala or Python, functions are also treated as objects. But they actually just wrapped the functions into an object, give them some name such as "apply" or "<strong>call</strong>", so that when the objects are "invoked", you know which functions to call. But putting a function into an object doesn't really mean functions are also objects, just like inviting friends to your house doesn't make them your family.</p>
<p>在一些语言,比如 Scala/Python, 函式也被视作对象.
而实际上,只是将一个函式包装成对象,
然后给予类似 <code>apply</code> 或是 <code>__call__</code> 的名称,
对象就酱紫能 <code>invoked</code> 了,而大家都知道函式只是调用了而已.</p>
<p>但是,将函式塞到对象中,并不等于函式也是对象,
好比,邀请朋友到家里来也不能令他们变成家人.</p>
<p>...</p>
<h3 id="actor">一切皆角色(actor) ?<a class="headerlink" href="#actor" title="Permanent link">¶</a></h3>
<p>~ Everything is an actor? </p>
<p>In his talk, Gilad Bracha disagrees with the FP hypes such as monads and pattern matching (with some good points), but he over-valued the ways of OOP and the actor model. From the blog posts he refers to, you can see that he thinks of the actor model as the "one true way".</p>
<p>在 Gilad Bracha 的有关言论中,
他不认同 FP 的炒作,
类似 monads 以及 模式匹配(这有点儿好处),
但他完全高估了 OOP 和角色模式了.
从他的blog 文章中可以看到,他宣称 角色模式是 "唯一正解".</p>
<p>I'm always wary of such notion as "one true way" or "everything is... " I actually read Carl Hewitt's actor model paper a long time ago and also some of his other concepts such as Direct LogicTM (Yes, there is a trademark sign on it). I didn't really appreciate the papers and his way of writing, with the "dedicated to some-big-names" headlines, trademark signs and grand claims.</p>
<p>俺对任何宣称 "唯一..." 或是 "一切..."
的概念有疑虑.
其实很久以前,俺就查阅过 Carl Hewitt 的角色模式论文,
他也描述了其它模式,比如 "Direct LogicTM"
(是的,有商标签注的呢).
这些论文都是标题 "高大上",签注商标以配套宏大的索赔可能性.
俺真心没体会到他论文这种撰写方法有什么意义.</p>
<p>The actor model suffers from the same drawbacks of OOP as I mentioned: over-abstraction and lacking of general expressiveness. There is no way a human being or an automated system can effectively reason about the programs if you build them at way. It hides bugs. Although the actor model may be useful in some cases, it is not really expressive and simple enough to nicely capture all computations. It has too much application-specific logic (which is essentially OOP) built in, thus it is not at the same universal level as lambda calculus or Turing machines.</p>
<p>角色模式有同OOP 一样的毛病,
正如俺所言:过度抽象,缺乏正常的表达能力.
用这种模式创建的程序,
没办法让一个人或是自动系统对其进行有效的推导.
当然,有时,角色模式很有用.
但是,它并不能真正很好的对所有计算进行简洁有效的表述.
它有太多内建的特殊应用逻辑
(这是OOP 的通病),
因此它和 lambda演算以及图灵机 不在一个能力水平上.</p>
<p>...</p>
<h3 id="_9">面向对象设计模式的傻缺<a class="headerlink" href="#_9" title="Permanent link">¶</a></h3>
<p>~ The stupidity of OO design patterns </p>
<p>It may not be inherent in all OO languages, but OO design patterns (such names as Factory, Facade, Flyweight, Singleton, Visitor etc) have been the major source of over-complication and confusion. Their origin was mostly due to the dogma of "everything is an object" and the lack of high-order functions (or the correct implementation of them).</p>
<p>可能不是所有 OO 语言固有的,
但 面向对象设计模式
(类似 Factory, Facade, Flyweight, Singleton, Visitor 等等)
就是代码过度复杂/混乱的根源.
主要原因就是 "一切皆对象" 的教条以及缺乏高阶函式
(或正确的执行它们).</p>
<p>The design patterns are completely nonsense to me and I never used them. When I first heard about them I was already a PhD student at Cornell doing some PL research. I was curious about the book's fame and borrowed one from the library. But I soon found a mapping from all those weird names to the programming techniques I have been using all the time. I don't understand how such a book as GoF can ever be published which contains nothing but just giving new and weird names to existing programming techniques that I use every day. If you say the purpose of writing this book is to "improve communication of programmers", then I would write a book and give new names to air, water and all kinds of food, in order to "improve the communication of all human beings".</p>
<p>这类设计模式完全是胡说八道,
俺从未使用过它们.
头一次听说它们时,
俺已经在康奈尔大学作为博士生在进行一些 PL 研究了.
(Programming Language research,参考:<a href="http://zoomq.qiniudn.com/ZQScrapBook/ZqSKM/data/20120910004839/index.html">什么是程序语言的研究</a>)
因为好奇这书的名气,
所以从图书馆借来的.
很快,俺发现书里那堆古怪的名称,可以逐一对应到俺一直在使用的各种编程技术上.
实在不明白,GoF
(<code>设计模式</code> 作者通常叫做 <code>GoF</code> ~Gang of Four, 即 <code>四人帮</code>)
这书是怎么出版的,
这书中没有任何新知识,
只是将大家每天都在使用的现有编程技术,赋予了新奇的名字.
如果你说这书的目的就是为了
<code>改善程序员的沟通</code>.
那俺就应该写本书,来给空气/水/各种食物赋予全新名称,
以 <code>改善全人类的沟通</code>!</p>
<p>Peter Norvig gave a talk on design patterns in 1998 pointing out most of the design patterns will be "transparent" once you have first-class functions. He was too polite to call design patterns nonsense or stupid, but that's implied.</p>
<p>Peter Norvig 在98年就设计模式指出,
一但你完成了 <code>高阶函数</code>(first-class function) ,
大部分设计模式对你将是 "透明的".
他其实就是过于文雅的暗示: 设计模式就是废话或是愚蠢的.</p>
<p>Every time I remove a design pattern (some other people made) from PySonar, the code becomes simpler and more manageable. I just removed the last visitor pattern a few days ago, and I felt so relieved. They gave me nothing but extra work when they existed. I can do anything, including a lot more advanced things than those provided by visitor patterns, but without using them.</p>
<p>每次俺从 <a href="https://github.com/yinwang0/pysonar2">PySonar</a>
中清除一个设计模式(由某些人物,生造出来的),
代码就变得的更加简洁,易于管理.
前几天,俺终于很欣慰的将最后一个 访问者模式 给清除了.
设计模式除了额外的工作,没有赋予俺任何好处.
俺可以作任何事儿,
包括所谓 访问者模式 提供的所有先进东西,
但是,不通用使用模式.</p>
<p>I owe my insights into design patterns to some functional programming people. If you really want to understand the essence of OO design patterns, and how NOT to use them, take a look at this little book other than the GoF one.</p>
<p>...</p>Tests and static analysis2013-11-27T00:00:00+08:002020-01-31T16:42:10+08:00Zoom.Quiettag:blog.zoomquiet.io,2013-11-27:/131127-yw-on-test-static-analysis.html<p>via: http://yinwang0.wordpress.com/2013/12/27/tests-and-static-anaysis/</p>
<p>Ever since I made a static analysis tool for Python called PySonar, I have been asked about the question: "What is the difference between testing and static analysis?" I just replied to a comment asking a similar question, so I think …</p><p>via: http://yinwang0.wordpress.com/2013/12/27/tests-and-static-anaysis/</p>
<p>Ever since I made a static analysis tool for Python called PySonar, I have been asked about the question: "What is the difference between testing and static analysis?" I just replied to a comment asking a similar question, so I think it's a good time to write down some systematic answer for this question.</p>
<h2 id="static-analysis-is-static-tests-are-dynamic">Static analysis is static, tests are dynamic<a class="headerlink" href="#static-analysis-is-static-tests-are-dynamic" title="Permanent link">¶</a></h2>
<p>Static analysis and tests are similar in their purposes. They are both tools for improving code quality. But they are very different in nature: static analysis is static, but tests are dynamic. "Static" basically means "without running the program".</p>
<p>Static analysis is similar to the compiler's type checker but usually a lot more powerful. It can find bugs that type checkers cannot find, such as resource leaks, array index out of bounds, security risks etc. Static analysis has the "reasoning power" that tests hasn't, so static analysis can find problems that testing may never detect. For example, a security static analysis may show you how your website can be hacked after a series of events.</p>
<p>Tests just run the programs with certain inputs. They are fully dynamic, so you can't test all cases but just some of them. But because tests run dynamically, they may detect bugs that static analysis can't find. For example, tests may find that your algorithm produces wrong results. Static analysis tools are not (yet) intelligent enough for checking this kind of high-level properties.</p>
<p>But notice that although tests can tell you that your algorithm is wrong, they can't tell you that it is correct. To guarantee the correctness of programs is terribly harder than tests or static analysis. You need a mechanical proof of the program's correctness, which means at the moment that you need a theorem prover such as Coq, Isabelle or ACL2, lots of math/logics knowledge, lots of time, and even with all those you may not be able to prove it, because your program may have encoded the Goldbach conjecture in it. So the program's passing the tests doesn't mean it is correct. It only means that you haven't done terribly stupid things.</p>
<h2 id="huge-difference-in-manual-labor">Huge difference in manual labor<a class="headerlink" href="#huge-difference-in-manual-labor" title="Permanent link">¶</a></h2>
<p>Testing requires lots of manual work. Tests for "silly bugs" (such as null pointer dereference) are very boring and tedious to make. Because of thedesign flaws of lots of programming languages, those things can happen anywhere in the code, so you need a good coverage in order to prevent them.</p>
<p>You can't just make sure that every line of the code is covered by the tests, you need good path coverage. But in the worst case, the number of execution paths of the program is exponential to its size, so it is almost impossible to get good path coverage however careful you are.</p>
<p>On the other hand, static analysis is fully automatic. It explores all paths in the program systematically, so you get very high path coverage for free. Because of the exponential algorithm complexity exploring the paths, static analysis tools may use some heuristics to cut down running time, so the coverage may not be 100%, but it's still enormously higher than any human test writer can get.</p>
<h2 id="static-analysis-is-symbolic">Static analysis is symbolic<a class="headerlink" href="#static-analysis-is-symbolic" title="Permanent link">¶</a></h2>
<p>Even when you get good path coverage in tests, you may still miss lots of bugs. Because you can only pass specific values into the tests, the code can still crash at the values that you haven't tested. In comparison, static analysis processes the code symbolically. It doesn't assume specific values for variables. It reasons about all possible values for every variable.</p>
<p>The most powerful static analysis tools can keep track of specific ranges of the numbers that the variables represent, so they may statically detect bugs such as "array index out of bound" etc. (PySonar hasn't that kind of power yet and I'm working towards that.) Tests may detect those bugs too, but only if you pass them specific values that hits the boundary conditions. Those tests are painful to make, because the indexes may come after a series of arithmetic operations. You will have a hard time finding the cases where the final result can hit the boundary.</p>
<h2 id="static-analysis-has-false-positives">Static analysis has false positives<a class="headerlink" href="#static-analysis-has-false-positives" title="Permanent link">¶</a></h2>
<p>Some static analysis tools may be designed to be conservative. That is, whenever it is unsure, it can assume that the worst things can happen and issue a warning: "You may have a problem here." Thus in principle it can tell you whenever some code may cause trouble. But a lot of times the bugs may never happen, this is called a false positive. This is like your doctor misdiagnosed you to have some disease which you don't have. Lots of the work in building static analysis tools is about how to reduce the false positive rate, so that the users don't lose faith in the diagnosis reports.</p>
<p>Tests don't have false positives, because when they fail your program will surely fail under those conditions.</p>
<h2 id="the-value-of-static-analysis">The value of static analysis<a class="headerlink" href="#the-value-of-static-analysis" title="Permanent link">¶</a></h2>
<p>Although static analysis tools don't have the power to guarantee the correctness of programs, they are the most powerful bug-finding tools that don't need lots of manual labor. They can prevent lots of the silly bugs that we spend a lot of time and energy writing tests for. Some of those bugs are so stupid but so easy to make. Once they happen they may crash an airplane or launch a missile. So static analysis is a very useful and valuable tool. It takes over the mindless and tedious jobs from human testers so that they can focus on more intellectual and interesting tests.</p>
<blockquote>
<blockquote>
<blockquote>
<p>试理解::</p>
</blockquote>
</blockquote>
</blockquote>
<h1 id="_1">测试与静态分析<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<p>自从俺折腾了Python静态代码分析工具 PySonar, 俺就问过自个儿这个问题:"究竟测试和静态分析的差异在哪儿?" 这不是一个简单的评注就能回答的了的,现在俺想可以好好解释一下了.</p>
<h2 id="_2">静态分析是静态的,测试是动态的<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<p>Static analysis is static, tests are dynamic Static analysis and tests are similar in their purposes. They are both tools for improving code quality. But they are very different in nature: static analysis is static, but tests are dynamic. "Static" basically means "without running the program".</p>
<p>Static analysis is similar to the compiler's type checker but usually a lot more powerful. It can find bugs that type checkers cannot find, such as resource leaks, array index out of bounds, security risks etc. Static analysis has the "reasoning power" that tests hasn't, so static analysis can find problems that testing may never detect. For example, a security static analysis may show you how your website can be hacked after a series of events.</p>
<p>Tests just run the programs with certain inputs. They are fully dynamic, so you can't test all cases but just some of them. But because tests run dynamically, they may detect bugs that static analysis can't find. For example, tests may find that your algorithm produces wrong results. Static analysis tools are not (yet) intelligent enough for checking this kind of high-level properties.</p>
<p>But notice that although tests can tell you that your algorithm is wrong, they can't tell you that it is correct. To guarantee the correctness of programs is terribly harder than tests or static analysis. You need a mechanical proof of the program's correctness, which means at the moment that you need a theorem prover such as Coq, Isabelle or ACL2, lots of math/logics knowledge, lots of time, and even with all those you may not be able to prove it, because your program may have encoded the Goldbach conjecture in it. So the program's passing the tests doesn't mean it is correct. It only means that you haven't done terribly stupid things.</p>
<h2 id="_3">存在巨大的人肉工作量差异<a class="headerlink" href="#_3" title="Permanent link">¶</a></h2>
<p>~ Huge difference in manual labor </p>
<p>Testing requires lots of manual work. Tests for "silly bugs" (such as null pointer dereference) are very boring and tedious to make. Because of thedesign flaws of lots of programming languages, those things can happen anywhere in the code, so you need a good coverage in order to prevent them.</p>
<p>You can't just make sure that every line of the code is covered by the tests, you need good path coverage. But in the worst case, the number of execution paths of the program is exponential to its size, so it is almost impossible to get good path coverage however careful you are.</p>
<p>On the other hand, static analysis is fully automatic. It explores all paths in the program systematically, so you get very high path coverage for free. Because of the exponential algorithm complexity exploring the paths, static analysis tools may use some heuristics to cut down running time, so the coverage may not be 100%, but it's still enormously higher than any human test writer can get.</p>
<h2 id="_4">静态分析是符号化的<a class="headerlink" href="#_4" title="Permanent link">¶</a></h2>
<p>~ Static analysis is symbolic </p>
<p>Even when you get good path coverage in tests, you may still miss lots of bugs. Because you can only pass specific values into the tests, the code can still crash at the values that you haven't tested. In comparison, static analysis processes the code symbolically. It doesn't assume specific values for variables. It reasons about all possible values for every variable.</p>
<p>The most powerful static analysis tools can keep track of specific ranges of the numbers that the variables represent, so they may statically detect bugs such as "array index out of bound" etc. (PySonar hasn't that kind of power yet and I'm working towards that.) Tests may detect those bugs too, but only if you pass them specific values that hits the boundary conditions. Those tests are painful to make, because the indexes may come after a series of arithmetic operations. You will have a hard time finding the cases where the final result can hit the boundary.</p>
<h2 id="_5">静态分析会误报<a class="headerlink" href="#_5" title="Permanent link">¶</a></h2>
<p>~ Static analysis has false positives </p>
<p>Some static analysis tools may be designed to be conservative. That is, whenever it is unsure, it can assume that the worst things can happen and issue a warning: "You may have a problem here." Thus in principle it can tell you whenever some code may cause trouble. But a lot of times the bugs may never happen, this is called a false positive. This is like your doctor misdiagnosed you to have some disease which you don't have. Lots of the work in building static analysis tools is about how to reduce the false positive rate, so that the users don't lose faith in the diagnosis reports.</p>
<p>Tests don't have false positives, because when they fail your program will surely fail under those conditions.</p>
<h2 id="_6">静态分析的价值<a class="headerlink" href="#_6" title="Permanent link">¶</a></h2>
<p>~The value of static analysis </p>
<p>虽然静态分析工具并不能确保程序的正确性,但却是最强力的bug调查工具,而且不需要大量的手工劳动. 以往我们花费了巨大工作量编写的测试依然包含极其愚蠢的错误.有的蠢到你无法相信是自个儿写出来的.而这种低级问题一但出现,就可能令飞机坠毁导弹发射! 因此,静态分析是种非常有用以及有价值的工具.能接管测试人员盲目而乏味的工作,使人类测试工程师能专注更加智能/有趣的测试.</p>
<h2 id="changlog">Changlog<a class="headerlink" href="#changlog" title="Permanent link">¶</a></h2>
<ul>
<li>14010? </li>
<li>131212 翻越抄录在 medium.com 开始翻译</li>
</ul>OSS good for enterprise2013-11-11T00:00:00+08:002020-01-31T16:42:10+08:00Zoom.Quiettag:blog.zoomquiet.io,2013-11-11:/oss-good-4-china-com.html<h1 id="oss">企业进行OSS的好处<a class="headerlink" href="#oss" title="Permanent link">¶</a></h1>
<p><code>~中国绝大多数IT企业</code></p>
<p><img alt="oss" src="https://d262ilb51hltx0.cloudfront.net/max/700/1*2m0OBPBnBJu0WrobbfnBkg.png"></p>
<p>其实也是欠稿一篇, 先是忽悠朋友完成了作文:
<a href="http://zhuanlan.zhihu.com/zhuangbiaowei/19576637">企业开源杂谈 — 思考IT — 知乎专栏</a></p>
<p>然后,又引发了 …</p><h1 id="oss">企业进行OSS的好处<a class="headerlink" href="#oss" title="Permanent link">¶</a></h1>
<p><code>~中国绝大多数IT企业</code></p>
<p><img alt="oss" src="https://d262ilb51hltx0.cloudfront.net/max/700/1*2m0OBPBnBJu0WrobbfnBkg.png"></p>
<p>其实也是欠稿一篇, 先是忽悠朋友完成了作文:
<a href="http://zhuanlan.zhihu.com/zhuangbiaowei/19576637">企业开源杂谈 — 思考IT — 知乎专栏</a></p>
<p>然后,又引发了系列讨论,结果变成了自个儿应该还的一篇文章,,,
同样的,由大脑自动后台组稿42天,快速输出一版本先:</p>
<h2 id="_1">背景:<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<p>首先, 俺自个儿, 社区称号:大妈, 入行以来加入N 多技术社区, 长年混杂在各种企业内外社区中,折腾,再折腾,从来没有什么成型的NB的流传于世或是企业生产系统中的项目... 按照 Eric Raymond的著名文章:</p>
<div class="highlight"><pre><span></span><code>如何成为一名黒客
</code></pre></div>
<p>其中的定义,俺属于绝对意义上的大妈式 Hacker, 公布有效信息(文档/翻译)/维护维基/传播Hack 文化本身... </p>
<p>然后,从业14年,从前台作到后台,作不动现代的全端工程师,掺合过的公司从4人到4000人的级别都有;近年,基本作 开发者关系管理(DRM), KPI 计算 40%开发,其它是社区活动的组织/筹备/主持/演讲/宣传/推广... </p>
<h2 id="_2">范畴<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<p>一篇文章绝对不可能将一个领域的发展问题分析明白的,所以,为了表述的健康/合理, 先定一下讨论的范畴,以免各种扩大化式的乱入.</p>
<ul>
<li>只说IT企业,即,主赢收业务是软件/互联网/移动/服务... etc.</li>
<li>中国企业,无论注册地/资本来由/管理层国藉, 只论主要业务在中国大陆,主要开发者是中国本土码农... </li>
<li>开源,就是标准的 FLOSS ~ 使用标准的许可证以及发布形式/维护过程 的 自由/开源软件, 因为开放源代码,对于 自由软件还是开源软件都是基本要求,只是后续发布的要求有差别,早已被中国媒体给搅合的说不清楚了,所以,一概论之了... </li>
<li>因为职业原因,不便对老雇主或是现雇主泄漏什么内部机密,所以,只讨论,如同化学实验,嗯嗯嗯,,,精确的说,就象写 SiFi 小说一样推演,企业推行 OSS 的好处; 试图达到度目标就是能向一般的BOSS/同事,以极其常识的叙述来说明白,为什么应该 OSS, 至于坏处,就当没有吧,反正在中国没有什么正当的追究过程... </li>
</ul>
<h2 id="_3">故事<a class="headerlink" href="#_3" title="Permanent link">¶</a></h2>
<ol>
<li>从前有个公司,使用了开源软件,后来,嗯嗯嗯,就没有后来了!</li>
<li>从前又一公司,开源了内部系统,然后,嗯嗯嗯,就没有然后了!</li>
<li>从前还是一公司,从一开始就用开源软件的形式来专发,嗯嗯嗯,然后也没有然后了... </li>
</ol>
<h2 id="_4">断语<a class="headerlink" href="#_4" title="Permanent link">¶</a></h2>
<p>嗯嗯嗯,共同之处就素:所有公司都玩一朝天子一朝臣,后人废掉前尘事儿! 大家都实在太习惯太顺畅太自说自话太自发自觉的作这类事儿了... .其实,追点儿根儿,很简单,无论多重要,多NB 的代码,在公司中除了写那些代码的人,其余根本没有人能够/愿意/喜欢 真正理解这些要命的代码,而且最后竟然,就连代码原作者也都认同了这种"文化"随时抛弃无论当初花多少精力折腾出来的代码了... </p>
<p>所以,企业真正进行开源工程式的产品开发,目测至少有这么几个方面是立即可以获得好处的:</p>
<ol>
<li>产品安全性立即获得极大的提高,因为所有人知道,代码都特么开源了,服务想安全,就得作到运行时,真正安全了!</li>
<li>代码将真正为越来越多的人理解,从而所有工程师的工作将无法简单的通过行政命令抹杀,随着开源项目的不断扩散/衍生/复用,原作者的价值在不断增值!</li>
<li>文档将被自主自发的不断完善,因为一个没有好文档的项目,本身再NB 也没人用!
测试将被自主自发的由开发者自个儿进行了,因为开源后,有太多自动化测试服务可以在外网自在的使用了,再也不用跟测试部的那帮XX叽歪了!</li>
<li>开发人员的工作时间立即被自主自发的延长了! 因为开源工程受到关注后,全球用户可不管你们是否下班了,那 Issue 是随时捅过来的!</li>
<li>项目维护人员免费增加了! 只要项目真正解决领域问题,那么公司自个儿都没有用到的场景也一定会有人用上,根据开源协议,人家也必须将修订提交回来... 好了,免费的比自家公司还NB 的工程师为咱开始工作了!</li>
<li>技术团队的业界形象立即加持圣光了! 以后招人,也就不用送MM 之类的下作手法了,只说来了能同 XX项目的原创程序员一起工作!</li>
</ol>
<p>等等吧... 就不逐一推导了... </p>
<h1 id="_5">但是!<a class="headerlink" href="#_5" title="Permanent link">¶</a></h1>
<p>以上的一切好处获得的前题是:</p>
<div class="highlight"><pre><span></span><code>进行真正的开源项目运行
坚持以纯粹的开源社区形式运营
公司的真实业务系统真正使用开源项目的代码
</code></pre></div>
<p>以及,其实隐藏在这三项基本坚持之下引发的各种
<code>管理/组织/绩效/人力</code> 等等的配套支撑.</p>
<p>所以, 只能是SiFi 式的推导了... 因为中国IT 企业天生的同开源社区式开发有内在的抵触... 具体的,大家都懂的,不用俺费劲分析了卟?!</p>
<h2 id="_6">所以<a class="headerlink" href="#_6" title="Permanent link">¶</a></h2>
<p>友人收作业后反馈,肿么没有后续了? 比如遭遇各种反驳,如何进一步攻防之类... </p>
<p><code>图样儿图森破!</code></p>
<p>在公司里,不遭受质疑那是不可能的!</p>
<p>但是,有质疑就进行反驳... 你以为你是方舟子对韩寒哪!</p>
<p>企业进行开源,无非两种推行模式: <code>嬴政式</code>/<code>吴广式</code></p>
<ul>
<li>前者,BOSS 就是开源出身,先信了,强行推之,整个公司所有部门为之配合,反正败了BOSS 自个儿负责,然后,慢慢品出了好处,于是更加大力在实践中学习再学习,在学习中感动再感动... 慢慢的,公司如果不死,那就真正形成文化传承下去了,否则就变成业界又一SB 传说... </li>
<li>后者,习惯了开源开发方式了,瞒着公司,将自个儿一亩三分田先折腾起来,慢慢的,慢慢的对比其它同类团队的同类系统,肿么这么出名呢? 靠! 原来这丫开源了! 然后,没有然后了,不是被掐掉,就是这团队解散了... </li>
</ul>
<p>所以? 这些好处,多数情况,要不根本无从质疑 (BOSS稀饭!-) , 要不根本轮不到质疑,也就没有什么反击之说了... </p>
<p>其实! 公司里的质疑,根本没有质疑的任何意思在里面,无非是责任推卸:</p>
<div class="highlight"><pre><span></span><code>"我早就质疑过的哟,只是这丫不听,所以,没俺一毛钱关系!"
"看吧! 要不是早先我质疑过,他们才改进,现在肿么可能成功?!"
</code></pre></div>
<p>所以? 有质疑时,只要你勇敢的担当下来,没人有空跟你分析什么协议的... </p>
<p>所以! 在企业里推进OSS, 最最最低程度,你得是个有足够话语权的强力团队头目,或领域技术带头人... </p>
<p>不过,一般在这种地位上,都要担营收的KPI, 需要接销售各种奇葩的单子,哪儿有空搞 OSS 运动哪... </p>
<p>所以,俺反复说了是 <code>SiFi</code> 式的推理呢... </p>
<h2 id="changelog">Changelog<a class="headerlink" href="#changelog" title="Permanent link">¶</a></h2>
<ul>
<li>140107 move into Pelican as zoomquiet.io</li>
<li>131114 增补后续地图炮</li>
<li>131112 初放 <a href="https://medium.com/i-m-h-o/74caad149e7e">企业进行OSS的好处 — I. M. H. O. — Medium</a></li>
</ul>Collections and Embedded Documents in MongoDB2013-10-27T00:00:00+08:002020-01-31T16:42:10+08:00Zoom.Quiettag:blog.zoomquiet.io,2013-10-27:/mongo-collections-embdded-think.html<h1 id="mongodb">MongoDB 中的集合或嵌入式文档<a class="headerlink" href="#mongodb" title="Permanent link">¶</a></h1>
<p><img alt="mongo" src="https://d262ilb51hltx0.cloudfront.net/max/700/1*cwCnTFQEbcUSy1KvoiIqXg.png"></p>
<p>[via] http://fosterelli.co/collections-and-embedded-documents-in-mongodb.html</p>
<p>When someone is approaching MongoDB from the SQL world, a very common confusion regarding database structure is when to use embedded documents, and when to create an entirely new collection. This distinction is …</p><h1 id="mongodb">MongoDB 中的集合或嵌入式文档<a class="headerlink" href="#mongodb" title="Permanent link">¶</a></h1>
<p><img alt="mongo" src="https://d262ilb51hltx0.cloudfront.net/max/700/1*cwCnTFQEbcUSy1KvoiIqXg.png"></p>
<p>[via] http://fosterelli.co/collections-and-embedded-documents-in-mongodb.html</p>
<p>When someone is approaching MongoDB from the SQL world, a very common confusion regarding database structure is when to use embedded documents, and when to create an entirely new collection. This distinction is very important because, although MongoDB is schemaless in nature, whether or not an element of your database is structured as embedded documents or a separate collection will change your code a fair amount. Making this change later on can represent a fair amount of work, so it helps to get this right the first time.</p>
<p>There is no "right answer" to this question, as it depends entirely on the situation at hand. The natural tendency of people coming from the SQL world is to stick everything in separate collections, but often this is very unnecessary and will cause serious performance impacts. However, mistakenly placing something within another document may lead to pain further down the road.</p>
<p>A set of rules I have found useful is to ask yourself the following questions:</p>
<ul>
<li>Does the embedded document relate to one or more other collections?</li>
<li>Will you most often need the embedded document without the parent document?</li>
<li>Will you most often need the parent document without the embedded document?</li>
</ul>
<p>If the answer to two or more of these is yes, you likely will want a separate collection. If the answer to only one of these is yes, a separate collection should still be considered, but likely not needed.</p>
<h2 id="examples">Examples<a class="headerlink" href="#examples" title="Permanent link">¶</a></h2>
<h3 id="comments-on-a-blog">Comments on a blog<a class="headerlink" href="#comments-on-a-blog" title="Permanent link">¶</a></h3>
<p>You would like to create a system where people may submit comments on blog posts. The problem is that you are unsure if you should store the comment on the post document, or create a separate collection named comments.</p>
<h4 id="does-the-embedded-document-relate-to-one-or-more-other-collections">Does the embedded document relate to one or more other collections?<a class="headerlink" href="#does-the-embedded-document-relate-to-one-or-more-other-collections" title="Permanent link">¶</a></h4>
<p>No. A comment is typically related to only the post that it is commented on. There may be some situations where this is not true, such as if you provided comment author accounts for editing. However, even this is not a very convincing reason by itself to separate the comment into a separate collection.</p>
<h4 id="will-you-most-often-need-the-embedded-document-without-the-parent-document">Will you most often need the embedded document without the parent document?<a class="headerlink" href="#will-you-most-often-need-the-embedded-document-without-the-parent-document" title="Permanent link">¶</a></h4>
<p>Again, the answer is no. You likely will not often need to load a comment without also needing the context of the post.</p>
<h4 id="will-you-most-often-need-the-parent-document-without-the-embedded-document">Will you most often need the parent document without the embedded document?<a class="headerlink" href="#will-you-most-often-need-the-parent-document-without-the-embedded-document" title="Permanent link">¶</a></h4>
<p>In the majority of cases, the answer here is no. Most of the time you use this object, someone will be viewing a blog entry. You will want to both display the post and the comments at once, so it makes sense to fetch those together.</p>
<p>Overall, comments for a blog is a very good candidate for embedded documents.</p>
<h3 id="students-in-a-class">Students in a class<a class="headerlink" href="#students-in-a-class" title="Permanent link">¶</a></h3>
<p>You have a school management system, and you would like to enable students to enrol in a particular class. You are unsure if you should store the student objects on the class, or create a separate collection named students.</p>
<h4 id="does-the-embedded-document-relate-to-one-or-more-other-collections_1">Does the embedded document relate to one or more other collections?<a class="headerlink" href="#does-the-embedded-document-relate-to-one-or-more-other-collections_1" title="Permanent link">¶</a></h4>
<p>Typically, we can assume yes. A student will likely relate to other things, such as an assignment or school object. Also, a very important note is that each embedded document will likely relate to multiple documents in the classes collection, which is a very strong hint you need a separate collection.</p>
<h3 id="3-will-you-most-often-need-the-embedded-document-without-the-parent-document">3 Will you most often need the embedded document without the parent document?<a class="headerlink" href="#3-will-you-most-often-need-the-embedded-document-without-the-parent-document" title="Permanent link">¶</a></h3>
<p>The answer here will often be yes. If you want any sort of student information panel or want to have students enrolled in different classes, then you will often want the student document without needing the context of each class.</p>
<h4 id="will-you-most-often-need-the-parent-document-without-the-embedded-document_1">Will you most often need the parent document without the embedded document?<a class="headerlink" href="#will-you-most-often-need-the-parent-document-without-the-embedded-document_1" title="Permanent link">¶</a></h4>
<p>Probably no for this one. It depends on what operation we are doing most often with the class, but I imagine that when we fetch a class we would likely need at least one student as well.</p>
<p>Overall, students in a class are probably better suited for a separate collection. It's important to keep in mind the scope of the problem you are solving with the data, and the operations that will be done most commonly. That said, a student is a very relational piece of data and better fits a separate collection.</p>
<blockquote>
<blockquote>
<blockquote>
<p>尝试翻译为中文:</p>
</blockquote>
</blockquote>
</blockquote>
<p>如果刚刚从SQL 世界进入 MongoDB, 最常见的困惑就是 "嵌入式文档" 以及何时创建新的"集合"?
这类困惑的根源就是还没有建立起来 MongoDB 的自由结构世界观 ;-)
SQL 世界的来客,总是试图先建立起一个完美的关系体系可以兼容以后的所有业务变化, 而 Mongo们,则是更加愿意先将已知的数据舒服的收集起来,随着业务的理解,不断的调整结构,同时代码永远可用!</p>
<p>那么,这里给出俺知道的判定问题:</p>
<ul>
<li>嵌入的文档,同其它集合有一个或以上的关联嘛?</li>
<li>你将总会请求嵌入的文档,而 不需要 父文档嘛?</li>
<li>你将总会请求父文档,而 不需要 嵌入的文档嘛?</li>
</ul>
<p>如果以上问题,有两个或以上回答为 yes, 那么最好使用独立的集合.
如果回答只有一个为 yes, 那么独立集合也应该考虑,但一般不必要了.</p>
<h2 id="_1">示例<a class="headerlink" href="#_1" title="Permanent link">¶</a></h2>
<h3 id="blog">blog 的评注<a class="headerlink" href="#blog" title="Permanent link">¶</a></h3>
<p>你可能创建过类似blog 的系统,允许用户创建评注.问题在于你无法确定这堆评注,是存储在文章对象中呢,还是另外创建集合来保存?
动用以上问题来考查一下... </p>
<h4 id="_2">嵌入的文档,同其它集合有一个或以上的关联嘛?<a class="headerlink" href="#_2" title="Permanent link">¶</a></h4>
<p>首先呢,评注肯定是先同当前文章有关联的. 同时也有很多其它方案, 比如想支持作者可以修订评注. 但是,这还不足以今评注分离成独立集合.</p>
<p>你将总会请求嵌入的文档,而 不需要 父文档嘛?</p>
<p>再来,如果这问题的回答是 否. 意味着你并不想加载文章时,一定就显示评注.</p>
<h4 id="_3">你将总会请求父文档,而 不需要 嵌入的文档嘛?<a class="headerlink" href="#_3" title="Permanent link">¶</a></h4>
<p>多数情况,这个问题的回答是 否. 一般只是想显示文章, 只是有时,期望同时显示, 那就必须让这一动作简单.</p>
<p>综上, 评注作为 嵌入文档 是合理的.</p>
<h2 id="_4">班级中的学生<a class="headerlink" href="#_4" title="Permanent link">¶</a></h2>
<p>你有个学校管理系统, 想让学生作为特殊的一个类, 但是,不肯定是作为班级的嵌入文档呢, 还是独立集合.</p>
<h4 id="_5">嵌入的文档,同其它集合有一个或以上的关联嘛?<a class="headerlink" href="#_5" title="Permanent link">¶</a></h4>
<p>典型的,我们回答 是 . 每个学生总是会关联各种事物, 比如学校.同时,重要的每个嵌入文档同多个班级有关系时,这是分离为单独集合的重要暗示.</p>
<h4 id="_6">你将总会请求嵌入的文档,而 不需要 父文档嘛?<a class="headerlink" href="#_6" title="Permanent link">¶</a></h4>
<p>这问题经常回答为 是. 如果你想对学生进行多种排序,或是不同班级有不同学生参加,所以你总是想使用 学生节点而不是班级的信息.</p>
<h4 id="_7">你将总会请求父文档,而 不需要 嵌入的文档嘛?<a class="headerlink" href="#_7" title="Permanent link">¶</a></h4>
<p>这问题可能就是 否了. 这取决于我们经常怎么使用班级的数据, 目测其实我们最常查询班级的数据就是最后那名学生是谁.</p>
<p>综上,班级学生最好分离为独立的集合. 重要的是问题域要关注你的数据,并且令数据分布吻合常见事务要求. 即, 学生关联那多数据,最好独立!</p>
<p>that all!</p>
<p>其实, 使用文档型NoSQL, 特别是 MongoDB, 放弃RMDB 那堆范式的概念,使用我们的直觉,从当前已知的常见操作出现来设计文档结构就对了!</p>
<h2 id="changelog">Changelog<a class="headerlink" href="#changelog" title="Permanent link">¶</a></h2>
<ul>
<li>140107 move into Pelican as zoomquiet.io</li>
<li>131027 pub. <a href="https://medium.com/i-m-h-o/c161d7036f89">Collections and Embedded Documents in MongoDB — I. M. H. O. — Medium</a></li>
</ul>reply On literate programming2012-09-18T00:00:00+08:002020-01-31T16:42:10+08:00Zoom.Quiettag:blog.zoomquiet.io,2012-09-18:/reply-yw-on-literate-programming.html<p><a href="http://yinwang0.wordpress.com/2011/05/18/literate-programming/">On Literate Programming | Surely I Am Joking</a></p>
<p>对于文学化编程,俺使用的是 Leo :
http://wiki.woodpecker.org.cn/moin/LeoEnvironment</p>
<p>你提及的:</p>
<ul>
<li>丢失了全景思考</li>
<li>程序不仅仅是文本</li>
<li>人的语言 …</li></ul><p><a href="http://yinwang0.wordpress.com/2011/05/18/literate-programming/">On Literate Programming | Surely I Am Joking</a></p>
<p>对于文学化编程,俺使用的是 Leo :
http://wiki.woodpecker.org.cn/moin/LeoEnvironment</p>
<p>你提及的:</p>
<ul>
<li>丢失了全景思考</li>
<li>程序不仅仅是文本</li>
<li>人的语言/认知 至上</li>
<li>痛苦的导航</li>
</ul>
<p>几个观点中,俺非常同意的是:</p>
<ul>
<li>目前并没有一个,可以真正统一人的思想以及程序代码形式的编辑方式/环境</li>
</ul>
<p>但是,目前为止,在代码的语法结构维度之上,可以给予我们一个可以自在记录原始思路的编辑方式,应该只有 LP 了;
从俺使用 Leo 进行各种编辑/编程 的体验而言</p>
<ul>
<li>LP 其实是关注包含时间维度的代码的变迁过程,而不是简单的精细化切分</li>
<li>其实,到最后看起来是碎片的代码片段,以及关系,并不是从一开始就形成的</li>
<li>而是在开发的过程中,逐步抽象/提取而成的</li>
<li>也就是説,在 LP 的编辑思想中,人的整体思路是最重要的对象,是必须随时加以记录的</li>
</ul>
<p>程序当然不仅仅是文本</p>
<ul>
<li>但是,程序只能以文本形式来管理/编辑/传播吼,,,</li>
<li>当然的,因为 LP 不关心 程序文本的运行时结构,所以,无法自动跳转到相关定义...</li>
<li>不过,俺感受到的是:</li>
<li>记不住的就是不重要的</li>
<li>不知道的就是不必要的</li>
<li>如附件截屏:</li>
<li>Leo 通过可视化的树形结点来记录了我对程序的整体思考</li>
<li>而右方的编辑区,永远只是当前结点的内容</li>
</ul>
<p>也就是説,通过 Leo 进行文学化编程的整体过程是一系列相同的重构过程串起来的:</p>
<ol>
<li>定个文件的框架</li>
<li>定个大致的(子)功能流程,每个先以可运行的伪代码记录下来</li>
<li>进入对应的结点完成功能</li>
<li>每当超过一定的行数 hold 不住了,说明应该进行重构,将重复部分抽象出去了
回到第1或是第2步...</li>
</ol>
<p>所以,如果是 Leo 这种的文学化编程环境</p>
<ul>
<li>并不太需要 IDE 类似的全程自动解析,追踪,导航,以帮助我们快速定位代码</li>
<li>因为,每次进行修訂的代码片段都足够小,关注的因素也足够少</li>
<li>而每个足够小的片段,都是从足够大的上层逻辑节点演化来的</li>
<li>即,有关整体程序的概念,结构,思路,永远在 outline 的节点树中有体验</li>
</ul>
<p>不过,你点出的工程性问题的确存在</p>
<ul>
<li>同 coffeescript , Leo 进行编程调试时,一样麻烦在</li>
<li>如果调试运行时,引发错误的代码,超出当前编程的片段范围时</li>
<li>错误信息反馈的行数,在 Leo 中找不到精确的对应</li>
<li>所以,只能 到输出的正常文本程序中搜索,明确了代码所在代码段后,才能回到 Leo 人工定位到对应的</li>
</ul>
<p>期待你的大一统式编程/测试/运行环境!</p>
<h2 id="changelog">Changelog<a class="headerlink" href="#changelog" title="Permanent link">¶</a></h2>
<ul>
<li>140109 pub. as zoomquiet.io's blog</li>
<li>120918 邮件 as:<div class="highlight"><pre><span></span><code><span class="err">发件人</span><span class="o">:</span><span class="w"> </span><span class="n">Zoom</span><span class="o">.</span><span class="na">Quiet</span><span class="w"> </span><span class="o"><</span><span class="n">zoom</span><span class="o">.</span><span class="na">quiet</span><span class="err">@</span><span class="n">gmail</span><span class="o">.</span><span class="na">com</span><span class="o">></span>
<span class="err">发送至</span><span class="o">:</span><span class="w"> </span><span class="n">shredderyin</span><span class="err">@</span><span class="n">gmail</span><span class="o">.</span><span class="na">com</span>
<span class="err">日期</span><span class="o">:</span><span class="w"> </span><span class="mi">2012</span><span class="err">年</span><span class="mi">9</span><span class="err">月</span><span class="mi">18</span><span class="err">日</span><span class="w"> </span><span class="err">下午</span><span class="mi">5</span><span class="o">:</span><span class="mi">22</span>
<span class="err">主题</span><span class="o">:</span><span class="w"> </span><span class="o">[</span><span class="n">via</span><span class="w"> </span><span class="n">On</span><span class="w"> </span><span class="n">Literate</span><span class="w"> </span><span class="n">Programming</span><span class="o">]</span><span class="w"> </span><span class="err">我的体验</span>
<span class="err">很有感觉</span><span class="o">,</span><span class="err">但是没有找到评注入口</span><span class="o">,</span><span class="err">只好直接邮件了</span><span class="o">;</span>
</code></pre></div>
</li>
</ul>CI is hard!2010-10-09T00:00:00+08:002020-01-31T16:42:10+08:00Zoom.Quiettag:blog.zoomquiet.io,2010-10-09:/101028_jacob-ci-is-hard.html
<p><a href="http://buildbot.net/">Buildbot</a>,
the venerable Python
<a href="http://en.wikipedia.org/wiki/Continuous_integration">continuous integration</a>
server, has the reputation of being complex and difficult to set up.</p>
<p>After spending a couple of weeks deep in Buildbot land, I've come to the conclusion that this reputation, while true, is only partially deserved. That is, Buildbot is complex, but only if …</p>
<p><a href="http://buildbot.net/">Buildbot</a>,
the venerable Python
<a href="http://en.wikipedia.org/wiki/Continuous_integration">continuous integration</a>
server, has the reputation of being complex and difficult to set up.</p>
<p>After spending a couple of weeks deep in Buildbot land, I've come to the conclusion that this reputation, while true, is only partially deserved. That is, Buildbot is complex, but only if you're trying to view it as an out-of-the-box CI solution. Buildbot suddenly starts to make much more sense if you view it as a framework for creating your own CI solution, not a CI server in its own right.</p>
<p>You won't find this revelation anywhere in the Buildbot docs, nor in any of the books or online material that cover the tool. There are some good tutorials out there showing how to set up a simple Buildbot instance – Jeff Younker's
<a href="http://www.amazon.com/dp/1590599810/?tag=jacobian-20">Foundations of Agile Python Development</a>
has the best one I've run across – but none of these examples make much sense when setting up a complex buildfarm with complicated requirements.</p>
<p>So I'm here to fill that gap. In this series of posts – I think I'm looking at five parts – I'll explain this "Buildbot is a CI framework" view, delve into Buildbot's architecture, and then walk through the complicated-but-worth-the-effort CI sever I've built for Django.</p>
<p>By way of disclaimer I should mention I'm anything but a Buildbot expert. I'm almost certainly Doing Things Entirely Wrong. I may or may not be using public APIs as I've simply trolled through Buildbot's source until I found something that did what I wanted. However, what I've got here on the other side makes me pretty damn happy, and I want to show it off.</p>
<p>Here, then, is</p>
<h2 id="part-1-background">Part 1: Background<a class="headerlink" href="#part-1-background" title="Permanent link">¶</a></h2>
<p>We've been looking for a CI solution for Django for quite some time. Over the years we've tried a bunch of different tools: Buildbot,
<a href="http://cruisecontrol.sourceforge.net/">CruiseControl</a>
,
<a href="http://hudson-ci.org/">Hudson</a>, and even some home-grown solutions.</p>
<p>Nothing's worked out. That is, nothing's been able to provide the "continuous" part: builds only continue working as long as there's someone dedicated around to babysit the system. This sucks: it's meant that at times Django's been broken on supported platforms simply because nobody's been bothering to run the tests.</p>
<p>A few weeks ago a few of us started banging on this problem again, determined to get it right this time. Eric set up a new Hudson instance (modeled after the one he'd been using at work), and I dove headlong into Buildbot again. I'm not really going to talk much about Hudson here, but I'll note that it's actually been really instructive working on two different systems in parallel. It's forced us to really think through and formalize our CI needs.</p>
<p>This led me to my first big CI revelation: </p>
<div class="highlight"><pre><span></span><code>CI is hard.
</code></pre></div>
<p>There's any number of "simple" CI tools out there... and they appear to work for exactly two projects (the project the tool was built to test, and the CI server itself, natch). The general purpose tools – Hudson, Buildbot, CruiseControl, etc. – are big, complicated, and heavily opinionated. This is a clear sign that we're in a space where even the basic tenets of the problem can't be agreed upon by all parties. CI is one of those problems that's hard because there really isn't a good core set of needs to be abstracted. Nearly every project has very different CI needs.</p>
<p>[This is part of what makes Buildbot so complicated: I think it's actually trying pretty hard to be completely agnostic and allow any kind of continuous integration system you could think up. If Buildbot was more opinionated it could drop some of the layers of abstraction, but because it's trying so hard to be everything to everyone it ends up being crazy complex. I've not decided if this is admirable or crazy. Both, perhaps.]</p>
<p>So what are Django's needs? What make CI hard for us?</p>
<ul>
<li>Django's big. The test suite is around 40,000 lines of code in something like 3,000 individual tests. We work constantly to speed up the test suite, but best case it still takes about 5 minutes to run.</li>
</ul>
<p>This means that our CI absolutely needs to be distributed – a single test server won't cut it.</p>
<ul>
<li>Our test suite isn't just unit tests; in fact, it's mostly integration tests. We run most tests against real databases and attempt to simulate as much of the HTTP request/response cycle as we can.</li>
</ul>
<p>This means that our build system needs to be heterogeneous: since we test against real databases, we need to have lots of different ones to test against. We can't just run a farm of Linux buildslaves running Python 2.6 and SQLite. Since slaves are heterogeneous, the build system needs to be highly targeted. We can't treat each build slave identically, but we'll need to target certain types of tests to the slaves that support 'em.</p>
<ul>
<li>We're ambitious in what we support: Django supports four versions of Python (2.4, 2.5, 2.6, and 2.7), three Python implementations (CPython, Jython, and PyPy), four database engines (PostgreSQL, MySQL, SQLite, and Oracle), multiple versions of each database (for example, we support six versions of PostgreSQL: 8.0, 8.1, 8.2, 8.3, 8.4, and 9.0), and a bunch of OSes (Mac OS X, Windows, and most Linux and BSD flavors).</li>
</ul>
<p>We need the capability to run all sorts of crazy combinations. In an ideal world, we'd actually be able to test against every single unique python/db/os combination.</p>
<p>This means that our build system needs to be capable of getting really big, potentially spanning dozens or even hundreds of machines. We're clearly talking cloud computing here: there's no way a bunch of volunteers can afford the money and time to keep a rack of dozens of heterogeneous hardware all running smoothly.</p>
<ul>
<li>As I mentioned, we're all volunteers. Nobody gets paid to babysit the CI server, which means it needs to be highly autonomous. Builds need to happen without any intervention. Most critically, build servers can't disappear, go "stale" or break because /tmp gets full.</li>
</ul>
<p>After a bunch of playing with these requirements, I sketched out a dream system that looked something like this:</p>
<ul>
<li>We've got a bunch of (dormant) VM images for a cloud computing service or platform.</li>
<li>Each image "knows" which kinds of configs it can build. For example, one image might have Python 2.4 and SQLite, while another might have Python 2.7 and PostgreSQL 9.0.</li>
<li>When new requests are made the build master spins up some VMs, hands them build jobs (based on the types of builds the VM can support).</li>
<li>When no more builds are in the queue for a particular VM, the build master shuts down the image and saves us money.</li>
</ul>
<p>Every out-of-the-box CI system I examined failed to give me that workflow. Most failed on the "heterogeneous" requirement. That includes Buildbot. I knew, however, that a few projects – PyPy, Chrome, and Python itself – were using Buildbot to some success against similar issues, and I knew that Buildbot had recently gained the ability to deal with cloud computing. Finally, since Buildbot's written in Python I was fairly confidant in my own ability to hack it to pieces if necessary.</p>
<p>Well, a couple of weeks later, I'm there: I have a Buildbot-based system that's doing exactly what I described above. I'm still not 100% sure this is the solution, but it's a solution, and it's working.</p>
<p>The rest of this series will dive into the code. Next time, we'll look at an overview of Buildbot's architecture and configuration, and I'll explain my Buildbot-is-a-framework revelation in more detail.</p>
<h2 id="changlog">Changlog<a class="headerlink" href="#changlog" title="Permanent link">¶</a></h2>
<ul>
<li>1406?? </li>
<li>140618 偶遇抄转</li>
</ul>What to write2009-11-10T00:00:00+08:002020-01-31T16:42:10+08:00Zoom.Quiettag:blog.zoomquiet.io,2009-11-10:/091110_jacob-what2write.html
<p>Tech docs can take a bunch of different forms ranging from high-level overviews, to step-by-step walkthroughs, to auto-generated API documentation. Unfortunately, no single format works for all users; there's huge differences in the way that people learn, so a well-documented project needs to provide many different forms of documentation.</p>
<p>At …</p>
<p>Tech docs can take a bunch of different forms ranging from high-level overviews, to step-by-step walkthroughs, to auto-generated API documentation. Unfortunately, no single format works for all users; there's huge differences in the way that people learn, so a well-documented project needs to provide many different forms of documentation.</p>
<p>At a high level, you can break down the different types of documentation you need to provide into three different formats:</p>
<ul>
<li>step-by-step tutorials,</li>
<li>overviews and topical guides to the various conceptual areas of your project, and
-low-level, deep-dive reference material.</li>
</ul>
<p>Let's look at each in turn.</p>
<h2 id="tutorials">Tutorials<a class="headerlink" href="#tutorials" title="Permanent link">¶</a></h2>
<p>Good tutorials are a must as they're usually the first thing someone sees when trying out a new piece of tech. First impressions are incredibly important: that rush of success as you work through a good tutorial will likely color your future opinions about the project.</p>
<p>Django's tutorial is frankly a bit musty at this point and is probably due for at least a light refresh, but it hits all the important points. A good tutorial should:</p>
<ul>
<li>
<p><code>Be quick.</code> At some conference or another I heard someone – I think it was <a href="http://headrush.typepad.com/">Kathy Sierra</a> – say that, as a rule of thumb, a new user should be able to experience success within thirty minutes. That's a great rule: thirty minutes is nothing – think "half a lunch hour." If your project can give new users the warm fuzzies that quickly, they'll come away wondering about all the awesome successes a deeper dive might give.</p>
</li>
<li>
<p><code>Be easy.</code> Remember: you want success to be the outcome of the tutorial. This means you need to playtest the tutorial under all sorts of different circumstances, making sure that it always works (even on Windows).</p>
</li>
<li>
<p><code>But not too easy.</code> There's always going to be a class of users who aren't really qualified to use your project. Someone who's never written any code before isn't going to get very far with Django; those types of users should fail quickly. Don't get them through the tutorial only to run into a wall later on.</p>
</li>
</ul>
<p>Another similar anti-pattern is glossing over bad choices made in the interest of expediency. Django's tutorial makes this mistake: we gloss over the project/app distinction in a way that bites users later on. (It'll get fixed soon, I promise!)</p>
<p>The best way of thinking about a tutorial's ease is that it's the on-ramp onto your project's learning curve. This means the slope can be more gradual than later tasks, but no so much so that things suddenly get much much harder after the tutorial's finished.</p>
<ul>
<li><code>Demonstrate how your project "feels."</code> More than anything, people are using your tutorial to get a sense of how your project is going to "feel" in the long term. This means you that it should be pretty cross-sectional; a good tutorial should show off most of the different areas of the project.</li>
</ul>
<p>A couple of projects with really good tutorials to check out for inspiration are
<a href="http://love2d.org/documentation?page=documentation">LOVE</a> and
<a href="http://lamsonproject.com/docs/getting_started.html">Lamson</a>.</p>
<h2 id="topical-guides">Topical guides<a class="headerlink" href="#topical-guides" title="Permanent link">¶</a></h2>
<p>This is the meat of your documentation. Once somebody's learned (from a tutorial) the high-level concepts, they're going to need to dive into the details of some area or another. Any documentation worth its salt is going to have a whole bunch of these – Django's got about 35 different topical guides, covering each conceptual area (e.g. models, sessions, testing, etc.)</p>
<p>These don't need to cover every single configuration option or function argument – that's what reference material is for – but each guide (or section, or chapter, depending on how things are organized) needs to take a pretty deep dive into its respective area.</p>
<p>The main goal for topical coverage should be <code>comprehensiveness</code>. The reader ought to come away from a close read feeling very comfortable with the topic in question. They should feel that they know the vast majority of the possible options, and more importantly they should understand how all the concepts fit together.</p>
<p>Unfortunately there aren't a lot of projects that do these very well. Most have reasonable tutorials, many have okay-to-good reference material, but most seem to leave the topical guides to books.</p>
<p>While it's true that books shine in the "topical guide" area, they're not really a great substitute for guides as part of the official documentation. Official docs, even when done poorly, are usually much more up-to-date; books, even when done well, are often out of date the day they hit the shelves.</p>
<p>Books-as-guides can be done well – the
<a href="http://svnbook.red-bean.com/">Subversion Book</a>
is a great example – but only when the book is continuously maintained available for free.</p>
<p>There's a particularly pernicious anti-pattern in documentation where tutorials are provided for free but the real documentation is only available for purchase. At best that's lazy and sloppy; at worst it's downright evil. Free software needs free documentation. If you've got otherwise you should be ashamed of yourself.</p>
<h2 id="reference">Reference<a class="headerlink" href="#reference" title="Permanent link">¶</a></h2>
<p>Finally, you need complete reference for all the public APIs your project provides. These should be designed for those who already know how to use some API, but need to look up the exact arguments some function takes, or how a particular setting influences behavior, etc.</p>
<p>It's important to point out that reference material is not in any way a substitute for good tutorials and guides! Great reference material on the foo.baz package does readers no good whatsoever if they don't know the name of the package they're looking for.</p>
<p><a href="http://docs.python.org/">Python's documentation</a></p>
<p>is a perfect case in point. The individual standard library modules tend to have incredibly good documentation, but there's no high-level overviews to help you discover which module you might actually want! Take for example the
<a href="http://docs.python.org/library/collections.html">collections</a>
module: it's great reference material, explaining exactly what's in the module, how to use it, and what all the options are. But if you don't know that Python ships with a
<a href="http://en.wikipedia.org/wiki/Double-ended_queue">deque</a>
implementation in collections.deque you'll probably end up missing the library entirely.</p>
<p>Think of guides and reference as partners: guides give you the "why," and reference gives you the "how." Following the deque example, some sort of "guide to data structures in Python" could give an overview of all the different types of data structures in Python (be they built-in or standard library), linking off to the documentation for each module and type for the complete details.</p>
<p>It's really tempting to use an auto-documentation tool like Javadoc or RDoc for reference material.</p>
<h2 id="dont">Don't.<a class="headerlink" href="#dont" title="Permanent link">¶</a></h2>
<p>Auto-generated documentation is almost worthless. At best it's a slightly improved version of simply browsing through the source, but most of the time it's easier just to read the source than to navigate the bullshit that these autodoc tools produce. About the only thing auto-generated documentation is good for is filling printed pages when contracts dictate delivery of a certain number of pages of documentation. I feel a particularly deep form of rage every time I click on a "documentation" link and see auto-generated documentation.</p>
<p>There's no substitute for documentation written, organized, and edited by hand.</p>
<p>I'll even go further and say that auto-generated documentation is worse than useless: it lets maintainers fool themselves into thinking they have documentation, thus putting off actually writing good reference by hand. If you don't have documentation just admit to it. Maybe a volunteer will offer to write some! But don't lie and give me that auto-documentation crap.</p>
<h2 id="whats-next">What's next<a class="headerlink" href="#whats-next" title="Permanent link">¶</a></h2>
<p>Now that I've covered what to write, I'll move into how to write. Tomorrow I'll start going into the actual mechanics of writing good, readable technical prose.</p>
<h2 id="changlog">Changlog<a class="headerlink" href="#changlog" title="Permanent link">¶</a></h2>
<ul>
<li>1406?? </li>
<li>140618 偶遇抄转</li>
</ul>探讨 信息化社会中 中国传统思想的作用1998-01-01T11:17:00+08:002020-01-31T16:42:10+08:00Zoom.Quiettag:blog.zoomquiet.io,1998-01-01:/issue-chinese-for-internet.html<p>(<code>是也乎:</code></p>
<p>这是大学选修课:<code>科学史</code> 的论文,
算是自个儿思想的黑历史...总算能有足够的心力来直面互联网时代前的5毛思想了...
)</p>
<p>~ 不远的 …</p><p>(<code>是也乎:</code></p>
<p>这是大学选修课:<code>科学史</code> 的论文,
算是自个儿思想的黑历史...总算能有足够的心力来直面互联网时代前的5毛思想了...
)</p>
<p>~ 不远的将来面对的是技术化,信息化的高科技社会,这种社会本身是反人文,反文化的,中国传统思想是救赎信息化人类社会的唯一凭借!</p>
<h1 id="_1">二十一世纪必然是信息化社会,面对的是计算机技术为主的数字化生存.<a class="headerlink" href="#_1" title="Permanent link">¶</a></h1>
<p>70年代中期以后,出现了以微电子技术为核心的新兴技术群,开始了继蒸汽机,电力之后的第三次技术革命. 主要包括信息技术,新能源技术,新材料技术,生物技术,空间技术和海洋技术六大领域的革命. 以微电子技术为基础的信息技术是新技术革命的主导技术和主要标志,其开辟了人类历史上的新时代棗信息时代. </p>
<p>随着信息的采集,加工,利用的技术越来越成熟,对信息认识的深化;又随着信息高速公路的建设,信息的产业化,已使之越来越成为全社会影响力最大的因素. </p>
<p>全人类也以达成共识:当信息高速公路将所有图书馆,学校,医院,实验室,电视,电话,公司等等全社会连接起来时,将产生不可估量的社会生产力!</p>
<p>随着各种新技术的广泛应用,将使人类的生存条件和生活方式发生前所未有的改变:环境污染大大减少;资源能够合理开发利用;人口数量得到控制,素质会有较大提高"绿色食品"和新型医药,使人们更加长寿和健康......</p>
<p>如此美好的前景,使人类社会进入到"后工业社会",即以信息产业为主的社会,成为不可扼止的趋势. </p>
<h2 id="_2">高技术化,信息化的社会与自然人文本质上背离<a class="headerlink" href="#_2" title="Permanent link">¶</a></h2>
<p>~ 现代技术的进步是以几何速度递增的. </p>
<p>人类大约经过100万年才达到农业革命,再10,000年便达到第一次工业革命,仅仅又不到两个世纪就达到第二次工业革命,不足半个世纪便迎来了第三次技术革命!</p>
<p>如此惊人的速度带来了一个不能回避的问题:人类作为一个物种,能否柔顺到足以适应一种他们正在如此迅速地改变,并在许多情况下予以污染的环境?</p>
<p>发达工业社会中,人们社会心理的虚无,失衡,精神创伤和人际关系的淡漠不断加剧,社会"失范"......使人们越来越意识到高科技的消极影响,认识到科学既能成为潘多拉盒子,又能成为神灯. 同时,又自信地想象选择权在人类手中---"因为科学是中立的",认为所有新技术都是人类精神发展的无情的产物. 不管它是否会造福于人类,还是会给人类带来灾难,都应该被人们接受,因为它与科学一样是冷酷的,是不含有意识形态的价值判断的!</p>
<p>但是,现在发觉,沉醉于现代生活中的人类所依赖的高技术,决不是中立的!</p>
<p>科学是一种价值观. 当人们试图谅解和揭示宇宙运行所遵循的自然法则时,所面对的是一个需要静思冥想的严肃话题. 人们如果想揭示和认知这一法则取决于人们能否听命于善德的支配,在与自然对话和进行自我批评时,能否做到绝然的率真和谦逊. 就是一个道德上的问题. 技术同样也会涉及伦理学的范畴,但是其出发点与之孑然相反---绝大多数技术是为了巩固和维系现时社会的统治与依附关系的. </p>
<p>在对自然界进行观察以及在与自然界对话的过程中,科学总是表现得谦恭,深沉,同时又是令人满怀敬意的,而技术则总是高高在上,作出主宰一切的姿态. </p>
<p>比如说:当抗议声浪迭起时,当人们反对在自己的住所附近兴建核电站时,那些对于不断拓展自己的财富和权力感兴趣的人,就会反驳:"这些人太感情用事了. 我们总不不能回到石器时期. "(他们最喜欢说石器时期)"他们知道核物理对于不断增长的人口的能源需要意味着什么?"以及"这一问题只能和受过良好教育的专家,那些头脑冷静客观的人们探讨,他们知道自己应该说些什么. "许多参加抗议的人就会因此信服技术官僚. </p>
<p>事实上,在这里两方面都存在着很强烈的感情因素. 抗议一方,感到自己的生命受到了威胁,同时看到就种损害还将危及到自己的子孙后代;而可以从兴建核电站中受益的一方,则担心自己的利益受到伤害,害怕失去自己手中的权力. </p>
<p>但是,情感出了什么问题?人类的各种行为无不是被不同的情感所左右的. 科学和技术同样都具有感情色彩,但是它们展现的是孑然相反的不同情感:科学是深沉的,它力求理解这个世界,这一态度充满了爱. 而技术则希望统治,最终走向野心勃勃!</p>
<p>诚然技术的发展满足了人对物质欲望和现世幸福的需要,但人类也为此付出了巨大的代价. 在技术社会中,大规模生产产生的是标准化产品,大众媒介产生的是一种单一的文化. 个性失去了,甚至人与人之间的相互联系也被机械化与客观化了. 不仅如此,技术要求合理和有效的分层制组织,效率需要分工,专业化,速度和输出的最大化. 当它本身成为目的之时,其所产生的一切负作用棗人类的代价就被漠视了. 人文主义者所构想的理性王国在实践上表现为技术王国. 在这个王国里,技术以理性的名义支配着一切,所有的东西都是按照成本和利润原则,效率原则等运作的,自由,平等,博爱的理想在现实面前显得苍白无力;在技术的权威之下,人的自主性消失殆尽. 而这一切,有悖于当初人们热切地发展科技时所怀的崇高理想. </p>
<p>这都是因为技术,在它帮助人类改造自然时,也对人类自身的生活方式,思维方式和处事方式等产生了不可逆转的巨大影响,从而体现了其伦理与政治的价值,而非是一种简单的为达到目的的中性手段或工具体系. </p>
<p>需要注意的是,技术总是指下面几种东西的任何一种:</p>
<ol>
<li>技术知识,规则与概念;</li>
<li>工程或其它的技术实践,甚至包括对应用技术知识的特定职业态度,规范与假定;</li>
<li>由这种技术实践所生产或制造出来的物质工具,装置与人造物;</li>
<li>将技术人员与工艺建构到技术系统与体制中的组织活动;</li>
<li>由技术所带来的社会的技术状况或特点等等. </li>
</ol>
<p>这里所讨论的只是那种人类改变与控制自然环境的物质性技术或"自然技术". </p>
<h3 id="_3">现代技术是价值负载的:<a class="headerlink" href="#_3" title="Permanent link">¶</a></h3>
<p>这至少体现在如下几个方面:</p>
<ol>
<li>现代技术急剧改变了人类周围的空间,造成了生态环境的严重后果;</li>
<li>随着现代技术与工业厂家和工业利用结合成一个整体,现代技术作为第一位的生产力已纳入到经济与政治系统之中,对技术活动的控制与导向已成为各国政府的重要责权;</li>
<li>现代技术执行着意识形态的功能. 现代技术与科学已取代传统的神话和宗教而成为现代社会中一切现象赖以合法化的基础. 当代工业社会利用技术的进步而非传统的恐怖手段来征服对立的,离心的社会力量. (因而当代工业社会成为没有对立面和反对派的单向度的社会!)</li>
<li>现代技术制成了知识与生活世界的分裂;</li>
<li>现代技术造成了传统文化与价值观的崩溃与断裂. 现代技术是建立在传统形而上学(某种意义上即人类中心论)的基础上的,它趋向于捕获和控制每一个东西,使世界变得愈来愈依赖于人,而人愈来愈依赖于其虚无缥缈的意识. 因此,现时代是一个虚无主义的时代,上帝已死,人则无家可归. </li>
</ol>
<h3 id="_4">当代工业社会使人变成了单向度的人:<a class="headerlink" href="#_4" title="Permanent link">¶</a></h3>
<p>即丧失了对现存社会否定和批判的原则这一第二向度,而只剩下屈从于现存社会制度的向度的人. </p>
<ol>
<li>当代工业社会通过愈来愈舒适的生活标准把人们束缚在现有的社会体制中,使人变成了只追求物质的人,丧失了追求精神自由和批判的思维能力. 现代社会大量的运输与通讯工具,住,吃,穿的各种商品,娱乐和新闻事业的产品,造成了一种人们愿意接受的很好的生活方式. 然而,这种为商品而生活的生活方式妨碍着质的变化,于是便出现了单向度的思想和行为,任何超越,否定现存制度的思想和行为会受到排斥;</li>
<li>由于科技的高度发展,当代工业社会不仅能够利用先进的技术手段控制物质生产过程,而且也加强了对人的心理,意识的操纵与控制,使人们彻底屈从于整体社会需要,从而丧失了对现存制度的怀疑性;</li>
<li>当代工业社会由于自动化的实现而变成了一架巨大的机器,人沦为一个功能性的部件,丧失了自由,成为被管制和操纵的对象. </li>
</ol>
<h3 id="_5">现代社会所依从的技术理性<a class="headerlink" href="#_5" title="Permanent link">¶</a></h3>
<p>至少包括如下基本文化旨趣的一整套观念:</p>
<ol>
<li>人类征服自然;</li>
<li>自然的定量化;</li>
<li>有效性思维;(指的是在行动中对各种行动方案的正确决择和对工具的效率的追求)</li>
<li>社会组织生活的理性化,包括体力劳动与脑力劳动的分工,生产的科层控制等;</li>
<li>人类物质需求的先决性---这是最根本的一点. 只有在人类的物质需求获得了相对于其它需求的绝对优先后,人类的才华才有可能大规模地投入物质生产技术,而非诸如欧洲中世纪的那种拯救技艺. </li>
</ol>
<p>人类在技术理性的指导下,从自然界和宗教的蒙昧中解放出来,却又被理性的自身创造物---机器,商品和技术官僚制所奴役. </p>
<p>但是,人类已在这条依赖技术的社会发展之路上无法回头,解决问题还是要靠科学技术的正面价值,靠技术与科学的发展来解决. 若因噎废食,一味地排斥技术只有可能造成更大的灾难. </p>
<p>所以,原子时代之父爱因斯坦留下了一句警世之语:"原子释放出的能量正改变我们的思想方式以外的一切,因此我们正走向空前的灾难". </p>
<p>果然,出现了新的希望---以研究信息的获取,存贮,变换,传输,处理,利用和控制的规律为任务的当代新兴学科---信息科学掘起!</p>
<h1 id="_6">网络时代·数字空间里,没有宗教,国家,政党·"原子"与"比特"<a class="headerlink" href="#_6" title="Permanent link">¶</a></h1>
<p>40年来,信息技术以极惊人的速度发展着. 自1945年第一台电子计算机ENIAC成功制造到今天,全球已充满了电子计算机,信息技术已渗透到社会生产和生活的一切领域,信息产业正逐步取代传统工业占据主导地位,人类社会已进入了信息时代. </p>
<p>信息时代向我们所展开的图景,根本不同于工业时代的机械化大生产的观念,即在任何一个特定的时间和地点以统一的标准化方式重复生产的经济形态. 而是一种"数字化生存",其能够显示甚至更大的经济规模,令时空与经济的相关性减弱了,无论何时何地人们都可以制造'比特'而实现价值... </p>
<p>越来越多的信息提供者(同时又是消费者)连入信息高速公路,越来越多的信息资源在网上共享,增殖和利用... 整个世界正渐渐为信息更有效的管理和控制. </p>
<p>人也已一代比一代"数字化",越来越多的接受数字化的信息,发布数字化的指令,生产享用数字化的产品,进行数字化的交流... </p>
<h2 id="_7">因为数字技术的四个强力的特质,使信息时代的前进不可阻止:<a class="headerlink" href="#_7" title="Permanent link">¶</a></h2>
<ol>
<li>分散权力: <ul>
<li>原先尊贵的大型机,已逐渐被低成本,大批量生产的PC的相互联结而取代;分布式系统已被证明具有无限升级的潜质,就是之前无论多么伟大的巨型机都不可想象的!</li>
<li>电脑联结起来共同处理计算消耗大的问题,使它可以用一种全新的,可升级的方式满足自身的需求. </li>
<li>这令电脑确实的既可以为个人服务,也可以为群体服务. 可以看到同样的分权心态正逐渐弥漫于整个社会中,这是由于数字化世界的年轻公民的影响所致. </li>
<li>传统的中央集权的生活观念将成为明日黄花. </li>
</ul>
</li>
<li>全球化: <ul>
<li>由于网络中,数字化空间是个没有距离的空间,在这里世界已缩小为一个'地球村',且能在任何一台PC上被自由地互览. </li>
<li>民族国家本身也就遭受到巨大的冲击,因为从前受民族主义力量的阻挠,而无法达成的方案等,在数字空间里都为轻而易举. </li>
</ul>
</li>
<li>追求合谐:<ul>
<li>当政治家们还在背负着历史的包袱沉重而行时,新的一代正在从数字化的环境中脱颖而出,完全摆脱了许多传统的偏见. </li>
<li>过去,地理位置相近是友谊,合作,游戏和邻里关系等一切的基础,而现在的数字化一代则完全不受地理的束缚. </li>
<li>数字科技可以变成一股把人们吸引到一个更和谐的世界之中的自然动力. </li>
<li>这一点已变得很明了了---过去明争暗斗的学术界和尔虞我诈的企业都开始以合作取代竞争,因为一切的发明和进步都不须等候,它就在此时,此地!(数字化多媒体通信,可以让全球不同地方的科学家同时进行同一个实验;或是不同地点的学生同时学习一个最新技术概念... )</li>
</ul>
</li>
<li>赋予权力:<ul>
<li>这是数字化生存的本质,也是对数字化生存抱有乐观主义的人的主要依赖. </li>
<li>数字化生存之所以能让我们的未来不同于现在,完全是因为它易进入,具备流动性及引发变迁的能力. 数字化的未来将超越人们最大胆的预测. </li>
</ul>
</li>
</ol>
<p>数字化生存以更惊人的速度,更彻底的深度,广泛地改变着我们的生活.
信息时代中,大众传媒的受众往往只是单独一人. 所有的商品都可以订购,信息极端个人化,数字化生存中,我就是"我",而非人口统计学中的一个"子集". </p>
<p>"Have It Your Way",成为数字化生存的标准. 在熟知你的一切的PC的帮助下,你可以在你所喜欢的任何时候,任何地点,以任何你所喜欢的方式受教育,工作,消费... 进行一切社会活动!</p>
<p>"没有空间的地方", 数字化空间,即电脑空间中,每一个机器的距离都一样,除了地球本身的范畴
之外,电脑空间完全没有物理边界. 正如媒体一方面变得越来越大,另一方面又变得越来越小,就整个世界的管理而言,情况也如出一辙.
... ... </p>
<p>当然可以看出,数字化生存,依然是一种高技术的反人文的非自然生存. 只不过技术所控制的对象由全社会变成了具体的个人. 每一个人被信息技术精心照料着,人对技术的依赖性更强了. 虽然这种数字化生存,表面上不再受8小时工作制,机关,教室等的时空限制,而实际上每个人还是技术化社会中精细分工的一个小小的单一功能单元,而非人本主义意义下的完整的人. </p>
<h2 id="_8">原子与比特...<a class="headerlink" href="#_8" title="Permanent link">¶</a></h2>
<p>更可虑的是,在由原子组成的现实的社会空间中,每个人被迫禁锢在一个功能角色上;而在由比特组成的数字空间里,却又绝对的平等,自由,被公平的赋予权力棗只要以适当的方式方法,不论你是想邮购书籍,还是想控制美国的核武器,都不会受到限制! </p>
<p>如此剧烈的反差,当然的造成了一个不满社会现实的最佳宣泄口,致使数字化犯罪,Hacker盛行... 更可怕的是,现行的一切法律,法规都是针对"原子"的,在数字化空间中,它们就象离开了水的鱼拼命挣扎般难逃毁灭的命运. </p>
<p>比如:你带了一些CD想通过海关,可能被视为走私,但是你从网上传送同样的CD的"比特"回家,则不会有任何人来找你的麻烦;你在一个国家的边境行走时,很可能因越界而被射杀,但是你在网上随意浏览他国的一切时却毫无危险... </p>
<p>所以说数字空间是世界性的,无疆界的世界,国家的角色将越来越没有发展的空间. 可以料想如同樟脑丸会从固态直接挥发一样,国家根本不需要经过一场混乱,就已消逝无踪. </p>
<h2 id="_9">进而,人类文化的混乱是不可避免的!<a class="headerlink" href="#_9" title="Permanent link">¶</a></h2>
<p>基于如此的前景和后果,人类现存社会及可预测的未来社会的社会弊端和问题可以归咎于技术,但是试图拒斥技术的作法是错误的. 我们需要反对的是科学技术的文化霸权,是技术理性的虚无主义扩张. 推进人文主义的人性化,论理化技术!</p>
<p>然而,面对正急速到来的信息化社会,依据什么来推行人文视野中的技术?依据什么来重新构筑适应新社会的人类文化?依据什么来重新构筑数字化生存中的有效法规,社会规范?依据什么来协调与已被蹂躏得千创百孔的自然的关系?依据什么来... ?!</p>
<h1 id="_10">基于以上前景,中国传统思想的博大精深使之成为数字化生存中人类的救星:<a class="headerlink" href="#_10" title="Permanent link">¶</a></h1>
<p>面对战后世界的急剧变迁,当代世界哲学也适应地有了速度更快,传布更广的运动性特点. 并且具有了科学化,内在化,伦理化的共同特性. 任何哲学都不可能超越它所处的时代和社会,同样每一个时代和社会又需要适当的哲学的参与和干预. </p>
<p>在我们现时代所盛行扩散的工业文化,更确切的说是一门狂热的宗教,是一门不幸的婚姻---中世纪基督教徒的世界观和古希腊古典主义思想结合的产物. 这种宗教没有从佛教或是印度教中汲取任何营养,它从万物有灵论中吸取的精华也似是而非,同时也不是单纯发端于古希腊的思想. 格守人本主义思想的中世纪基督徒把世界视为"涕泣之谷",就个充溢了罪恶的深渊同时也是难以持久的,它必须被人类征服,并臣服于人类的统治. 这种消极的目光一直保留到今天. 在我们眼里,科学不是人类认识和读解宇宙奇伟瑰丽的窗口,而是一个技术不断更新的源泉,用以征服,统治整个自然和人类自身!</p>
<p>那末面对信息时代中,由于人的"原子"化孤立和"比特"化自由的社会属性之断裂而造成的文化,观念崩溃,要什么样的哲学思想才能匡护纠正?</p>
<p>放眼世界哲学思想,可以说只有中国传统思想才能担当此重任!
这就是由中国传统思想的特性所决定的:</p>
<p>中国传统哲学思想很独特,不论是儒之入世务实还是道之玄妙或是佛之浪漫圆融,其核心总是人生观而非宇宙观,侧重点是社会观而非自然观,重点研究对象,是"人". </p>
<p>与西方的人本主义不同,中国的人本主义是作为传统文化存在的,而非是作为反传统思潮出现的. 更重要的是,中国传统思想所研究的"人",从来不是孤立的,个体的,孤独的"人",而是群体的人或人的群体,是社会的人和人的社会. 总而言之,中国传统思想哲学是从相互联系中推论和规定人的本质的,中国传统思想所研究的是联系中的人或人的联系,其最高宗旨是寻求人际关系的稳定,有序,和谐,所以,中国传统思想哲学,堪称是辩证的人本主义,或有机和谐的人本主义. </p>
<h2 id="_11">可以看出,中国传统思想的很多本质特性是与数字化生存图景里的特性相契合的:<a class="headerlink" href="#_11" title="Permanent link">¶</a></h2>
<ul>
<li>"全球意识"与儒家的"天人合一",老子之"人法自然",佛之"诸法空相"... 思想相一致;</li>
<li>"追求和谐"与儒家的视人我和谐的人生理想为生活最高准则的观念,与老子之"自然无为",佛之追求"常乐我净"的立地成佛等的观念相一致;</li>
<li>... ... </li>
</ul>
<p>并且中国传统思想一向不同于西方传统哲学那种封闭,一元绝对的体系的思维方式不同,是一种大自然眼光的追求大和谐的思维方式,可以说是一种"道德的宗教". 在仪式上,它将一般宗教仪式转化为日常生活中的礼乐;在信仰上,它以天人一体取代一般宗教的人格神. 因此,儒教能够给人们现世的安慰,使人通过道德养成而达到"仁者与天地万物一体"的境界,从而满足人们突破个人有限生命取得无限圆满的愿望. 儒家这种将神性通过道德寓于人性的进路,完善地统一了现世伦理界与未来超越界,是其它宗教所做不到的. </p>
<p>中国传统思想的这种圆通的,着眼于人性,不执着于现世社会的开放的思维方式,正是其历久常新的积极因质所在. 也非常与现代自然观相吻合. </p>
<p>通过宇航技术使人类得以以新的视角来看待地球---地球,并非如达尔文进化论所理解的先为生物提供了适于生存的条件而后才有生物的适者生存;相反,地球通过生命(光合作用)而捕获,转移,储存太阳能,通过生命活动(生物与地球的化学作用)而推动地球表层物质元素循环,并通过生命过程去调节,控制,维持自身的系统平衡. 正是生命的参与,才使地质历史构成生物圈,才使地球保持平衡态!地球本身也是一个生命体系,作为一个有生命的机体,它的要求本身也应得到应有的关注和尊重!---生态学家将这种关系称作"该娅定则"(以古希腊中大地女神该娅的名字来称呼我们所世代居住的这个星球)</p>
<p>另一方面,电脑虽然没有道德观念,但随着数字化生存的到来,电脑越来越以一种实在的生活参与者的姿态加入人类社会,人文主义的人性化,论理化技术的发展,也要求电脑具备一种全球性的全人类高度的道德!以便在数字化空间里建立秩序;并且也需要人性化,论理化的数字化管理者,在数字化空间中行使职权... 也只有一贯注意伦理道德的中国传统思想才有资格提出这样一种旨在全人类社会与地球,自然的大合谐的道德规范. </p>
<p>还有,中国传统思想的"合知行"观念,即强调思想学说与生活实践相融合使道德准则融于日常生活中,令博大精深的哲学思想观念外表上平淡得不象思想,却又在日常工作中潜移默化入人的血脉之中再无法摆脱. 也只有这种形式才可能有效地约束住不断高速变迁的社会中的社会行为!
... ... </p>
<h1 id="_12">总之,<a class="headerlink" href="#_12" title="Permanent link">¶</a></h1>
<p>中国传统思想的沉厚人文主义内容,决定了其指导信息社会数字化生存的主导地位. </p>
<p>这是通过对信息的社会特点的分析,明确主要矛盾后反推出的唯一回答. </p>
<p>并且东方哲学中,印度哲学和阿拉伯哲学与宗教意识密不可分,因而,不可能象中国传统思想哲学那样作为全人类的哲学来发展. </p>
<p>中国传统思想的主要成分---现世思想(儒学),只是因近代的外族入侵,而被迫中断了发展,并为更注重实效的适合于工业化商品社会的马列主义,毛泽东思想所替代. 但,其之固有的可贵特质,使我们不得不重新认识它,发展它,完成古代哲学思想向现代的转化,使中国传统思想的'无为而制','天人合一'等的积极因质发扬起来,拯救危机中的人类文化!</p>
<p>我们再不能继续扮演地球致命寄生虫的角色了!</p>
<p>"科幻是一种引导我们如何面对未来的伟大艺术",所以,作为科幻迷亦或是科幻事业的从业者,都必须具有比常人更加敏锐的感知力,和历史责任感,将对宇宙,生命,未来... 的敬畏,对人类不同前景的合理推想,未来社会的生活态度等等作为人不能逃避的种种思考传播出去,让越来越多的人们特别是青少年,也加入到这种向上的健康活力的阵营之中,形成力量改变更多人的观念,让人类学会与创造合谐共处,否则我们终会走向灭亡!</p>
<h2 id="_13">希望在未来,向下一代讲述科技时会象这般自然朴素:<a class="headerlink" href="#_13" title="Permanent link">¶</a></h2>
<blockquote>
<p>"</p>
<p>一小群人聚集在山坡草地的篝火旁,坐在中间的最年长的妇女是在座某个孩子的祖母. </p>
<p>老奶奶也许会拾起一大块花岗石说道:'从前,在地球刚刚形成的时候,整个星球到处是沸腾的溶岩,我们膜拜岩石,因为岩石给了我们一切---不仅是大洲和高山,而且还有树木,海洋和你们的身体. 岩石就是你们的祖父祖母. 当你想知道是什么将你铸造成今天的这个生命时,你必须首先想到岩石,因为没有岩石,你也就不存在. '</p>
<p>她在他们面前举着这块岩石,向他们一一展示. '你们 听见岩石在歌唱吗?</p>
<p>在上个世纪元,人们认为岩石里没有音乐,但今天我们知道那是错的. 总之,一些岩石变成了莫扎特,并像莫扎特那样表现音乐. 你是不是认为人们必须到火星上去学习音乐?不必,莫扎特就岩石,他就是地球上岩石的音符. "现在她慢慢把手插入土地,掬起一捧沃土放在面前:"每一块岩石都是一首交响乐,但泥土所发出的音乐却不是人类的语言可以表述的,我们必须进入外层空间才能够理解泥土是多么的宝贵. 只有地球才产生泥土. 火星上没有泥土,金星上没有泥土,太阳,木星或亿万英里之内的空间都没有泥土. 即使在太阳系中最富有创造力的地球上,也要化上40亿年的时间才会产生泥土. 我们之所以崇拜,滋养和保护地球上的泥土,因为所有的音乐和生命以及所有的一切都来自于泥土. 泥土是人类的源泉. '</p>
<p>现在她指着无边无际的夜空中低垂的一颗星星说:'你看,那颗星正在创造元素,这些元素有一天会成为生命的基本要素. 地球上的一切事物都产生于我们的元素,这些元素构成了地球上的一切,当她耗尽了自己无比强大的创造力时,她爆炸了,以此庆祝自己的成就,和宇宙共享她的财富并创造了人类. '</p>
<p>'她的命运就是你们的命运. 你们存在的目的,也就是要创造,要用你们自己的创造力作为回报. 你们的生命中充满磨难和欢乐,你们将不时面对死亡和困苦,但所有这一切都将由于你们置身于地球的伟大生命之中而变得有意义. 由于你们的创造力,宇宙的行程更加深刻. '</p>
<p>她凝视着远方,此刻万籁俱寂,她听到惊涛拍岸,发出阵阵轰鸣,看见它在夜色中时隐时现. 海水悄无声息地卷起,又猛然拍打到海岸上. 他们就这样倾听着. </p>
<p>'想想看,当我们是多么的疲惫,而我们要做的一切就是拖着我们弱小的身躯爬上山顶. 现在,让我们冥想:世界上所有的海滩都卷起激浪拍击着海岸,生生不息地运动着;地球永不停息地围绕着太阳运行;银河系中1000多亿颗星球不停地围绕着银河系的中心运动. </p>
<p>'但是星辰有运动时并未意识到这些,海洋也未意识到它那永不停息地海浪,它们被一种无法抗拒的力量驱使着,不停地运动. 地球发现,它无可抗拒地被太阳吸引着,对其它的生命方式完全不能忍受. 星辰和行星所做的一切真是不可思议,我们从未听见它们抱怨过什么. '</p>
<p>'我们人类和动物也是如此. 我们发现,我们无法摆脱某种生活道路. 如若我们遵守这些道路,我们的生活,即使充满了苦难和艰辛,也会有丰硕的果实. 一旦我们屈从于宇宙中的深深的诱惑,我们就会被抛弃. 就会被置于150-200亿年前宇宙蒙昧时代的边缘.人类最大的快乐便是置身于这种无所不在的诱惑中,并给他物---土地,草场和一切被遗忘了的东西---以力量,以使它们自己深陷于它们的诱惑之中. '</p>
<p>黄昏的最后一抹亮色已经消失了,她与他们在黑暗的寂寞中默坐着. 篝火渐渐熄灭,只有一些火星儿在闪烁,海洋反射出点点星光. </p>
<p>'你们会时时遇到困难使你们放弃你们的梦想,满足于玩世不恭和贪婪,你们会面对巨大的不安和恐惧. </p>
<p>'但无论发生了什么,请记住,我们的宇宙是一个充满惊奇的宇宙,我们的自信不是建立在自我身上而是建立在能够聚集起星辰和把生命细胞编织在一起的那就是说股力量之上. 请记住,你们在这个150-200亿年中编排的戏剧中已经觉醒. 启迪最初心智的智慧,分配着夜莺般音符的天赐,把1000亿颗星星抛洒向天际的力量,都像你一样觉醒了,并完全渗入了你的生命. </p>
<p>'我们并不知道,眼前等待着我们的是什么样的奥秘,但是它一定会使我们惊奇和着迷. 整个宇宙是从一个单一的超自然的微粒进化而来的,我们的起源是神秘的;我们的命运是紧密地连在一起的;我们全体物种的共同目标是颂扬那个塑造我们生命的伟大的欢愉. '</p>
<p>岩石,泥土,海洋,星辰用宇宙间上万种的语言诉说着它们的故事,它们深深植根于我们的情感,精神,思想和肉体之中. 地球和宇宙是万物中至高无上的,宇宙创造故事不过是宇宙宣布开始其行程纪元的一种方式. </p>
<p>"
</p>
</blockquote>
<p>(引自---新世纪学术译丛"后现代科学---科学魅力的再现"大卫·雷·格里芬)</p>
<h1 id="_14">参考书目<a class="headerlink" href="#_14" title="Permanent link">¶</a></h1>
<ul>
<li>"BEING DIGITAL" Negroponte<ul>
<li>海南出版社</li>
<li>ISBN 7-80617-643-81N·3</li>
</ul>
</li>
<li>"The World since 1500 A Globe histoty" Englewood Cliffs,N.J <ul>
<li>上海社会科学院出版社</li>
<li>ISBN 7-80515-657-3/K·92</li>
</ul>
</li>
<li>"中国人的大思路--辩证的人本主义" 马中<ul>
<li>陕西人民出版社</li>
<li>ISBN 7-224-02880-0/B·50</li>
</ul>
</li>
<li>"世界全史"<ul>
<li>第94卷:"世界当代哲学思想史"</li>
<li>第97卷:"世界当代科学技术史"</li>
<li>中国国际广播出版社</li>
</ul>
</li>
<li>"世纪之交--与高技术专家对话"<ul>
<li>辽宁教育出版社</li>
</ul>
</li>
<li>"科学观念丛书":中国社会科学出版社<ul>
<li>"人文主义视野中的技术" 高亮华 ISBN 7-5004-2015-7</li>
<li>"自然的沉沦与拯救" 李章印 ISBN 7-5004-2015-3</li>
</ul>
</li>
<li>"自然不可改良" 何塞·卢岑贝格<ul>
<li>三联出版社</li>
<li>ISBN 7-108-01300-2</li>
</ul>
</li>
<li>"后现代科学---科学魅力的再现" 大卫·雷·格里芬<ul>
<li>中央编译出版社</li>
</ul>
</li>
</ul>
<h1 id="_15">是也乎:<a class="headerlink" href="#_15" title="Permanent link">¶</a></h1>
<p>多年后的再曰:</p>
<ul>
<li>"科学是深沉的,它力求理解这个世界,这一态度充满了爱. 而技术则希望统治,最终走向野心勃勃!"</li>
<li><code>-></code> 科学是放肆的,力求突破一切常识来理解世界,这一态度是孩童般的纯粹;<ul>
<li>技术是集约的,解决问题是一切目的而不论问题何来,最终总是被利益集团控制,毕竟技术需要经济的投入...</li>
</ul>
</li>
</ul>