XXHolic

数学函数可视化

引子在看 babel 文档的时候，接触到 The Super Tiny Compiler，其中的注释感觉解释的蛮容易理解，翻译记录一下。OriginMy GitHub为什么要关注编译器大部分的人在他们的日常工作中，实际上没有必要去思考编译器相关的东西，不关注编译器很正常。然而，编译器在你的身边很常见，你使用的很多工具，都是借鉴了编译器的概念。编译器很可怕编译器的确很可怕。但是这是我们（那些写编译器的人）自己的错误，我们舍弃了简单合理，并且让它变得如此复杂可怕，以至于大部分的人认为是完全无法

引子在 Dependency Injection 中了解了相关概念，接下来看看在 Node 中如何使用依赖注入。原文：Dependency Injection in Node.jsOriginMy GitHub正文依赖注入是一种软件设计模式，其中一个或多个依赖项（或服务）被注入或通过引用传递到依赖对象中。使用依赖注入的理由解耦依赖注入使你的模块耦合性降低，从而产生更易于维护的代码库。便于单元测试你可以将它们传递到你想要使用的模块中，而不是使用硬编码的依赖项。在大多数情况下，你不必使

引子在尝试运用 Scalable Frontend 1 — Architecture Fundamentals 里面所说的 Dependency Injection（依赖注入）时，感觉有些不清不楚，找了些资料，才更明白了一些，在此翻译记录部分聚合。OriginMy GitHub依赖注入是什么在软件工程中，依赖注入是一种一个对象接收它所依赖的其它对象的技术。这些其它对象称为依赖。在典型的“使用”关系中，接收对象称为客户端（client），传递的（即“注入的”）对象称为服务（service）。将服

引子最近看一些文章的时候，看到事务的概念，只记得在很早的时候接触过，想不起来有什么用，查询了资料后发现还是挺有用的。OriginMy GitHub介绍事务处理（Transaction processing）是计算机科学中的信息处理，它被分成单个不可分割的操作，称为事务（transaction）。每个事务作为一个完整的单元必须成功或者失败，绝不可能部分完成。事务处理通过确保系统上相互依赖的操作，全部成功完成或者全部成功取消，在已知的一致状态上维持系统的完整性。举个例子，一个典型的银行交易：将

引子在看 Scalable Frontend 1 — Architecture Fundamentals 的时候，想到应该不止这一种分层模式吧，就去找了些资料，翻译记录。原文：10 Common Software Architectural Patterns in a nutshelleOriginMy GitHub正文有没有想过大型企业级系统是如何设计的？在主要软件开发开始之前，我们必须选择一个合适的架构，它将为我们提供所需的功能和质量特性。因此，我们应该理解不同的架构，在将它们应用到我们

引子继 Scalable Frontend 2 — Common Patterns 第三篇，继续翻译记录。原文：Scalable Frontend #3 — The State LayerOriginMy GitHub正文状态树，实际上就是单一来源在处理用户界面时，无论我们使用的应用程序的规模有多大，必须要管理显示给用户或由用户更改的状态。来源可能是从 API 获取的列表、从用户的输入获得、来自本地存储的数据等等。不管这些数据来自何处，我们都必须对其进行处理，并使用持久化方法使其保持同步

引子继 Scalable Frontend 1  — Architecture Fundamentals 第二篇。原文：Scalable Frontend #2 — Common PatternsOriginMy GitHub正文模式应该很好的适应，就像玩积木。让我们继续前端可扩展性的讨论！在上一篇文章中，我们讨论了前端应用程序的架构基础，但仅限于概念。现在我们要用实际的代码亲自实践一下。常见模式（Common patterns）我们如何实现第一篇文章中提到的架构？和我们以前做的相比

引子读了关于可扩展前端讨论的一些文章，翻译记录。原文：Scalable Frontend #1 — Architecture FundamentalsOriginMy GitHub正文关于软件开发中“可扩展性”一词最常见的两个含义，与随着时间推移代码库的性能和可维护性有关。你可以同时拥有它们，但是注重良好的可维护性，可以让优化性能变的更容易，且不会影响应用程序其余部分。更重要的是在前端，与后端有一个重要的区别：本地状态。在这个系列文章中，我们将讨论如何使用经过实际测试的方法，开发和维护一

引子基于 NodeJS and Good Practices 想尝试下分层，在做的时候发现另外一个类似的分层，继续翻译记录。原文：The Clean ArchitectureOriginMy GitHub正文在过去的几年里，我们看到了一系列关于系统架构的想法。其中包括：Alistair Cockburn 的 Hexagonal Architecture（又称 Ports and Adapters），并在 Steve Freeman 和 Nat Pryce 的精彩著作 Growing

引子文章 《The Single Responsibility Principle》 是从《NodeJS and Good Practices》里面看到的，继续翻译记录。翻译原文：NodeJS and Good PracticesOriginMy GitHub正文软件总是处于随时变化中，而有助于衡量代码质量的一个方面是改动代码的容易程度。但为什么会这样呢？…如果你害怕改变某些东西，那么它显然设计得很糟糕。— Martin Fowler关注点和责任分离（Separation of

引子很多地方看过或听过单一责任原则，看了《The Single Responsibility Principle》这篇文章后，有了新的认识，翻译记录一下。原文中有些链接失效了，找了资源重新换了下。翻译原文：The Single Responsibility PrincipleOriginMy GitHub正文1972年，David L. Parnas 发表了一篇优秀论文，题目是《On the Criteria To Be Used in Decomposing Systems into Mo