作者可以做到 篩選 這件事,是因為 Spring 有幾項優點 …
是啊!文件裏有寫…
框架應該要有個最小集合,而這個最小集合,最好可以基於開發者既有的技術背景,在略為重構(原型)應用程式,以使用此最小集合後,就能使應用程式運行起來,之後隨著對框架認識的越多,在判定框架中的特定功能是否適用,之後,再逐步重構應用程式能使用該功能。
目前沒有,倒是最近把《Servlet & JSP 教學手冊》改版並更名為《Servlet & JSP 技術手冊》,最後用上了 Spring 5,基本上就是我這篇文章的過程實現,把書裏一路用 Servlet/JSP 發展起來的應用程式範例,重構到可以用上 Spring MVC 的最小集合,然後注入元件、逐漸去除 Servlet API、抽出表單物件、改用 Thymeleaf、使用 JdbcTemplate、簡化 Java Mail 等…
能夠漸進式移植的話,目標比較明確,這樣瞭解 Spring 比較有意義,我個人是覺得,這些功能拆開來說明的話會很空虛。
姑且當成 Spring 技術手冊借殼還魂吧!…XD
它改寫自〈JavaScript 本質部份1〉。
除了將近十年前寫的東西更新之外,主要是做為一個實驗性的文件,目的是想試試,如果有機會拋棄一些包袱的話,在瀏覽器上寫 ES6、XMLHttpRequest Level 1 等,應該要做什麼樣的思考與設計!可以與〈JavaScript 本質部份〉中對應的文件對照看看,寫法有什麼不同。
有人的會問…瀏覽器的相容性嘞?嗯…都說是實驗性的文件了,〈ECMAScript 本質部份〉也不是用來取代〈JavaScript 本質部份〉文件的,後者還是會擺著,包袱重的話,就還是參考後者!
指定壓縮,去掉 jmod 裏不必要的文件、標頭檔或指令等,還可以更小一些。
docs.oracle.com/javase/9/tools/jlink.htm
之前 Sun 某個 Java 傳教士就曾在某個研討會投影片中靠北過了,反正他的大意就是「你們這些人總是覺得演化 Java 時這好哪好,其實才沒你們想的這麼簡單,我們要考慮的情況可多著嘞」…XD
JUnit 5 想當共主,搞了個所謂的 JUnit Platform!
單就測試框架來說,JUnit 5 中應該是指 JUnit Jupiter 這塊。
JUnit Vintage 底層跑的,應該還是 JUnit 4,只不過多了層 JUnit Platform Engine,然後 JUnit Platform Launcher 透過 Engine 來跑 JUnit 4。
簡單來說,JUnit 4 還是 JUnit 4,只不過 JUnit 5 透過 JUnit Vintage 知道怎麼跑它。
如果有人想,可以實作一個 TestNG 的 [TestEngine1],然後 JUnit Platform Launcher 也可以透過 Engine 來跑 TestNG 了,寫程式時照樣使用 TestNG 的 API。
只是說,如果我用 JUnit 4、TestNG 還是爽爽的,那就繼續用就好了啊?幹嘛中間還多個 JUnit Platform?如果不想使用 JUnit Jupiter 的話,確實就是如此,就架構看來,JUnit Platform 主要是對 IDE、plugin、build tools 有利,不用每個測試框架做一套自己的工具。
當然,真的看完 JUnit Jupiter 而產生了愛的話, JUnit Platform 還是可以當 Migration 過程的平台(從 JUnit 4 到 JUnit Jupiter,或者是從 TestNG 到 JUnit Jupiter?)
目前的理解是這樣…
龍麟有規則性、龍身是貝茲曲線、龍頭有對稱性…簡單來說,龍適合用程式來建模,其實可以更細緻,只是我想驗證一下想的對不對而已。
跟貝茲曲面或 Torus knot 之類的建模相比,龍算是簡單的,只是比較有噱頭…XD