Martin

Hypervisor允许多个操作系统共享一个CPU(多核CPU的情况可以是多个CPU)。虽然基本的技术已有半个世纪之久，但是应用到嵌入式领域却是近些年才发生的。 Hypervisor是宽泛的计算概念的一部分，作为虚拟化技术为人所知，这个概念已经出现半个世纪左右了。基本上Hypervisor的目的是共享硬件资源，就像操作系统所做的那样。本文将讨论Hypervisor与操作系统之间的显著差异，同时说明Hypervisor是怎么工作的。 历史背景: 19世纪60年代中期，大型机统治着整个计算世界，但是这些大型机非常稀有且价格极其昂贵(1960s的成百上千美元，相当于今天的百万美元)。不像今天，每个人都拥有自己的电脑(考虑到我们携带的所有数码产品，事实上每个人都拥有多个计算机，而且计算能力比大型机时代的计算机更加强大)。由于大型机的稀有和昂贵的价格，早起的大型机系统一般具有分时的能力。这意味着一台机器可以服务于多个用户，给每一个用户分配一个特定的时间片，在该时间片内某个用户的任务将被执行。一旦一个时间片消耗完毕，机器将会切换到下一个用户的任务。简单起见，可以理解为每个用户获得了一个虚拟机(VM)，从每个用户的角度来看，他们每个人都像是拥有自己的大型机。这样的大型机提供了一个Hypervisor(有点像操作系统的操作系统)，用以协调多个虚拟机。由于这个原因

软件质量，不但依赖于架构及项目管理，更与代码质量紧密相关。简洁高效的代码不但易于阅读，更能避免潜在 Bug 与风险，提高代码质量。这是显而易见的道理，但是要做到这个标准可不容易。想想看，据说 Oracle 12.2，有近 2500 万行代码，是不是很恐怖？你能做到在不破坏成千上万个现有测试的情况下更改这样产品中的单单一行代码吗？很难，对吧？要想避免这样的情况，就要从源头做起。“30”规则就是一个很好的办法，让我们看看 Riccardo Giorato 是怎么说的？ 正文： 本文最初发布 Medium 博客，经原作者 Riccardo Giorato 授权，InfoQ 中文站翻译并分享。 如果你在编程中，不考虑代码长度的话，那么可维护性、未来更新或对代码库的更改，都将会变得异常困难。 方法或函数的大小应该多大呢？ 我们都遇到过这样的问题，当一个函数太长的时候。 或者类，或者包，或者任何其他代码块。在某些情况下，任何一段代码都有可能会变得过于庞大，以至于他人无法正确理解。但是，多大才算大呢？ 在 Code Complete （《代码大全》，金戈等人译，电子工业出版社）， Steve McConnell 指出，理论上，一个方法或函数的最佳最大限制是在一个屏幕上可以容纳的行数。 这种“适合屏幕”的尺寸相当于 65~200 行之间的函数的最佳点。这种大小的例程开发成本更低

第一次读 重构 - 改善既有代码的设计（Refactoring: Improving the Design of Existing Code） 这本书还是在学校的时候，那个时候刚开始写Java代码，师兄推荐了两本书《重构》、《设计模式》。在今日看来，这两本书都是经典好书，得谢谢我的师兄。 最近，打算重新读一下这两本书，先读了重构，感觉还是收获颇多。想来这两本书都是比较偏向实践的，并不是读一遍就可以束之高阁了，而是应该常读常新。 本文地址： https://www.cnblogs.com/xybaby/p/12894470.html 去年重读了 代码整洁之道 这本书，也写了一篇笔记 什么是整洁的代码 。今年重读《重构》的时候，发现书中很多内容都是相同的，作者好像都是叫 Martin 什么的，我还想难道是同一个人？ 查了一下，并不是，重构的作者是 Martin Fowler ；而clean code的作者是 Robert C. Martin ,江湖人称 "Uncle Bob"。 不过好像两位都在面向对象、敏捷领域有所建树。By the way，重构的第一版写于1999年，（本文也基于第一版的译文），而clean code的第一版写于2009年，且clean code是有参考 “refactoring: Improving the Design of Existing Code”的。

前言 Django作为一个庞大的、自带电池的、整体Web开发解决方案框架，源代码多、子系统多、工具多。要将如此多的内容集成到一起，必然需要一个指导性的设计理念和哲学思维。这样才不至于显得东拼西凑、杂乱无章、接口混乱，而是整体一致、思路清晰、逻辑合理。既方便了源码开发，也方便了应用开发。 下面就介绍一下Django的设计理念和哲学思维，这其中有一些是Django源代码中正在遵循的，一些是使用者开发项目过程中需要遵循的： 系统性原则 松耦合 Django 追求各子系统（层）的低耦合和高内聚。各层之间保持代码独立、功能独立、尽量没有交联。 例如，模板层不需要知道用户的 Web 请求具体情况，模型层不需要了解模板层是如何展示数据的，视图层也不关心程序员所使用的模板系统到底是哪种和怎么使用的。通俗地说，模型层只关心数据的CRUD，视图层只负责业务逻辑的实现，模板层只管前端页面的渲染和展示。这三个核心层之间只有数据的传递，没有代码的交互，各自相对独立。 更少的代码 Django 建议每个APP的代码应该尽可能地精简，应该充分利用 Python 的动态能力，比如自省机制（introspection）。 快速开发 Django诞生于一个新闻编辑社，其应用环境要求快速开发和迅速迭代，所以在设计之初就追求以更快的速度实现需求的处理，你只需要编写一些新代码，或者修改一些局部代码就可以实现新的站点。

一、内部类的概念与分类 1、什么是内部类 如果一个事物的内部包含另一个事物，那么这就是一个类内部包含另一个类。 例如：身体和心脏的关系。又如：汽车和发动机的关系。 2、分类 1. 成员内部类 2. 局部内部类（包含匿名内部类） 二、成员内部类定义使用 1、成员内部类的定义 成员内部类：定义在类中方法外的类 1、定义格式： 修饰符 class 外部类名称 { 修饰符 class 内部类名称 { // ... } // ... } 2、定义类 package day11.demo03; public class Body { // 外部类 public class Heart { // 成员内部类 // 内部类的方法 public void beat() { System.out.println("心脏跳动：蹦蹦蹦！"); System.out.println("我叫：" + name); // 正确写法！ } } // 外部类的成员变量 private String name; // 外部类的方法 public void methodBody() { System.out.println("外部类的方法"); new Heart().beat(); } public String getName() { return name; } public void setName

综述 近两年来，Serverless 概念在开发者中交流的越来越多，实践、服务、产品层出不穷。 Serverless 的主题分享呈现爆发趋势，如在云原生领域颇具影响力的 KubeCon&CloudNativeCon 会议中，关于 Serverless 的主题，2018 年有 20 个，到 2019 年增长至 35 个。 产品层面，从最早的 AWS Lambda，到 Azure Functions、Goolge Functions、Google CloudRun，再到国内阿里云 Serverless Kubernetes、Serverless 应用引擎、函数计算等，面向计算的 Serverless 云上基础设施越来越丰富。 新概念、新产品的产生不是凭空出现，它们诞生之初要解决的是当前问题。随着实践者对问题域的理解越来越清晰和深刻，会逐步迭代问题的处理方法，提供更接近问题本质的解决方案。 若不从问题域出发来理解解决方案，容易陷入两个极端，即「它能解决一切问题」「它太超前了，理解不了」。 本篇文章尝试以日常开发流程为起点，分析每个阶段面对的问题，然后组合解决方案，提炼面向 Serverless 的开发模型，并与业界提出的 Serverless 产品形态做对应，为开发者采用 Serverless 架构和服务提供参考。 迭代模型 从项目整体视角来看： 这个模型的目标是满足客户需求。通过

原文: Entity Framework Core - CURD 【EF框架】DbContext的使用: https://blog.csdn.net/zmh458/article/details/78935172 DBComtext使用 DbContext 类是 EntityFramework （简称 EF ）中的一个类，可以理解为一个 数据库对象的实例 。在 EF 中，无需手动的拼接 SQL 语句对数据库进行增删改查，而是通过 DbContext 来进行相应操作。 DbContext类 DbContext是负责与数据交互作为对象的主要类。DbContext负责以下活动： （1）EntitySet： DbContext包含映射到数据库表的所有实体的实体集（DbSet ）。 （2）查询（Querying）： DbContext将LINQ-to-Entities查询转换为SQL查询并将其发送到数据库。 （3）更改跟踪（Change Tracking）：跟踪实体在从数据库查询后发生的更改。 （4）持久数据（Persisting Data）：它还根据实体的状态对数据库执行插入，更新和删除操作。 （5）缓存（Caching）： DbContext默认进行一级缓存。它存储在上下文类生命周期中已经被检索的实体。 （6）管理关系（Manage Relationship）：

--用system用户登录，创建用户并授权 conn system/system as sysdba create user username identified by password grant connect to username grant select on ta1 to username --例如： SQL> conn system/system as sysdba; 已连接。 SQL> create user test identified by test; 用户已创建。 SQL> grant connect to test; 授权成功。 SQL> grant select on scott.emp to test; 授权成功。 SQL> conn test/test; 已连接。 SQL> select * from scott.emp; EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO ---------- ---------- --------- ---------- -------------- ---------- ---------- ---------- 7369 SMITH CLERK 7902 17-12月-80 800 900 20 7499 ALLEN SALESMAN 7698 20-2月 -81

大家好，欢迎来到本人博客，昨天我给大家带来了哈喽沃德先生的微服务架构的前世今生（二）：技术架构的演变。今天将会用2个故事帮助大家更好的理解 SOA 与微服务的区别。 一、故事1 很久以前的一天，Martin 在跟好友的交流中悟到了一种很棒的架构设计。他总结了一下，然后告诉了好友，好友说，这不是新鲜东西，早有人总结了，叫做 SOA。 Martin 很高兴，开始在公司内外推广 SOA。结果，不停有人质疑和挑战他。 你这不是 SOA 吧？SOA 这里应该是如此这般的。对，这里我对 SOA 的理解是这样的。你看，这本 SOA 的书说的和你说的有出入。粒度？SOA 没有谈到这个呀，你这不是 SOA。分层跟 SOA 没有关系，你为什么要说这个呢？… Martin 没办法，心一横，老子就叫它 Martin’s SOA。老子发明的词，老子就是最高权威，有最终解释权。还有谁不服？ 同事们一看，这思想本身很不错，值得推广，但叫 Martin’s SOA 太没品了吧？还是要取个好一点的名字，最好还能跟 SOA 有某种暗示传承。干脆就叫 Microservices 好了，又新，又有服务含在其中。 Martin 忿忿地接受了这个建议，心里想着：娘的，明明就是 SOA，一群**非要逼我取个新名字。 后来 Martin 发现每次提一个东西就会收到旧恶傻势力对解释权的挑战，所以每次要提一个什么概念

《 JavaScript 风格指南》（Clean Code JavaScript ）是一本开源书籍，遵守MIT开源协议，目前已经被热心网友翻译完成多个语言版本（包括中文）。原作者是Google 工程师 Ryan McDermott ，根据 Robert C. Martin 《代码整洁之道》（Clean Code）总结的一份适用于 JavaScript 的软件工程指导准则。帮助读者写出易读、易复用、易重构的 JavaScript 代码。 作者称，不必严格遵守本文的所有原则，有时少遵守一些效果可能会更好，具体应根据实际情况决定。本书是多年经验整理的代码优化建议，但也仅仅只是一份建议。建议读者把这些原则当作试金石，尝试将他们作为团队代码质量考核的标准之一。同时也需要时常和同行们进行代码评审，不断优化自己的代码。不要惧怕改善代码质量所需付出的努力。 GitHub 仓库挂件 WordPress 插件 ryanmcdermott / clean-code-javascript :bathtub: Clean Code concepts adapted for JavaScript https://github.com/ryanmcdermott/clean-code-javascript 37,326 4,422 Download ZIP 相关文件下载地址 本地直接下载 来源： oschina