我们是使用FMDB保存好友，联系人数据，在开始使用FMDB的进行小批量数据的读写时，开始还是蛮正常的，随着数据量以及业务的复杂的增加，发现了一些离奇的问题：1、偶现联系人数据表中存在重复记录；2、偶现读取不到数据，但拉数据库里面却有数据；根据业务场景分析，确实存在并发读写的情况，由于我们使用的是单例模式，所以问题1在不进行多线程互斥访问的情况下，确实是存在这个问题，所以想到的思路是将所有读写操作都放到一个队列中

购买装备，在Apple上选定设备类型的时候，如果你选择了自定义的机型，比方默认配置是8G内存，但官方可选配置支持16G,如果不小心选了16G,而你又着急拿到设备的话，可能就有点难搞了，定制机型需要等两周左右时间！本想让it同学花几天时间装上几部黑苹果，想想最后还是放弃了，公司最后采购了5台mini，两台高配，定制型16g内存。

虽然第一个项目还是2014年那会做的，但同事们都知道我有过iOS项目的经验，公司客户有了iOS版本的需求，自然会想到我来参与这个项目，，但具体充当什么角色，我自然是拿不准的，期望的，和实际的能力差距，很奇妙的感觉；比方我现在是在架构师的位置上，但在iOS的技能上，却没有充当架构四的能力，如何平衡现实和期望，着实让人纠结的一种状态 ！

在考虑实现一个P2P的公网监控点播方案，监控端通过局域网组网，局域网放一台服务器（双网卡，可上外网），作为局域网内所有监控的控制出口，该服务器上运行ZLMediaKit Server程序，集成tinyfecVPN Server的能力，通过该端口维持一个端口到公网STUN服务器的心跳（并转换为公网的地址和端口），所有接入的客户端通过公网的地址和端口点播实时的监控（协议走rtmp、rtsp或者hls均

I/O模型主要包括：阻塞IO、非阻塞IO、I/O 多路复用、异步I/O和信号I/O;阻塞和非阻塞能应用于所有文件描述符。所谓阻塞方式的意思是指，当试图对该文件描述符进行读写时，如果当时没有东西可读，或者暂时不可写，程序就进入等待状态，直到有东西可读或者可写为止；而对于非阻塞状态，如果没有东西可读，或者不可写，读写函数马上返回，而不会等待，O_NONBLOCK 的标志打开文件/Socket/FIFO句柄，如果连续做 read 操作而没有数据可读，此时程序不会阻塞起来等待数据准备就绪返回，read 函数会返回

接触过一些非专业的同学转行到程序员这个行业的，动手能力和代码能力都很强，但是底层知识的逻辑总会稍显欠缺，我也是在想这个问题，到底缺少的是什么？专业论坛也是对从培训班出来的同学，带着各种有色眼镜，原因是什么？先看看大学软件工程类专业必修的专业课程：计算机组成原理、程序设计语言、计算机多媒体编程、计算机网络、数据结构、操作系统、编译原理、数据库、软件工程、统一建模语言、软件体系结构...；这些专业书籍

c++中引入了右值引用和移动语义，可以避免无谓的复制，提高程序性能，用的不多，每次看过了就忘了，整理下；

Windows端的java程序使用jni调用C++编写的库，原来实现过在Android和Linux端通过JNI调用C++程序，在Windows端没有实现过，这里记录下几个关键的点；1、64位的dll工程，现在少有32位的平台，所以需要通过VisualStudio编译出64位的dll，注意属性页->C/C++->代码生成/运行库/选择多线程调试（/MTd），参考Linux编译选项的静态链

今天给团队调试一个错误，概率性的加密的数据没法做解密，现象是解密出来的结果和源数据长度不一致，很奇怪的现象，因为加密使用的数据是随机的，所以使得问题出现时表象是概率的问题；因为初次做加解密算法相关的项目，碰到这样的问题，首先是单步把解密流程过了一遍，发现解密没有问题，能正常的解密，但解密出来的长度就是不对，分析才发现加密后的数据的长度也不正常，所以考虑是加密源数据的问题，通过分析，才发现一个二进制

一个小工具，发现有一个开源的诗词库( https://github.com/michaelliao/shici/tree/master/web/src/main/resources/text  )，考虑导入到数据库中，诗词库是通过文件夹方式组织，所以用python发现很快的实现这个需求，主要功能包括递归枚举文件夹，然后将文件内容读出来写到数据库中。代码记录如下：