西蒙·温彻斯特(Simon Winchester)的“完美主义者”评论

从制造机械表到帮助航海者分辨出海上经度位置的机械钟,再到哈勃望远镜的镜头,当然还有当今的晶体管,一书都记载着制造精确物体的历史。 它包含许多有趣的故事和花絮。 例如: 今天,使用机床来制作精密物体令人印象深刻。 但是对我来说,更令人印象深刻的是手工制作-例如约翰·哈里森(John Harrison),他在1700年代中期至45年代中期制作了一系列时计,最终造就了一只手表大小的时计经过数月的长时间航行。 我已经模糊地知道了哈勃望远镜的镜头问题和解决方法,但是这本书讲述了整个故事。 参见这里的摘要,但长话短说:主光学镜(直径约2.4 m)变形约2200纳米,约为人发宽度的1/50。 它当然是在第一次定期维护任务中修复的,它挽救了数十亿美元的项目,并制作了我们今天喜欢的清晰空间图像。 记得高中化学的人会记得,有7个基本的SI单位,分别是质量(kg),长度(m),时间(s),温度(K),物质量(摩尔),电流(安培)和亮度(cd)。 截至2018年末,米和秒被定义为基本的恒定物理量(例如,秒是“与铯133原子基态的两个超精细能级之间的跃迁相对应的辐射的9,192,631,770个周期的持续时间” )。 当然,这些定义过去并没有那么基本-例如,电表最初是在1700年代后期定义的,它是北极和赤道之间沿某个纵向线的距离的函数。 公斤的字面含义仍然是指在巴黎某处坐着的特定文字的质量。 这种安排会导致奇怪的情况发生,例如当此标准随时间变化时。 由于潜在的明显原因,一个小组目前正在努力将千克(kg)重新定义为更基本的数量。 类似地,但也许不太严重,开尔文被定义为水的三相点的函数。…

增强业务能力:在Square实习生的感觉

抬起头,我们已经搬家了! 如果您想继续了解Square的最新技术内容,请访问我们的新家https://developer.squareup.com/blog Square致力于增强经济实力并简化贸易。 作为Square的一名工程实习生,我有机会对实际影响卖家生活的各种功能进行了构建。 该公司的规模很小,可以提供动手解决问题的能力和项目所有权,但对于支持强大的指导和讨论的公司,其规模足够大(以我为背景,他们都是出色的工程师)。 我有很多机会不仅可以提高自己的工程技能,而且可以影响产品决策,对其他项目发表意见,了解行业等等。 我在Square Apppointations的网络应用程序上工作,这是一个在线计划工具,可帮助卖家管理他们的约会。 想象一下一家拥有多个地点,拥有众多员工,营业时间各异且每天都有数百次约会的美发沙龙。 约会解决了卖家在管理这些物流时遇到的日常问题,从允许客户在线预订到提供功能丰富的日历应用程序,向卖家和客户发送提醒文本等等。 Square给予实习生很大的责任,并提供更强大的指导。 在Square,我首先被视为“工程师”, 然后被视为“实习生”。这意味着我的导师让我在整个暑假期间进行产品改进并拥有许多项目的所有权,就像其他人一样。我的团队。 从大公司的其他人那里,我听说了为期一周的入职培训。 我们的入职培训计划历时半天,之后我的导师帮助我扎实了基础:第一周我就可以对Square约会进行一些改进。 我开发的一项功能是双重预订警告,卖家现在可以查看是否尝试安排约会超出员工的工作时间或与个人义务相冲突。 建立这个看似简单的想法的最大好处是迭代开发附带的协作,建议和反馈循环:我与团队的设计师和产品经理紧密迭代以说明国际化,并在清晰度和性能之间进行了艰难的权衡。 从我的队友那里,我学会了看重简单,可维护的代码,而不是速度更快,更复杂的解决方案。…

我对DevOps Journeys 2.0的贡献

我认为与您共享电子书可能会有所帮助,因为对于那些对DevOps和现代软件/基础设施工程的未来感兴趣的人们,它具有宝贵的内容,分享我自己的贡献并获得您的反馈。 您可以在此处阅读完整的电子书。 这些是我的贡献: 关于DevOps DevOps是一种文化,它需要一种新的愿景,其共同目标是通过建立正确的沟通流程和跨职能协作,将人员和部门围绕独特的目标统一起来。 这些文化特征之一就是以客户为中心:以客户为中心是使团队朝着相同的重要目标结盟而又不会引起部门间战争的最佳方式。” 关于采用DevOps 正如Aymen El Amri所说的那样,DevOps始于流程:“采用DevOps需要由合适的人使用正确的工具来完成正确的流程”。 关于我的早期经历 Aymen El Amri谈论了他在DevOps项目上的早期经验,研究了“困难的问题,(奇妙但不成熟的)技术和一些误解”: “但是我并不孤单,一个不断发展的社区正在解决类似的问题,这些人奠定了基础,并使DevOps引入从初创公司到公司的所有类型的公司成为可能。” DevOps是一项社区运动,网络会议,聚会和论坛的迅速发展为寻找解决问题的方法提供了巨大的机会,越来越多的工程师可以将灵感带回他们的组织。 关于正确的工程DevOps转型 DevOps是一个令人兴奋的领域,面临许多挑战,例如零停机时间部署,自我修复和自动扩展性。…

为什么我们都应该成为工程师(或者更应该具有工程师的思维方式)

今天早些时候,我听了马克·扎克伯格(Mark Zuckerberg)在尼日利亚拉各斯的现场演讲,并回答了有关他如何从代码编写员转变为首席执行官的问题,他回答“我是工程师”,然后他继续定义了两个“原则”。 ”即工程师的思维定势: 将一切都视为可以改善或改进的“系统” 将问题分解成可解决的小问题 但是,无论您是编写代码的工程师,团队的经理还是运营跨国公司的首席执行官,这些原则都适用于所有人。 马克打趣说,他错过了编写代码的优雅之处,“尽管有些代码总是可以满足您的要求,而人们却不需要。”尽管他很快补充道,“人们也会感到惊讶”。 这些原则引起了我的共鸣,尤其是第一个原则。 可悲的是,众所周知,大多数人都缺乏这种工程思维方式,因为(我怀疑)我们作为人们并不真正喜欢(由变化引起的)变化(即摩擦)。 我们希望事物/系统是静态的,因为我们与之互动的事物/系统如此之多,我们需要记住与之互动的过程。 大多数人想做的最后一件事是学习每天,每周,每月,每年的新方法。 取决于它们与这些系统/事物交互的频率。 也许,这就是问题所在。 大多数人都不想每天学习一些新事物,即使它可以使他们的生活提高10倍。 因此,问题是,“工程师”可以采取什么措施来减少这种摩擦或学习曲线? 一种方法是建立用户完全信任的平台,该平台可以在流程和事物之间导航用户。 这样做的结果是,当平台进行更新或调整时,没有人引人注目,因为用户仍然可以到达其预期的目的地或结果。 但是,这些类型的平台需要花时间开发并获得用户信任(例如,Facebook,Uber等)。…