在我经历的每一个项目，几乎都要去讨论的一个事情就是到底用什么git的分支策略，在向来以技术卓越著称的Thoughtworks内部，也无法真正每个项目都有一致的实践，大家都很推崇Trunk-based开发方式，但很少有见到落地的。

然后我发现，即使退回到git-flow，也几乎没有人真正理解它，于是出现这样一个奇怪的现象：

每个项目都自己发明了一套workflow，它既不是标准的Trunk-based，也不是标准的git-flow，很可能跟github-flow或者gitlab-flow接近，总之来说，就是不标准。当然很可能这些差异是更好的，但坦率来讲，如果连基本的git-flow或者trunk-based方法都不理解的话，也很难知道它的好处和不好，又谈何是改进呢？

作为一个从来没接触过大数据的小白，从0开始来学习一下Hadoop。首先是安装环境，官网给出了几种方式:

• Local (Standalone) Mode: 单机版的模式，运行在一个JVM进程
• Pseudo-Distributed Mode: 伪分布式模式，运行多个JVM进程来模拟分布式的环境
• Fully-Distributed Mode: 完全分布式部署在多台机器上

当然最理想的当然是真实的分布式部署了，在进行分布式部署之前，先来简单的单机版本部署一下，以便熟悉一下Hadoop相关的概念。

Apache Hadoop是一个分布式的大数据处理框架，在2008年击败超级计算机，成为最快排序1TB数据的系统，用时209秒。

从Java技术栈迁移到C#，一个最直观的不同是C#对异步编程的语法层面的支持:async/await。在此之前，我也在Javascript以及Dart等语言中使用过类似的功能，以至于我一度想当然地认为async/await是Javascript最先发明的；但当我去追根溯源的时候才发现这其实C#几乎是最早开始引入的(2012年的时候C# 5.0中正式引入)，比Javascript(ECMAScript 2017)整整领先了5年。不得不佩服，虽然没有很火，但是微软的技术前瞻性的确是做的很好的。

那异步编程到底是什么呢？我没有找到一个完全准确的释义，但是要解释清楚还是比较容易的:

• 程序执行无序等待一个任务的完成(比如I/O操作)
• 可以并发地执行多个任务

实际上，并发也即意味着任务之间不需要串行等待。我的理解是，异步编程的核心就是优雅的实现“并发”。

这是读《计算机程序的构造和解释》的笔记。