最近花了一个周的零星时间，看了《编写可读代码艺术》，收获颇多。虽然平时也经常使用书中提到的一些方法编写代码，但只是一种直观感觉认为这种方式是“正确”的。书中将这些方法提炼成一条条原则，并采用大量实例佐证这些原则。书中系统化的介绍了如何编写可读代码，并提出很多指导性原则，整本书不到200页，非常值得阅读。
何为好代码，何为坏代码，每个人的判断标准可能并不一样，但作者提了总的指导原则：代码应当易于理解来诠释什么是好的代码，并用可读性基本定理：代码的写法应当全人理解它所需的时间最小化来衡量代码的可理解程度。即“可读”是一个总的指导原则，而可读性基本定理则是对“可读”的定量判断。当我们在犹豫不决时，可读性基本定理可以帮你做判断。
在编写代码时，做的最多的一件事情就是命名，我们会对变量、函数、类、包等命名，命名的本质是把信息封装到名字中，好的命名，可以帮忙你快速理解代码。书中提到了很多指导原则，我认为比较重要有些原则的如下：
这个星期利用上下班时间，读了一下《如何阅读》，书只有200页左右，很快就能读完。之所有写这篇读书笔记，一是实践书中的一些方法，训练自己归纳总结的能力；二是希望自己养成做读书笔记的习惯。以下是自己读完这本书的一些感想，我尝试用三个问题来对整本书进行总结。
明确自己的阅读目的非常重要！这可能跟学生时代学习课本知识不同，学习时代学习的课本都是系统化构建好的知识体系，我们没有多少选择。但当你想挑选一本书进行阅读时，可选择的书就太多了，如果不明确为什么要读一本书，那么读完后只是短暂地存储于你的大脑中，很快就会忘记。
一本书的信息量可能是非常大的，当自己带有目的性去阅读时，这就好比划重点，会着重关注自己比较在意的内容。这个时候跟作者就会有对话，你急需想通过书中的内容解答你的疑问，会加深对书中内容的理解。
比如我读《如何阅读》这本书时，就带有很明确的目的，我想通过这本书回答我以下两个问题。
在mac环境下，我们经常会使用iTerm2终端连接远程服务器，也经常会有本机和远程服务器之间进行文件共享的需求。这个时候lrzsz就派上用场了。
lrzsz是unix下的开源软件包，支持XMODEM, YMODEM ZMODEM文件传输协议。本文将会展示如何将lrzsz集成到iTerm2终端中，通过sz和rz命令和远程服务器传输文件。 其中，s表示send，r表示recieve，z表示使用的协议为ZMODEM。
对于传统Win32界面编程来讲，微软提供一整套界面标准，比如窗口、按钮、滚动条、列表等。对于每一个窗口（控件也是一个窗口），其能响应的消息和行为都有规范（通过API提供给开发者）。微软这套界面标准是为通用场景下提出的解决方案，能够满足绝大部分需求，但业务场景的多样性，使得开发者们并不满足于这套界面标准。
DirectUI是一种界面开发思想。其核心思想是指将所有的界面控件都绘制在一个窗口上，这些控件的逻辑和绘制方式都必须自己进行编写和封装，而不是使用Windows的原生控件，所以这些控件都是无句柄的（Windowsless）。
那这个名称是怎么来的呢？由于Windows有句柄窗口是一套工业标准，窗口消息和API都是公开的，所有人都知道怎么操作窗口。微软在做MSN的时候为了保护用户隐私，搞了一个DirectUIHWND，后边DirectUI这个名字就被沿用下来，后边说的DirectUI一般都是指无句柄窗口。
很多初级甚至有丰富开发经验的开发者都可能会遇到乱码的问题，对深入理解字符编码的人来说，问题很容易解决。但如果你对字符编码一知半解，这些问题可能会让你抓狂。对一名开发者来讲，不管你使用什么语言，在什么平台上开发，字符编码都是需要掌握的基本技能之一。
我们都知道，计算机只能处理0和1，为了让计算机能够处理我们的信息，就需要对信息进行编码。信息编码是一个很大的主题，本文只涉及计算机字符的编码，包括ASCII、Unicode、UTF-8、UTF-16、UCS-2。
原文出自：Windows Messaging Architecture
Most of the fresh software engineers and .NET developers may not know what really happens inside the Windows operating system when they implement and run a Windows application. This article explains the Windows Messaging Architecture of the Windows operating system.
很多新手软件工程师和.NET开发者在编写并运行一个Windows应用时，他们并不清楚其在操作系统中的运作原理。这篇文件将阐述Windows操作系统的消息体系。
我们在开发应用程序时，一般会引入一些第三方库，通常情况下，我们是把这些第三方依赖文件放到应用程序所处目录，这样应用程序启动时就能正确找到相关依赖文件。但当依赖文件比较多，我们希望对依赖的文件进行归类，放置到不同的目录下以便管理，这个时候应用程序的manifest就派上用场了。
在介绍应用程序的manifest之前，需要了解一下并行程序集(Side-by-Side Assembly)。什么是并行程序集呢? 并行程序集是微软为了解决DLL Hell问题而提出的一种解决方案，它采用manifest文件扫描组件之间的依赖关系。其工作原理如下图所求：
简单说明一下，微软在未提出Side-by-Side Assembly之前，应用程序启动时按照一定的规则加载DLL。通常情况下，应用程序会采用动态链接方式共享一些操作系统提供的基础库文件，当Windows更新共享库且共享库不能向后兼容时(DLL自身并不能向后兼容，这种情况通常发生在DLL的内存布局发生了改变）,那些依赖于老版本共享库的应用程序就不能正常工作了。为了解决这个问题，微软重写了DLL动态加载子系统，提出了并行程序集的解决方案，即允许多个版本的库共同存在，应用程序通过manifest描述自身所依赖的文件，SxS Manager再通过manifest按照一定的规则找到应用程序的依赖文件，使应用程序正确工作。
CEF(The Chromium Embedded Framework) 是Marshall Greenblatt于2008年基于 Google Chromium 项目创建由BSD开源协议授权的开源项目。它和Chromium项目不同之处在于，Chromium项目侧重于Google Chrome应用开发，而CEF侧重于使浏览器更容易内嵌到第三方应用中。CEF屏蔽了Chromium和
Blink代码的复杂性，在Chromium Content API之上提供了一套友好且稳定的API，开发者只需要在CEF API的基础上就能很容易地建立起基于CEF的应用。了解更多关于CEF的内容，请参考CEF官网。
CEF官网提供了两种发布方式：二进制发布和源码发布。二进制发布包含了基于CEF开发的应用程序所依赖的所有二进制文件和头文件。本文主要讲CEF的二进制发布，官网提供了较新版本的二进制发布包，下载地址在这里, 选择一个合适的版本(在写本文是，最新版本是3202)。编译CEF需要依赖以下编译环境：
需要注意的是安装VS2015u3的时候，默认是不会安装Win10.0.14393 SDK 的，所以需要你手动勾选；
CMake可以去CMake官网下载 Windows安装版本。
由于项目需要用到内嵌浏览器，IE内核太依赖于操作系统，对H5的支持也不太好。CEF是基于chromium 项目的内嵌浏览器开源框架，已经应用到了很多产品中，而且有比较健全的论坛和官方支持，是项目的不二选择。由于客户端要运行到Windows XP系统，但Chome浏览器在49版本(对应CEF3版本为2623，以下说的CEF均指CEF3)后不再支持Win7以下系统。CEF二进制发布官网上并未包含2623版本, 但CEF提供了源码发布，官方也给了源码编译文档说明，虽然按照官方文档说明进行构建，但在编译CEF 2623版本过程还是遇到不少问题，在此做个记录供网友参考。
注意:
- 由于某些原因（你懂的），源代码是同步不下来的，建议使用VPN。另外，CEF基于chromium，源码比较大，同步源码时间比较漫长，耐心等待；
- 安装VS2015u3的时候，默认是不会安装Win10.0.14393 SDK的，所以需要你手动勾选；
- 安装python后需要将python的执行环境加入到环境变量中；
对于Windows应用, 当应用发布出去之后，如果应用程序在用户机器上发生了崩溃，我们需要这样一种手段，即在程序崩溃的瞬间能够“记录”下崩溃时进程、线程、栈、栈上下文等信息，这些信息对我们分析崩溃原因非常有帮助。另外，由于客户端程序一般是运行在用户的机器上，当生成崩溃信息后，还需要将这些信息上报至服务器，以方便开发者能够快捷地拿到这些崩溃信息进行分析。一般来说客户端程序崩溃的收集与处理流程如下图：
