CodeTengu Weekly 會在 GMT+8 時區的每個禮拜一早上 10:00 出刊,每一期會從目前的 curator 名單中選出三位來負責當期的內容,每一位 curator 各自負責不同的領域,如果你在這一期沒有看到自已感興趣的東西,說不定下一期就會有了。
你也可以瀏覽一下前幾期的內容,有價值的東西是不會過時的。
以下是目前的 curator 陣容:
大家也可以 follow 一下 CodeTengu 的Facebook、Twitter 或GitHub,有很多 Weekly 看不到的內容。有任何建議或疑問也可以來Gitter 聊一聊,歡迎亂入 :japanese_goblin:
致力於解決開發者之間的資訊不對稱
如果你曾經 google 過任何一個 Python standard library,十之八九你都會被導去 Python Module of the Week ,這個網站專門在介紹 Python 的每個標準函式庫(标准库)的用途和用法,畢竟 standard library 可是每個程式語言的精髓啊。
這裡順便推薦幾個在 Python 江湖上走跳不能不知道的 modules:
PyMOTW 原本是針對 Python 2.7 的,而這個 PyMOTW 3 則是作者最近才開始為 Python 3.5 寫的全新的版本(還沒寫完,會每週更新),新增了諸如asyncio 等條目。
P.S. 說到 Module of the Week,我前陣子也才發現一個 Node.js Module of the Week ,跟大家分享一下。
pymotw.com
這是 iMySQL.com 的站長前陣子在台灣分享的關於 MySQL 效能優化的簡報,言簡意駭啊!關於 MySQL 的文章,在之前幾期的 CodeTengu Weekly 也分享過不少,有興趣的朋友可以回味一下。
google.com說到 cache,大家可能都會想到 Memcached 或 Redis,再不然就是 Varnish 和 Squid,有些人可能不知道,其實 NGINX 也有 cache 的功能,而且完全不依賴額外的 data storage。從這篇文章還可以發現,它非常容易配置(望向 Varnish,唉)。有趣的是,作者還提到了幾個特別的參數:
這個所謂的 " stale-while-revalidate " 的功能,Varnish 似乎也有。
P.S. NGINX 的 blog 上面還有很多文章都不錯,大家不要錯過。
nginx.com
Walrus 是@coleifer 寫的一個 Python library,能夠讓你用更 Pythonic 的方式操作 Redis 的各種 data type,例如可以像操作 dictionary 和 set 那樣操作 Redis 的 Hash 和 Set;除此之外,Walrus 還封裝了一些大家常用 Redis 來做的功能,比如說 counter、cache、rate limit、autocomplete 等,可以直接用一個 decorator 就解決。
延伸閱讀:
charlesleifer.com
關於程式碼的最重要的元素,有些人可能會說是架構、擴展性、效能或是它到底能不能動,但是老實說其實最重要的就是「可讀性」嘛!因為即使你寫的是完全無法執行的 pseudo code 或是效能很糟的程式碼,只要可讀性足夠好,完全沒有歧義,在 code review 或是別人接手你的程式的時候,其他人至少能夠知道你的思路,然後可以給你意見(甚至是直接幫你改啊)。
所以說 Readability 才是關鍵,而這本 The Art of Readable Code 就是專門在談論這個主題的書,第二、三章在講 naming 的部分是整本書的精華,第五章以後的章節讀起來其實有點像是簡單版的「重構」,總之就是這本書非常值得一讀,而且是越早讀越好。
這本書有出繁體中文版,書名叫「 易讀程式之美學 - 提升程式碼可讀性的簡單法則 」。
最後,雖然跟主題無關,但是我還是要說: Torment: Tides of Numenera (異域鎮魂曲的精神續作)已經可以在 Steam 上面玩到了(雖然只有第一章)!沒玩過異域鎮魂曲的人,推薦你看一下這篇文章,感受一下。
amazon.com
不知道有沒有人有看韓劇?
Anyway, 韓劇「她很漂亮」當中的女二「高俊熙」真的不得了了, 誰看的都會愛上她的, 雖然 IG 上面沒有強的照片就是了。
然後要跟各位讀者說聲抱歉了, 本週我只能送上這則了, 最近工作上實在是太忙, 完全沒時間讀新文章, 所以沒有好東西跟大家分享, 期待哪天我 solo 放送一期, 謝謝各位!
instagram.com
前一陣子剛好需要為公司制定程式碼規範,無意間找到這篇 Objective-C 程式開發的禪意與藝術,發現裡面所提倡的東西都很符合我的想法。這一篇文章所規範的作法可以:
如果你剛接觸 Objective-C 不久,或是你們團隊還沒有程式碼規範的話,我強烈推薦你們就先將這篇文章提到的做法照單全收,絕對大有幫助。
github.com
曾經是所有獨立開發者與小公司的最愛,曾經我們以為被 Facebook 買走之後會很穩的 Parse 在前幾天放出了一顆重磅炸彈:它們要收起來了!
還好 Parse 的人很有良心,它們提供了一年的緩衝時間,讓開發者可以慢慢找替代方案。如果你懶得去慢慢找的話,網路上也已經有人整理出一份替代方案懶人包了。
parse.com
隨著 Swift 開源之後,學習 Swift 的人也越來越多了。前一陣子就有人幫忙把官方網站翻譯成繁體中文版本,希望能幫助到其他人,降低進入 Swift 世界的門檻。 除此之外,這位維護者也發起了一個Swift Meetup,目前才剛起步,希望能吸引到更多人參與分享,讓這個 meetup 變得越來越好。
swiftlang.twSwift 剛出來的時候,還有很多 API 的命名有濃濃的 Cocoa 味,但隨著 Swift 不斷地快速演進,原有的一些命名規則開始顯得格格不入。於是他們打算要為 Swift API 命名來個大變動,讓這些 API 用起來更像是 Swift。雖然一切都還沒定案,但改變已經是勢在必行,可以想見這波改變將會影響到許多人。如果你願意的話,也可以一同加入討論,說不定就能影響 Swift 未來的發展!
swift.org
蘋果曾經在 WWDC 2015 的某個 talk 分享了一個設置中斷點的小技巧:你可以設定中斷點的 Debugger Command 為 po $arg1
,就可以在中斷的時候印出詳細的訊息。通常我們都會用在 Exception Breakpoint,這樣當我們遇到 exception 而當掉的時候,就可以看到相關訊息而知道發生什麼問題。
可是這麼一個好用的功能,在 Xcode 7 卻失效了!這位作者經過一陣嘗試之後終於找到解法:改成 po $eax
就可以了。