CodeTengu Weekly 碼天狗週刊 – Issue 81 I Unicode – Mar 27th 2017

Hello World

CodeTengu Weekly 碼天狗週刊

CodeTengu Weekly 會在 GMT+8 時區的每個禮拜一 AM 10:00 出刊,每期會由三位不同的 curator 負責當期的內容,每個 curator 有各自擅長的領域,如果你在這一期沒有看到自已感興趣的東西,可能下一期就會有了。你也可以瀏覽一下前幾期的內容。

目前的 curator 陣容:

  • @vinta – I failed the Turing Test
    – 科幻迷,最近在讀The Forever War
  • @saiday -Imnotyourson – 最近在看禪與摩托車維修的藝術
  • @tzangms -Oceanic / 人生海海 – 衝動型購物
  • @fukuball -ImFukuball – 婚後生活
  • @mingderwang – Ethereum enthusiast
  • @kako0507 – 熱愛嘗試新事物的前端工程師
  • @chiahsien – 新年新專案,好刺激啊!
  • @hiroshiyui – 沒有人是一座孤島
  • @uranusjr -Smaller Things – 不愛談技術的技術人,最近對做菜很有興趣
  • @kkdai -態度萬歲 – 喜歡 Golang 的略懂工程師,最近在學機器學習 (疑?)
  • @yhsiang

你也可以關注我們的Facebook、 Twitter
GitHub
或微博,有很多 Weekly 看不到的內容。有任何建議或疑問也可以來Gitter 聊聊,歡迎亂入。

致力於解決開發者之間的資訊不對稱

@saiday

GitHub lets workers keep the IP when they use company resources for personal projects

在上班時間或用公司資產創造出來的作品,即便作品的內容跟公司無關,公司還是擁有你的作品的智慧財產權。這樣的爭議場景常常在影集或是科技名人自傳裡看到。

現在 GitHub 提出了一個新的政策,Balanced Employee IP Agreement,讓員工擁有在上述情況下創造的個人作品的智慧財產權,這除了加強 GitHub 的文化之外,我相信對於 GitHub 在尋找強者的路上也會有更好的機會。

這份政策也是 Open Source 的 – balanced-employee-ip-agreement
。身為一個受雇的開發者,當然樂見這樣的發展方向。

研究了一下,以台灣來說,沒有特別簽契約的話,只要被認定是利用公司的設備和資源以及上班時間所完成的著作,大多會被認定為是受雇著作。根據著作權法第 11 條第 2 項規定,受雇著作之著作人為受雇人,著作財產權人為雇用人,因此該著作財產權歸老闆所有。

qz.com

The Two ID Problem

前陣子 Trello app 改版,多了 offline 的功能,而他們的技術團隊也因此寫了一篇開發這個功能時遇到的 offline ID 問題。

只要支援離線操作,就免不了要思考有兩組 ID 的解決方式。還沒有跟 backend 溝通之前的那組 local ID 跟溝通之後新得到的 server ID,要怎麼做儲存跟對應的修改?

Trello 團隊說明了兩種他們試過並放棄的方案:

  1. 在拿到 server ID 之後將自己產生的 local ID 全部替換掉

    • 要更新所有的關聯欄位,效能問題
    • 不安全,漏更新到欄位也不知道,後果會很嚴重
  2. 將 ID 的型別改為一組自定義的結構,包含 local ID 跟 server ID,並且在 client 建立一份 ID 的 mapping table

    • 要對應修改的範圍太大
    • 得頻繁去查表,行為詭異

最後也分享了他們目前的解決方法。這種案例分享真是不錯~

trello.com

硅谷和国内的 iOS 开发到底有何不同?

分析中國跟矽谷的 iOS 工程師跟開發工具的差別。

提到幾個有趣的現象:

  • 中國目前特有的工程師培訓班, 帶學員刷面試題,有計劃地弄好 GitHub 跟部落格,讓學員拿到 Offer,量產了一大批的工程師到市場上。
  • 中國與矽谷對產品經理角色定位的不同,矽谷對產品經理的要求嚴格,技術能力是必備的技能,通常都是拿來培養部門經理的接班人,中國則標準較低一些。
  • 矽谷的職涯發展較能發展出只寫程式不做管理的技術愛好者,讓其在特定領域作專精的事情,相較之下中國工程師技能樹點得較廣,不只技術領域涉獵較多,後期也會轉型管理職。這個現象可以跟 If Management is the Only Way Up, We’re All F’d
    一起看。

jianshu.com

Future of Java 8 Language Feature Support on Android

去年 Android 忽然出現了Jack 這套新的編譯工具,擾亂了一池春水,各大第三方套件都在討論要不要引入。

忽然之間,Google 就放棄了,打算回到原本 javac + dx。

官方給的理由是

Over time, we realized the cost of switching to Jack was too high for our community when we considered the annotation processors, bytecode analyzers and rewriters impacted.

簡單來說,透過 Jack 這個自己打造出來的編譯器 Google 可以直接在上面加入 Java 8 的 features 跟針對 Android 做優化,但是也因此 Java bytecode 就沒有了,社群上很多現存工具會無法支援,要重新打造一套編譯系統的門檻已經不是技術問題而是生態的問題。

We are currently matching Jack’s feature set. That means that we support lambdas, method references, type annotations, and repeated annotations for every API level; default and static interface methods are only supported for 24 and up. 來源 (Reddit comment)

回到 javac + dx 之後的進度看似也很不錯,可喜可賀。

googleblog.com

Why your app should crash

這篇文章以 null check 為例討論什麼情況不應該加上僅只是防止 app crash 的判斷式。

也以 null check 為例,我在做 null check 之前會問自己一個問題,照我的設計或是參與的第三方行為,這個地方有沒有可能是 null?如果照理說不可能,那就不要 null check 啦!

發生問題就去該找真正的問題來源,這種「我挺住了,我沒 crash」的判斷很有可能讓你的 program 進入奇怪的 state 中,加深之後想要除錯的難度~

jeroenmols.com

@mingderwang

Design first, then code.

2785 天以前,就有一群人在討論到底是先設計再 coding,還是不需要設計就直接 coding 的問題。其實這個問題,還是每天不斷的困擾著我們。尤其是還沒找到自己的路和方法的公司或某些創新公司,更需要仔細思考一下這個問題。

其實,最根本問題不是 “需不需要設計”,而是 “到底多少設計,才不算太多”。在 coding 前,不可能完全沒設計,只有要設計多少的問題。

另外,program architecture 到底要不要設計,我個人覺得如果貴公司還沒有自己的 program architecture,那當然要; 且如果設計的好,就可以重複使用。它的目的,就是能讓設計快速 (敏捷地) 實作,且能快速的抽換。也就是在本文中所提到的: Good design can try out and throw away ideas really quickly.

ycombinator.com

Learn Elasticsearch Sorting in 5 minutes

最近在寫 Elasticsearch 資料庫查詢程式,發現不只需要對您選用語言所使用 elasticsearch 的副程式庫要深入了解,更需要知道 Elasticsearch 查詢的語法和特性,才能將程式發揮到極致。這篇文章,讓你能在短短五分鐘內學會 Elasticsearch sort 的方法,我也對 twitter 撈來的資料,做了一個簡單的練習,如下:

GET /logstash-twitter/_search
{
    "query" : {
        "bool" : {
            "filter" : {
                "term" : {
                    "retweeted" : false
                }
            }
        }
    },
    "sort" : {
        "user.keyword": {"order": "desc"}
    }
}

如果您還不熟悉 Elasticsearch 的 Query DSL,不妨先看看這篇 3 年多以前就有的文章Elasticsearch 101,就能對 Elasticsearch 查詢先有個大概的了解。

appbase.io

The Hitchhiker’s Guide to Smart Contracts in Ethereum

開發 smart contracts 環境的架設,以及部署智能合約到 Ethereum 網路,對初學者來說,的確是有點難度。這篇文章教您如何安裝 testrpc 來架設一個模擬 Ehtereum 網路以及幫你開好 10 個帳號。並介紹如何利用 truffle 這套工具,很快能產生一個新專案, 開始撰寫與測試您的 solidity 程式。

但最後要部署到 testnet,或真正的 Ethereum 網路,還是要裝 geth 才能成功。我建議可以使用Parity 代替 geth,或用 docker 安裝instance-parity,可以省去大量 blocks 同步的時間。

medium.com

@uranusjr

The Unofficial Bash Strict Mode

寫過 JavaScript 的人

大概
應該要
知道什麼是 strict mode

#!/bin/bash
set -euo pipefail
IFS=$'nt'

第一行沒什麼問題,大家都懂 shebang。第二行代表設定三個模式:

  • -e
    :當任何一個指令失敗(return code 不為 0),立刻結束 shell。這個大家應該很熟悉了。預設的行為是當指令失敗時,繼續往後執行。這是 interactive shell 該有的行為,但 script 這樣做很危險。
  • -u
    :禁止未定義的參數。預設的行為是把未定義的變數視為空白,但這很危險,尤其當你用變數組路徑時。
  • -o pipefail
    :會把 pipe 中的錯誤往外傳。預設模式下,使用 pipe 時會回傳最後一個指令的結果,讓你看不出來前面的指令是否失敗。

第三行的設定就比較是個人偏好,會影響 Bash 中 for loop 拆字串的行為。不過這滿合理的,建議使用。

和 JavaScript 一樣,不是所有現存程式都與 strict mode 相容。作者也在下面列出一些常見的狀況,並提供解法。如果你遇到什麼其他問題,歡迎回報!

redsymbol.net

Bug 1202858 – 重啟 Squid 讓硬碟中所有檔案被刪除

重現度:

100%

重現步驟:

  1. 登入已安裝 Squid 的 RHEL 6.7 主機
  2. 啟動 Squid service squid start
  3. 重啟 Squid service squid restart

實際狀況:

機器上所有檔案被刪除。

預期狀況:

Squid 正常重啟。

上一篇說了 Bash script 裡有未定義的變數很危險。這裡有個實際例子。還好 Red Hat 在正式發行之前就抓到了這個問題;Steam 可是發了正式版之後才有使用者回報呢。幫 QQ。

redhat.com

A formal spec for GitHub Flavored Markdown

GitHub

終於
發表了他們的 Markdown specification。基本上以 CommonMark

對一般人這可能沒差,我已經預想這篇的點閱率應該會超低。XD 但對 Markdown editor 維護人
而言這是大新聞啊。GitHub 之前使用首席工程師 Vicent Martí 開發的Sundown(基於 Natacha Porté 開發的 Upskirt),以及它的 Ruby bindingRedcarpet。這個實作非常優秀(MacDown 使用它的一個衍伸專案Hoedown),但有一些 不直覺
的行為。這不是誰的錯,而很大部分來自 原始 Markdown specification
不夠清楚造成的未定義行為。CommonMark 清掉了很多類似問題,但造成一些不相容語法,而 GitHub 在 Markdown 界的影響力太大,成為與 CommonMark 競爭的de facto standard。

GitHub 這次的舉動讓 CommonMark 實質上一統天下了,應該會讓我們的工作輕鬆許多。期待。

githubengineering.com

If-statements in Smalltalk

在討論語言時,一個很重要的區別是了解某個功能是 語法
還是 函式庫
帶來的。Mark Dominus認為 design pattern 代表一個語言不夠高階,無法直接達成你想要的功能,而需要使用者重複描述同樣的概念。但什麼樣的功能才算是語言提供呢?作者舉了 Smalltalk 獨特的條件式實作作為例子。在大部分的語言裡,if block(包含 else 與 else if)都是語言功能,但 Smalltalk 不然。在 Smalltalk 中,條件式是這樣寫:

a < b
  ifTrue: [^'a is less than b']
  ifFalse: [^'a is greater than or equal to b']

下面是這段程式的解讀:

  • Smalltalk 中 Boolean
    有個 - ifTrue: ifFalse:
    方法。這個方法接受兩個 block 引數( [^ ...]
    語法)。
  • Boolean
    有兩個 concrete subclasses True
    False
    。其中 True
    - ifTrue: ifFalse:
    會執行 ifTrue:
    後面的 block, False
    會執行 ifFalse:
    後面那個。
  • 這一整段其實是一個 method call, a < b
    得到的 Boolean
    實例是 callee。

這代表 Smalltalk 中,條件式 不是語言功能
,而是實作 design pattern 的內建函式——因為即使 Smalltalk 標準庫沒有它,使用者也可以自己寫出等效的功能。語言功能與內建函式之間的界線其實比我們想像得更模糊,以語法 expresiveness 判斷語言夠不夠高階,也不是正確的基準。

MIND. BLOWN.

livejournal.com

稿源:CodeTengu Weekly (源链) | 关于 | 阅读提示

本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » 综合技术 » CodeTengu Weekly 碼天狗週刊 – Issue 81 I Unicode – Mar 27th 2017

喜欢 (0)or分享给?

专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录