• 最近，我与一位员工以上级别的工程师聊天，他一直在努力影响他的同行：每次他建议一种新方法时，组织中的其他同事却不同意，并予以回击。他希望得到我的建议，为什么他的同事总是破坏他的方法？ 聊天结束后，我又与他的同事们聊了聊最近的一些分歧，他们不断强调这位工程师所提的各种[b]建议中缺少上下文背景信息[/b
  • 比特币为啥有用？不是它本身用多少黄金 石油做标的，不是它本身指向了多少实在物质，而是有人使用它，只要被使用就有价值，而不在于该符号本身有多少价值。 我们所说的 "成功 "是指当前
  • 领域驱动设计（DDD）通过将精心设计的领域模型整合到软件系统中，为解决复杂业务问题提供了有价值的框架。其中，有界上下文（BC：限界上下文、有边界的上下文）的概念至关重要，它们是针对特定用户或业务挑战而定制的模型，使用共享的通 icon
  • 集合论中的罗素悖论以及软件系统设计中过度宽容规则的问题。 [list] [*]罗素悖论揭示了集合论中的自指矛盾，表明过度宽容的规则可能导致难以处理的边缘情况。 [*]软件系统中的过度宽容规则也可能引发意想不到的问题，挑战系统的可预测性和稳定性。 [/list] 在软件系统设计中，需要平衡灵活性和严谨 icon
  • DDD中的错误抽象比其他设计方法具有更大的破坏性影响。这篇文章分享了 DDD 中代价最高的设计错误；导致单一和紧密耦合系统盛行的一个常见错误。 背景 企业中存在很多臃肿而脆弱的客户应用程序接口，而针对这种脆弱性提出的解决方案，最终会在客户应用程序接口不可避免地变得过于繁琐时，将其拆分成更小的、目的明 icon
  • 基于上下文关系的阅读方法：不死扣每个词语字眼，而是着眼这个词语的语境前后关系。 以下是ChatGPT回答： 基于上下文关系的阅读方法强调理解文本的整体语境，而不仅仅是理解单个词语或短语。 这种方法的核心是通过识别句子、段落甚至整篇文章中的逻辑关系和线索，来解读文本的含义。以下是一些实践方法： icon
  • ASOS人工智能团队是一个由机器学习工程师和科学家、数据科学家和产品经理组成的跨职能团队，利用机器学习来改善客户体验、提高零售效率并推动增长。 banq注：在讨论[url= icon
  • 这篇文章是一位游戏开发者关于他们使用 Rust 进行游戏开发的经历和决定停止使用 Rust 的详细阐述。文章中提到了他们对 Rust 语言和其社区的看法，以及他们为什么认为 Rust 不适合他们的游戏开发需求。 以下是文章的一些关键点： [list=1] [*]Rust 学习曲线和生产力：作 icon
  • 单体架构是一种软件设计方法，其中应用程序的所有组件都集成为一个不可分割的单元。在这种架构中，整个应用程序（包括用户界面、业务逻辑和数据访问层）作为单一实体进行开发、部署和维护。 什么是单体？ 单一存储库 — 将源代码共同定位在单个存储库中 单一应用程序 — 在单一应用程序中提供所有功能 单 icon
  • 我一直倾向于尽量避免Go struct结构体嵌入，因为我发现这样做会增加阅读难度，因为这个 "上帝结构体god struct "恰好实现了大量独立的接口，并被传递到很多地方。不过我还是想听听其他人的意见。 您对结构嵌入（尤其是实现trait接口时）有什么看法？ Reddit网友讨 icon
  • 谷歌这项研究引入了一种有效的方法，可以将基于 Transformer 的大型语言模型 (LLM) 扩展到具有有限内存和计算的无限长输入。 一个关键组成部分是一种称为“无限注意力 Infini-attention ”的新注意力技术： Infini-attention 将压缩记忆融入到普通的注意力机制中 icon
  • Google DeepMind 团队如何创建迄今为止任何大型基础模型中最长的上下文窗口。 Gemini 1.5 模型的创新之一是其长上下文窗口，可以处理多达 100 万个令牌的原始数据。 长上下文窗口的突破性实验功能使模型可以接收和处理更多的文本、图像、音频、代码或视频。 通过长上下文窗口，Gemi icon
  • 日志很重要，日志记录对维护网络应用至关重要，日志记录不力可能导致问题无法被发现，从而引起客户不满。 常见日志级别： 大多数编程语言和日志库都提供多种日志级别，通常包括ERROR、WARN、INFO、DEBUG 和 TRACE。不过，不同语言和框架的具体级别及其用法可能会有很大差异。 icon
  • 这篇博文深入探讨了如何构建Spring Boot应用程序、利用Docker一致的本地环境、Zipkin进行跟踪以及实现 100% 代码覆盖率的策略。 我们将探讨设置基于功能的模块化bookstore应用程序作为示例。我们将利用JPA数据持久性、SwaggerAPI 文档、Postgres数据库、Ja icon
  • TOGAF 规定，架构视点（Architecture Viewpoint）管理架构视图（Architecture vView）。那么，如果利益相关者有疑虑，该疑虑会反馈到哪里，是架构视点还是架构视图？ 解释1： 我站在山顶（viewpoint）俯瞰大冰川（view）。 我的妻子在冰川形成的湖面上的 icon
  • 这篇文章介绍了复杂自适应系统（简称CAS）的定义和特征。 [b]什么是复杂自适应系统CAS？[/b] [list] [*]复杂自适应系统CAS的定义：包括多个相互连接和相互依赖的交互代理，并具有非线性行为。 [*]复杂自适应系统的关键特征：包括代理的自主性、主动性、反应性，以及具有存储、学习、适应、 icon
  • 我们将探讨支撑有效微服务设计的核心原则，从确保高内聚性和低耦合性到将失败作为设计原则。在此过程中，我们将提供真实示例、实用技巧和可行的见解，帮助您自信地应对微服务架构的复杂性。 1、内聚和耦合 在深入研究微服务架构领域时，不能忽视内聚和耦合的基本概念。这两个原则是微服务整个结构的基石。但不用担心，我 icon
  • SOA面向服务的开发基于以下四个基本原则： [b]1、边界明确[/b] 面向服务的应用程序通常由分布在遥远的地理位置、多个信任机构和不同执行环境中的服务组成。在复杂性和性能方面，穿越这些不同边界的成本并不低。 面向服务的设计承认这些成本，因此对边界穿 icon