[心得]20151221周讀網心得

這個禮拜是現代化網站技術分享日，

很可惜我沒有參加，不過還是收集了一些相關文章，

作為回顧與分享。(hackpad支援)

先用JSDC2015的Casear Chu的影片作為回顧

JSDC 2015 #08 技術演進的大亂鬥 by Casear Chu

前端就是演進這麼得快速，僅僅是幾個月，也許技術又翻了一翻

當我們盲目(也許只有我啦)追求新技術時，不仿想想新技術的目的為何？

致我們終將組件化的Web 點出所有作Web的人的烏托邦，

所有元素不再會是html tag、css style 與js 硬兜出來的功能，

而是一個一個組件，小至一個Label，大致整個Page整個Site

只要重組、重新利用這些組件，就能產生網站，

可以看看2015年前端[JS]工程師必知必會 。

了解一下目前的技術，究竟自已掌握了多少？

有些2、3年前的舊技術(笑) ，是不是有更好的替代方案。


Web的組件化，終將會融入前端(Javascript、HTML、CSS)的標準，

但目前最好的解決方案，

或許就是React+webpack+postCSS ,

這個solution的優點可以參考這篇文章，

ES2015(ES6) 也是重要標準，可以看一下最新的開發者投票結果 。

但在Browser支援之前我會選擇TypeScript作為開發。

測試也是很重要的，本周沒有機會看到相關文章，

但是有看到一些js的測試模組，有機會要嚐試看看。


其它本周閱讀的文章:
程式人產能之謎
http://f2e.souche.com/blog/a-js-problem-about-global/

[[[本誌僅為個人分享與記錄，不保証內容永久正確性，如有謬誤、疏漏或侵權還請留言告知]]]

[轉貼]程式人產能之謎

原文

本文開始:

留意正負產能差異原因，而不是指標結果，例如不適任者的虛耗與難以專注工作的環境

在程式人的產能差異上，你可能聽過不少的傳說，像是「程式人間有5:1或10:1產能差距並不是種曲解」、「90%程式碼是由10%程式人撰寫」、「優秀軟體開發者價值遠勝平庸開發者10,000倍」等，產能差異在哪？單純關注個別程式人的正向產能，是對的嗎？

產能評量的迷思
Joel Spolsky、Robert C. Martin、Bill Gates分別對產能差異提出了以上的想法，Steve McConnell在〈10x Software Development〉中亦提到「許多研究發現，產能與品質在個體甚至團隊間會有10:1的差異」，總之，任何10次方的產能差距你可能都有聽過，作為管理者，大多會關心如何評量開發者產能，期待促進專案整體的生產力。

只是要量測程式人的產能相當困難，程式設計是個知識工作，先不論其本身有許多難以量化元素，如果為了評量開發者產能，訂出了許多量化指標，就會出現許多收集點數的荒謬行為。那麼，這些10次方產能差距的結論到底從何而來？Joel Spolsky是研究學生用相同技術做相同作業花費的時間，以及取得的作業分數，Steve McConnell研究中談到的是創建、除錯一個程式需要的時間，以及程式的大小、速度、找到的錯誤等。

從收集而來的資料看來，產能差距似乎指向時間與品質，因而有人試圖從中建立指標，期待於每年、每季甚至每月，提前並切割地評量程式人的產能表現，然而實務上不會讓兩個開發者做相同的任務，Tom Cargill也說過：「前90%程式碼耗掉了90%開發時間，剩下的10%需要另外90%的開發時間」，這說明了提前與切割地進行產能評量也是個問題。

從管理角度來看，不可否認地需要某些指標來評量開發者好壞，其實當我們覺得某開發者極具生產力時，實際上，心中確實為他建立了一些指標，也許是類似功能另一開發者花了一整月開發而他只花一星期，某問題另一開發者花了一星期無法除錯，而他接手僅花一天就順心解決……那麼，原因呢？與其就結果來論斷他是否有生產力，不如進一步探究為何他擁有這樣的生產力。

程式人的三種美德
在《Programming Perl》中，Larry Wall鼓勵程式人應培養三種美德：「懶惰（Laziness）、沒耐性（Impatience）與驕傲（Hubris）」。懶惰就會讓程式人努力減少整體工作量，寫一些能節省人力的程式，並寫下這個程式的文件，免得要親自回答許多問題；沒耐性的程式人無法忍受電腦怠惰，寫的程式就會儘可能讓它閒不下來，而不是停下來等待你的需求，驕傲的程式人會寫下旁人無可挑剔，而本身極度自豪的程式。

這三種美德看來就對應了先前談到程式人產能差距指向的時間與品質，探討程式人生產力祕訣的《The Productive Programmer》書籍前言中，也談到即使沒有直接提到這三個名詞，然而這三種美德將會在該書中擴展開來。

程式人的三種美德可以拆開來看，也可以合併來看。想要減少整體工作量有個簡單方式，就是不做重複的工作，電腦絕對比你擅長重複工作，只要告訴它怎麼做，如果發現常常用滑鼠在電腦上重複地走來走去，那就想辦法用工具或寫程式把這個過程「錄」下來，如果發現經常要輸入相同的指令，那就想辦法用工具或寫程式讓這個過程自動化，如果發現類似專案間有些個別差異而增加了溝通麻煩，那就讓它們標準化，實際上會發現，不少現成工具就是這麼創造出來的，是否能瞭解、善用甚至創造出這類工具，就決定了優秀與平庸程式人間的產能差距。

重複的程式碼也是一種重複的工作，無論形成重複的原因是否來自程式碼的剪貼，重複會造成程式碼後續維護時整體工作量的增加，將明顯或三次以上的程式碼重複加以適當重構，透過適當設計讓程式有彈性，就構成了程式人第三種美德。實際上，許多文件、書籍在教導或傳承的就是這三種美德，作為一個進取的程式人，多半會關心如何彌補自身與優秀開發者的這段差距，以提升自我程度為自豪。

程式人的三種罪行

「90%程式碼是由10%程式人撰寫」是Bob大叔在〈One per Pixel〉文章中談到的，文中後續還講了「其他90%的人寫了剩下10%程式（而10%的那些人還得修正這些程式）」，他提到優秀的程式人其實不多，只有10%或許太誇張，也許是20%，也許是30%。實際上在職場生態中確實如此，程式設計對許多人來說，只是份工作，追求優秀與產能這種事，大多數人並不關心。

懶惰、沒耐性與驕傲是程式人的三種美德，這是幽默地從正面意義去看待這三個負面詞語，如果用負面方向來解釋這三個詞語，就是不少從事程式設計工作者的三種罪行。

就懶惰這方面來說，大多數從事程式設計工作的人，就真的只是懶，他們懶得去熟練語言與工具、懶得去探究問題發生的原因，也沒耐性去學習新的東西、沒耐性寫下文件，對於程式本身不會有責任感，程式能動就好，不會去管程式碼的重複、不在意程式的溝通性，甚至隱藏程式碼中的錯誤，隨意地在不同元件中自私地進行各式程式碼侵入，他們建立自己的舒適區，如果你基於改善程式品質的立場去冒犯了他們，他們還會有各式傲慢的回應。

無論是文件或書籍總愛討論如何提升程式人產能，實際上優秀的程式人會自動追求這類自我提升，在關注產能之時，也許不該去評量這類程式人的產能，指標對這類程式人經常是種傷害；真正該注意的是，如何評量出「負產能」，負產能程式工作者建立出來的程式，後續還得耗費優秀程式人來修正，一正一負之下雙方產能抵消歸零也就算了，優秀程式人如果因此心生委屈而離開了，負產能與優秀程式人間的差距，就不是10,000倍可以比擬了。

David Parnas在有次訪談中被問到「軟體工程中最常被忽略的風險是什麼？」他的回答是「不適任的程式工作者（Incompetent programmer）」，並談到「差勁的程式工作者，一年可以輕易創造兩個新工作」，這跟Bob大叔說的類似，因為還得有人來為不適任程式工作者寫的程式進行善後，技術債（Technical debt）這名詞似乎很適合拿來形容這類情況，只不過欠下技術債的是不適任程式工作者，卻得由優秀程式人來償還。

給程式人專注的環境
產能這方面有個人因素，實際上也有環境因素，在關注個別程式人產能之時，別忽略了給予程式人可以專注的環境。

在《Peopleware: Productive Projects and Teams》一書中，就指出：「管理者的工作並不是叫人去工作，而是創造讓人想去工作的情境」。許多公司都會有類似的情況……規範員工每日的產能指標，然後實際上每天不斷地把員工從工作情境中拉離（電話、郵件、開會……），最後在每月、每季或每年考核時，再來指責程式人為何產能如此之差，打擾者也許不只是管理者，不適任程式工作者也經常會做這種事。

關注正向產能當然是好事，只不過程式設計這領域，沒有真正適用的評量，任何基於自我想像的指標傷害性就更大了，不適任程式工作者為了符合指標，也總是能「下有對策」；與其關注程式人的產能，不如關注優秀程式人用了哪些方法提高產能，讓他們能發揮，並且留意不適任程式工作者的行為。

更重要的是得留意，產能差異的謎團也許不只是來自程式人，也有可能是環境或本身，想想看，算過自己打電話打擾其他開發者的次數嗎？這類的指標，也許是從沒有被考量進去的！

作者簡介

林信良

因在網路上經營「良葛格學習筆記」（openhome.cc）而聞名，曾任昇陽教育訓練中心技術顧問、甲骨文教育訓練中心授權講師，目前為自由工作者，專長為技術寫作、翻譯與教育訓練。喜好研究程式語言、框架、社群，從中學習設計、典範及文化。閒暇之餘記錄所學，技術文件涵蓋C/C++、Java、Ruby/Rails、Python、JavaScript、Haskell等多個領域。 

心得小結:
美德與惡德只是一線之隔，保持謙遜的態度。別讓美德成為惡德。
專注真的好嗎？ The Clean Coder 作者 Bob大叔說過「不要進入flow zone」，
原因是進入這個狀況，或許會有極大的產出，但是不容易顧及全面，依本文所說反而容易產生負產能，「挖一個坑來補一個坑」是很容易發生的。如何建立一個良好的工作環境，不讓單一工程師進入流態，而是讓整個團隊專注於一項功能/產品 進行開發，我想這是專案管理上的重要課題。

[[[本誌僅為個人分享與記錄，不保証內容永久正確性，如有謬誤、疏漏或侵權還請留言告知]]]

[轉貼]常用 Git 命令清單

原文

作者:阮一峰
--

我每天使用Git ，但是很多命令記不住。

一般來說，日常使用只要記住下圖6個命令，就可以了。但是熟練使用，恐怕要記住60～100個命令。

下面是我整理的常用 Git 命令清單。幾個專用名詞的譯名如下。

• Workspace：工作區
• Index / Stage：暫存區
• Repository：倉庫區（或本地倉庫）
• Remote：遠端倉庫

一、新建代碼庫

# 在當前目錄新建一個Git代碼庫
$ git init

# 新建一個目錄，將其初始化為Git代碼庫
$ git init [project-name]

# 下載一個項目和它的整個代碼歷史
$ git clone [url]

二、配置

Git的設置文件為.gitconfig，它可以在用戶主目錄下（全局配置），也可以在項目目錄下（項目配置）。

# 顯示當前的Git配置
$ git config --list

# 編輯Git配置文件
$ git config -e [--global]

# 設置提交代碼時的用户信息
$ git config [--global] user.name "[name]"
$ git config [--global] user.email "[email address]"

三、增加/删除文件

# 添加指定文件到暫存區
$ git add [file1] [file2] ...

# 添加指定目錄到暫存區，包括子目錄

$ git add [dir]

# 添加當前目錄的所有文件到暫存區
$ git add .

# 删除工作區文件，並且將這次删除放入暫存區
$ git rm [file1] [file2] ...

# 停止追踪指定文件，但該文件會保留在工作區
$ git rm --cached [file]

# 重新命名文件，並且將這個命名放入暫存區$ git mv [file-original] [file-renamed]

四、代碼提交

# 提交暫存區到倉庫區
$ git commit -m [message]

# 提交暫存區的指定文件到倉庫區
$ git commit [file1] [file2] ... -m [message]

# 提交工作區自上次commit之後的變化，直接到倉庫區
$ git commit -a

# 提交時顯示所有diff信息
$ git commit -v

# 使用一次新的commit，替代上一次提交
# 如果代碼没有任何新變化，則用來改寫上一次commit的提交信息
$ git commit --amend -m [message]

# 重做上一次commit，並包括指定文件的新變化
$ git commit --amend [file1] [file2] ...

五、分支

# 列出所有本地分支
$ git branch

# 列出所有遠端分支
$ git branch -r

# 列出所有本地分支和遠端分支$ git branch -a

# 新建一個分支，但依然停留在目前分支
$ git branch [branch-name]

# 新建一個分支，並切換到該分支$ git checkout -b [branch]

# 新建一個分支，指向指定commit$ git branch [branch] [commit]

# 新建一個分支，與指定的遠端分支建立追踪關係$ git branch --track [branch] [remote-branch]

# 切換到指定分支，並更新工作區
$ git checkout [branch-name]

# 建立追踪關係，在現有分支與指定的遠端分支之間
$ git branch --set-upstream [branch] [remote-branch]

# 合併指定分支到當前分支
$ git merge [branch]

# 選擇一個commit，合併進當前分支
$ git cherry-pick [commit]

# 删除分支
$ git branch -d [branch-name]

# 删除遠端分支
$ git push origin --delete [branch-name]
$ git branch -dr [remote/branch]

六、標籤

# 列出所有tag
$ git tag

# 新建一個tag在當前commit
$ git tag [tag]

# 新建一個tag在指定commit
$ git tag [tag] [commit]

# 查看tag信息
$ git show [tag]

# 提交指定tag
$ git push [remote] [tag]

# 提交所有tag
$ git push [remote] --tags

# 新建一個分支，指向某個tag
$ git checkout -b [branch] [tag]

七、查看信息

# 顯示有變更的文件$ git status

# 顯示當前分支的版本歷史
$ git log

# 顯示commit歷史，以及每次commit發生變更的文件$ git log --stat

# 顯示某個文件的版本歷史，包括文件改名
$ git log --follow [file]
$ git whatchanged [file]

# 顯示指定文件相關的每一次diff
$ git log -p [file]

# 顯示指定文件是什麼人在什麼時間修改過
$ git blame [file]

# 顯示暫存區和工作區的差異
$ git diff

# 顯示暫存區和上一個commit的差異
$ git diff --cached [file]

# 顯示工作區與當前分支最新commit之間的差異
$ git diff HEAD

# 顯示兩次提交之間的差異
$ git diff [first-branch]...[second-branch]

# 顯示某次提交的元數據和内容變化
$ git show [commit]

# 顯示某次提交發生變化的文件
$ git show --name-only [commit]

# 顯示某次提交时，某個文件的内容
$ git show [commit]:[filename]

# 顯示當前分支的最近幾次提交
$ git reflog

八、遠端同步

# 下載遠端倉庫的所有變動
$ git fetch [remote]

# 顯示所有遠端倉庫
$ git remote -v

# 顯示某個遠端倉庫的信息
$ git remote show [remote]

# 增加一個新的遠端倉庫，並命名
$ git remote add [shortname] [url]

# 取回遠端倉庫的變化，並與本地分支合併
$ git pull [remote] [branch]

# 上傳本地指定分支到遠端倉庫
$ git push [remote] [branch]

# 强行推送當前分支到遠端倉庫，即使有衝突$ git push [remote] --force

# 推送所有分支到遠端倉庫
$ git push [remote] --all

九、撤銷

# 恢復暫存區的指定文件到工作區
$ git checkout [file]

# 恢復某個commit的指定文件到工作區$ git checkout [commit] [file]

# 恢復上一個commit的所有文件到工作區$ git checkout .

# 重置暫存區的指定文件，與上一次commit保持一致，但工作區不變
$ git reset [file]

# 重置暫存區和工作區，與上一次commit保持一致$ git reset --hard

# 重置當前分支的指針為指定commit，同時重置暫存區，但工作區不變
$ git reset [commit]

# 重置當前分支的HEAD為指定commit，同時重置暫存區和工作區，與指定commit一致$ git reset --hard [commit]

# 重置當前HEAD为指定commit，但保持暫存區和工作區不變
$ git reset --keep [commit]

# 新建一個commit，用來撤銷指定commit
# 後者的所有變化都將被前者抵消，並且應用到當前分支
$ git revert [commit]

十、其他

# 生成一個可供發佈的壓縮包
$ git archive

[[[本誌僅為個人分享與記錄，不保証內容永久正確性，如有謬誤、疏漏或侵權還請留言告知]]]

[心得]你為什麼還在用便條紙?為什麼看紙本書?

今天BOSS問我為什麼還在用便利貼？

現在雲服務這麼方便，像是Trello，就是一個很方便的工具。

其實我是Trello的重度使用者，只要有專案我就會透過它在追踨進度。

不過反過來說，如果沒有專案的情況下，我是不會使用Trello的。

網路越來越方便的現在，是不是所有的東西都要上雲端呢？

但是我仍然覺得雲仍有一種看得到摸不到的不便利性，

天與地仍有隔閡 。
摸不著，是雲的優勢也是劣勢。

紙張是難以取代的，

雖然它有承載資訊量小、寫入慢、
不防水(?)等等的缺點。

但它的可攜性卻相當的高，

便條反而是它最適合的舞台，

我用了很多的Todo List App，仍然比不上便條紙，

偶爾喜歡的女孩貼上的問候，

更是令人無法捨棄的原因啊。

電子書推行多年，仍然是小眾市場，

我覺得是人能專注的知識量，

大概就是書的一頁，而能專注的時間，

大概也就是1~2個小時。

看的快得人也大概一本書的量，

縱有千藏萬卷，閱讀的當下，也僅僅是一頁一字。

現在資訊爆炸，但真正有價值的資訊卻反而淹沒其中了，

當你刷著facebook、微博的頁面時，有多少資訊是對你有意義的呢？

你可以試著作一個實驗，每當你刷一下facebook，

看到超過兩篇同一個人的訊息，就將他的貼文數量減少顯示(如圖所示)

相信我，只要你這樣作，大概只要一個禮拜就有感覺了。

你會看到更多不同的文章，不同視界。

當然你不一定會認同那些觀點，

在社群網站的演算機制底下，

你只會看到兩個東西「廣告」、「你主觀認同的訊息」

這樣其實是很危險的，因為你看世界的角度將會小的可憐。

「我們都是以管窺天，只是角度與管徑的差別」

真的非常推薦大家試試這個實驗!

[開發].NET 套件管理 - Nuget

導言

我們在開發的過程中，難以避免需要引用第三方的套件。

軟體界常常聽到的一句話「不要重複打造輪子」，

不過你要去哪裡找這些輪子、引撆或是方向盤呢？

就是車子為例，假設你要組裝一台汽車，

套件管理工具就像是個代理商，

進口了各式各樣的套件讓你組裝的你夢想中的車子。

(當然你也可以自已成為代理商--**建立自已的Nuget Server**)

你可以找到各式各樣的套件，包含不同的版本，

「哇!!這可以找到1946的法拉利車胎!!!!」。

微軟提供了相當方便的套件管理工具「Nuget」，

像是Ruby有Gems或是Nodejs有Npm，

不同的語言有不同的套件管理工具。

透過Nuget你可以下載所需要的套件，

就好像你打了一通電話給代理商，

他就把你需要的零件通通都寄過來了。

(現在可以打造你自已獨一無二的車子了)

在這裡我要暫停一下，

或許該提一下**版本控制**。但是我不要!!!

想像一下，你手工打造了一台夢幻跑車

「1946年的法拉利車胎 ，2015年福特底盤再加上1985年麥加倫的車頭燈....」(噗!!)

Cool ! 你肯定有一筆長長的「清單」，

你可能還會在fb打卡分享，然後馬克祖克柏(?)還會要求你教他怎麼DIY組出這台車。

該怎麼作? 如果真的有人也想打造一台一模一樣的車子，

我想你不可能會把這些零件通通寄給馬克祖克柏，運費、時間成本太不符合效益了

別忘了，我們可是有一個超級代理商 「Nuget 」!

我們只需要把「清單 」寄給馬克就好了!

馬克可以直接從超級代理商 「Nuget 」拿到他所需要零件。

實務

實務上，當專案進行到一定程度，

一定會引入相當的第三方套件，

對C#來說，他只是個「.DLL」的二進位檔，

對我們來說他並沒有什麼版本控制的意義，

因為我們不會也沒有必要修改他。

(其他語言來說，如nodejs是js檔，雖然是文字檔，

但是以組件的角度來說，也是沒有修改的意義)

我們所需要的只有「組件名稱」以及「組件版號」，

當別人要透過版本控制取得你的程式碼的時候，傳輸檔案的量就會有明顯的差異了

一包組件可以大到幾百MB，而一份清單只需要幾KB，

節省下來的時間，都可以讓你作個伸展操了。

另外，你也可以透過版本控制查詢過往組件的汰換記錄，

這在實務上查找問題是非常有幫助的。

--

來看看實際操作

以Visual Studio 2013為例，

對著方案檔按右鍵選取「Enable NuGet Package Restore」

完成以後，會在方專底下新增一個.nuget資料夾，

並且有著以下幾個檔案，

「NuGet.Config」

「NuGet.exe」

「NuGet.targets」

畫面如下:

大多數的時候，我們只需要專注在專案的開發，

而不需要來看「.nuget 」資料夾，

唯一需要的情況是引用的套件，

引用套件的步驟可以參考黑大的「還在揮汗徒手安裝程式庫? 試試NuGet吧」

如果安裝成功，就會在你的專案產生一份

packages.config檔與packages資料夾。

packages.config就是清單，packages資料夾裡面放的就是你的零組件。

我們沒有必要傳遞零組件「packages 」資料夾，

只需要傳遞這份清單「packages.config 」，

簽入你的版本控制吧 !!

簽入你的版本控制吧 !!

簽入你的版本控制吧 !!

很重要，所以說三次。

小結

這樣一來，任何與你共同開發專案的人員，

都可以拿到同一份組件清單，

而且大家都可以跟超級供應商取得正確版本的組件。

又是美好的一天，Good Luck !!!

[[[本誌僅為個人分享與記錄，不保証內容永久正確性，如有謬誤、疏漏或侵權還請留言告知]]]