https://www.ifixedbug.com/Recent content on iFixedBug.comHugo -- gohugo.iozh-CNWed, 05 Jun 2024 23:41:20 +0000https://www.ifixedbug.com/posts/%E5%A4%A7%E6%A8%A1%E5%9E%8B%E8%83%BD%E5%8A%9B%E4%B8%8E%E5%BA%94%E7%94%A8%E5%9C%BA%E6%99%AF%E6%80%9D%E8%80%83/Wed, 05 Jun 2024 23:41:20 +0000https://www.ifixedbug.com/posts/%E5%A4%A7%E6%A8%A1%E5%9E%8B%E8%83%BD%E5%8A%9B%E4%B8%8E%E5%BA%94%E7%94%A8%E5%9C%BA%E6%99%AF%E6%80%9D%E8%80%83/前言 # 上周去杭州开人工智能研讨会之前，写了一篇文章《大模型是连接主义的胜利吗？》。这篇文章实验了大模型对复杂规则的推理能力，总结了两个观点： 不能过于迷信大模型的能力，它并不是万能的。大模型基于相关性，不是因果性。它需要传统的机理模型、符号推理等弥补自身缺陷。比如大模型并不能回答你现在是几点，所以它也不能聪明到推导出炼钢作业计划。 大模型的回答普遍不精确、不幂等、不实时、不可解释，其结果不能直接用在工业现场反馈到现实世界，在工业领域应用有限。 上面是我的观点并非得到实证，所以很期望这个研讨会能给出答案。 培训概述 # 参加了三天的培训课，各位专家从AI的发展历程、原理、应用场景、甚至哲学层面去理解和探讨人工智能对当前世界的影响。培训内容不限于大模型，还包括了很多传统模型的介绍和应用。但显然参会者都对大模型抱有更大的热情，提问也很积极，在晚上的讨论会上大家也分享了很多自己企业的应用情况。比如一汽用视频方式演示了大模型在企业内的应用，着重介绍了如何赋能研发过程，在编码、项目管理、设计等层面大模型都发挥了很大价值。 但总体参与下来，感觉各大企业或多或少地在做三件事： 造锤子 拿锤子找钉子 拿锤子一直在砸那几颗钉子 这里的造锤子是指打造大模型，比如中国移动的九天、中国电信的星辰，也打造了一些周边的应用生态。钉子是指应用场景，尽管有中国电科的专家分享了将近30多个应用场景，但大多跟大模型没有关联，还是传统模型的应用。一直在砸的那几颗钉子是指与语义或文本理解相关的应用，如：智能客服、咨询等。这些应用场景在很多企业作用有限。 目前各大企业在做的事情限于以上场景，覆盖大模型的L0到L2级别。 对于L0，如阿里等可以提供基础算力，这些是有硬件资源的大型互联网公司的主战场，本身是算力、分布式网络以及基础服务能力的资源整合。该商业价值明确，以按小时的方式提供算力租用为上层应用服务。 对于L1，则如智谱等发布大模型，同时也有阿里提供支持预训练、微调等服务，将大模型的训练过程标准化、流程化，最大限度降低训练门槛。该商业价值也很明确，为行业大模型提供训练的方法，“授之以鱼”或者“授之以渔”，都可以交付商业价值。 对于L3，则开发某领域的专业Agent，为用户提供应用价值，如：智能客服、政务咨询、数字人等。L3目前充分利用大模型的语义理解力，在文本、语音和视频等多模态方面发挥商业价值。 反思与观点 # 大模型正深刻影响人与机器的交互方式 # 大模型最大的能力在于语义理解力，它是通过单词之间的相关性统计获得的涌现能力。这个能力在翻译、文本理解、任务指令方面能发挥极大作用。我们同机器的交互方式发生重大变化。人类科技的进步，某种程度上可归结到与机器交互方式的变革上，从物理的按钮、手写笔、手、动作到语音、文字、眼球甚至到脑波（人机接口），逐渐有了意识控制物质的意味。 回到软件应用上，大模型促进了使用问答聊天的方式来与系统进行交互。在用户体验上发生本质变化，体现出了便利性和优化性。我们应充分利用大模型的语义化交互能力，融合到我们的软件产品中。未来随着大模型技术的不断发展，我们有理由相信，人与机器之间的交互方式将会变得更加智能化、自然化，为人类的生活带来更多的便利和可能。 不能过于迷信大模型的能力 # **大模型的出现并没有解决掉以前未解决的难题，它的作用属于锦上添花。**我们面临的问题是钢铁行业的计划调度问题，运筹学工程化难题，大模型对此也无能为力。同时，大模型需要依赖传统的符号推理，无法取代以前解决问题的方法。 比如：在炼钢的计划调度问题上，大模型虽然能够处理大量数据并提供一定的优化建议，但它依然无法解决复杂的运筹学问题。这些问题通常需要精确的数学建模和符号推理，而这些是大模型目前难以胜任的领域。运筹学的工程化难题涉及到具体的资源配置、生产计划和物流优化等，这些需要高度专业化的算法和方法，大模型在这方面只能提供辅助支持，而不能从根本上解决问题。 研讨会分发了一些阿里的通义千问大模型的使用案例。其中一个案例是工业机器人如何利用大模型完成码垛任务。码垛需要规划路径。这里的方法是让大模型根据场景生成代码，然后调试代码后运行得出结果，再指导机器人完成码垛。该应用场景巧妙地利用了大模型的代码生成能力，但生成的代码充满了不确定性，能否顺利得出结果还是未知数，方案的可行性非常存疑。 故大模型在某些方面具有显著的优势，但它并不是万能的工具。我们需要理性看待它的能力，充分结合传统的运筹学和符号推理方法，才能在复杂的工业领域中取得实质性的进展。大模型可以作为一种辅助工具，为我们提供新的思路和方法，但在面对具体的工程化难题时，传统方法的作用依然不可替代。 大模型的商业价值仍然模糊 # 尽管大模型在许多领域展现出了强大的潜力和应用前景，但其实际商业价值尚未完全显现。目前来看各大企业都在布局大模型基座或应用，赋能研发过程和客服等领域，但ROI到底如何并没有得到验证。 大模型的黑箱特性也限制了其商业应用。在研讨会的提问中也有多人问起关于大模型的准确性问题。企业在实际应用中，需要对决策过程有清晰的理解和掌控。如果不够精确，特别是在工业领域是不能接受的。 大模型的性能也高度依赖于数据的质量和数量。与其说是大模型的价值，不如说是数据的价值。对钢铁行业来说，最宝贵也依然是数据本身。数据不足或数据质量不高，都会直接影响大模型的表现。我们需要投入大量资源来确保数据的可靠性。 另外甚至垂直大模型的必要性也有争议，研讨会有2位专家对此提出了质疑。即便是垂直大模型成立，那么训练的过程也应该是能借助成熟的训练平台低成本地执行，并不需要从头再来。另外垂直大模型如何赋能钢铁行业和盈利，也是不确定的，还有很长的路要走。 我个人认为未来大模型的价值在于垂直行业的agent，在于使用agent自主决策的应用，在于agent下的tools能解决什么问题。产品的价值依然还是以前的价值，只是交互方式发生了变化。 大模型作为基础设施还在不稳定期 # 大模型作为基础设施目前还处于不稳定期，每天都有大量的大模型发布，新的方法和理论层出不穷。在这个阶段，对于钢铁行业来说，对基础设施的投入可能会面临得不偿失的情况。毕竟大模型的发展和稳定需要时间，并且需要大量的资金和资源进行支持和完善。 大模型基建应该由大厂完成。一切方法论稳定的基础设施和平台服务都会被市场化，这些也不应该是垂直行业涉足的领域。 因此，当前钢铁等垂直行业的重点和核心竞争力依然是在应用上。通过将大模型技术与钢铁行业的实际业务相结合，开发出符合行业需求的应用程序和工具，可以更好地提升生产效率、优化资源配置、改善产品质量。这些应用将直接面向垂直市场，为企业带来实际的价值和回报。 我们应该做什么 # 准备好数据 # 我们应充分结合自身的行业特征以及中立地位，将工艺数据、材料、冶金流程、装备等数据收集好、处理好、标注好。无论大模型如何发展，大模型的应用方法如何变化，唯有数据才是最根本的。这些高质量的数据能够更好地支持大模型的训练和应用，从而实现更精确的预测和决策，在行业占得先机。即便是没有垂直大模型，这些数据也可以轻松利用现有的RAG机制实现一个行业知识库。 夯实业务基础 # 深刻理解与抽象我们目前的业务，融合冶金流程的思想，将现有的软件功能进行解析与重构，使它们能够产品化、模块化、流程化，更好地适配不同的需求和场景。这样当大模型生态足够丰富时，我们可以轻而易举地将各种模块以tools的方式融入到大模型中，建立大模型在冶金方面的应用工具，完善整个应用生态，实现更加智能化的冶金生产和管理。毕竟我们对大模型的功能业务是最熟悉的，也是我们的竞争优势和根本能力。 研究大模型的开发模式 # 随着大模型技术的不断进步和应用范围的扩大，开发者需要不断学习和探索新的开发方法和技术，以应对未来的挑战和机遇。了解大模型的开发生态，可以帮助开发者更好地理解其内部机制和工作原理，从而更高效地利用大模型开发和优化我们的产品，提高我们的工程化能力。比如了解ReAct的plan能力，如何将现有功能实现tools化，如何使用dify等等。 我们开发者应该保持对新技术和趋势的敏感性。随着技术的不断演进，新的开发模式和工具不断涌现，开发者需要及时了解并适应这些变化，以保持自身的竞争力和创新能力。只有不断学习和进步，才能在激烈的市场竞争中立于不败之地，为我们的产品开发做出更大的贡献。 结合业务开发agent进行尝试 # 目前大模型生态足够丰富，有很多免费api可供使用。我们可以结合当前的应用场景如：炼钢作业优化调度、仿真评价等，将一些业务模块化和工具化。使用类似于 dify 等 无代码开源项目帮助我们更快地验证想法和能力。充分利用开源社区的项目，我们可以更加高效地开发出符合实际需求的 agent，并在实际应用中进行验证和调整。 这样在不断地尝试和实践中，我们可以积累丰富的开发经验，保持技术敏感，为钢铁行业的智能化转型提供更多的支持和帮助。同时，我们也可以借鉴其他行业的经验和做法，加速产品交互方式的创新和产品价值的提升，更好地应对未来大模型对钢铁行业带来的冲击，保持一定的竞争力和领先地位。https://www.ifixedbug.com/posts/llms%E6%98%AF%E8%BF%9E%E6%8E%A5%E4%B8%BB%E4%B9%89%E7%9A%84%E8%83%9C%E5%88%A9%E5%90%97/Mon, 27 May 2024 17:00:20 +0000https://www.ifixedbug.com/posts/llms%E6%98%AF%E8%BF%9E%E6%8E%A5%E4%B8%BB%E4%B9%89%E7%9A%84%E8%83%9C%E5%88%A9%E5%90%97/—老北京马蜂怎么蜇人？ —怎么蜇？ —您猜怎么着？ 怎么蜇不重要，但大模型是连接主义的胜利吗？ 前言 # 前几天在看郭朝晖老师的一本书《知行：工业基因的数字化演进》。郭老师是宝钢老专家，书里提到的很多观点感同身受。在“从自动化到智能化”章节中，提到人工智能的三个学派：符号主义（计算机学派）、连接主义（生理学派）和行为主义（控制论学派）。他提到通俗意义上的智能是指在一个巨大的搜索空间内，迅速找到较优解的能力。钢铁企业里有多个工序，在排计划时都期望在不同约束下获得最佳目标，如工时、产品质量、收得率、交货期等，是个非线性的规划问题，经典的计算机学派无法通过符号学在有限时间内快速的推导出答案。 连接主义的算法往往带有某种玄学，“只可意会，不可言传”，就像人类的感觉一样。这种“默会知识”不像显性知识那样精确描述，无法通过代码推导实现。为了让计算机具备感知默会知识的能力，连接主义创造了各种算法，当然也包括大模型。 以上是郭老师的观点，我深以为然。 基本概念 # 人工智能（AI）的三大流派通常指的是以下三种主要的研究和开发方向： 符号主义（Symbolism）： 符号主义也被称为逻辑主义或规则主义，它侧重于使用符号来表示知识，并通过规则（如逻辑规则）来处理这些符号。 符号主义的核心是符号推理，它试图模拟人类的思考过程，通过符号操作来解决问题。 符号主义在专家系统、知识表示、逻辑推理等领域有广泛应用。 连接主义（Connectionism）： 连接主义基于人工神经网络，特别是深度学习，它试图通过模拟人脑的神经元网络结构来处理信息。 这种方法强调通过训练数据来自动学习特征和模式，而不是手动设计规则。 连接主义在图像识别、自然语言处理、语音识别等领域取得了显著的成功。 行为主义（Behaviorism）： 行为主义关注于智能体与环境之间的交互，以及如何通过感知和行动来适应环境。 它通常不涉及复杂的内部表示或推理，而是侧重于通过试错和强化学习来优化行为。 行为主义在机器人学、自动驾驶、游戏AI等领域有着重要的应用。 用大模型解决规则引擎问题 # 我在工作中会经常遇到使用规则引擎解决决策推导问题。基于我对大模型的理解，它不应该也不会具备符号推理的能力。大模型的推理能力体现在语义理解层面。我一度认为大模型不可能直接解决规则引擎的问题，直到我用工作中遇到的组炉组浇规则试了试。 以下是个简化后的组炉组浇规则的实验，规则中含有中间变量，以及对条件满足度的累加计算。  先后使用了kimi、通义千问、gpt-4o等大模型，准确率基本在98%以上。它们的推理思路非常的一致，即：先制定推理路径，然后逐步推理，直到得到答案。 但是也有问题。当给定的条件稍微有所偏差时，大模型就开始胡诌起来，失去了稳定性。 这跟我预想的不一样，看来连接主义似乎胜利了。 让大模型解微积分 # 来点高难度的，让大模型试试解微积分。 假设模型需要解决微分方程 $$ \frac{dy}{dx} = 3x^2 $$ 大模型给出了以下的推理过程： 识别微分方程：模型识别这是一个基本的微分方程。 分离变量并积分： $$ \frac{dy}{dx} = 3x^2 $$ $$ dy = 3x^2 dx $$ $$ \int dy = \int 3x^2 dx $$ 计算积分： $$ y = \int 3x^2 dx = x^3 + C $$https://www.ifixedbug.com/posts/llm%E5%A4%A7%E6%A8%A1%E5%9E%8B%E5%BC%80%E5%8F%91%E7%94%9F%E6%80%81%E6%80%BB%E7%BB%93%E4%B8%8E%E5%BA%94%E7%94%A8%E6%80%9D%E8%80%83/Sun, 05 May 2024 17:00:20 +0000https://www.ifixedbug.com/posts/llm%E5%A4%A7%E6%A8%A1%E5%9E%8B%E5%BC%80%E5%8F%91%E7%94%9F%E6%80%81%E6%80%BB%E7%BB%93%E4%B8%8E%E5%BA%94%E7%94%A8%E6%80%9D%E8%80%83/大模型 # 小明在倒果汁的时候被暗杀了，因为他汁倒得太多了。 我知道的还不多。 按照目前我的理解，当前一切大模型的应用都基于LLM提供的两个能力： 理解力，可以概括内容、理解语意、结构化语句。 生成力，可以生成内容。 这两个能力也直接促进了RAG、Agent等概念的兴起，所有工具集都依赖于这两个能力。所有的应用也都是在这两个能力上扩展与想象，创造无限可能。 对应地，openai有两类主要api： text completion， 文本补全，一问一答，某种程度上体现了生成力。 chat completion， 对话补全，需要记住上下文，某种程度上体现了理解力。 当然有时候这两类是融合在一起的，不好区别。实际上openai的对话上下文都是通过assistant角色带入的，结合该角色内容返回结果，总体看起来本质上也是一问一答。但这也可能产生新的问题：long context问题，也就是扔给大模型的太多，消化不良。 长上下文是大模型的一个卖点，如kimi声称可以支持200万token，可以扔进去一本红楼梦。但我已经排队2个多月了，据称kimi CEO都在出售自己股份了，我还是没体验到。 长上下文会使大模型的记忆能力下降，无法建立明确的上下文关联，造成长距离的信息，会让大模型看上去很傻。这一点脱口秀演员就做得挺好，来个call back，结尾要呼应上开场，增强听众记忆，听懂掌声。 模型的分类 # 现在比较常用的模型应该分为以下几类： 推理模型 inference/ reasoning， 就是我们所说的text-generation模型，大模型 embedding模型，用以将分段后的数据集文本做嵌入时使用，或对提问做向量化等 Rerank模型，主要在做RAG时，对检索到的候选文本(向量库中的高相关性文档)与用户提问做再排序，提高关联性。如：Cohere Rerank 模型 语音转文字模型，asr(automatic speech recognition)模型，如：openai的Whisper3，已开源，可自托管。 文本转语音模型，tts(text to speach)模型，开源的很多，如：vits等 其他生图生视频等多模态模型，生态复杂，暂且不表。 我们所说的大模型一般是指推理模型，也是大部分应用的基座。基于推理模型结合其他开源模型，世面上已经出现了丰富的富有想象力的应用。 部署方式 # LLM的两种部署方式： 使用商业模型的api作为基座，融入到业务中。对于工业应用，这一点基本是不能接受的，因为数据安全问题。 使用训练好的开源模型运行起来。 对于程序员来说，未来的方向是私有化部署，部署方式则是从model托管平台拉取对应的模型数据，然后启动。并使用RAG或者微调技术，对开源的模型进行个性化训练。了解开源社区及周边的开发生态，是一般开发者的关注重点。 托管平台 # 抱抱脸(https://huggingface.co) 是一个大模型(Models)和数据集(Datasets)托管平台，平台提供了大量开源社区的模型，也有开发者微调后上传的模型。比如llama3-8b的中文支持不够好，就有开发者加入中文语料微调后上传。我们就可以直接使用微调后的中文大模型，如： https://huggingface.co/shenzhi-wang/Llama3-8B-Chinese-Chat-GGUF-8bit 该模型名中的8bit是指采用了8位的量化，减小了模型体积，提高运行速度(内存到CPU的数据传输量减小)，但有一定的精度损失。 GGUF代表GPT-Generated Unified Format，是用于存储大型模型预训练结果的一种格式。它被设计为一种紧凑的二进制编码格式，优化了数据结构和内存映射技术，提供了高效的数据存储和访问方式。 另外托管平台也直接运行了对应的大模型实例，可以在平台上直接使用，如： https://huggingface.co/spaces/llamafactory/Llama3-8B-Chinese-Chat。 也可以申请抱抱脸的api key，直接调用对应的大模型。 https://groq.com 也是一个托管平台，运行了llama3、mixtrial等大模型实例。groq以速度快著称，我在vscode里安装了codegpt插件，并使用groq的provider和llama3模型，飞一般的响应速度。 类似的托管平台还有很多，如 together.ai 等。都各有特色。 本地托管 # 本地部署使用OLLAMA比较简单。安装地址： https://ollama.com/download , 安装llama3模型则使用：https://www.ifixedbug.com/posts/%E5%8A%A8%E6%80%81api%E8%AE%BE%E8%AE%A1/Fri, 05 Apr 2024 17:10:22 +0000https://www.ifixedbug.com/posts/%E5%8A%A8%E6%80%81api%E8%AE%BE%E8%AE%A1/设计目标 # 目标： 用模板引擎的方式撰写一段Sql脚本模板，并指明对应的参数含义，发布后前端可以通过 /api/dynamic-api/invoke/my-api-name的方式直接调用，且调用支持多种HTTP方法和以不同的方式传递参数，如：查询参数、body和header参数方式。该设计思路与： http://www.51dbapi.com 类似。 基本过程 # api定义(ApiDefinition): 定义一个api，指明唯一的name和备注信息等，并指明它的sql脚本和数据库链接等。 连接池(ConnectionPool): 多个api请求数据库的数据时共享同一个连接池，减少建立链接的过程。为api指定连接池，即指明对应的数据库链接地址，则直接执行调用； api参数(ApiParameter): 定义一个api需要的参数，该参数的名称需要上述sql脚本使用的脚本保持一致。 配置动态api的过程如下： 提供表单，用户填写api的基本信息，如：英文名称、请求方法、备注信息等； 用户填写api运行时要执行的sql脚本，注意这里要使用到模板引擎，有很多判空的逻辑。本系统推荐使用liquid模板。 为该api指明sql脚本执行时调用哪个链接，即使用哪个数据库。弹出连接池列表选中一个。 用户填写api是否支持分页和排序，若支持，则自动含有分页和排序对应的查询参数，如：pageSize\MaxResult\Sorting等。 用户为该api添加参数，参数分为：查询参数、body参数和header参数，另外也需要添加参数的名称。这些参数需要与第2步中，脚本引擎引用的变量名称保持一致。 发布该api，配置该api的可访问permissions。 测试api的可用性，提供参数的输入界面，点击测试后能返回对应的结果。 liquid模板的sql脚本实例如下： {% assign param1 = 'value1' %} {% assign param2 = 'value2' %} {% assign param3 = null %} {% assign sql_query = "SELECT * FROM your_table WHERE 1=1" %} {% if param1 != null %} {% assign sql_query = sql_query | append: " AND column1 = '" | append: param1 | append: "'" %} {% endif %} {% if param2 !https://www.ifixedbug.com/posts/linux%E5%A4%87%E5%BF%98%E5%BD%95/Fri, 05 Apr 2024 12:12:22 +0000https://www.ifixedbug.com/posts/linux%E5%A4%87%E5%BF%98%E5%BD%95/Linux # npm install -g nrm nrm ls nrm use taobaoMacBook 安装brew以及修改镜像 cd "$(brew --repo)" git remote set-url origin https://mirrors.aliyun.com/homebrew/brew.git cd "$(brew --repo)/Library/Taps/homebrew/homebrew-core" git remote set-url origin https://mirrors.aliyun.com/homebrew/homebrew-core.git echo 'export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.aliyun.com/homebrew/homebrew-bottles' >> ~/.zshrcsource ~/.zshrc参考网址：https://www.cnblogs.com/feiquan/p/13267284.html wsl2安装Ubuntu20.04 LTS版本 # 添加删除命令执行后要重启。 安装wsl_update_x64.msi 要重启。在微软商店安装最新版。 记住在ps中设置Ubuntu20.04默认用户的口令为： ubuntu2004 config –default-user root ubuntu2004 是win10系统中存在的命令。 SSH协议 # openssh是一个可以用来产生rsa密钥对的命令行工具。需要更新到最新版，以前的安装的太老了。导致使用的时候有错误（chmod 600 命令于此有关）。 下载最新的openssh产生密钥对 ssh-keygen -t rsa 密钥对会在/home/Zigzag/.ssh/下，此时需要对id_rsa进行权限变更，可以使用cmder执行如下命令： chmod 600 /home/Zigzag/.ssh/id_rsa 把id_rsa.pub字符串拷贝到centos服务器上，使用cmder命令： scp id_rsa.pub root@123.45.67.8:~/.ssh会提示输入密码，输入后即可，点击yes，会在本地填入known_hosts，是来与服务器的公钥。等待客户端加密使用。 登录CentOS服务器，将id_rsa.pub里的文件写入到~/.ssh/authorized_keys里。 cat ./id_rsa.pub >> authorized_keys然后重启ssh服务https://www.ifixedbug.com/posts/oracle%E5%A4%87%E5%BF%98%E5%BD%95/Fri, 05 Apr 2024 12:12:22 +0000https://www.ifixedbug.com/posts/oracle%E5%A4%87%E5%BF%98%E5%BD%95/Oracle # 倒序查询某表的最后100条记录，并正序排列 # select * from (select * from FAC_HEAT_CONSUMPTION t order by id desc) where rownum < 100 order by id select * from (select * from HS_CHEMICAL_IRON t order by id desc OFFSET 0 ROWS FETCH NEXT 100 ROWS ONLY) order by id从0开始，获取100个，OFFSET 0 ROWS可以省略掉。 删除sys.dbms_scheduler.create_job创建的日志 # begin sys.dbms_scheduler.create_job(job_name => 'ARIMSGTEST.UPDATE_PL_JOB', job_type => 'STORED_PROCEDURE', job_action => 'arimsgtest.update_pl_job', start_date => to_date(null), repeat_interval => 'Freq=Hourly;Interval=1', end_date => to_date(null), job_class => 'DEFAULT_JOB_CLASS', enabled => true, auto_drop => false, comments => ''); end; / SELECT * FROM User_Scheduler_Jobs; // 查看作业 SELECT * from All_scheduler_job_log where owner= 'ARIMSGTEST' and job_name= 'UPDATE_PL_JOB2' select * from All_scheduler_job_run_details where owner= 'ARIMSGTEST' and job_name= 'UPDATE_PL_JOB2' Delete from all_scheduler_job_run_details where owner= 'ARIMSGTEST' and job_name= 'UPDATE_PL_JOB2'logging_level——日志记录级别（DBMS_SCHEDULER.https://www.ifixedbug.com/posts/js%E6%9D%82%E9%A1%B9/Tue, 05 Mar 2024 12:12:22 +0000https://www.ifixedbug.com/posts/js%E6%9D%82%E9%A1%B9/基础知识 # 移除一个对象的某个属性 # const removeProperty = (propKey, { [propKey]: propValue, ...rest }) => rest; object = removeProperty('a', object);https://stackoverflow.com/questions/208105/how-do-i-remove-a-property-from-a-javascript-object/52301527#52301527 $ npm install -g cnpm --registry=https://registry.npmmirror.comnpm install -g nrm nrm ls nrm use taobao // 注意npm publish 到 npm官方站点后记得切换到官方源，否则看不到最新的版本 // 旧地址2022年(今年)5月份停止解析 npm config set registry http://registry.npmmirror.com ts项目不识别@符号的相对路径设置 # 在tsconfig.json 或者jsconfig.json中，配置 compilerOptions 的路径，加入： "paths": { "@/*": [ "./src/*"] } 直接运行js字符串代码 # 引用： https://stackoverflow.com/questions/939326/execute-javascript-code-stored-as-a-string 方法一：使用 Function，注意：如何为Function添加参数？ //Executes immediately // 注意使用return， 不然没有返回值。 function stringToFunctionAndExecute(str) { let func = new Function(str); return (func()); // <--- note the parenteces } //Executes when called function stringToFunctionOnly(str) { let func = new Function(str); return func; } // 有参数的Function let func = new Function ([arg1[, arg2[, .https://www.ifixedbug.com/posts/opu-da%E8%BD%AC%E6%88%90ua%E7%9A%84%E6%96%B9%E6%B3%95/Tue, 05 Mar 2024 12:12:22 +0000https://www.ifixedbug.com/posts/opu-da%E8%BD%AC%E6%88%90ua%E7%9A%84%E6%96%B9%E6%B3%95/OPC # OPC DA（Classic） 和OPC UA的链接方法 # 在仅支持OPC DA 2.0的OPC SERVER上部署代理程序（COM Wrapper），然后发布成 UA SERVER。从： https://github.com/OPCFoundation/UA-.NET-Legacy 下载兼容版的UA-.NET，因为是源代码基于.net framework3.5编写的，故3.5~4.5.1之间的framework都可以运行。因为要兼容windows XP系统，XP最新只能到Framework4.0， 故改成4.0的框架。 几个重要的配置，在Opc.Ua.ComServerWrapper.Config.xml文件中： <BaseAddresses> <ua:String>opc.tcp://localhost:48400/UA/ComServerWrapper</ua:String> <ua:String>http://localhost:48401/UA/ComServerWrapper</ua:String> </BaseAddresses>以上指明发布的ua地址，tcp和http都可以。 <ServerSecurityPolicy> <SecurityMode>None_1</SecurityMode> <SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#None</SecurityPolicyUri> <SecurityLevel>0</SecurityLevel> </ServerSecurityPolicy>以上指明认证方式，把其他的去掉，只保留不需认证方式。其他认证方式暂时没有研究。 <ComClientConfiguration i:type="ComDaClientConfiguration"> <ServerUrl>opc.com://localhost/ProcessIT.SimulationSvr.1</ServerUrl> <ServerName>DA</ServerName> <MaxReconnectWait>10000</MaxReconnectWait> <SeperatorChars></SeperatorChars> <AvailableLocales> <ua:String>en-US</ua:String> <ua:String>de-DE</ua:String> <ua:String>ja-JP</ua:String> </AvailableLocales> <BrowseToNotSupported>false</BrowseToNotSupported> </ComClientConfiguration>以上配置本地的OPC Server地址和名称。该配置节可以有多个，ServerName可以换成语义化的名称，并不强求一致。 运行UA COM Server Wrapper.sln项目，编译后有UA COM Server Wrapper.exe，直接使用会报错，需要拷贝Opc.Ua.CertificateGenerator.exe，产生证书。 把该程序拷贝到OPC Server的机器上，配置本地的OPC Server地址和名称。双击UA COM Server Wrapper.exe运行，会产生一个地址：opc.tcp://39.107.78.139:8888/UA/ComServerWrapper，使用一般的OPC UA 客户端，点击链接即可浏览数据了。 Modbus # 线圈状态/输入状态/保持寄存器/输入寄存器: coilStatus/inputStatus/holdingRegister/inputRegisterhttps://www.ifixedbug.com/search/Mon, 01 Jan 0001 00:00:00 +0000https://www.ifixedbug.com/search/https://www.ifixedbug.com/docs/example/folder_1/text/Mon, 01 Jan 0001 00:00:00 +0000https://www.ifixedbug.com/docs/example/folder_1/text/ h2 # h3 # h4 #https://www.ifixedbug.com/about/Mon, 01 Jan 0001 00:00:00 +0000https://www.ifixedbug.com/about/关于我 # 曾经写过很多代码，都是垃圾。 现在不写代码，但是关心代码。 因为名字起得不好，误入钢铁行业。 折腾过，但无果。不够聪敏，没有特质，不是那块料。 爱音乐，爱电影，爱代码。 不爱运动，没有什么追求。 爱吃麻辣，爱喝啤酒，肚子有点大。 不爱说话，爱安静，没什么格局。 知天命，尽人事。 吃好喝好，或者留下点什么。 关于博客 # 2013年10月3日的那个下午，我在一个还能抽烟的咖啡馆注册了一个微信公众号，名字叫麻花段子。三个月前我刚经历一场大的手术，术后容光焕发若获新生，对世界充满了好奇。那时候微信公众号出现一年，微信也才刚刚流行起来，一切都寂静无声。谁能料到今天的微信能制霸移动IM又装进一个万花筒，无数人在浪潮之巅靠着执行力和恒心赢得红利。 那天我群发了麻花段子的第一条消息，时间接着又悄悄地过去了十年。 年轻时的我喜欢各种段子，玩谐音的、回文的、反转的，总之充满了讽刺、世俗和一点点智慧，收集与改造它们变成了我的乐趣之一。这个转段子的习惯从百度hi、QQ签名、朋友圈、微博一直延伸到公众号。为此我注册了一个wow.so的域名，专门做了个网站收集段子。随后，公众号来了，注册了麻花段子。从10月到2014年的11月，断断续续摘抄了一些网络中的猎奇网文后再也没有更新，网站也因为so这个索马里后缀的域名越来越贵得离谱而注销。接着随之而来的是一场梦。 10年前的中关村创业大街，人头攒动，鸡血四溢，每个人都在谈论着几个亿的大项目。那时候3W咖啡的桌子还像黑熊家的床一样又大又舒服，我还像一个充满斗志的新手猎人冲动又好奇地打量着这个世界。每到周末我都会带着电脑，去那里喝一杯充满互联网泡沫的咖啡，顺便去中关村图书大厦看各种新上的技术书，晚上就坐特9绕着四环半圈回家，那真是一个充满希望的岁月。 也常常去光顾那里有个折扣很大的电子书店，后来没了，变成了京东奶茶店。奶茶妹妹不在奶茶店，后来奶茶店也没了。我恨奶茶妹妹。 10年后，人生渐渐活成了段子，也没了讽刺和戏谑的心境。而麻花段子的公众号还在，那些年关注过这个公众号的朋友们还在。他们作为青春岁月的参与者，就静静地躺在后台的用户列表里，虽然不多，但很熟悉。 麻花段子作为我个人青春的资产留了下来，但它没有什么价值了，故没有存在的必要了。所以我想将它改一个名字，发挥余热，作为个人的空间写一些技术文章和总结，也可能会和我20年前的QQ空间一样有一些吐槽。总之它会留作私用，传播价值不大。 所以，各位师长，朋友们，陌生人们，感谢你们的关注，江湖再见。