『汇总』兑现一些和园友的承诺
写在前面的话
2020-05-18 日，对博客园某园友 许下一个承诺：
文章：《『开源』50行代码 扒取 博客园文章》 85楼评论
承诺：
@前方一片光明
心往哪里想，哪里就会有亮光；心往哪里思，哪里就会有奇迹；心往哪里移，哪里就会有新意；心往哪里放，哪里就会有力量。【暖心良言】
虽然你是 机器人 的 评论 —— 但还是很感谢你。
这段时间 很忙，很少来圆子了，主要是 不想和太多人接触（孤独其实 也挺好，不会看到那些 闹心、丧气的言论，自己的心态 就能稳定得很好。）
—— 等我把 事情做完，我就回 圆子 放大招。
今天就以这个承诺打头，将 这几年在 博客园许下的承诺 尽可能多兑现几个，该开源的 一定会开源。
开源 Tcp.cs 文件，一套 Tcp 通讯代码，容错、多通道、 Any CPU 、.Net 2.0+
承诺起源：《『开源』Slithice 2013 服务器集群 设计和源码》 第31楼 wyd1520 大佬的评论
大佬的评论太长，简要概括就是：指出了我的 Socket 基础不扎实，需要提高。
于是，在接受这个批评之后，这些年 自己写过两个Socket框架， Laura.Comm 框架 > InkFx.Comm 框架
多年以后，返璞归真，大道至简，直接压缩成了 Tcp.cs 文件，一个文件打天下，接口函数 兼容 WebSocket 定义，不用引用额外的程序集。
开源 InkFx.OpenXml 框架，基于 OpenXml 技术，实现对 Word文档、Excel文档 的 读写操作 、Any CPU 、.Net 4.0+
承诺起源：《『开源』Slithice 2013 服务器集群 设计和源码》 第35楼 longware 大佬的评论
评论内容： 大婶， InkFx.Office2007 啥时候出来呢
项目背景：
2014年，在上海某公司任职时，有个 生成 Word文档的 报表需求。
当时，参考了一下 同事操作Word的操作，同事使用的是COM组件....
基于 COM组件的 Word操作，在Word文档中 输出一行文本 都得 几十行代码。
而项目要求的报表：最终 图片、文本、表格 加起来就有 80多个 —— 如果使用 COM组件，这代码量、后期维护成本 简直要炸天。
所以，当时用了三天时间 研究透了 OpenXml 格式，基于 DocumentFormat.OpenXml.dll 封装了一套 OpenXml 的调用。
—— 最终的项目结果：替换 Word中的图片、文本、表格 通通只需要 一行代码【一个好的封装 对开发、维护 都有大用】
之后，鉴于 公司项目 使用的 Word操作不多，为了 兼容市面上的 通用需求，于是完成了下面的功能：
> Word 文档：图片、表格（支持自定义渐变色）、文本、字体、标题、大纲、样式克隆 、内嵌附件（失败）等操作
> Excel文档：海量数据（10W行+）读写、坐标定位读取、自定义表格样式
—— 本想商用，想想算了，今天就直接开源了。
开源 Task.cs 文件，兼容 .Net 4.5 的 Task 定义，实现多线程操作，Any CPU、.Net 2.0+
承诺起源：《『审慎』.Net4.6 Task 异步函数 比 同步函数 慢5倍 踩坑经历》 第16楼评论
评论内容：
其实，全文代码也就150行。
150行代码就能复现一个BUG，却没人愿意去运行代码，帮我查错。
反而，大道理讲得头头是道的，却没有一个说到点子上。
当然，当我被某楼层的评论恶心到了之后，我愣是用五个小时，自己实现了自己的Task类，函数定义用的还是微软.Net的定义。
基于自己的Task类，我将GitHub上，好几个异步项目无缝降级到了 .Net 2.0 —— 运行稳定，这就更有意思了。
项目背景：
2015年，在上海公司实际项目中，需要使用 多线程并发执行，数据全部处理完成后，执行数据汇总。
当时，自己就已经封装过一个 ThreadQueue（线程队列），已经实现了 多线程的协同。
2018年 的这篇踩坑文章，被评论区一通臭骂，把我给气到了 —— 然后就有了 Task.cs 类。
基于 Task.cs 类，几乎可以 无缝装 .Net 4.5+ 中的 Task 完全替换掉，实现 .Net 降级
实际项目 中，总会遇到 WinXp 这类客户，低版本的 .Net 反而可以让项目的部署 简单方便、路走宽点
Redis 基于 TCP/IP 通讯 —— 我的电脑配置差，TCP 通讯 CPU跑满 也才 5000次/秒。
目测 Redis 或者 TCP 的 实际性能 可能和 CPU性能 直接相关。
另外，在众多的 Redis 库中 来回穿插 —— 我已经厌烦了。
于是，我直接找到了 Redis 协议的 官方文档 —— 我已经 用 2000 行代码，花了两天 自己写了一个 Redis 库【从此，一个 代码文件 解决问题，省的 引用一堆库。】【最重要的是：以后的代码快速移植 也在自己的 掌控之内】。
近来很忙，今天偶然回来一下。过段时间 再回圆子 放大招 （此次的 Redis 库 也会以 小角色 开源）
项目背景：
Tcp 通讯已经娴熟之后，在实际项目中被 Redis 三方库呛到了，于是自己查询 Redis 官方文档，了解其 字节协议，自己实现了自己的 Reids库。
这里有必要提一下：Redis的字节协议 设计得挺巧妙的，但也决定了 Redis 不支持 乱序响应（所以会导致 部分阻塞 和 性能损失）
所以 Redis.cs 中，加入了一个 RedisProxy 类，实现 多通道 并发。
开源 一键混淆.Net 程序集 工具（保护知识产权）
承诺起源：
2019年底时，私下和 博客园的 AYUI 大神聊天，询问了一下 AYUI-WPF控件库 的商用盈利情况
后来才得知，AY大神 早早的将源码开源了，靠每次的 咨询费盈利，突然有点五味杂陈 —— 不知道 开源 是好是坏。
2020年初时，的一篇 博文《开源项目在闲鱼、b 站上被倒卖？这是什么骚操作？》 （我的评论在80楼）
我只是得出了 这个结论：在你的项目还没有任何知名度时，强行开源只能是替他人做嫁。
一些通用技术、底层算法，开源 可以让 程序员群体 共同进步；
一个完整项目，一个可以解决实际商业需求的项目，你没有知名度，强行开源。很容易被人利用，别人抢你的专利，注册你的代码，走你的路，让你无路可走，甚至反客为主 让你成为被告 —— 这就很尴尬了。
一旦 对薄公堂，你一点知名度都没有，程序圈子里面的网友 都不知道 孰是孰非，都 没法替你战队。
当然，人各有志，坚持开源的同学 肯定是优秀的 —— 当然，我这段话 可能也有错误的地方，希望观点相左的同学 嘴下留情，轻喷。
或许，有个案例可以参考吧：大名鼎鼎的报表框架 FastReport，至少 15年的知名度了，但 FastReport 2017 版的程序集，代码依然是混淆过的；当然， FastReport 2018 版的程序集代码，却没有混淆了。
暂不开源 InkFx.WinControl 一套 UI控件库，WinForms、Any CPU、.Net 2.0+
承诺起源：2014年 在园子放过几次大招后，上过几次头条，有一位 南京的网友，私底下联系我，建议我写一套 UI控件库
项目过程：
开始的时候，觉得UI重绘挺有意思的，但后来就卡住了。
一卡就是 一年多，8点下班，9点到家，每天2小时 都没能攻下 一个难点。
这个难点就是 滚动条的 重绘 —— 事实上，很多 WinForms 重绘大神，几乎都卡死在了这里。
有人会问：一个区区滚动条，有啥难的？
这个答案，只有 卡死在这里的大神们 才知道：WinForms 的滚动条分 3种：纯滚动条（这个简单）、内嵌滚动条（反射替换就行）、无句柄滚动条（几乎都卡死在这里）
滚动条难关攻下后，剩下的 控件就不过如此了。
控件的编写其实不难，但就是比较磨人，有时候 一两个像素 就能把人磨半天。
2020年，在家闭关，算是将这个控件库 完成了 —— 不喜欢 半途而废，不完成总觉得心里 咯得慌。
其他的东西，如果园友需要，我这边也不准备商用的话，我也就顺手开源了
这段对话和工作相关，和我聊天的是我的一个 学弟。
.Net 这条路到底能走多远
> 村里 有几个好有是我带出来的，走的 .Net，在杭州、上海 工资也挺高的（比我高多了）。
> 当初上学时，老师建议学 Java，结果我顶着Java第一的成绩选择了C#，起到了一点示范效应，好多 学弟、学妹 跟进。
> 我挺怕的：我怕以后 .Net 这条路 不好走时，他们会迁怒于我，责备是我将他们带跑了偏。
让人焦虑的 35岁危机
> 我们村有矿，遗憾的是 我老爹 没能成为 铁饭碗的工人（“工人身份”，矿里包你生老病死），只能兜兜转转 各种折腾。
> 35岁前，我老爹都是打零工、瓦匠、木匠，37岁时我老爹开始养鱼，40岁时我老爹开始承包种地，50岁时 开始养猪。
> 今时今日，我老爹比我有厉害，一年赚的钱比我在职场还多 —— 果然，还是得折腾。
> 按理说，35岁是一个人 最年富力强的年纪，结果在 程序圈子 却成了 焦虑的一道坎 —— 不知道是谁贩卖的焦虑，我其实也挺怕的。
> 我能做的，或许只是 不断的学习，不断的折腾，艺多不压身，总会有 派上用场的时候吧。
> 争取在 35岁前，把房贷提前还清；35岁后，哪怕是 送外卖、回老家种地（这是我保留农村户口的原因） 至少饿不死吧。
> 翻看 智联、BOSS直聘 会发现：大部分工作 其实都没啥含金量，大部分都是 一周上手，然后每天重复 —— 或许，社会上的大部分工作 都是如此吧。
> 在博客园曾经看到大佬评论：多结交 广阔的人脉资源，真正能施展才华的工作 往往都是 人脉推荐的。
程序员的人际交往
> 就像 2013年的那篇文章说的：“我可能更多的是希望能多和人打交道，而不是程序；我不希望在程序的世界中，变得 不谙人情、不食烟火”。
> 很多人不喜欢出差，但我其实感觉还好：“就当是公费旅游咯”
> 每次到 客户城市，每晚我都会去 所在城市的夜市转转，找路人聊聊天。
> 跟客户打交道的过程，其实就更有意思了：很多时候你能了解到 更多有意思的故事（项目背后的故事远比项目本身更有意思，了解了这些背景故事后，你甚至能推断出 那些客户会阻挠你，哪些客户会配合你）。
> 当客户 指着你的鼻子 大骂：“你们公司项目好垃圾” 时，才是 真正能得到 宝贵意见的时候。我就假装很谦逊的听取意见 “是的，是的，这个确实是我们的问题”，“这个我们一定调整”，心里其实都笑开了花（反正骂的又不是我写的模块） —— 有些客户骂完了、舒服了，项目反而推进的更快了。
> 其实，程序员都是很单纯的生物，不太喜欢人情世故。
> 但在客户现场，了解公司的代码是如何工作的 可以加深对公司业务的了解；多听听客户现场的故事 那就更有意思了；
> 当然，与项目本身无关的故事，你要让别人自己说（很多人压力大的时候，会不自觉的找身边利益无关的人吐槽，吐槽完了就舒服了）。当然，不要目的性太强的追着问，别人会反感堤防的。
我似乎不太会做选择题
> 就像 年轻时候，顶着Java第一的成绩 选择 C#，结果 搞Java的同学 混的更好（哪怕同样是没有 含金量的工作）。
> 2017年 在武汉，本想利用每天 2小时，开始写自己的 图像识别 这类高层算法的。
> 2018年 开始，才发现 底层技术 也挺重要的；于是开始转战 底层 —— 上面的控件库 只是其中之一（后期会将其 跨平台，在写代码时就已经 为跨平台 在做准备）。
> 大环境如果垮了，每个人都会是 牺牲品 —— 对每一个 开发者而言：让自己的路 越走越宽，首先受益的是自己，其次受益的是社会 （所以，写下每一行代码时 尽量多思考这段代码的 移植性、兼容性，别把自己的路走死了）。
最后，我和各位 C# 开发者其实是同路人
我一直在 微软为我们制定的道路 和 我自己的道路 上，反复横跳。
我曾经在 园子 某篇文章下，写过这样一条评论：“我磁盘上的几十万行C#代码，是我的个人财产，我要带走。” —— 这是我最重的一个承诺。
为了兑现这个承诺，我的 C# 编译器 + SDK底层，已经在进行中 —— 我要用自己的方式，实现 C#语法的跨平台、跨CPU。
这条路有点难走，但没关系 —— 失败了，算我的；成功了，算所有人的；
所有 C#、Java、Js 开发者，都是可以团结的人 —— 我们都是同路人。
小INK
2021-04-13 06:30
