哪里有遗嘱

只要有意愿……

格蕾丝·霍珀和玛格丽特·汉密尔顿最近被提名为21位获奖者自由总统奖章为了纪念他们对计算机技术进步的贡献。他们的名字在软件专业人员之间是众所周知的，即使不像公众普遍熟悉。

料斗被小工具着迷，当她在海军中遇到的印记时，她被迷上了。她只成为第三个人试图编制机器，最终被授予了她的工作的海军军械发展奖。

后来她开发了第一个编译器。它被称为a -0，或算术语言版本0，由一组可以接受立即参数的预构建子例程组成。它的功能是加载器或链接器，没有文本解析功能;但这远远超过了以前的做法。

她对使计算机能够被人类使用的兴趣促使她推动了编译器技术的一系列改进，从a -0、a -1、a -2(算术- matic)到AT-3(数学- matic)、B-0 (FLOW-MATIC)到COBOL(公共业务导向语言)。亚博vip9通道在20世纪末的鼎盛时期，COBOL被认为代表了全世界97%的生产商业软件。亚博vip9通道不糟糕的遗产。

料斗是一个高能量的人，令人缘关重要。她最喜欢的捕捞短语之一是，“最好要求宽恕而不是许可。”她决心弄清楚做完成的方法。

多年后，玛格丽特·汉密尔顿将展示相同的个人特征，并将在软件领域推动进一步的进步。与许多称为“头部”或“铅”或甚至的许多受欢迎的帐户相反唯一作者在Apollo航班上使用的软件，汉密尔顿加入了NASA团队作为初级程序员。

她从事这份工作的背景是数学而不是工程学，她并不比团队中的其他人更清楚“程序员”是如何谋生的。那时候，还没有这样的职位描述。正如汉密尔顿在几年后的一次采访中所说，“因为软件是一个谜，一个黑盒子，高层管理给了我们完全的自由和信任。我们必须找到一种方法，我们做到了。”

每个人都认为这是一个零缺陷的系统。如果一个错误发生在距离地球25万英里的地方，宇航员就会死亡。因此，Hamilton询问团队如何确保软件没有缺陷。答案:Augekugel。

她按下了这个问题并学会了这意味着“盯着”。有一个人通过在视觉上检查源代码来发现潜在的集成错误。汉密尔顿认为这有点危险。她坐在他身边，学会了他的方法。最终她看到它是一种模式识别过程，她认为它可以以编程方式进行。她发明了更高阶软件;在其他软件上运行的软件而不是域问题。今天我们称之为静态代码分析。

在阿波罗11号登月任务的下降阶段，汉密尔顿的另一项创新发挥了作用。尽管尼尔·阿姆斯特朗和巴兹·奥尔德林都是一流的试飞员，并完成了大量的训练，但他们所做的事情却从未有人做过，而且这也不是例行公事。有关于发生了什么事情的详细报告，但简而言之，宇航员基本上打开了所有的程序，加载了每个程序，以防万一。

转向一切都是一个错误，因为指导计算机和聚合雷达之间的RF干扰存在着名的问题，即使在下降阶段不需要它，Aldrin也会接通。加载Ascent程序是一个错误，因为指导计算机中的有限内存不允许一次加载的所有程序，并且在下降阶段中不需要该程序。

在零星的硬件故障和小数字控制台可怕的1201和1202信息之间，宇航员决定手动着陆。这些错误代码与汉密尔顿的另一个创新有关——系统可以转储它不需要的程序，以便为它的程序释放稀缺的内存资源亚傅体育app做过所需要的。当宇航员加载过多的程序时，系统会根据他们所处的任务阶段，尽职地丢弃不必要的程序。尽管错误代码看起来很吓人，但这台电脑和软件都没有问题。

到那时，汉密尔顿对球队的价值已经一次又一次得到了证明。但一开始，她是队里的初级队员。他们把最不重要的程序交给了年轻的团队成员。他们称之为“忘记它”项目。它将在发生灾难性故障时执行。他们认为不会发生灾难性的故障。快进到阿波罗13号，汉密尔顿在恢复工作的最前线。

在阿波罗之后，汉密尔顿和实际的人是团队领先，丹舔，形成了一家他们称为高阶软件的公司。他们似乎领先于他们的时间。公司对静态代码分析不感兴趣......或者数学家/程序员和工程师/教授只是擅长销售。今天，在没有静态代码分析的情况下运行专业软件交付组织几乎是不可想象的。不糟糕的遗产。

......有办法

当我读到总统霍尔和汉密尔顿被总统尊重的时候，这让我想到了我们今天经常在大公司遇到的态度。人们只是自动化某些东西的一步或两步，他们停止缩短。他们继续手动重复相同的任务，每年几十或数百次。

开发团队可能有一个备受普通的和清晰明确的程序来运行测试，集成代码并部署。但他们永远不会将他们的文档转换为可执行脚本。它会拯救他们这么多努力和时间！

人们很擅长找借口不要做的事情。在一家公司，团队在设置持续集成服务器上犹豫不决，因为他们的架构团队仍在考虑产品的选择。我还是不明白为什么团队不能同时建立他们自己的CI服务器。这将使他们的生活更轻松，他们将解决通用CI过程中的任何问题，使过渡到“官方”产品更加顺利。哦,好吧。

基础架构团队可能有一个良好的审美和明确记录的程序，可以提供各种虚拟服务器。但他们永远不会将他们的文档转换为可执行脚本。它会拯救他们这么多努力和时间！

在一家公司，基础设施团队维护了几百台服务器，主要是VM，大多数标准的累积。其中一个人告诉我他们没有脚本任何建造因为一些其中的系统是一次性配置，支持对各种过时事物具有内置依赖性的遗留应用程序。好吧，这是可以理解的，但是80-90%的标准配置呢?为什么不继续编写脚本呢那些？一个独立的工程师至少可以编写他/她的脚本自己的重复的配置任务，即使没有告诉任何人。这样不是更容易工作吗?哦,好吧。

也许我是那个错了的人。也许我懒得一遍又一遍地重复同样的手动任务。也许我应该更勤奋。我将在这一天工作。承诺。可能是。

如果我是不错误，那么我不确定是什么缺失，除非它是愿意要求的宽恕而不是许可或者确定找到一个方法。随着最近的总统奖项建议，有这种事情的榜样。