不要忘记历史：
Evernote：导出备份的 .enex 文件， 再导入时提示有几篇日志图片 太多，没有会员无 法导入。
印象笔记：用户因为从 Evernote 导入到印象笔记时触发了一个 BUG，五年笔 记丢失。新版本禁止导出公开格式的 .enex 文件，只能导出自己加密的 .note 格式，别的软件无法识别，只能映像笔记自己导出导入。
Notion：因为服务器在境外，偶尔会有无法访问的情况。未来有被墙的风险。
Wolai：CEO 公开声称用户上传非法信息要报警。CEO 公开声称自己审查用户笔记。公开挂程面试序员的隐私信息。
百度：百度盘扫描用户上传文件并做精准广告推送（上传证件图片的人被推荐电子证件钱包） 百度盘替换用户视频，换成净网行动的宣传视频。
某在线文档：用户用在线编辑的文稿，因为保存到在线云盘，数日后触发关键字被删除。
语雀：本来免费的，近期突然宣布新的收费策略，规定免费用户总文档数量不能超过 100 篇（包括小记、文档、数据表、表格、画板等），见这里：如何看待语雀付费策略 ？遭到大量投诉后又改为：免费用户每月 100篇，还是无法分享。
当年 github 就是天天被码云投诉，然后被墙掉了（不一定全是因为它，但它投诉了不少）；现在码云又在投诉仅有的 gitlab ，oschina 上天天看得到 gitlab 的黑文章，比如：
扒一扒极狐 GitLab 的底裤 – OSCHINA – 中文开源技术交流社区
OSCHINA 和码云是一家，天天发这些，也不标注下 “利益相关”，兴许各位的 notion 最近经常不容易访问到，也是被国内的竞争对手天天举报吧？按某些公司的尿性，面试程序员的隐私可以挂，用户的笔记随便审核举报，投诉下它 notion 简直小儿科，也许哪天真的就完全用不了。
因此，你的笔记如果打算保留十年以上，请选择支持本地存储+公开格式（最好文本）的软件，前者在于自己掌握数据，后者在于自己保留可以随时离开的权力。
我也用了 zk 一段时间了，觉得挺科学，应该是我近半年学习到最有价值的东西吧，分享一些我的理解和整理的笔记吧，以下观点来自对他人观点的整理和总结：
不用纠结 Zettelkasten 这个单词是啥，不是高深的玄学，就是德语的 “卡片盒”。
你无需像卢曼那样靠 zk 在 30 年里出版 60 本书，200 篇论文，但是 zk 是你的 “第二大脑”，通过修炼你的第二大脑，可以助你形成更深刻的洞见，并更高效率的进行输出。
想了解 zk 的背景介绍，可以看这篇文章：卢曼：与卡片盒交流 。
以下内容可能初读有点烧脑，每句话都是一个观点，都能展开成一段文字，但我挤干了所有水分，留下这么几百字，真的理解了，能持续受益，当然，在真正有价值的东西上花点时间很合算。
整个 zk 系统包含三个核心概念：
（点击 Read more 展开）
Read more…
图形界大佬 John Carmack 在推特上呼吁大家，现在应该有意识的保存你的开发环境，这样多年以后你想重新构建你的软件时才不会慌脚乱手，因为通常每过几年你常常会发现，自己之前的老代码已经没有合适的环境编译了：
今天互联网上的内容，由于各种原因，正在以越来越快的速度消失，而习惯什么都从网上找的新一代网民们，却并没有备份和记录的习惯及意识。不远的将来，会有一天，当你特别想找某个工具却搜尽互联网你都找不到时，就麻烦了。
这是一张兼具收藏价值和实用价值的光碟，收录了 Borland 公司全胜时期的著名桌面开发工具：C++ Builder 6 和 Delphi 7，以及各种配套书籍和资源，都是全网最好的版本（原版 CD 安装文件加最新补丁）。别看这两款软件老，因为生成可执行独立小巧，至今依然可以用他们做出交互尚可的桌面应用。
他们最大的特点，是可以让你轻松开发出 1MB 以内的无依赖的桌面软件：（点击 Read more 展开）
Read more…
1）不可撤销，SVN 随便你怎么折腾都不会把仓库弄挂，git 的话就要小心了，即便你设置保护了 master，其他分支不小心也会给弄没了。
2）简单直观，不但美术容易使用，连行政和 HR 用 TortoiseSvn 的话，二十分钟就上手了，一说就懂。Git 的话，即便是程序员，想用好的话，不读下 pro git 之类的书，我看都着急。
3）权限细分到目录，可以每次只 update 一个小目录。
4）好管理，只要本地修改下 authz.ini 然后 commit，服务端 crontab 设置个脚本，自动让最新的 authz.ini 生效即可，一切权限变更都有记录。
5）不占空间，占用空间更小，提交一些美术资源都不用担心，比 git 占用小多了。
6）成熟的工作流，branch 不方便没问题，一般 release/trunk/develop 三级分支就够了，平时大家都在 develop 分支上开发，每周一冻结版本，merge 回 trunk 开始测试 trunk，稳定下来以后再从 trunk 合并到 release 对外发布，hotfix 直接在 trunk 上做，测试通过又分别合并回 release 和 develop，非常清晰的工作流，有什么大功能的话再分出一个来。
7）负担轻，用 git 最大的负担就是天天 merge/rebase，这负担比 svn 重很多。
8）单调递增的纯数字版本号：13001, 13002, 13003 看着比一大堆 hash 标记直观，可以大模大样的写到测试邮件里，可以高效率口头交流，别人说个数字你就基本有概念，大概何时提交的？谁前谁后？
。。
说公有云 svn 少的，github 本身就可以用 svn 来操作，直接 checkout github url 即可，提交的时候用 github access-token 当密码，就是 ghp_ 开头那个很长的字符串 ，就能提交了。
代理的话 svn 一样可以配置，码云和 coding.net 等也都同时支持 git/svn。
。。
更没必要把用个工具上升到宗教程度去信仰，多角度看问题，别人的说法自己也想一想，比如曾经流传的：
说法1：git 可以当作 svn 用，svn 却不能当作 git 用，这说的是 git 可以完全包含 svn，根据上面几条，细究起来显然不是这样的。
说法2：git 是分布式的，中心挂了可以恢复；没毛病，但你又不是 linux kernel 需要全球协同，你一个公司项目，团队里所有人都坐在一起办公，即便有人在家工作也有强有力的组织约束，你是联不通内网非要用分布式还是说公司系统不可靠到备份需要依靠每个程序员的 working copy ？
说法3：git 可以方便做分支，没毛病，确实是 git 的长处；但它不经意间植入了一个潜台词 ，即“你需要频繁做分支”，真的是这样的么？还是看各个团队自己的工作流才对吧？上面三级分支的工作流在若干团队里成熟稳定的跑了多少年了，不需要像 git 一样每人每天都要处理合并问题。分支满天飞的代价就是下班前想推代码手慢被同事先 push 了，自己就只有晚半小时回家了。
这里并不是呼吁大家用 svn 代替 git，不用那么二极管思维，而是没必要把 git 当作 zz 正确，适当的时候需要用 svn 也开开心心的用就是。
第一层：协议非对称加密交换密钥，对称加密传输内容，保护好服务端私钥，防止中间人攻击。流式加密，同样包发两次内容不一样。
第二层：不用标准序列化工具如 protocolbuf，用修改版或者自己实现的。
第三层：客户端加密加壳防止调试和注入，程序签名防止篡改二进制。
第四层：重要代码放虚拟机或者脚本里运行（脚本字节码需需改），一般黑客主要分析反汇编，你复杂逻辑多套几层他就晕了。
第五层：关键数据不落内存，一律使用 getxx，setxx 之类的接口，后面将真实数据经过变换以后才落内存。
第六层：守护进程动态跟踪监控情况。
第七层：决定性逻辑永远放在服务端。
第八层：服务端定期校验消息合理性，比如十秒内最大的移动步长是多少，实际发上来的合理不合理，不合理就踢掉，比如按键点击频率是否超过正常人。
第九层：不定期弹出反外挂答题，答正确奖励经验，错误就掉线。
第十层：必须要放在客户端计算的内容将输入和结果 hash 同步给其他客户端验算，不对就踢掉。
第十一层：当检测到客户端触碰到某规则不要急着踢掉它，而是有概率被踢掉，还要随机几秒踢掉，这样黑客发现一会这里断一会那里断，就蒙圈了。
第十二层：发现某黑客/外挂工具利用某漏洞破解了游戏，先看影响大不大，再看他挣不挣钱，影响一般又不挣钱的话可以先养着他，等他挣钱了用户多了，大型活动之前，一条指令就把它封了，用户退款都可以弄得他爬不起来。
。。。。。
手机打字慢，先写这些，没有绝对安全，就是合理的策略加攻防成本。
在前文 用 MFC 写 GUI 程序是一种什么样的体验？ 中提过 Anchor Layout 可以很简单的设定让控件跟随窗口四条边大小变化的策略：
比如右下角的两个按钮，设置的 anchor 是 “right,bottom” 他们在窗口扩大缩小时，会跟右和下两条边保持恒定距离，左上角的文字是 “left,top” 的 anchor，他会保持恒定的左边距和上边距，中间文字框的 anchor 是四个方向的 “left,top,right,bottom” 他会和窗口四条边框保持相同边距，因此会随窗口扩大而扩大。
这种布局方式最早是 Delphi / C++ Builder 引入的，非常简单实用，后来被 C# Winform 原封不动的抄了过去，而 QtWidgets 里用了另一套规则，虽然用起来更精细了，却没有 anchor layout 这么简单直白。
虽然 QtQuick 和 QGraphicsItem 里面也支持 anchor 布局，不过原生的 QtWidgets 里并没有支持，所以我写了两行代码解决了这个问题，只需要在窗体的 resizeEvent() 里调用下 AnchorLayout 类的 update() 方法，就能将所有子控件中包含 “anchor” 属性的 geometry 全部按照 c# 规则更新：(点击 Read more 展开)
Read more…
本文来自知乎问题：MFC、WTL、WPF、wxWidgets、Qt、GTK 各有什么特点？
感觉我说了太多 Qt 的事情了，今天只说一下 MFC ，到底过时在哪里，都在说 “MFC 就是 xxx” 类似的话，我来补充点细节，增加点感性认识，到底 MFC 过时在哪里？想要用好 MFC 可以怎么办？
虽然 MFC 也有 DIALOG 的设计器，似乎可以拖一下控件，做个 hello world, 计算器之类的好像也很简单，但是稍微复杂那么一点就麻烦了，比如布局，MFC 里的控件只能设置绝对坐标和大小，那么如果你的窗口扩大或者缩小了，想自动改变内部特定控件的大小和位置怎么办？比如 C# 里随便设置一下各个控件的 docking 和 anchor 就能：
C# 里给控件设置 docking/anchor：窗口变大变小后就能自动调整控件的位置和大小
就能让某些控件随窗口变大而移动，某些控件随窗口变大而变大，而某些控件不变，这在任何 GUI 库里都是最基础的功能，都可以在设计器里点两下就做到的事情，MFC 却需要重载 WM_SIZE, WM_SIZING 消息来自己写代码每次手工计算所有控件的新坐标和大小，想写的通用点，还得上千行的代码，枚举所有子控件，根据额外信息重新计算位置大小，虽然 2015 的 MFC 里加了一个半成品的布局信息，但是基本没用，你在 MFC 的设计器里拖控件，都是写死坐标和大小的。（点击 Read more 展开）
Read more…
同一个动作重复 300 遍，肌肉就会有记忆，重复 600 遍，脊柱就会有记忆，学完五十音图不熟练，经常遗忘或者要好几秒才想得起来一个怎么办？没关系，我做了个命令行下的小游戏 KanaQuiz 来帮助你记忆：
usage python3 kanaquiz.py <operation>
operations:
python3 kanaquiz.py {-h} play hiragana only
python3 kanaquiz.py {-k} play katakana only
python3 kanaquiz.py {-a} play all kana quiz
python3 kanaquiz.py {-d} play dakuon quiz
python3 kanaquiz.py {-t} play trinity quiz
python3 kanaquiz.py {-l} list kanas with romaji
python3 kanaquiz.py {-o} list kanas only
python3 kanaquiz.py {-q} query performance history
首先使用 -l 参数来复习所有假名：
python3 kanaquiz.py -l
然后在终端中查看：
当你复习完了，可以用下面命令开始挑战：（点击 Read more 展开）
Read more…
Recent Comments