转载

Issue 8 人類的生產力在電腦和網路普及之後大幅提升,但是工時卻沒有變少 - Sep 21st 2015

Issue 8 人類的生產力在電腦和網路普及之後大幅提升,但是工時卻沒有變少 - Sep 21st 2015 @vinta

关于 Python 的面试题

列出了很多 Python 滿基本的概念和用法,範例也都很精簡,就算沒有要面試,掃一下也是不錯的。

延伸閱讀:

  • Python interview questions

github.com

Tools for profiling your Python / Django project

在開始優化你的程式之前,你總是得先知道究竟是哪個 function 或哪一行程式碼最需要被優化嘛,這件事就是所謂的 profiling。前陣子試玩了幾個 Python 常用的 profiling 工具,包括 timer , pycallgraph , cProfile , line_profiler , memory_profiler ,可以很容易地找出哪一行 code 花了多少時間執行或是用了多少記憶體。

突然想到,像 Go 那樣把 benchmark 作為 unit test 一部分的概念其實挺不錯的。

PS. 另外也推薦一下 Opbeat ,它的 Performance Metrics 功能真的好。

延伸閱讀:

  • How can you profile a Python script?
  • Optimizing Python - a Case Study

vinta.ws

Anatomy of a Modern Production Stack

由前 Google Compute Engine 的 Lead Architect 寫的一篇關於現代化的大規模系統應該使用哪些玩意兒,毫無懸念地是 container-based。但是老實說,與其說是「現代」倒不如說是「近未來」啊,因為文章裡頭提到的大概有一半以上的東西,我想大部份的 developer 可能都沒碰過(甚至沒聽過)。話雖如此,先了解一下歷史的車輪究竟會往哪個方向碾過去總是沒有壞處的嘛。

eightypercent.net

Elasticsearch Indexing Performance Cheatsheet

這篇文章(和底下延伸閱讀的那兩篇)都是在講 Elasticsearch 在使用上的 best practice,從 configuration、index settings、type mappings 到該怎麼下 query 等大大小小的方面都涵蓋到了,值得一讀。其中我覺得最基本的一件事就是:要記得用 alias ,這樣才能先為你遲早都會遇到的 reindex 做準備。

我前幾天正好就遇到一次要重做 index 的情況,寫了一篇 Change index mappings with zero downtime using elasticsearch-py ,有興趣的人可以看一下。

延伸閱讀:

  • Elasticsearch gotchas and tips
  • Indexing Performance Tips

codecentric.de

python-decouple: Strict separation of settings from code

根據 The Twelve-Factor App 宣言,建議你把 config 存在 environment variables,而 python-decouple 就是在做「從環境變數(或 .env 檔案)讀一個設定進來,然後 cast 成正確的 data type」這件事。

用一行 EMAIL_USE_TLS = config('EMAIL_USE_TLS', default=False, cast=bool) 漂亮地解決。

延伸閱讀:

  • vinta/awesome-python - Configuration

github.com

Issue 8 人類的生產力在電腦和網路普及之後大幅提升,但是工時卻沒有變少 - Sep 21st 2015 @saiday

Reducing FOOMs in the Facebook iOS app

Facebook 分享關於他們怎麼處理 OOMs (Out Of Memory) 的文章,說明了 Facebook 是怎麼統計 OOMs 發生,透過什麼樣的機制去減少 OOMs 的可能及成效。將 UIWebView 換成 WKWebView ,效果很好,簡單粗暴。

但我覺得值得一提的是抓出 Memory Leaks 的方法,大至 Facebook 小至獨立開發的專案其實都常常發生 Memory Leaks 而不自知,這篇文章說到他們為了找 leaks 寫了一個所謂的 AllocationTracker 透過不正常的 instances 數量幫助開發者早期猜到哪個物件有 leak 的可能。

剛好我在 iOS 上也試過一種早期判斷 Memory Leaks 的方法,想法上不同,我是透過執行 Unit testing 時驗證物件會不會被 release。大家有興趣也可以參考我的做法 Unit tests with memory leaks assertion 。

PS. 大家可能都有裝 Crashlytics ,但 Crashlytics 其實是沒辦法抓到 Low-memory events 的,所以 OOMs 發生時你是不會在 crash report 上看到的。

facebook.com

Shipping an App with App Transport Security

iOS 9 已經正式釋出了,App Transport Security aka "HTTP! You shall not pass! " 想必是影響開發者最大的改變,真心推薦這篇文章,將 ATS 講得很清楚。

How critical is App Transport Security? 的 這個回答 更是詳列了六種你可能需要調整 ATS 白名單或開關的狀況。

延伸閱讀:

  • Is your app iOS 9 ready?
  • Issue 2 的中文 iOS9AdaptationTips 。

timekl.com

Android: Looper, Handler, HandlerThread. Part I

這是一個講 Android threading 的系列文章,從最常見的 AsyncTask 分析及什麼情況下你不該用 AsyncTask (你的 AsyncTask 直接 reference 你的 Activity / Fragment )、 Java 的 Thread + Handler 跟 Android 提供的 HandlerThread 的差異及你應該要知道的 MessageQueue 。

Part 2

延伸閱讀:

  • 附上一個 HandlerThread 的 real world example

    書: Efficient Android Threading: Asynchronous Processing Techniques for Android Applications

nikitaog.me

Fun with Functions – Crunchy Development

這是一篇講 Swift functional programming 的範例,有 簡中版本 ,涵蓋了入門的 currying 以及演示了一個很好的 operator overloading 應用,我以前一直覺得這樣不好吧,一定會有報應。

雖然我看過有人說現在的 funtional programming 現象就像是 20 世紀末的共產主義浪潮,信奉者散播著理想化的理念到你的國家 (codebase) 裡,一直到你的國家 (codebase) 充滿了債務 (monads),他們又離去了。 ( 沒有人知道 monads 是什麼 )

不過我還是覺得在 Swift 就是要適度的引入 functional programming 才能解放這個語言的強大跟彈性,而且在特定的情況用 functional programming 會讓閱讀性提高嘛。

github.io

Guide: Writing Testable Code

這是 Google 內關於加強程式可測試性 (testability) 的設計準則,沒話說,寫得真的好。總共有四個 flaws,都有提供 bad smells 讓我們可以憑感覺找到可以加強的地方。有重構的 before 跟 after。

我想大家應該都有過想要寫測試但是看了想要測試的 object, method 就發現「媽的,這根本沒辦法測啊」然後轉頭又離開的情況,其實寫測試入門最先要處理的就是我們平常寫的 code 思維,而當寫出高可測試性的 code 時也直接提高了它的維護性跟品質。

hevery.com

Issue 8 人類的生產力在電腦和網路普及之後大幅提升,但是工時卻沒有變少 - Sep 21st 2015 @tzangms

Issue 8 人類的生產力在電腦和網路普及之後大幅提升,但是工時卻沒有變少 - Sep 21st 2015

[MV] Hyukoh - WI ING WI ING

最近發現了一個韓國獨立樂團叫 Hyukoh, 主唱的聲音真的是不得了, 覺得一定要跟大家分享一下。 除了這首 wi ing wi wing 之外, 還有一首叫 Big Bird 的也超棒!

youtube.com

如何每年讀 60 本書?

2013 年自己發憤打算讀一百本書, 不過最後其實只讀完了 60 本書, 當初讀完一本書都還拍照做個紀錄, 便把照片集結起來留個 紀錄 。

而我這兩年則是跟這篇文章中提到的一樣, 我利用通勤時間開始用 Audible 聽有聲書, 大多時候也用 1.5 倍或是 2 倍的播放速度來聽電子書, 這樣聽書就更快了, 一本 8 小時的書, 用兩倍速的播放速度聽, 只需要 4 個小時。

不過大多是聽管理類的相關書籍就是了, 後來英文聽力也提升非常多, 我一直在推薦身邊的人用這方法, 大家可以參考一下。

另外, 文章中的 Blinkist 也是一個不錯的讀書方法, 剛好前一陣子又開始用 Blinkist 了, 大家也可以試試。

36kr.com

窮人 32 元踏頻計

自從知道 @yllan 的時候就覺得他是天才, 而且是擅長把科技應用在生活上。 最近他似乎迷上騎腳踏車, 所以他用了磁鐵跟橡皮筋搭配 iPhone 來做出踏頻計。

實在是很帥, 哈哈哈, 簡直就是工程師界的生活智慧王啊!

medium.com

Book Club for Tech Leads

99designs 技術團隊內部的讀書會, 主要是針對 Tech Leads, 除了書單之外。 文章中講述了他們為何要看這些書, 為何要有讀書會以及跟流程等等。

99designs.com

Pineapple

iPython for Mac

github.io

正文到此结束
Loading...