居然在 2013 年的筆記看到，沒想到現在還是沒有切確的執行，真是汗顏 >"< 希望在#2018review時候可以有點成績

如果你每兩個月讀完一本程式設計相關的好書， 大約是一天讀 35 頁， 你很快就能對整個產業有清楚的理解， 並且將能你和你身邊其他人清楚的區分出來。 -- Steve McConnel, 軟體建構之道

懷念的 SFII，讓我用一張龍的「二陪」來懷舊一下！

終於想到要把 pelican 塞進去 docker 來做事了！

Link: https://hub.docker.com/r/samuelololol/docker-pelican/

當你真正的洞悉問題的本質時，你所做出的解答就會以那個最簡潔的形式呈現。 -tweet from Qing

講的實在是太好了!

在設定 Raspberry pi 設定的時候，往往都是 remote ssh 因為灌好之後， 幾乎不會有人把它直接拿來接螢幕作設定。但是當你要修改的是 sshd_config 的時候，千萬要很小心，因為一個不小心設定失誤就斷線了。

為了預防這個雷，在重啟 sshd service 之前用這個 script 就能檢查是否有問題了

$ sudo /usr/sbin/sshd -t

一行結束，如果有問題就會把問題印出來，如果沒問題就船過水無痕囉！

Code Review 在軟體開發是佔很重要的一個環節，通常聽到的情況是在要 commit code 前、pull request 之前，或是 fixing tracker 之前的一個動作，確保新增、修改的部分不會影響既有的架構，也不會產生額外的問題。

如果是 fixing tracker ，抓緊幾個問題：

• 為什麼要修？
• 修了哪些東西？
• 和之前差別是什麼？
• 有沒有影響到其他的地方？
• 為什麼修這樣就修的好？

今天某匿名大神同事分享了幾個重點

1. Reviewer 要了解問題是什麼，如果不清楚，不是 requester 沒有寫清楚的話，要請 requester 解釋清楚
2. 如果是 workaround 要問清楚採取 workaround 的原因
3. Reviewer 從自己的理解，看看新的 design or implementation 有沒有問題。特別注意一般容易會被忽略的地方，eg, error handling, boundary, etc 以及會不會造成其他 side effects
4. 要了解一下之前沒有被測到的原因

以往修 tracker 大家都是憑直覺修，但是像這樣具體列出來，拳拳到肉真的很有感覺！

預設文章連結網址會變成這樣(已改)

http://samuelololol.github.io/2017/02/zhun-bei-gai-ban.html

怎麼會是拼音 -_-|||，無法忍受啊！看起來是 pelicanconf.py 裡面的設定

ARTICLE_URL = '{date:%Y}/{date:%m}/{slug}.html'

然後搭配文章(markdown)裡面的設定

slug: pelican-article-link

這樣就可以改成你要的uri, 不過有點麻煩，又怕衝到，看來之後再加日期當 prefix 好了

詳細設定可以看這邊 Translations

Medius

參考的 template/theme 來自於Medius demo website(source), 是基於 medium 的 design 在 pelican 上面實作的一個 theme. 想要來試試看，順便修改一些自己的東西在上面。

改版目標:

1. 換 theme
2. 改成首頁全展開，不要 "read more.."，然後文章連結還是繼續留著這樣
3. 加個免費的 google analytics
4. Disqus?
5. 其他再想想 ...

Timo Tolkki's new album:

Revolution Renaissance

Recommanded:

• Heroes
• I did it my way
• Keep the flame alive
• Last night on earth