我討厭 xml

這套真的感覺不錯耶

如果這樣賺翻的話表示會顧更多專職開發者? 應該會是好事？（然後其實是更多律師跟業務XD

金融業才不管什麼划不划算的咧…

後續 趨勢科技聲明:針對 Mac App 商店中趨勢科技 App 問題的回應1

解壓縮軟體去搜集瀏覽紀錄幹嘛？為了安全性目的？解壓縮軟體跟安全有個屁關係。是在工三小。

會嗎？以現在 Oracle 的計費方式，我猜很多公司會考慮 Azul 這種有上限的比較划算，或者本來有買 RedHat Linux 的公司就用 RedHat 上的 Java 了 XD

Indeed.

這個模式再 run 個三年就知道了。

結果… 是 Oracle 賺翻了

這哪叫犯低級錯誤

這叫明知故犯, 這是犯罪.

另外架 DB 去改 OS 參數是很常見的事，裝過 Oracle DB 就會知道。

寫程式十多年都沒有聽 DBA 提起過有這回事 ...

可能是我和 DBA 比較不熟吧 XD

P.S. 一般開發時用的 DB (測試區) 都是用預設值 ...

一般而言都不用動到，postgresql 舊版的預設參數都很保守，現在好多了。

另外架 DB 去改 OS 參數是很常見的事，裝過 Oracle DB 就會知道。

沒想到架個 DB 也需要改到 Kernel Parameters ...

不過應該是 PostgreSQL 有丟出相關錯誤訊息時才需要改吧？

是啊，沒有問題

你現在postgres時間用 timestamp with tz?

snake_case 是很美好的，但是我自個是不採用，我只用 camelCase。當然啦，這樣進資料庫後會變醜，但我比較希望:

Mobile Client/Web client -> REST JSON -> Model -> Database Table 這四個 layer 裡的欄位通通長的一樣，而不是在那轉來轉去的自找麻煩。

Android/Swift/Typescript/JSON/Kotlin 通通都是 CamelCase，除非你的 tool chain 裡有 ruby 或 python，不然建議不要浪費時間在這上面。

日期是指 literal 嗎？

不然 format 成什麼樣子有什麼差？不是都 prepare statement 代問號進去？

edit: 剛看完 mysql 那篇，best practice 是 uint。LOL，mysql 果然沒下限。

hm 看到他寫 ISO-8601，但最近習慣存進去就直接 utc timestamp int。

剛剛 qrtt1 提醒了我還有這篇 Facebook 在 MySQL 裡存時間的型態1

之前還有貼過文石 Note 的開箱文1 :p

10吋以上的電子墨水主要是文石跟Sony這兩家在出1

現在市面上還買得到 10 吋電子書嗎？ Kindle 出過一台就不出了，應該是賣不好，如果用平板是可以，只是就沒有電子紙的優勢...

對，可是沒辦法，市面上的大多程式書的可視面積都大於等於十吋。對於程式碼這種重排可讀性就完蛋的特性，必須要做出取捨。

可是 10 吋拿起來應該很重吧 XD

我自己有一台7.8吋的博閱，但說老實話看程式碼還是小了一點。10吋左右比較好。

7.8 吋的大小看電腦書籍應該蠻方便的，6 吋的 Kindle 程式碼範例都會摺行有點難讀...

最近不是有謠言說 Amazon Kindle 要來台灣嗎？期待！

如果只是想要買機器的話很簡單啊，找代買就搞定了 XD