由于Qt本身的复杂性，且有一套独特的构建工具qmake，因此并不能像其他C/C++库一样，可以很简单的配置使用。对此，Qt推出了Qt Creator这一对Qt开发有着优秀支持的IDE，简化使用难度。除了Qt Creator，我们也可以借助Visual Studio的插件Qt Visual Studio Toos插件实现对qmake项目的支持。qmake还为我们提供了qmake项目生成VS，XCode对应工程的功能。当然，Vim经过配置，也可以很舒服地进行Qt开发。
很多人一想到Qt，就想到GUI程序开发，将Qt定义为一个C++ GUI库。确实，用Qt可以很方便的进行GUI程序开发，但GUI开发只是Qt的一部分。维基百科中对Qt的定义是
Qt是一个跨平台的C++应用程序开发框架。
Qt最鲜明的特点是它的跨平台性。目前Qt几乎支持常见的所有系统，包括Windows，MacOS，Linux，Android，iOS，BSD等等。只要不依赖平台相关的特性和API，一份代码可以在其所支持的所有平台编译运行。我刚解除Qt时对这一点并没有很深的体会，直到有一天我未修改一行代码，便将我的一个Windows程序运行到了Android上，除了由于界面大小未做处理导致看上去有些问题外，功能完全正常。利用Qt强大的跨平台性，我们可以很方便的写出兼容多个平台的软件。
另一个特点就是Qt是一个框架。Qt中提供了大量的模块，其中仅有一部分模块是和GUI开发相关的，其他的模块提供了包括数据库，网络，多线程等在内的功能的跨平台支持。很多人认为学习Qt就是为了GUI开发，但实际上，我们在进行非GUI程序，甚至是用其他C++ GUI库的开发时，都可以考虑使用Qt的这些模块提供的功能。
要想理解什么是应用软件开发，我们必须理解什么是应用软件。
在维基百科上对应用软件的解释是
An application software is computer software designed to perform a group of coordinated functions, tasks, or activities for the benefit of the user.
翻译一下就是 应用软件是被用于完成一系列相互协作的功能，任务或活动来满足用户需求的计算机软件，这句话中有几个关键词，一个是 coordinated，一个是 the benefit of the user。
应用软件开发就是应用软件从想法诞生到废弃的整个过程。根据我目前的经验，这个过程被分为了需求获取，开发规划，需求分析和设计，交互和UI设计，编程实现，软件测试，软件发布，维护迭代和最终下线。很多开发人员对软件开发的理解仅仅停留在编程实现这一步上，这是不对的，相反，在整个开发流程中，编程实现仅仅是其中一部分，其他的部分也都需要开发人员的积极参与。这些过程中，限于本人当前的水平，部分过程我里了解不多，因此接下来仅选择和开发人员相关的几个步骤做一些说明，其他过程仅做简单介绍。
Vim，一款被称之为编辑器之神的上古神器，从出生到现在已经有27年了。程序员普遍是喜新厌旧的，在这个存在着一票有着现代化的UI，各种智能操作的编辑器，IDE的时代，Vim看上去就像是早就应该被抛弃的IE6，但为什么一款这么古老的编辑器却依然有一批坚定地拥护者呢？要回答这个问题，我们必须知道，Vim是什么？
Vim是什么，相信绝大多数听过的人的第一反应都是黑黑的终端下的一个编辑器。是的，Vim是一款广泛应用在类UNIX系统下的文本编辑器，是基于更古老的一款编辑器VI发展而来的。Vim和其他的编辑器最大的差别就在于它的编辑方式。几乎所有其他的编辑器，都或多或少地依赖鼠标操作，但Vim可以说是完全抛弃了鼠标。为了达到离开鼠标的目的，Vim发展出了一套独特的按键操作，这让众多的新手纷纷放弃。在StackOverflow上，关于如何退出Vim的回答有一百万的浏览量。就这样一款让新手退出Vim可以用来生成随机字符串的的按键规则，才是Vim的精髓之所在。Vim发展到现在，早已不仅仅是一款编辑器，它更多的是代表了一套可以摆脱鼠标的按键规则。在文本编辑领域，目前几乎所有的主流编辑器都直接获间接提供了对这一套按键规则的支持；在主流的浏览器上，都可以安装提供这一套按键规则的插件；还有诸如Ranger等CLI程序，均可以使用Vim的按键规则。
最近工作中需要实现一个自定义外观的菜单，但在网上搜索后发现很少有QMenu的样式自定义相关的深入解析。请教了公司的一位前辈，他提到QMenu自定义样式不方便，于是他一般是自己实现一个菜单控件。但这样未免太过于麻烦，因此经过一番摸索后基本实现了自己所需的样式。
使用Arch系列发行版Linux系统由于经常需要滚动升级，导致稍不注意就会滚挂，影响正常使用，一旦无法修复就可能需要重新安装系统了。因此为了提高重装效率，经常备份当前已安装的软件包列表是一个非常好的习惯。在Archlinux的wiki中，就提到了如何备份和恢复已安装软件包，然而里面提到的备份方法虽然简单通用，但生成的备份列表中往往存在很多自己没有手动指定安装的软件包，即使添加了-e选项指定仅列出显式安装的软件包。这里给出一种更加精确的获取手动指定安装的软件包的方法。
使用了Manjaro有一段时间了，从最初的Ubuntu kylin，到Ubuntu，CentOS，Deepin，直到Manjaro这个发行版，被其相对简单的安装和强大的软件源所深深吸引。刚从Debian系切换过来还不是很习惯，相对于Deepin的开箱即用，Manjaro还是有一些需要手动去配置的地方。本文将以刚安装完成的Manjaro为前提，以作备忘
最近由于工作需要，我需要将C++库封装打包成AAR给Android项目使用，因此接触了JNI技术。由于完全没有经验，我在使用过程中遇到了不少坑，耗费了不少时间。
在我遇到的JNI错误中，其中最常遇到的一个报错便是在运行时提示”No implementation found for native”错误，错误信息类似于
No implementation found for void com.xxx.xxx.xxx.xxx(tried Java_com_xxx_xxx_xxx_xxx and Java_com_xxx_xxx_xxx_xxx_xxx)
导致这个错误的原因有很多，我也踩了其中不少的坑。为了避免以后再犯同样的错误，通过这篇文章记录总结一下我遇到的部分原因。
注：为了简洁，本文使用了部分可能不太合适的术语，具体如下
| 术语 | 说明 |
|---|---|
| native方法 | Java文件中声明的native方法 |
| native库 | 包含native方法实现的C/C++库 |
| JNI声明 | native方法对应的C方法的声明 |
| JNI实现 | native方法对应的C方法的实现 |
| JNI头文件 | 包含native方法对应的C方法声明的C头文件 |
| JNI源文件 | 包含native方法对应的C方法实现的C源文件 |
最近在一个使用CMake进行构建的项目中，我希望在用户编译时如果通过-D CMAKE_INSTALL_PREFIX=<path>指定了安装目录，则使用用户指定的路径，否则为了避免默认安装到系统目录（如Linux下默认安装到/usr/local/目录），则另外设置一个默认安装目录，因为系统目录往往需要一定权限才能安装，，而且这个项目本身并没有安装到系统目录的需求。
查阅CMake手册我们可以知道，官方提供了CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT这个变量来判断CMAKE_INSTALL_PREFIX是否被用户手动指定。然而在使用过程中，发现这个变量经常会莫名其妙的失效。
经过查找资料和不断测试后，原来这是CMake的”变量污染”机制在捣乱。