QCon 上海站 2014 遊記

去年還是前年就有注意到 QCon 大會在大陸開始有了,囿於時間和費用考量一直沒成行。今年中換工作後比較有空了,就決定報名 QCon 上海站。第一次買破萬塊的 Conference 門票(四千左右人民票),收穫跟見識長進不少。Qcon 是個專業於軟體開發的研討會,議題多元,除了技術面,也有管理面、產品面、創業的議題,重要的是講者都是工程師背景,所以調性上就是比較合啊。

QCon 一天有六軌議程,每天有不同專題軌。他們的議程設計是主辦單位先決定有哪些專題軌,然後由該專題出品人負責該軌的講者邀請、審核和品質控制,蠻像策展的感覺,基本上該軌的議程都很有連貫性,有些出品人也會搞一些該軌特別的活動,例如圓桌討論、圖像引導等等。每天早上開場的時候,出品人還會上台介紹當天該軌的議程,很像在拉票。一整天的那一軌,出品人當然也就是主持人,同時因為出品人也是這個議題的專家,所以和講者應對和聽眾的Q&A也可以應對的很好,甚至擔任外國講者的即時翻譯。相較之下台灣的大型研討會像 COSCUP 雖然有進行議題分類,但卻沒有連貫的感覺,主題感較為薄弱。

Continue reading

Exception Handling: Designing Robust Software in Ruby 投影片

這是上週末參加 Rails Pacific 所給的演講投影片:

以及演稿版本:

因應英文演講的關係,所以特別準備了演稿,不過也因此可能比較無趣一點,不像講中文這麼輕鬆就是了。

對這個議題有興趣的朋友,推薦 Teddy 的例外處理設計的逆襲 和 Avdi 的 Exceptional Ruby 這兩本書,讓我學到了很多。投影片末還有列出其他的參考資料。

亞洲首次的 Ruby on Rails 年會 – Rails Pacific 大會 9/26-27

xdite 主辦的 Rails Pacific 年會即將於 9/26-27 展開,目前還在售票中。講師陣容很強大,看得出來是一場國際化導向的專業研討會,最近的技術研討會真是越來越專門啊。

小弟也受邀有一場 45 分鐘的演講,主題是 Exception Handling – Designing Robust Software 例外處理和強健的軟體設計。

In a perfect world, every method call succeeds, users enter correct data and resources are accessible always. But the real world is brutal and failures happen. You will be miserable if you fail to design your software for a production environment.

In this talk, I will explore how to design robust software, the exception handling mechanics of Ruby and Rails, bad smells and best practices of exception handling.

寫 Ruby on Rails 也好多年了,從初學到研究進階用法、從會動到寫的漂亮,最近比較多的痛苦體悟則是在 production 環境上的一堆鳥事考驗。希望這場 talk 可以分享一些 Ruby 例外處理的技巧和錯誤處理的策略,進而達到強健軟體的目的。

ALPHA Camp 10週網路事業實戰營 10/6 開課

ALPHA Camp 是一間很特別的創業學校,跟創辦人 Bernard 聊過之後,我很喜歡他們的辦學理念,既不是電腦補習班,也不是育成中心,甚至還會面試篩選學員。來這裡不一定是因為要創業,而是學習如何將點子實作出來的完整能力,非常適合渴望換跑道進入網路產業的朋友。

我之前也有開過不少次 Ruby、Rails 或 Git 的教學,但都是非常短期一天或兩天的課程。這次有機會能擔任 Web Development Bootcamp 這一班的班導師,在長達十週 full-time 的時間裡,希望不只教會學員 Ruby/Rails 等程式設計的技能,也希望能夠分享好的軟體工程和團隊開發文化。

週四(9/11)晚上還有最後一次的課程說明會,有興趣的朋友可以來聽看看。

SSH agent forwarding 的應用

SSH agent forwarding 可以讓本地的 SSH Key 在遠端 Server 上進行轉送,也就是當你需要在選端 Server 上使用 SSH Key 時,就不需要將你的 key pair 手動複製到 server 上,是個暨方便又安全的作法。

舉例來說,首先 SSH 登入進 Server1,接著在 Server1 上登入 Server2 時,就會自動使用你本地的 SSH Key:

Local ---(SSH)---> Server1 ---(SSH)---> Server2

那要怎麼使用:

方法一:每次要 Local 連上 Server 時,加上 -A 參數:

ssh -A user@{you server1 ip}

方法二:修改 ~/.ssh/config 設定,加上 ForwardAgent yes,這樣就不需要每次連都加上 -A 參數。例如

Host server1
  HostName 106.187.36.122
  ForwardAgent yes

實務上有什麼應用呢? 這裡舉兩個常用的例子:

Bastion Host

在 AWS 的架構課中,每次講 VPC 就會提到 Bastion host 的概念,也就是整組內部網路只開放一台 server 可以從外部做 SSH 連線,如果需要 SSH 連線其他機器,都必須透過這一台 Bastion host 轉過去。這樣做的目的當然是為了安全性,我們可以特別加強這一台 Bastion host 的安全,例如鎖外部 IP 或是裝 SELinux 等等,這一台的用途就專門只做 SSH 連線,畢竟越簡單越容易防護,更細節的 OS 防護原則可以參考 OS Hardening Principles

既然 SSH 連線都必須透過這台 Bastion host,那麼 SSH agent forwarding 這招就很好用了,就不需要、也不應該把 private key 放到 Bastion host 上面。

Git Deployment

如果你有用 Git 版本控制系統的話,你的應用程式佈署也很可能需要在 Server 上把 Source Code 從 repository 拉下來,這時候就會需要 SSH 的權限。

以前小時候不懂事,總是在 Server 上生出一組部署專用的 SSH key pair,然後在 Github 上設定這組 key 可以讀取 repository。後來發現這完全是多餘又增加安全風險。既然有權限佈署,那麼也就表示你應該就有權限可以讀取 source code,那就用你自己的 SSH key 就好啦,就不需要在 server 上擺一組 SSH key pair 了。

如果是用 Ruby 的 capistrano 做部署的話,只要設定一下就可以了:


set :ssh_options, {
  forward_agent: true
}

這樣在佈署程序中就會用到你自己的 SSH key 去 Github 拉 source code 了。

參考資料