sgdk3435的博客

机器人将进入 4.0 时代，把云端大脑分布在从云到端的各个地方，充分利用边缘计算去提供更高性价比的服务，把要完成任务的记忆场景的知识和常识很好的组合起来，实现规模化部署。机器人除了具有感知能力实现智能协作，还具有理解和决策的能力，达到自主的服务。在某些不确定的情况下，它需要叫远程的人进行增强，或者做一些决策辅助，但是它在 90%，甚至 95%的情况可以自主完成任务。

自然语言处理是人工智能的一个重要应用领域 ，也是新一代计算机必须研究的课题。它 也是新一代计算机必须研究的课题。它 的主要目是克服人机对话中各种限制，使用户能自己语言与计算。本研究报 的主要目是克服人机对话中各种限制，使用户能自己语言与计算。本研究报 的主要目是克服人机对话中各种限制，使用户能自己语言与计算。本研究报 告对自然语言进行了简单梳理，包括以下内容 ： 自然语言处理概念。 自然语言处理研究情况 。 自然语言处理领域专家介绍。 自然语言处理的应用及趋势预测。

图计算是基于图数据的分析技术与关系技术应运而生的，图计算系统是针对处理图结构数据的系统，图计算也是人工智能中的一个使能技术。基于此背景，本研究报告对图计算这一课题进行了简单梳理，包括以下内容： 图计算的概念与图计算特征。对图计算的概念进行阐述，对代表性分布式图计算系统进行介绍，并列出图计算的特征。 图计算技术。从图计算面临的挑战出发，介绍图算法，图计算模型主要解决的问题，并图计算框架进行介绍。同时对技术资源和图计算的高引论文进行相关介绍。 图计算领域专家介绍。 图计算产业应用。从医疗行业、金融行业和互联网行业三个方面介绍领域图计算的技术构建应用与研究现状。 图计算趋势研究。对图计算的发展趋势特点进行分析。

3D打印，即增材制造技术于十九世纪末在美国起源它以计算机三维设模型为蓝本，通过软件分层离散和数控成型系统用叠加的方式制造实体产品。近年来由于市场成熟及与计算机图形学、机器人生命科材料等领域的结合， 3D打印呈现了越来越丰富的可能性与越来越广阔的空间。

区块链技术的主要优势是去中心化、基于共识机制的信息传输和共享、信息的不可篡改三个方面，确保各种场景下的信息安全。纵览目前区块链技术的发展和医疗领域的特征，主要可分为如下三个方面：健康医疗数据与资产管理、支付与理赔和供应链管理。 区块链作为一种使能技术，能够优化和解决目前医疗领域存在的诸如信息安全、数据孤岛、信任体系不健全和监管溯源复杂等难题。

为了建立更准确、高效的烟叶产地识别模型,提出了基于自适应遗传算法的修剪随机森林算法(AGARFP). 该算法根据种群的进化程度,适配不同的选择算子;然后利用改进的自适应遗传算法对随机森林进行修剪.实验选择５个产区的样本构建烟叶产地识别模型,以产地识别准确率作为算法优劣的衡量标准.实验结果表明,AGARFP分类准确率为９４．６７％,分类效果优于其他方法,从而证明了所提算法的有效性.

移动边缘计算介绍，驱动力，典型应用，服务迁移介绍，机遇与挑战

2018埃森哲前沿技术展望报告，公民AI，泛现实，真数据，大合作，智联网。

2018人工智能趋势报告英文版，CBInsights出品 1 New blue collar job — robot babysitters 2 AI for X is … everywhere 3 China vies with US for global AI leadership 4 The future of defense turns on AI 5 ¿Cómo estás, Alexa? 6 White-collar automation accelerates 7 AI moves to the edge 8 The emergence of ‘capsule networks’ 9 6-figure salaries in the AI talent wars 10 The machine learning hype will die 11 Amazon, Google, Microsoft dominate enterprise AI 12 AI diagnostics gets the node from regulaors 13 DIY AI is here

2018工业互联网参考架构，工业互联网在制造业中的应用，分布式工业互联网平台的实施。

Gerrit，一种免费、开放源代码的代码审查软件，使用网页界面。利用网页浏览器，同一个团队的软件程序员，可以相互审阅彼此修改后的程序代码，决定是否能够提交，退回或者继续修改。它使用Git作为底层版本控制系统。它分支自Rietveld，作者为Google公司的Shawn Pearce，原先是为了管理Android计划而产生。

1.自动驾驶行业宏观形势及发展现状 2.自动驾驶行业竞争与细分领域梳理 3.自动驾驶行业趋势展望

作者：Gojko Adzic 目　录 第一部分 　开始 第1章 　主要优点　2 1.1 　更有效地实施变更　4 1.2 　更高的产品质量　5 1.3 　减少返工　8 1.4 　更好的协作　10 1.5 　铭记　11 第2章 　关键过程模式　12 2.1 　从目标中获取范围　13 2.2 　协作制定需求说明　14 2.3 　举例说明　14 2.4 　提炼需求说明　15 2.5 　自动化验证时不修改需求说明　15 2.6 　频繁验证　17 2.7 　演化出一个文档系统　17 2.8 　实际的例子　18 2.8.1 　商业目标　18 2.8.2 　范围　18 2.8.3 　关键实例　18 2.8.4 　带实例的需求说明　19 2.8.5 　可执行的需求说明　20 2.8.6 　活文档　20 2.9 　铭记　20 第3章 　活文档　21 3.1 　为什么我们需要权威的文档　22 3.2 　测试可以是好文档　22 3.3 　根据可执行的需求说明创建文档　23 3.4 　以文档为中心的模型所具有的好处　25 3.5 　铭记　25 第4章 　开始改变　26 4.1 　如何开始改变过程　27 4.1.1 　把实施实例化需求说明当作更广阔的过程变更的一部分　27 4.1.2 　专注于提高质量　27 4.1.3 　从功能测试自动化开始　28 4.1.4 　引入一个可执行需求说明的工具　29 4.1.5 　使用测试驱动开发作为踏脚石　30 4.2 　如何开始改变团队文化　31 4.2.1 　避免使用“敏捷”术语　31 4.2.2 　确保你得到管理层的支持　32 4.2.3 　把实例化需求说明当作是比执行验收测试更好的方式来推销　33 4.2.4 　不要让测试自动化成为最终的目标　34 4.2.5 　不要太关注工具　34 4.2.6 　在迁移过程中，遗留脚本也要有人维护　35 4.2.7 　跟踪哪些人在运行（以及没有运行）测试自动检查程序　35 4.3 　团队如何在流程和迭代中集成协作　36 4.3.1 　Ultimate软件公司的Global Talent Management团队　37 4.3.2 　BNP Paribas银行的Sierra团队　38 4.3.3 　天空网络服务部门　39 4.4 　处理签收和可追溯性　40 4.4.1 　在版本控制系统中保存可执行需求说明　41 4.4.2 　通过导出的活文档来签收　41 4.4.3 　签收的是范围，而非需求说明　41 4.4.4 　在“精简的用例”上签收　42 4.4.5 　引入用例实现　42 4.5 　警告信号　43 4.5.1 　注意频繁改动的测试　43 4.5.2 　当心回退　44 4.5.3 　注意组织级的失调　44 4.5.4 　当心“以防万一”的代码　44 4.5.5 　注意霰弹式修改　45 4.6 　铭记　45 第二部分 　关键过程模式 第5章 　从目标中获取范围　48 5.1 　构建正确的范围　49 5.1.1 　理解“为什么”和“谁”　50 5.1.2 　理解价值从何而来　51 5.1.3 　了解商业用户预期的输出是什么　52 5.1.4 　让开发人员提供用户故事的“我想要”部分　53 5.2 　在没有高层次控制权的情况下，协作确定范围　53 5.2.1 　询问“为什么这些东西有用？”　54 5.2.2 　询问替代方案　54 5.2.3 　不要只顾最低层次的需求　55 5.2.4 　确保团队交付完整的功能　55 5.3 　更多信息　56 5.4 　铭记　56 第6章 　通过协作制定需求说明　58 6.1 　为什么需要协作制定需求说明　58 6.2 　最热门的协作模型　59 6.2.1 　尝试大型的全体工作坊　59 6.2.2 　尝试小型工作坊（“神勇三剑客”）　61 6.2.3 　结对编写　62 6.2.4 　让开发人员在迭代开始前频繁地审查测试　63 6.2.5 　尝试非正式交谈　64 6.3 　准备协作　65 6.3.1 　举办介绍会　65 6.3.2 　邀请项目干系人　66 6.3.3 　进行具体的准备工作并事先审查　67 6.3.4 　让团队成员尽早审查故事　68 6.3.5 　只准备初始的实例　69 6.3.6 　不要让过度的准备阻碍了讨论　69 6.4 　选择协作模型　70 6.5 　铭记　71 第7章 　举例说明　72 7.1 　举例说明：一个例子　74 7.2 　例子必须精确到位　75 7.2.1 　不要在例子中出现“是/否”的回答　75 7.2.2 　避免使用等价抽象类　75 7.3 　例子必须完整　76 7.3.1 　用数据作试验　76 7.3.2 　使用替代方法来检验功能　76 7.4 　例子必须要真实　77 7.4.1 　避免虚构自己的数据　77 7.4.2 　直接从客户那里获得基本的例子　78 7.5 　例子应该易于理解　79 7.5.1 　避免探讨所有可能的组合　80 7.5.2 　寻找隐含的概念　80 7.6 　描述非功能性需求　81 7.6.1 　取得精确的性能需求　82 7.6.2 　为UI使用低保真度的原型　82 7.6.3 　试用QUPER模型　83 7.6.4 　讨论时使用核查清单　84 7.6.5 　建立一个参照的例子　84 7.7 　铭记　85 第8章 　提炼需求说明　86 8.1 　一个好的需求说明的例子　87 8.1.1 　免费送货服务　87 8.1.2 　实例　87 8.2 　一个劣质需求说明的例子　88 8.3 　提炼需求说明时要关心什么　90 8.3.1 　实例要精确可测　90 8.3.2 　脚本不是需求说明　90 8.3.3 　不要使用流程式的描述　91 8.3.4 　需求说明应关注业务功能，而不是软件设计　92 8.3.5 　避免编写与代码紧密耦合的需求说明　92 8.3.6 　不要在需求说明中引入技术难点的临时解决方案　93 8.3.7 　不要陷入到用户界面的细节里　93 8.3.8 　需求说明应该是不言自明的　94 8.3.9 　使用叙述性标题并使用短篇幅阐释目标　94 8.3.10 　展示给别人看并保持沉默　94 8.3.11 　不要过度定义实例　95 8.3.12 　从简单的例子入手，然后逐步展开　96 8.3.13 　需求说明要专注　97 8.3.14 　在需求说明中使用“Given-When-Then”语言　97 8.3.15 　不要在需求说明中明确建立 所有依赖　98 8.3.16 　在自动化层中应用缺省值　99 8.3.17 　不要总是依赖缺省值　99 8.3.18 　需求说明应使用领域语言　100 8.4 　提炼实战　100 8.5 　铭记　102 第9章 　自动化验证而不修改需求说明　103 9.1 　非得自动化吗　104 9.2 　从自动化开始　105 9.2.1 　为了学习工具，先尝试一个简单的项目　105 9.2.2 　事先计划自动化　106 9.2.3 　不要拖延自动化工作或将其委派他人　107 9.2.4 　避免根据原有的手动测试脚本进行自动化　107 9.2.5 　通过用户界面测试赢得信任　108 9.3 　管理自动化层　109 9.3.1 　别把自动化代码当作二等公民　109 9.3.2 　在自动化层里描述验证过程　110 9.3.3 　不要在测试自动化层里复制业务逻辑　111 9.3.4 　沿着系统边界自动化　112 9.3.5 　不要通过用户界面检查业务逻辑　113 9.3.6 　在应用程序的表皮之下进行自动化　113 9.4 　对用户界面进行自动化　115 9.4.1 　以更高层次的抽象来详细说明用户界面的功能　115 9.4.2 　UI需求说明只检查UI功能　117 9.4.3 　避免录制的UI测试　117 9.4.4 　在数据库中建立环境　118 9.5 　管理测试数据　119 9.5.1 　避免使用预填充数据　119 9.5.2 　尝试使用预填充的引用数据　120 9.5.3 　从数据库获取原型　120 9.6 　铭记　121 第10章 　频繁验证　122 10.1 　提高稳定性　123 10.1.1 　找出最烦人的问题并将其解决掉，然后不停地重复　123 10.1.2 　用CI测试历史找到不稳定的测试　124 10.1.3 　搭建专用的持续验证环境　125 10.1.4 　使用全自动部署　125 10.1.5 　为外部系统创建较简单的测试替代品　125 10.1.6 　选择性地隔离外部系统　126 10.1.7 　尝试多级验证　127 10.1.8 　在事务中执行测试　127 10.1.9 　对引用数据做快速检查　128 10.1.10 　等待事件，而非等待固定时长　128 10.1.11 　将异步处理变成可选　129 10.1.12 　不要用可执行需求说明做端到端的验证　129 10.2 　获得更快的反馈　130 10.2.1 　引入业务时间　130 10.2.2 　将较长的测试分割成较小的模块　131 10.2.3 　避免使用内存数据库做测试　131 10.2.4 　把快速的和缓慢的测试分开　132 10.2.5 　保持夜间测试的稳定　132 10.2.6 　为当前迭代创建一个测试包　133 10.2.7 　并行运行测试　133 10.2.8 　禁用风险较低的测试　134 10.3 　管理失败的测试　135 10.3.1 　创建已知失败了的回归测试包　135 10.3.2 　自动检查那些被禁用的测试　136 10.4 　铭记　137 第11章 　演化出文档系统　138 11.1 　活文档必须易于理解　138 11.1.1 　不要创建冗长拖沓的需求说明　138 11.1.2 　不要使用许多小的需求说明来描述单个功能　139 11.1.3 　寻找更高层次的概念　139 11.1.4 　避免在测试中使用技术上的自动化概念　139 11.2 　活文档必须前后一致　140 11.2.1 　演化出一种语言　141 11.2.2 　将需求说明语言拟人化　142 11.2.3 　协作定义语言　143 11.2.4 　将构建模块文档化　143 11.3 　活文档必须组织得井井有条，便于访问　144 11.3.1 　按用户故事组织当前的工作　144 11.3.2 　按功能区域组织用户故事　145 11.3.3 　按用户界面的导航路径组织　146 11.3.4 　按业务流程来组织　146 11.3.5 　引用可执行需求说明时请使用标签而不要使用URL　147 11.4 　聆听活文档　147 11.5 　铭记　148 第三部分 　案例研究 第12章 　uSwitch　152 12.1 　开始改变流程　152 12.2 　优化流程　154 12.3 　当前的流程　156 12.4 　结果　157 12.5 　重要的经验教训　157 第13章 　RainStor　159 13.1 　改变流程　159 13.2 　当前流程　161 13.3 　重要的经验教训　162 第14章 　爱荷华州助学贷款公司　163 14.1 　改变流程　163 14.2 　优化流程　164 14.3 　活文档作为竞争优势　166 14.4 　重要的经验教训　167 第15章 　Sabre Airline Solutions　168 15.1 　改变流程　168 15.2 　改善协作　169 15.3 　结果　171 15.4 　重要的经验教训　171 第16章 　ePlan Services　172 16.1 　改变流程　172 16.2 　活文档　174 16.3 　当前的流程　175 16.4 　重要的经验教训　176 第17章 　Songkick　177 17.1 　改变流程　177 17.2 　当前的流程　179 17.3 　重要的经验教训　180 第18章 　思想总结　182 18.1 　协作制定需求能在项目干系人与交付团队之间建立信任　182 18.2 　协作需要事先准备　183 18.3 　协作的方式多种多样　183 18.4 　将最终目的视为业务流程文档，不失为一种有用的模型　184 18.5 　活文档带来的长期价值　184 附录A 　资源　186 [1]

《SeeMipsRun》中文第二版，超清非扫描，看过的都知道这本书的精髓。非常适合底层开发的嵌入式程序员作为工具书使用

利用C语言，链表，实现的一个简单的入栈出栈的小例子。