寫在前面的話
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年，在家閉關，算是將這個控件庫 完成了 —— 不喜歡 半途而廢，不完成總覺得心裏 咯得慌。
其他的東西，如果園友需要，我這邊也不準備商用的話，我也就順手開源了
寫在最後的話
其實，今天回園子，主要是 2021-03-24 有個學弟，聯繫到我，說我8年前的文章 被推薦了。
我當時就驚呆了，差點覺得，是不是 園子 讓他來給我帶話的，後來發現是我想多了。
推薦給他的文章是 《『感想』這幾年的編程》 2013-03-12
這段對話和工作相關，和我聊天的是我的一個 學弟。
.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