Bruce 的玩具間

my works and notes on ruby, rails, git, ubuntu linux, mac os x, etc...

在T客邦 新進工程師如何學習 Rails

| Comments

T客邦有許多優秀前輩經手並建立起來的 codebase 與 infrastructure、數個以維護為主的產品、不固定的新網站開發需求、已實行一段時間的軟體工程與專案管理方法等,因此在許多人眼中是不錯的 Rails 開發者練功環境。

也因此這是許多對T客邦工作有興趣的人會想知道的事,這次趁機會寫出來給大家參考,T客邦是個好溝通、氣氛佳、愛學習的團隊,歡迎來應徵。

但是,若抱著「我什麼都不會,但是我願意學習」的心態來應徵,恐怕機會是比較小的。如果有心,應該會展現在「我在某某線上課程完成多少課」、「我做過這個那個 side projects」或「我有個技術筆記分享部落格」等結果上,如果跟你競爭的應徵者多少有這類的成果可參考,那結果...你知道的。

這部分還可以參考我的另一篇文章 應徵 Rails 工作的心得

Rails 101 訓練

T客邦長期都使用 XDite 的教材 Rails 101 進行新人訓練,但一直有隨著時間進化,目前除了熟悉 Rails 功能、coding style,也會順便練習實際的工作流程。

  • 使用 Rails 101 的題目,但會加上一些限制,例如不准使用 scaffold generator
  • 負責帶新人的同事會用 Redmine 派票,也會要求養成回報到票上的習慣
  • Git 分支策略採用 GitHub flow,branch 名稱也有命名原則
  • 每個 PR 都會抓效能問題、不良的開發習慣、可改寫得更漂亮的地方與 coding style 等問題

這套練習還包含架設一台 Ubuntu server、用 Unicorn 跟 Capistrano 達到 zero-downtime deploy 等。

線上課程與文章

公司會要求的只有上述 Rails 101 的練習,其他的就只能看個人願意花多少時間學習/練習了。

所以觀看線上教學、閱讀 tutorial 或官方文件等都都是要自己去安排的。不過公司會補助一些線上課程的費用,例如 Code School, RailsCast, TeaLeaf 等。就算不在目前補助範圍內的,有需要的話也可以談。

另外就是工程師之間都會互相丟好文章連結、推薦不錯的書籍或 Leanpub 電子書等。最近復活的 Techbang 技術部 粉絲頁 前 20 幾則文章基本上都是從頻道紀錄裡撈出來貼的。

追程式碼與查資料

由於 Techbang 的許多專案都累積幾年了,有些架構不直覺可能是有原因的,因此接到某些票發現解法不單純的話,有可能需要追某個功能的所有相關 code、翻那段 code 的 git 修改歷史紀錄、找出對應的票並搞清楚當初設計的原因、繞過或處理歷史包袱等等。

有些功能則是沒有前例可查,但可以用關鍵字找網路上的範例或構想、查官方文件想辦法兜出解決方案、研究別人的 open source project 是如何實做的等等。

讀別人的 code、上網找資源兜解法,常常可以學到很多技巧、探索一些之前不知道的 API、library 或工具。

當然也不是派了票就放你自生自滅 生命會自己找到出路 ,有遇到問題都可以提出來討論,工程師前輩或熟悉業務邏輯的 PM 會很樂意提供意見。

workshp 的斷線備案 - 離線 bundle install

| Comments

之前準備在 Rails Pacific 上帶的 Refactoring workshop 時,想到以前參加 conference 時 wifi 通常都很不穩,因此有先想一下斷網備案。

但 Rails Pacific 2014 的現場網路很穩(感謝中午吃飯時間還在架設網路的小蟹),這招不但沒用到,而且還有幾位遇到 nokogiri 裝不起來的問題。

如何離線 bundle install

簡單來說就是用

bundle package

把 gems 放到 vendor/cache 裡。之後透過 usb 碟等離線方式 copy 給別人後,請他跑

bundle install --local

詳細的設定與原理可參考官方文件 bundle package

但不同作業系統可能會不相容,有些 gem 像 nokogiri 可能也無法只靠這樣安裝,應該避免使用。這次 workshop 是因為最後一題的測試使用到了 capybara,又因為生病沒有注意到而沒排除掉。

以上,提供給要帶 ruby 相關 workshop 但擔心網路問題的人參考,這只是很陽春的記錄,也許您有更完整的備案準備方式,歡迎留言指教 m(_ _)m

Refactoring Workshop 補充 (Rails Pacific 2014)

| Comments

2014-09-26 我在 Rails Pacific 主持一場 Refactoring 的 Workshop,這篇是補充一些可參考的資源。

原始投影片

個人其實對這次的品質有一些遺憾,有些細節跟題目設定都沒有很好,也沒有足夠的排演,實在對參加者很抱歉,但我真的盡力了,且讓我解釋一下發生了什麼事。

Rails Pacific 開始的前幾天,因為下腹持續疼痛跑醫院,醫生建議我立刻掛急診做斷層掃描,依照報告結果選擇要「住院+打抗生素」或「住院+開刀」,結果我回醫師說:

可是我禮拜五有活動耶

醫師就一臉無奈:「我們醫生是這樣建議啦,但還是要尊重你的意見」,於是 workshop 教材還是做出來了(驚險萬分),我只能說這真的是用半條命換來的,其實 workshop 當天早上我人也在醫院,現在寫這篇的同時,身體也都還有一點不舒服。

進入正題

pry 的進階

關於 Concerns

為什麼這個 workshop 完全沒有提到放進 concerns,即使有些題目其實是可以用的?

“Any application with an app/concerns directory is concerning.”

請看這篇文章 http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/

需了解這其實沒有標準答案,需依照條件,例如說如果是拋棄式活動網站(只維護短期),「花時間把架構搞得很好」是錯誤的。團隊現有慣例與未來接手維護的安排也都是要考量的點。

只有一個地方用到,還要抽成 method 嗎?

這基本上有兩派說法,容我引用 Ga Dii 的心得

其中印象比較深刻的是被問到對於 over refactoring 的看法:Akira 說他 over refactoring 的經驗是過度抽象化,有時候甚至是 commit 之後才覺得後悔;Ryan 認為有時候一些 method 只有在一個地方被呼叫到的話,就不應該抽出來,而是讓整個 function 一氣呵成;Nick 則不贊同 Ryan 的想法,他認為這些 method 即使是只有被呼叫一次,但如果抽出來能夠讓 code 可讀性變高,那還是應該要拆開比較好。

不過我沒有當場聽到 Panel discussion,因為那個時候我人在醫院。

Service Object 的補充

RailsCasts 上有一篇講得不錯(付費) http://railscasts.com/episodes/398-service-objects

Form Object 的補充

也是 RailsCasts,也是付費 http://railscasts.com/episodes/416-form-objects

需注意 workshop 主要目的是帶觀念,production 網站要使用的話,應該用類似 Reform 的工具來做比較理想。(Reform 的作者也就是這次的講者之一 Nick Sutterer)

在T客邦工作滿一年紀念

| Comments

今天正好是在T客邦工作滿一年。

這一年發生的事太多了,值得寫一篇紀念文

成長

去年我整個就是亂寫,知道的也不多,Ruby debugger, Capistrano, Unicorn 之類的東西也都只聽過沒用過。

這一年來除了接觸很多有的沒的工具(現在看來,都是很基礎的東西,但當時對我來說像天書...),甚至小事如 coding style 也有固定下來。

附帶一題,在T客邦會抓 coding style 問題,多一個或少一個不符合團隊習慣的空格都會被退回去修改。

今年也買了 Aeron 椅,加上「在公司登入 Facebook 測試帳號,就會懶得登入主要帳號」的政策(自己訂的),讓我每天的效率提升不少;以 2014年2月跟8月相比,RescueTime 花在 Software Development 類數據增加了 23%。

Aeron 椅的部分有寫了一篇文章:改坐 Aeron 椅提升工作生產力

回顧這段時間發的技術相關文章

有一些讀基礎文件的心得

也有因為不順手而進階研究了一些工具

也跑去參加一些上課、活動

希望今年也可以繼續學學新東西、寫寫部落格 XD

這一年在工作上最高興的成就

維護中的 rails projects (7個) RSpec 全都修成綠燈了

我應該跟不少人提過,我對現代軟體開發有三件事情很在意,分別是:

  • 程式碼版本管理
  • Issue tracking
  • 自動測試

在我進T客邦前,版本管理跟 Issue tracking 就已經有了,但各 projects 的測試都有幾個壞掉以致於不能跑完。

終於在滿一年之前幾個禮拜開始,把維護中的 project 的測試全部重寫,現在全都是 pass 狀態了。(不過 coverage 還很低,這是接下來這年的任務)

而且為了避免老是忘記跑 test 而逐漸敗壞,雖然沒有架 CI,但是有土砲一個「測試失敗就會中斷 deploy 流程」的機制。

新計畫

最近在準備一些新計畫,有些是會公開的,敬請期待。

超棒的 rails console 設定

| Comments

這篇文章現在搬到新站: 超棒的 rails console 設定

這篇是我閱讀 Using pry in production 後,結合我自己的經驗與公司前輩留下來的設定等,最後得出的一套組合。由於主題的關係這篇只介紹 rails console 相關的部分,實際上那套組合還有別的東西,以後若有機會再另外介紹。

ps. 依照 Using pry in production 的設定將會受到一個 readline 的 bug 影響,在 pry 解決該問題前,本篇有 workaround 教學。

想達到的效果

1. 預設漂亮的格式、還可以輸出 table

注意到 prompt 顯示出 project 的名稱,而不是預設的 "irb" 或 "pry",同時維護多個專案的話很實用。

2. 在 staging/production 的 rails console 會有明顯提示,防止手誤

...

(完整內容請到新站觀看 超棒的 rails console 設定)

改坐 Aeron 椅提升工作生產力

| Comments

這篇文章現在搬到新站: 改坐 Aeron 椅提升工作生產力

幾個禮拜前下重本買了一把 Herman Miller Aeron 椅放公司

其實我早就知道這張強大椅子的存在,但猶豫了好幾年,因為雖然有人會分享坐起來很舒服、效率會提升之類的,但能提昇多少生產力呢?很多人都是憑感覺講,這種的我都不相信,因為感覺是很不準的,最至少拿出一人樣本的數據吧!?

因此,這篇是把我這段時間 time tracking 的記錄變化跟心得整理起來,希望有幫助到正在考慮買 Aeron 椅的人。

...

(完整內容請到新站觀看 改坐 Aeron 椅提升工作生產力)