CloudFlare 在台灣有機房,代表從台灣出去海外的頻寬瞬間 "空" 了一大塊。
就算你的服務沒用到 CloudFlare,也會因為頻寬空出來,你放在海外的站在台灣用起來也會快了一點。
各站長們想省錢,所以利用一些網路上免費服務來幫忙,這很正常。不過不要認為這種事是理所當然啦。
想免費… 是可行的,但就是做好心理準備隨時被別人趕就是了。不管你下次換到哪家免費的水管,大概兩三年就得再換一次,這工夫是跑不掉的。
等價交換啊!就算是免費還是有代價的。真的想省力就是自己花錢租主機吧。
裝新東西都要做一堆評估和測試… 所以我習慣一口氣升一堆,然後實測就只要做一次就好了。
每個軟體和 library 都有各自的升級週期,每個都細細的追太累了,沒這種美國時間。
話說回來,還沒看到 16.04 升級的懶人包… 就是升級後有多少東西會壞掉之類的報告 ( upstart 有改版嗎?新的 kernal 參數哪些 sysctrl 裡面已經不能設了?python2 的相容性如何?…
當然不可能。
不是因為 swift 不好或是它與 jvm 不合。
Google 現在要選新語言就是要選沒法律負擔的,它能完全掌握的。
選 Swift ?哪天再上演一次 oracle 拿 Java API 告嗎?Google 再怎麼做決定也不會犯同樣的錯誤了。
當然 Google 是很大的,有可能有一小撮 googler 起了個專案,讓 swift 在 android 上開發成真,但是要變成 first-class 語言就別傻了。
Swift on Android 比 Bash on Windows 還唬爛。
自己架重點是 proxy 啊! proxy 超快啊 (就慢第一次而已),而且可以保護外部 repository 爛掉,因為除了 maven central 外,其他 repo reliability 都沒有很好,即使像是大廠 spring, scala… 等
Java concurrent framework 是魔人 Doug Lea 設計的,是世界上少數真的了解 concurrency 的人物。
Java 提供 high level 的工具 (executor, actor, fiber...etc) ,也有提供高效能的 data structure (ConcurrentHashMap... etc),最後再進一步還有 Semaphore、ReentrantReadWriteLock 等等 primitive 元件。高階、低階的需求都能完全的滿足,沒有更好的平台了
Google 使用的 front end
- Gmail -- Closure compiler
- Google Analytics -- 看不出來,可能跟 Gmail 一樣
- Google Inbox -- GWT
- Adsense -- GWT
- Google Cloud Engine dashboard -- Angular
而現在新版的 AdWords 轉到 Dart 去了。Google 的技術是多頭馬車…