设计 – 虫虫之家

数字电路到可消化胶囊机器人，细数麻省理工改变世界的伟大发明

lin123 — Wed, 27 Feb 2019 02:00:00 +0000

大家都知道麻省理工MIT是世界数一数二的大学，更是计算机技术科学界的翘楚。去年麻省理工又投资十亿美刀建立苏世民（Stephen A. Schwarzman）计算机学院。在最近院庆活动中，麻省了推出了其CS科技成果展，罗列了一些了伟大的发明包括了数字电路到可可消化胶囊肠壁治疗机器人。本文虫虫和大家一起来看看麻省这些改变世界的伟大发明。

1937年

数字电路

1937年克劳德·香农（Claude Elwood Shannon）在麻省发表硕士论文《A Symbolic Analysis of Relay and Switching Circuits》（继电器与开关电路的符号分析）：真/假逻辑的原理可以用来代表电气开关的开关状态。该论文开创了数字电路领域的基础，是整个数字行业，计算机的基础。基于该开创新的发现及后续一系列的理论，克劳德·香农被称为信息论之父。

上世纪40年代

数字计算机

世界上第一台可以实时运行的数字计算机来自旋风计划（Project Whirlwind）。这是二战期间的一项军方研究，1944年由麻省理工学院与美国海军合作开发完成旋风机器人，用于通用飞行模拟。该计划成功导致了世界上第一胎可实时运行的数字计算机旋风计算机，也为后续1951年麻省理工学院林肯实验室的成立奠定了基础。

Memex数据系统

Vannevar Bush教授1945年发表论文《As We May Think》提出了一个名为“Memex”的“扩展存储器（Memory-Extender）” 数据系统。该系统设想可以用来“存储用户所有的书籍，记录和通信信息”并能随意检索它们。这个概念启发了早期的超文本系统，正是由于系统的产生和繁荣，启发了几十年后万维网的诞生。

上世纪50年代

函数式编程语言LISP

第一种函数式编程语言LISP是由John McCarthy教授于1958年在麻省理工发明的。在LISP之前，基于功能事的编程很难同时处理多个进程。函数式编程可让您更简单地描述所需的行为，从而可以处理比以往更大的问题。LISP诞生带动了大量的语言产生比如Clojure, Scala, Erlang, Haskell和 Elixir等，甚至在当今的编程语言中，增加函数式功能也还是个热点。

实时传真

1959年麻省理工学院的学生Sam Asano发明了一种通过电话线传输扫描材料的技术，可以让你的听到声音的同时也能看到画面。但是该发明并未引起重视，日本电信公司NTT收购，NTT认为可以用来代替发电报，因为写下了传输图形，敲打字符要来的快。

上世纪60年代

多人制视频游戏

麻省理工电气工程系气采购了PDP-1计算机首先被用来不是计算，而是被一群贪玩的学生用来打游戏了。1962年Marvin Minsky AI团队的学生Steven “Slug” Russell和游友们一起开发了一款空战视频游戏“SpaceWar!”，并在码农中广为流行，这是世界上第一款多人制游戏。

CTSS、Multics和密码

我们每天都要和密码打交道，密码是保障我们安全的最重要的屏障。而密码的发明也是来自于麻省理工。世界上第一个使用密码的系统是麻省理工学院的分时系统CTSS，弗尔南多考巴托（Fernando Jose Corbato）教授于1963年在开发CTSS时候发明了密码，当时系统为了实现一个多终端，多用户，又互相隔离，每个用户自有文件目录，通过密码来区别用户成了简便快捷的解决方案。需要提及的是CTSS系统和后续的Multics，为Ken Thompson和Dennis Ritchie开发UNIX操作系统奠定了基础。考巴托教授因为这些突出的贡献于1990年被授予了计算机图灵奖。

图形用户界面

麻省理工的Ivan Sutherland博士生已经有了直接与电脑屏幕连接的想法，在前面提到的Memex系统的启发下，他于1963年开发“Sketchpad”系统，允许用户使用触摸笔绘制几何形状，开创了“计算机辅助绘图”的先河！

阿波罗导航系统

1969年玛格丽特.汉密尔顿（Margaret Hamilton）率领麻省理工学院的团队编写了阿波罗11号导航系统，该系统辅助宇航员Neil Armstrong和 Buzz Aldrin成功登月。系统功能强大，还覆盖了将飞行器计算机执行指令，比如从优先系统到雷达系统的切换等，更值得称道的的该系统在载人登月的阿波罗登月计划任务中始终未出现任何bug。汉密尔顿作为码农中的巾帼好英雄在2016年被奥巴马总统亲自颁发了自由总统自由勋章。

上世纪70年代

电子邮件Email

1971年麻省理工校友Ray Tomlinson发送了第一封通过计算机网络传递的电子邮件。他在BBN Technologies工作时，创造了Email，也是第一个使用@的人。

个人电脑

麻省理工教授Butler Lampson教授创立了施乐公司施乐帕克（Xerox Palo Alto）研究中心研究中心（PARC）。由于突出性研究工作，使Lampson教授赢得了“现代PC之父”的称号。1973年PARC创造世界上第一台个人电脑奥拓（Alto）。在奥拓电脑上有了世界上第一个图形用户界面（GUI），第一个位图显示，以及第一个“所见即所得”（WYSIWYG）编辑器。

数据加密

1977年麻省理工团队在发明电子商务时候，发明了数据加密的RSA算法，RSA算法是一种非对称加密算法，它基于大质数的因数分解的困难度，来保证RSA的可靠性。

该算法在虫虫之前的文章中曾今介绍过，大家可以关注虫虫，从历史文章中查看详情介绍。

RSA算发的名字也是来自于麻省理工的三个发明人罗纳德·李维斯特（Ron Rivest）、阿迪·萨莫尔（Adi Shamir）和伦纳德·阿德曼（Leonard Adleman）的名字，取他们名字的第一个字母就是RSA。

电子表格

1979年，Bob Frankston和Dan Brickson在麻省理工的大型机上工作夜以继日的工作，并创造了世界上第一个电子表格系统VisiCalc。VisiCalc一出世就受到广泛好评，第一年就卖出了超10万份的拷贝。有意思的是，VisiCalc还是推动苹果AppleⅡ电脑的大卖，因为当时VisiCalc和AppleⅡ是捆绑销售的。

上世纪80年代

以太网

通过以太网技术可让我们通过简单的电缆插件就可以联网。以太网技术的发明源于麻省理工校友鲍勃.梅特卡夫Bob Metcalfe。他曾在1973年了一篇有关以太网潜力的备忘录，1979他和助手一起发表了论文《以太网：局域计算机网络的分布式包交换技术》为以太网的诞生奠定了理论基础。1980梅特卡夫创建了3com公司，3com公司联合DEC、英特尔和施乐一起起早指定了太网标准化规范标志着以太网的正式诞生。由于以太网的发展和促进，才有了后来互联网的飞速发展和流行。

光学鼠标

麻省理工本科生史蒂夫.基尔希（Steve Kirsch）于1980年第一个申请了光学计算机鼠标专利。他设想使用最少的精密移动部件制作一个“点设备”，为此，他创立了鼠标系统公司。他还发明了跟踪方法专利，通过点击计数来计算在线广告展示次数。

自由软件的兴起

黑客文化和自由软件运动的主要先驱麻省AI实验室的Richard Stallman教父于1983年发起了GNU（GNU代表“GNU’s Not Unix”）计划，项目旨在开发Unix操作系统的免费替代品，GUN项目开发GCC、GDB、Gxxx等以G开头的自由软件。也为GNU/Linux操作系统和其他重要的计算创新奠定了基础。

生成树算法

Radia Perlman 是码农界的又一女豪杰，具有 “互联网之母”之称。她于1985年开发了生成树算法是全球计算机网络数据传输路由的基础。该算法将以太网从原始有限可扩展的单线CSMA/CD转换为可处理大型网络的协议，并使以太网可极大地利用带宽。路由生成树算法对互联网数据传输产生了深远影响，提高了整改互联网的鲁棒性，从此，互联网具具有了自我管理和可扩展的特性。

值得提及的是她还创建了LOGO，这是第一种面向儿童的编程语言。

上世纪90年代

万维网联盟（W3C）

WWW之父Tim Berners-Lee在发明Web之后，于1994年加入麻省理工并成立了一个致力于建立全球标准的互联网联盟，为建站、浏览器和设备提供服务，这就是W3C的来历。W3C标准用于构建可访问，安全，并可以轻松被搜索引擎优化(SEO)的网站标准。

区块链的诞生

1999年麻省理工教授Barbara Liskov的发表了关于实用拜占庭容错算法（PBFT： Practical Byzantine Fault Tolerance）论文奠定了区块链的理论基础，并生成了第一个区块链，这是一种广泛使用的密码系统。利斯科夫教授团队的区块链系统可以处理高吞吐量的事务，还首创了很多当今区块链平台至关重要的概念。

近20年

Roomba扫地机器人

Colin Angle在读本科的时候加入了AI 实验室，在实验室时他萌生了让机器人能够和真实的环境进行实时反馈的想法，他开发了一款可移动机器人GenghiS。Genghis仿生了蚂蚁的灵感，他的导师是著名的机器人之父 Rodney Brooks教授。1990年， Colin Angle和导师 Rodney 教授同学 Helen Greiner 一起创办了机器人公司 iRobot。iRobot创建很多NB的机器人，比如火星车火星（漫游者Sojourner Rover），但是他的商业模式都不是很成功，直到2002年Roomba的推出，对，就是它，没有腿的机器人。截止目前Roomba扫地人已售出超2000万台，并催生了整个自动化清洁产品行业。

移动个人助理

大家都知道苹果的Siri和亚马逊的Alexa。但是，很早之前就有了这样的系统。2007年麻省理工的教授Boris Katz就开发了StartMobile，一款可进行约会安排，信获取息以及使用语音完成各类任务的APP。

EdX在线开放课堂

由前CSAIL主管Anant Agarwal领导，2012年麻省理工联合哈佛大学开办了大规模在线开放课堂平台EdX，通过该EdX提供免费的在线课程。截止目前EdX免费在线课程已经吸引了全球逾1800万学习者。

可消化胶囊机器人

麻省计算机科学与人工智能实验室（CSAIL）Daniela Rus于2016年等开发了可消化折叠胶囊机器人，可将其吞咽到肠胃，预热可从胶囊状自动展开，可以在体外磁场控制它攀爬你的胃壁，修复伤口，去除结石和误吞咽下去的异物等。

波士顿动力

Marc Raibert教授于1992年创建了波士顿动力公司。该公司制造了让人们大饱眼福的“大狗”，“Atlas”， “SpotMini”等机器人明星，可以攀爬，跑步，跳跃，甚至可以进行翻转。其中Atlas被用于DARPA机器人挑战赛，取得很棒的成绩。2013年波士顿动力公司被谷歌收购，2017年波士顿动力再次易主被日本软银收归旗下。

需求工程推荐方法

桔子 — Mon, 07 Jul 2014 08:57:44 +0000

AOP-面向方面的程序设计

桔子 — Thu, 11 Jul 2013 09:47:58 +0000

AOP-面向方面的程序设计

Aop：aspect oriented programming
oop: object oriented programming
AOP和OOP是两种不同的认识事物的角度,并不是说有了AOP就不要用OOP。Aop并不能取代oop，aop所要做的是以一种简洁和优雅的方式解决传统的oop问题。转述一段aspectj in action中的原文。

AOP will replace OOP: False. Core concerns will continue to be implemented in OOP (or even procedural programming). AOP simply adds a few additional concepts to OOP, just as OOP adds to procedural programming. However, AOP will change the way we use OOP and procedural languages for implementing crosscutting concerns. A few currently used design patterns and idioms that specifically address the problems of crosscutting concerns will lose their importance. Further, crosscutting concerns will receive a lot less attention during the initial design phase.

关于aspect的中文翻译，个人感觉实在很别扭，不管是面向方面，面向切面，都感觉无法表达其精髓，oop是以事物对象为从发点来考虑问题的，它认为对象应该有特点（属性）和动作（方法）。但完成一件事务，需要一堆对象共同合作。而aop正是从业务逻辑（事务）的角度来看待问题的，它是对事务的封装，其精髓在于一个事务只关心本身的逻辑，而无需关注旁支末节。

aop有很多优点，在aspectj in action中讲的很透彻，呵呵，其实这也是一本老书了，03年的。不过万变不离其宗。这里个人总结一下
1、各个模块职责清晰，每个模块只需关心自个儿的核心业务，无需考虑其他交叉的业务逻辑，比如日志记录、业务授权检查、用户权限检查。这是一个非常了不起的功能啊，想像一下，无任是面向过程，面向对象，我们以往在实现核心业务逻辑时，不是都要写上一大堆相关的检查和记录吗（哪怕是调用已经封装好的方法）。当系统规模小时倒没什么感觉，一旦系统规模大起来了，这将是一个非常繁重的工作，而且业务逻辑也不清晰了。
2、高度的模块化，Aop提供了一种机制使得模块间的耦合度达到了最低的限度（AspectJ in action中这么说的），即使是表现交叉逻辑时，因为模块时分离的，它也避免的代码的混乱。这将使的系统变的简单和易于维护。
3、系统更易扩展，增加一个新的业务逻辑将变的更加容易。
可以在系统underdesign＆overdesign之间取得平衡，部分设计可以放到末期，而无需大到手脚；也可以放在前期，到后期将其移走，而不用破坏主程序。何其块哉！
4、剩下的3个优点：more code reuse,improve time to market,reduced cost of featur implementation ，文中说了很多，不过是老生话题，不转述了。

但任何好的东东必然有其不足的一面，aop也例外。
1、程序中的流程将变的难以跟踪，噢，这是一个非常令人头痛的事情，写核心业务的人有时候甚至不知道自己的程序里被加入了什么怪物，呵呵，不过个人认为这是个见怪不怪的事情，熟练了自然就行了。我们也不是第一次碰到这种情况了，从面向过程转到面向对象，多态的支持等等，不都有同样的故事嘛。随着IDE的支持，这将也不是问题。
2、AOP不能解决任何新的的问题，它只是把oop情况下的代码美容师而已。In fact, AOP requires a good design of core concerns and makes it easy to achieve an overall clean design goal.
3、aop是个好东西，但你必须有一个好的oop。个人认为，一个好的oop是一个好的aop的基础，一堆混乱的对象＆接口&实现，只会使代码变的更糟，而不是更优雅。
4、aop打破了封装，在面向对象的编程中，一个对象封装了其相应的方法＆属性，但aop的介入，打破的对象在控制流层面（包括系统层面）的封装。个人认为，这就是aop流程难以跟踪的本质原因。

从一则笑话分析需求的陷阱/zz/

桔子 — Thu, 11 Jul 2013 08:51:20 +0000

某日，老师在课堂上想考考学生们的智商，就问一个男孩:“树上有十只鸟，开枪打死一只，还剩几只？”
男孩反问:“是无声枪么？”
“不是。”
“枪声有多大？”
“80~100分贝。”
“那就是说会震的耳朵疼？”
“是。”
“在这个城市里打鸟犯不犯法？”
‘不犯。”
“您确定那只鸟真的被打死啦？”
“确定。”老师已经不耐烦了，”拜托，你告诉我还剩几只就行了，OK？”
“OK。鸟里有没有聋子？”
“没有。”
“有没有关在笼子里的？”
“没有。”
“边上还有没有其他的树，树上还有没有其他鸟？”
“没有。”
“方圆十里呢？”
“就这么一棵树!”
“有没有残疾或饿的飞不动的鸟？”
“没有，都身体倍棒。”
“算不算怀孕肚子里的小鸟？”
“都是公的。”
“都不可能怀孕？”
“………，决不可能。”
“打鸟的人眼里有没有花？保证是十只？”
“没有花，就十只。”
老师脑门上的汗已经流下来了，下课铃响起，但男孩仍继续问:“有没有傻的不怕死103f的？”
“都怕死。”
“有没有因为情侣被打中，自己留下来的？”
“笨蛋，之前不是说都是公的嘛!”
“同志可不可以啊!”
“…………，性取向都很正常!”
“会不会一枪打死两只？”
“不会。”
“一枪打死三只呢？”
“不会。”
“四只呢？”
“更不会!”
“五只呢？”
“绝对不会!!!”
“那六只总有可能吧？”
“除非你他妈的是猪生的才有可能!”
“…好吧，那么所有的鸟都可以自由活动么？”
“完全可以。”
“它们受到惊吓起飞时会不会惊慌失措而互相撞上？”
“不会，每只鸟都装有卫星导航系统，而且可以自动飞行。”
“恩，如果您的回答没有骗人，”学生满怀信心的回答，“打死的鸟要是挂在树上没掉下来，那么就剩一只，如果掉下来，就一只不剩。”
老师当即倒!

正值六一儿童节之际，用这篇笑话故事来做开头，笑过之后可能不少能会认为这个小朋友是需求调研的最佳人选。回顾软件开发上的许多案例，软件开发失败率一直居高不下，特别在外包开发这个领域中，这个值可能会更高一筹。在分析项目失败的原因的时候，需求的因素可能是失败的关键原因、需求不明确，客户对需求的变更频频等等。

1．需求的调研

需求调研是为需要说明书做前期工作，可以说需要说明书是从需求调研表中得到或抽取而出。需求调研是要了解客户希望所要开发的系统能够解决他们的问题，以及了解他们对系统的期望等等。需求调研是整个开发的基础，经过需求调研的结果整理出需求说明书作为后续开发使用。

如果做的项目是一个陌生的一个行业（专业），这是往往需要专家或者顾问等角色的协助，但是作为调研人员最少要想办法了解个专业，或许你需要成为这个行业的专家，但最少要了解一定的专业知识（最少专业词汇你要知道）。这样客户的沟通才能达到顺畅，不会出现牛头不对马嘴的现象。

在某些难度不是很大的行业或者项目，做需求调研的时候可以通过自学的方式了解行业的特点，这些项目往往因为规模比较小，也不会有专家的影子出现。但是作为调研的时候我们最需要了解的一些问题如：

1）：客户目前的问题与苦难
2）：客户现在的工作模式
3）：客户对系统的期望
4）：客户哪些要求是自己能做到的，那些是依靠系统来做
5）：还有客户对系统开发方式以及时间的要求等等

其实做需求调研的时候最重要的目的在于资料收集，或许小孩的那种打破砂锅的方式会引起客户的反感，但是实际项目中往往需要的就是这些比较周全的调研方式，能够考虑到的问题点都需要和客户确认，尽量避免想当然的做法，只是采用的方式可能需要优化一下，采用良好的方式，尽量得到客户的最大配合。

2．需求的描述和确认

对于需求的调研内容需要进行整理和分类，分清有用功能、可选用功能、无用功能及不可实现功能。对于这些功能和客户再次确认之后才能最终形成开发的需求文档。对于需求的描述有很多的方法和工具，但是无论采用那种方法和工具都是相对抽象的方式，如何让客户能够理解需求的实际内容，需要客户有良好的理解能力，毕竟系统还只是纸面上的内容，客户还是很难完全了解到真实的系统。

如何对需求进行103f描述在项目开发中是一个很难定夺的题目，有些公司采用Demo的方式，有些采用传统的功能树的方式，有些采用界面的描述方式，有些采用UML建模的方式，形式多种多样。各种方式都有其好坏。但是对于方式的选择需要注意一些问题：

1）了解客户是否能够理解所描述的问题，
2）避免先入为主，
3）避免形式主义，

有些公司采用UML描述需求，但是客户的能力达不到能够理解UML所描述的问题，甚至公司内部的开发人员也无法很好的理解UML，可能只有需求人员懂 UML，这种需求结果就值得思考，客户是否知道你在说什么？如果你先入为主使用这种方式来描述问题，难道也期望客户去学习这些知识吗？

3．需求的控制

客户往往很难知道他们需要什么样的系统，有时候系统做到一半的时候客户会提出一些新的想法，更甚至等系统上线的时候客户才发现系统和他们脑子里想的东西完全不是一回事。对于这些可能会说当初需求定义的时候不是签字下来说是做成这样，怎么不是你想要的呢？问题可能会归根于与客户沟通的方式和手法上，但是对于需求的控制来说，对如何避免需求的反复，客户脑门一热就有新点子出来，还有许多不切实的要求等等，都在需求的控制范围内。

有些人会说我们和客户说好了，协议也签订说：除了纸上描述的东西之外，其余的都是变更追加。但是这个观点固然好，也是完全归于一方有利来考虑，而且有很多时候我们签署在合同内的需求文档也比较含糊，而且双方在问题的理解上可能会有歧义，一旦真正要将合同拿出来对峙的时候，我想彼此都很难说服对方。就像树上有十只鸟一样，没有说好环境，状态等等的假设，一切的结果应该说都可能是合理的。

如何控制需求，我想除了软件工程上提出的那些理论之外，也很难有新的观点，但是在实际的操作过程中，我们可能一方面要维护和客户的关系，另一方面也要考虑系统的开发时间和整体工数等等，做一个权衡。不过我个人更趋向使用问题具体化的方式来控制，尽量将能够想出的问题通通罗列出来和客户确认，同时采用换位思考的方式，尽量能够让客户理解我们所描述的系统的状况，如果在调研和需求的确认阶段能够把工作做得很好，在后期的开发过程中变更的内容就会比较少，变更的内容也就容易控制。

和客户进行良好的沟通，多为客户做一个考虑，避免将自己以一个高调姿态介入和客户的沟通中，说一些客户很难懂的专业术语，将客户喷的云里雾里，自以为自己的专业领域多么了不起，这种和客户的共通方式最容易造成需求空洞，后期翻盘的概率很高。如果客户不懂你口中所说的内容，可能问题出于客户，另外更大的程度出于你，我们需要考虑采用的沟通的方式以及内容是不适通俗易懂，能将复杂的问题讲的简单就表示你不简单。

需求分析–一些好的参考资料

桔子 — Thu, 11 Jul 2013 08:47:40 +0000

几本好书

《软件需求管理》   机械工业出版社
《有效需求实践》机械工业出版社
《编写有效用例》   机械工业出版社
《软件需求》    机械工业出版社
《掌握需求过程》    人民邮电出版社

几个好的网站系统分析之窗 IT之源 UML中国中国软件工程网

登山的故事(什么是XP,设计)

桔子 — Thu, 11 Jul 2013 06:30:09 +0000

关键字：XP

从前，有一个A型血的人和一个B型血的人去登山。显然A和B有着不同的登山方法。

A到了山脚下，总是先停下来，仔细打量山势。接着，围着山脚转转，看看哪些是小山包，哪个是主峰。然后，设计几条不同的

登山线路，并选择出最好的登山线路作为首选计划。同时，他还考虑到如果首选计划出现问题，则可以启用第二计划或第三计划…

而此时的B几经爬上了第一个小山包。B登上小山包的时候，发现这个小山包不是去主峰的路。B并没有气馁，稍微打量一下环境，立即从小山包上下来，往更高的一个山峰进发…就这样，B无时无刻不在后退中前进，在下坡中上山，已经将A远远的甩在后面。

最后，B成功地登上主峰，而A还在半山腰艰难地攀登。当A终于登上主峰之后，B说了一句很有很有意思的话：你现在知道极限编程的威力了吧！A默然不语…

一位想学登山的新手来向A和B请教登山的方法。A把他的线路图和计划全部给了新手，没有说一句话。新手看都没看，就跑去问B。B意味深长地说：努力，努力，再努力，当你到达山顶的时候，就知道了登山的方法！新手由衷敬佩。

多年以后，A成功地登上了珠穆朗玛峰。据说B倒下的地方离一号营地只有一百米远…

当那位新手终于找到A求教的时候，A还是将所有的登山线路和计划交给了他，依然没有说一句话。

但新手明白：这就是设计