(書籤) codegen

General code generator for Java

1. 7 Tips for Successful Code Generation in Java

Libraries for Generating Java Codes

1. JavaPoet
1. how do I create a field from a TypeSpec?
2. How can I add generic Parameter?
2. Byte Buddy

Libraries for Generating Maven

1. Is there a Java Class that generates a POM.xml file?

Swagger’s code generator

1. swagger-codegen
2. Comparison of Automatic API Code Generation Tools For Swagger

Amazon Beanstalk 的應用程式位置

隨筆紀錄，如果把 Java 程式部署到 Beanstalk 上
預設在 Beanstalk 的路徑會是 /var/app/current/application.jar。

透過 Gson 輸出 pretty print 的 JSON

當使用 Gson 來解析 JSON 格式時，如果需要讓輸出的 JSON 以 pretty print 格式輸出
可以利用簡單的小工具達成這個目的。

Gson gsonBuilder = new GsonBuilder().setPrettyPrinting().create();
gsonBuilder.toJson(....);

不過 Gson 的這個工具，預設會自動做 HTML 跳脫，因此特殊符號都會自動被置換成 Unicode 表示形式
如果想要關掉 HTML 跳脫，可以使用 .disableHtmlEscaping() 方法。

Gson gsonBuilder = new GsonBuilder().setPrettyPrinting().disableHtmlEscaping().create();
gsonBuilder.toJson(....);

對 Jersey 製作的 RESTful API 做單元測試（二）：啟用 Servlet

Jersey 中使用 Jersey Test Framework 做測試時
如果遇到需要使用 Servlet 的狀況，例如使用了 @Context HttpServletRequest request
可能就會注意到，HttpServletRequest 這類應該要自動被注入的東西，在測試時都沒有被注入
因此會發生像是 NullPointerException 等等的錯誤。

在 Java 中解析、表達與計算日期時間（二）：JSR-310 概述

原本在 Java 7 和更之前的版本中，因為 Java 原生並沒有好的時間類別
因此比較合適的方式是使用 Joda-Time 這個套件，用來表示日期與時間。
不過在 Java 8 當中釋出了 JSR-310，也就是 java.time 套件之後，狀況就不同了
Joda-Time 官方網站中也說明了，如果使用 Java 8 以上版本，應轉移至 JSR-310。

Joda-Time is the de facto standard date and time library for Java prior to Java SE 8. Users are now asked to migrate to java.time (JSR-310).

在 Java 中解析、表達與計算日期時間（一）：時間系統與曆法

對大多數人（包括我）來說，大概都不會覺得日期時間有什麼特別的
在參加之前的 Java TWO 以前，其實我也沒有認真看待過這個東西，一直到在 Java TWO 上聽到良葛格談到這個議題
才知道～其實背後隱藏了許多魔鬼，導致這個議題事實上是個相當複雜的問題。

在開始研究如何正確地寫日期與時間相關的程式之前，先了解一下何謂時間、以及時間和曆法的關係為何。

使用 JAX-RS 2 做 HTTP Response 的壓縮

因為前陣子看了一些 RESTful API 的最佳實例（連結可以參考這裡）
裡面有提到好的 RESTful API 應該要支援 GZIP 壓縮，對伺服器端或者客戶端都有好處
因此開始在實作 RESTful API 時，就搜尋了一下，Jersey 上應該如何正確地支援 GZIP 壓縮。

對於「正確地支援 GZIP 壓縮」這個問題，當然最簡單的作法，就是每個 RESTful API 都各自把輸出的東西都呼叫 GZIP 壓縮
然後把壓縮好的結果丟去 Response，並且適當地加上 HTTP Header 即可。
但我覺得這種作法應該不是最好的作法，應該有更好的方式可以讓 Jersey 自動幫每個 Response 都做好這些事。
在 Jersey 上，這件事情最適合的方式就是透過 Interceptors 來實作了。

對 Jersey 製作的 RESTful API 做單元測試（一）

在比較完整的專案中，一般都會至少要包含自動化的單元測試
不過 Application 還好，如果是 RESTful API 的話，應該要怎麼測試呢？

原先我自己的想法是使用 JUnit，然後可能是使用內嵌式的 Jetty
讓測試程式執行時，自動打開一台本地端的 Jetty、把專案佈署上去後開始執行測試。
但既有找到的方法（例如 [1]） 感覺整合性都不太高…。
最後想說，也許其實有更簡易的方式，於是變更了關鍵字之後，發現…真的有 XD。
Jersey 原來本身就有涵蓋了對應的測試架構了。

叢集環境的 logging（三）：以 JSON 格式輸出 log

在把叢集中的每個 Application 的 log 都集中起來以後，下一個遇到的問題就是如何分析？
收集起來的 log 數量通常不小，而且各個不同節點的 log 全混在一起
要如何有效率一點地解析他們呢？

實務上，比較容易想像的方式大概就是把 log 導到某個能夠做 log 分析的系統上
例如 ELK 架構（Elasticsearch + Logstash + Kibana）。
不過要讓 Logstash 能夠簡單地把集中起來的 log 全部帶走，最好還是能讓 log 都以 JSON 格式輸出
這樣在 Logstash 那邊寫設定檔時，會比較簡單。

叢集環境的 logging（二）：辨識集中化 log 的來源

在前篇文章中，利用了 logback 的 SocketAppender 和 Receiver 功能，將不同來源的 logs 集中到一個地方
但在沒有特別設計的情況下，其實我們通常會分不出來哪個 log 來自哪裡。
不過這個問題在 logback 裡已經被考慮過了，可以利用 Mapped Diagnostic Context [1-2] 來實現。