發布於 

指正《【社群恩仇錄】byStarTW/instanceof/pan93412》一文中的斷章取義或錯誤描述

https://blog.init.engineer/posts/BlockedPan93412/

這篇文章僅為行使本人 (Pan93412) 之媒體答辯權。

關於訊息的可靠性問題

乾太在未經告知的情況下強行清空我與他的所有通聯紀錄。有鑒於原始訊息證據消失,原文之所有引用皆有杜撰或改寫之可能。即便如此,我仍嘗試推斷原 Context 並給予我這端的解釋。

被乾太清空的聊天記錄

原文論點的我方看法

怎麼不用 Memcached / MariaDB 還有 Redis,不用 docker-compose 或 k8s 感覺很累

這個訊息的內容斷片嚴重,個人認為可能有被斷章取義。這訊息最可能的出處是我詢問乾太有沒有考慮用 Docker 部屬周邊服務,因為手動配置 Redis 跟 MariaDB 的易便性,的確不及直接 docker-compose 部署方便。但這僅為建議 (feature request),我未批評原做法不好。

「不考慮換成 PostageSQL 嗎?聽說效能好一點」

欸?等等,前一句你不是說怎麼不用 MariaDB 嗎?怎麼下一秒問怎麼不考慮換成 PostageSQL 了?

算了,繼續看其他的好了。

不要用斷章取義的訊息推斷訊息情境。本訊息出處已不可考,但或許也是作為一個 feature request 提出。由於 Laravel 的 Eloquent ORM 本來就可以自行切換成喜歡的資料庫後端,這純粹就是提供一個遵循 SQL 標準,在普通情境有更加效能的資料庫系統建議。

你現在的開發模式大概跟 jQuery + Notepad++ 那時代差不多

你們是不是都很喜歡把 IDE 當 VI 寫

這裡的 context,是我發現到乾太在 Blade 範本,利用手動輸入元件路徑的方式取用 Vue 元件,完全不考慮讓 IDE 管理元件的名稱。這部分確實是個調侃,因為無論是現代前端或是後端,都盡可能希望仰賴 IDE 的 auto-completion 而非自己手打,而我又是寫 TypeScript 出身的,本來就會對這塊尤其留意。

縱觀包括這一則訊息的原始 context,我確實站在現代前端工程師的立場,批評了 init.engineer 目前前端開發模式的不足,而乾太也在之中,承認他並不是很了解前端開發的生態。我和乾太畢竟開發的領域和習慣大相徑庭,因此誤會與衝突個人認為是難免的。若乾太認為這種調侃使其不適,我在此遞上十足的歉意。

既然 Blade 可以做 Component,為什麼又需要一個 Vue?

問這問題的當下,我並不了解純靠北工程師的 codebase。因此當我讀到 Blade + Vue 的混合程式碼時,就向乾太詢問了這個混合的必要性。畢竟能用一個渲染模板完成的事情,我們為何要拆成兩個?

因為 Laravel 目錄架構與 Vue 習慣的開發模式不同,我問這句的另一個目的也是為了要把 Vue deprecate 掉。這樣我也比較可以不用為了維護 Vue 元件的名稱而操心。

無論是裝了 Laravel 的 JetBrains PHPStorm,還是裝了一堆 Laravel Plugins 的 VS Code,兩個都看不到這個函數的定義

我畢竟剛入門 PHP/Laravel 開發,因此當我發現乾太可以 auto-complete,而我不行的時候,我就向乾太請教設定 Laravel 相關的事宜。這純粹是一個普通,有些新手級的問題,但乾太的斷章取義,似乎讓整個情境變得像是我在指責 Laravel——我並沒有這個意思。

老實說,我不是很喜歡這個 Codebase 的前端擺放方式,所以我其實得承認,我有點在找碴

這個訊息的情境是這樣的:我原本想要自己開一個 repo,用自己熟悉的架構,獨立寫 init.engineer 的 Front-end。後端 API 的部分,我當時也有積極幫乾太尋找能開發純靠北 API 的夥伴。所以我的確有自己的解決方案,但乾太否決了這個建議,要求我寫在原來的 codebase。既然如此,我就像乾太提出了目前 codebase 開發前端的不足。不過我也得承認:在指出問題的過程中,我欠缺換位思考。在此再向乾太致上十足歉意。

原文中質疑我不滿 Laravel 的部分

見上,畢竟我原本是想要自己獨立一個 repo 寫前端的。啟動 Laravel 很快樂,但用 Laravel 的架構寫前端就不快樂了⋯⋯除此之外,乾太將我後來用 Laravel 正式貢獻前端的紀錄完全忽略了,實際上我後來花了幾週的時間,學習 init.engineer 的全端開發方式,並貢獻了乾太所期望的首頁 Milestone。詳情可以見 init-engineer/init.engineer PR#88

完整貢獻紀錄

當你把項目下放給這個人後,他雖然會嘗試接觸項目相關的技術,但是整個過程會有許多負面情緒、抱怨,甚至是質疑項目技術。

我承認。

如果對於項目技術不熟悉,會質疑項目是否過時了、難以開發,甚至會有「你現在的開發模式大概跟 jQuery + Notepad++ 那時代差不多」諸如此類的言論,反而不是嘗試去了解相關技術。

與上面的 他雖然會嘗試接觸項目相關的技術 相斥。

本部落格所有文章除特別聲明外,均採用 CC BY-NC-ND 4.0 許可協議。轉載請註明來自 我不會寫程式!

ND 部分我只能確保我想反駁的論點完全取自原文。BY 和 NC 皆已遵循。

專案始末

有鑒於還沒有人想知道這方面的事情,我先擱置不寫。

「其他人的想法」又是怎麼一回事?

  • haer0248 的回應:我完全承認本文內容我所有的疏失。在此誠摯向阿任道歉。
  • Telegram - 靠北 byStarTW (pan93412):我和幾位朋友都找不出後期訊息中明顯的靠北/錯誤點。或許對方是我的粉絲,所以才這麼鍥而不捨地收藏我的語錄?

本網誌所有文章除特別聲明外,均採用 CC BY-NC-SA 4.0 授權條款。轉載請註明出處。

本站由 @pan93412 建立,使用 Stellar 作為主題。