+1，我們團隊 coding style 要求使用 yoda condition。

出自 Hiring Front-end Engineers for Chrome DevTools Team1 Chrome 開發團隊徵才文

今年研討會蠻常看到有開 gitter.im 的頻道，我們公司辦黑客松時也是用這個，不過 gitter.im 目前用起來最顯著的缺點就是往上捲看舊訊息時非常的卡，體驗不佳，也許研討會這類訊息密集度高的使用場景還是適合用 IRC 吧

「後端工程師」要求條件有 AngularJS / ReactJS / Gulp / Webpack 怪怪的，為什麼不是列在前端工程師的條件？

已贊助 XD

此篇堪稱 「重構：改善既有 JavaScript 壞味道程式碼」，極為實用啊

PHP 之父昨天在 Fluent Conf 的演講，提到不少 PHP 7 新增的特性，簡而言之就是往強型別移動、提供更多便利的語法糖衣 (例如 Null Coalesce Operator 「??」)、比 PHP 5.6 好上兩倍的效能提昇

推薦用 Phabricator，我們公司選用它而非 GitLab 的原因主要有這兩點：

• 公司主流言語言是 PHP，如果要客製化（文末的例子）也比較容易

• DevOps 同事不傾向採用 Ruby 方案

如果公司沒包袱， Phabricator 也能勝任 issue tracking system 的角色

Phabricator 做 Code Review 的優勢除了 line by line comment 之外，還可以對 commit 做 Accept / Raise Concern

我們的流程是：

1. Reviewer 對某段 code 有疑問，Raise Concern

2. Author 回覆，決定處理方式：直接修正或是跟 Reviewer 辯論

3. Reviewer 認同處理方案，按 Accepted 結案；不認同的話繼續回覆，甚至拉其他人討論

最近參考 Phabricator Bot 文件1寫了一支 Bot daemon，Reviewer 回覆 commit 就會噴訊息到 HipChat 並 mention author，讓比較習慣使用 IM 工具而非 email 的人可以及早收到 Reviewer 的意見 (Phabricator 可以設定有人回覆就寄信出來）

如果以前是 SVN，一般都是用 git-svn 遷移? 至少我們公司是如此

Amazon 應該選在 4/1 釋出比較合理 (?)

我們的 Art 配 iMac，DevOps 就幫他們安裝 SourceTree1，然後有興趣的學 Git 的就再找個有空的人教會他 add / commit / pull / push，Art 就可以自己更換圖檔 / CSS 並且 deploy (GNU Makefile + Rsync) 到 production 。

公司 repo 太多，大部分放自行架設的 gitolite，一小部分放 GitHub Enterprise

請問有沒有「我推過的文章列表」功能？可以知道自己推過哪些文方便當書籤用