CodeTengu Weekly 會在 GMT+8 時區的每個禮拜一早上 10:00 出刊,每一期會從目前的 curator 名單中選出三位來負責當期的內容,每一位 curator 各自負責不同的領域,如果你在這一期沒有看到自已感興趣的東西,說不定下一期就會有了。
你也可以瀏覽一下前幾期的內容,有價值的東西是不會過時的。
以下是目前的 curator 陣容:
大家也可以 follow 一下 CodeTengu 的Facebook、Twitter 或GitHub,有很多 Weekly 看不到的內容。有任何建議或疑問也可以來Gitter 聊一聊,歡迎亂入 :japanese_goblin:
致力於解決開發者之間的資訊不對稱
作者整理了 23 種生產力促進方法,其中有一些讓我感到興奮:
生產力這件事我一路走來試過用wakatime 來記錄我寫 code 的時間、蕃茄鐘工作法、便條紙 tasks 工作法,甚至試過SelfControl 斷網大法 ..
目前還持續中的是跟別人說「我什麼時候會把什麼東西做完」羞恥心導向工作法及每日的工作排程,覺得應該試一下這篇文章有提到,@tzangms 好像也一直都這樣做的把自己所有的事情 (包含休息、娛樂) 都排程的方法。
medium.com
在 iOS 開發上 UIViewController 的重要性是不言可諭的,重要到甚至我們偶爾會被 UIViewController 給牽制,變成所謂的 UIViewController oriented programming。而作者根據 Patterns of Enterprise Application Architecture 中的 Application Controller 提出了 iOS 版本的 Coordinator。
我感覺像是MVP 的 Presenter + navigation flow,引入 Coordinator 之後會弱化 UIViewController 本來的責任,不再自己決定下一個 UIViewController 以及要怎麼導向、只能讀資料不能新增修改資料 (無論是 client 或 remote)。
Coordinator 這個概念特別適合不只是顯示從 API 拿到的資料自己也有能力做一些加工修改的 app。
khanlou.com
這篇文是寫給那些已經瞭解 iOS 並想跨足到 Android 的開發者。而我的經驗是,掌握了 iOS 或 Android 其中一個平台,要跨足雙棲其實是很簡單的事情,行動裝置的開發概念上當然是相似的,差異的就是實作上的細節,當然啦,可以開發只是最基本的,要在第二個平台成為好的開發者你還得像對第一個平台的態度一樣,對該程式語言有更深入的研究、對該平台的適當體驗有追求才行。
作者整理了語言關鍵字跟平台元件平行宇宙對應的參考表、適應螢幕尺寸的異同處、到底要用哪個 Android SDK 版本。
savvyapps.com
作者身為一個 Android 開發者對這個社群及 Google 做出血淚控訴,他認為 Android 開發歷經七年了社群的開發質量仍然沒有顯著的成長,多數的 Android 專案沒有做測試、一大堆警告、一堆義大利麵式碼 (但他沒有提出數據),並且作者認為 Google 是始作俑者。
他認為一個有品質的 Android app 要有版本控制、透過 Pull Request 做 code review、整合CI、不寫義大利麵式碼、做靜態分析、做單元測試、UI 測試、整合測試、使用開發期輔助工具。
不只是空口說白話,他舉出 Jake Wharton 的U2020 跟他自己維護的qualitymatters app 是大家可以參考的起點。
這讓我想到Joel Test 喬爾測試,每個開發者都應該盡力讓自己工作的環境跟專案變得更好,這樣對大家都是好事,在 What Makes Developers Happy? 裡有數據顯示,在符合 Joel Test 的環境下工作會讓開發者更快樂。
artemzin.com這篇是 Android Development Patterns 系列文章,我覺得這系列都很棒!
Android 提供的Loader 可以很好地跟 Activity 及 Fragment 整合,當 Loader 綁定的 Activity 或 Fragment 被 destroyed 時它也會自動被結束,因此把關於 data 的處理放到 Loader 除了更有組織之外,你也不會因為螢幕旋轉遺失你處理中的 data。
這篇文章提供了好幾個使用範例,不管你有沒有用過 Loader 都可以看一下,質量蠻高的。
medium.com
提到 Erlang 界名人,最能聯想到的便是Joe Armstrong 先生,而這篇博士論文便是他藉由論述如何處理軟體錯誤,來揭櫫 Erlang 語言的設計與特性,可說是從觀念到語法操作、一步步帶您認識容錯軟體設計與 Erlang 語言的現成教本。
段先德先生曾將這大作譯為簡體中文版《面对软件错误构建可靠的分布式系统》,原始連結已失效,但大家搜尋一下還是可以載到它站的拷貝。無論是英文原版還是中文譯版,我都誠心推薦關心軟體架構設計、特別是 microservices 的您花時間啃一啃。
erlang.org
初見 Elixir,寫 Ruby 的開發者或許會覺得「有點像 Ruby,可是更多地方又毋寧說是披著 Ruby 皮的 Erlang」,若對 Erlang 的設計哲學沒有基本認知,恐怕光是憑著 Ruby 的經驗來學、寫 Elixir,很多地方會混淆、丈二金剛摸不著頭腦。(延伸閱讀:Elixir is not Ruby)
我個人的 Elixir 入門途徑,是先讀過上述的《面对软件错误构建可靠的分布式系统》與蔡學鏞先生譯著《Erlang 程式設計》,先瞭解 Erlang 的核心精神後,再來看Programming Elixir 這本書。而最近發現 Elixir School 這份線上教材編得蠻不錯的,與 Programming Elixir 的豐富程度不相上下,您可以試試用這份教材自學 Elixir。
elixirschool.com雖然 Erlang 與 Elixir 幾近無副作用、獨立 process 的特性設計,使得 concurrency, scale-out 實作相對簡單,但效能並不會憑空而來,不能單純以為換了一種語言就能讓您從殺豬公瞬間上太空,以為「一台不夠力,我就開十台去扛」若遇到別人調校得宜,也許兩台就能打你十個,多開一台可能還只是為了容錯備援,如此豈不是很不堪嗎?
除了 kernel 的 sysctl
調校基本功,Erlang VM (BEAM) 本身也像 JVM 一樣有些參數 (Emulator Flags) 可以微調其行為模式,可以在 vm.args
檔案裡指定。具體的例子可以參考Riak、Erlang MQTT Broker……等各種已經發展了經年累月的 Erlang 專案文件資源。
erlang.org
前陣子在公司研究 ChatOps 解決方案時,看到Cog 這個很有趣的專案。沒想到從 GitHub clone 下來後,發現竟是使用Phoenix 寫的,頓時覺得倍感親切,同時也立即明白它 pipeline 的命令串接設計是其來有自,乃出於 Elixir & Unix 的設計思維。
即使工作中沒有碰到 ChatOps,把這個專案複製下來觀摩、學習 Elixir & Phoenix 也是不錯的材料。
operable.io
應該不少人知道 CPython 的 function 與 method calls 效能不太好。問題的根本原因是CPython 實作用一個 dict
放這些東西——和你平常用的那個一模一樣。這個實作讓 Python 非常動態,可以在 runtime 隨時增加、覆寫、甚至 刪除 任何 members,但也讓直譯器無法預測一個 instance 在 runtime 是否有某個 property,也無法知道 property 指向的東西是否改變。
Python core developers 過去也嘗試過優化,但因為(應該是 Guido 任性)希望保留 .__dict__
回傳普通的 dict
,最後都沒有成功。這次由 Yury Selivanov 提出的解決方案比較不同。他假設使用者不會在 runtime 頻繁進行 monkey-patching(畢竟這本來就不是好 practice),在 dict
中加上一個於 insert 與 update 時增加的 version number。這代表原本的 dict
功能只會多一個 CPU 指令,影響可以忽略,但在絕大多數狀況保證 cache hit。這個優化基於 Victor StinnerPEP 509,並衍生出一系列類似的優化,預計可以改善 Python 3.6 程式 5–10% 效能,且幾乎不會有負面影響。
另外,如果我沒記錯,這個想法也和微軟基於 .NET runtime 的新 Python JIT 實作Pyjion 相關。這個專案也頗有趣,未來或許可以再介紹。
python.orgJacques de Hooge 創造的Transcrypt 是個 Python 3 to JavaScript transpolar。最近嘗試在瀏覽器裡跑 Python 的專案其實很多,最潮的應該是後面有 Mozilla裡面的人撐腰的PyPy.js。不過我覺得這個專案有趣的點是,它不是在瀏覽器裡跑一個 Python interpreter,而是有點類似 CoffeeScript 的位置,讓你用 Python 語法寫 JavaScript。我附的連結是主要作者在Podcast.__init__ 的訪問,裡面提到不少很特別的 design choices,值得一聽。另外他對於怎麼維護專案 community 的看法也十分有趣。
podcastinit.comNBA 2K 系列的製作總監 Mike Wang 說 Stephen Curry 在現實生活的表現過於離奇,遊戲難以呈現。我從小牛拿冠軍之後就不看 NBA 了,2K 系列也幾乎沒玩,但你知道男生總是有幾個每天用運動影片洗你 Facebook timeline 的朋友,所以還是感覺這個消息頗有趣。
我是在想,這類軟體在本質上就是不斷 reverse engineering 自然定律,聽說近幾代的 2K 系列擬真評價都很好,感覺好像真的找到規律了。然後就出了一個反例,把我們自以為走對路的公式掃進垃圾桶。前陣子 AlphaGo 也有這種感覺不是嗎,感覺我們好像成功接近人腦的抽象邏輯概念了,但仔細一看又發現根本不是那麼一回事。究竟電腦的終極目標是要像科幻小說那樣往人腦接近,還是應該另闢蹊徑呢,這種有點 meta 的題目好像也很適合拿來當思考練習。
forbes.com
作者推薦大家在每個專案中都包含一個 decision making file,紀錄專案中決定事情的原因、其他方案、以及風險。MacDown 也接近兩週年了,想起無數次在 GitHub Issues 中解釋為什麼我不做 tab support、為什麼沒有 tree sidebar、為什麼不支援 Evernote 整合等等,看到這篇文章打從心底覺得是個好主意。
其實專案做到一定程度,好像就會開始發明類似的解決方案,工作的時候也會用各種方案整理文件啊 spec 啊討論紀錄等等。但做組織性比較弱的開源專案時,就比較容易忽略這些東西。最近很多專案流行enhancement proposal,或者有些組織會寫 dev blog,也是類似的概念。但有些專案用這些方案反而浪費時間(我之前也想過寫 blog,但很懶⋯⋯),值得考慮這個解法。
akazlou.com吉元ますめ的作品,講一個鄉下中學生巫女まち與會講話的熊ナツ的故事。聽起來很超現實,內容卻完全是家常(只要忽略ナツ是熊這件事)。之前朋友推薦時我看了一話就堅定追了因為まち好可愛喔喔喔喔喔喔喔喔喔喔喔喔喔喔喔喔喔喔喔喔喔喔喔喔喔喔喔我先去外面跑兩圈等等。
最近動畫化啦會動的まち也是好可愛喔喔喔喔喔呃呃我是要說還原度滿高的,趁機推薦一下。如果看得懂日文,ComicWalker 每兩個月會更新(原作是月刊連載,一次兩話)。當然有點 delay 不過免費就別嫌啦。從中間看可能會搞不太懂人際關係(其實也沒幾個人),不過我想動畫進度應該很快就會追上了。尤其響找了喜多村英梨,應該會早點讓他出場吧。
其實東立有代理不過我沒看過,而且日本上個月都出第六集了,中文只有兩本。也太慢。
comic-walker.com
一個工程師將自己在軟體開發上學習到的體悟以一個古老寺廟為故事背景,透過公案 的形式記錄下來。 莫名地有哲理,大家感受一下。
這個網站當然是他做的、故事是他寫的、連圖也是他自己畫的,太浪漫了吧!
由@saiday 提供
thecodelesscode.com
原創動畫,以動畫作為媒介的創作作品,不是改編自漫畫、小說、遊戲、vocaloid等創作的原創作品,換句話說,沒有「原作的劇透」之下,播映期間沒有人知道下禮拜會發生什麼事,所有觀眾的期待和猜想在同一個時間噴發,劇情轉折帶來的衝擊感之強烈,想像《EVA》或是《魔法少女小圓》當年帶來的衝擊,就能夠明白原創動畫特有的爆發力。read more
@ autisticcat