不好 http://erp-book.heroku.com/ch4-helper-antipatterns 我寫的 Helper Antipatterns

http://ruby-china.org/topics/1687 我在這裡有回覆過

Aeron 才是好東西啊。可以連續寫 code 超過 5-6 個小時還不容易累....

我家裡放一張公司放一張...

github 也是 2.3 項目

被 @ouyang 提到了。所以也來提一下我是如何寫出這些篇原創文章...

1. 融會貫通

也曾經有台灣朋友問過我是如何可以保持這樣的高產能的一手文章？他們也不是不想寫 blog，而是往往每次剛動筆不久，就又擱下了。拖拖拉拉開了幾個網站到處參考，寫了幾個鐘頭才擠出了一兩千字。但文章起得了頭收不了尾，所以最後也不敢刊登，後台滿滿都是寫一半的草稿。

我寫文章的寫法其實不是這樣的：我在開發時累積了很多經驗，而我平日學習複習的方式是讓經驗累積成一連串融貫的想法，而不是片段的記憶。這造就了我為什麼寫文章總是長長一篇，全面性的講述。因為每篇文章後面都有一個總想法在。

2. 熟練技術

我在寫任何文章時，幾乎不開任何網站，所以寫文自然不慢（Github hack 事件，5000 字的文章只花了我 1hr 寫作完成）。文章裡面的大多數想法都是我原生的融貫想法，在練習和實作技術時，我會先有一個猜想，然後去實踐，接著得利了就重復利用。累積成一整套的東西。于是在寫引述的這些技術時，我幾乎是熟到不能再熟。在行文時就十分利落。至於文章內提到的參考文獻，我多半是先用 Markdown 的 [] 先丟印象中的關鍵字括起來，最後文章完成時再上 google 找連結和正確標題補進去。

3. 大量閱讀、思考、實踐，並整理

我在小時候就練就了中文速讀能力，而且平日我的興趣就是閱讀，不僅是程式方面的書籍，各樣領域的書我都看，大學時代看最兇的是歷史軍事小說，就業後讀很兇的換成營銷、管理、創業、敏捷；程式語言、架構實踐、Design Pattern ...etc.

當然讀過不是就算了，每當讀完一本書，我就會嘗試整合到我現在大腦的資訊架構之中，或者是暫時當做零碎的記憶片段儲存起來。有的時候東西讀多感觸多了，就會自動融合起來。

職業生涯中，我有兩年的時間是在 build 一個 startup，這裡面的每樣工作都是我親自先做過再聘人撐起來，不管是 develop, operation, marketing, content optimization, hiring, management ...樣樣都是我在管。這麼廣的工作面向強迫了我實踐了我讀進的每段知識。而且整合成一段無縫的經驗...

工作上只遇到問題，我就去買書回家讀，找出可能解法，然後僅可能實驗解決。為了讓組織可以自己運轉，不讓事情都堆在我身上，從而節省我的力氣，我甚至為了每個面向的工作都打造了 SOP。在寫 SOP 的同時也連帶讓我順便總思考整理我在這些工作上所學到的經驗...

而寫 SOP 的好處除了總整理可以 delegate 出去之外。我知道我自己的記憶沒那麼牢靠，於是之後遇到類似的事情，找當年留下來的筆記，可以大量節省我的時間，不需再重造輪子。

4. 把書當作是別人寫好的 gem，我自己維護一個 generator 和寫一套 best practices gem

summary

我想這是為什麼別人看我文章原創性且含金量高的原因。

因為這些東西的確都是我想過練過才寫下來的...

可以買一張 Aeron，工作更舒適

1. 500 問題，在開發過程中我就會使用 airbrakeapp 去監測，傳送給 RD 馬上修理
2. 在上線前我不會特別去注意 Performance 問題，就是把功能專注完成即是。但在正式上線前，我會安裝 newrelic rpm，在 staging 打一輪壓力測試。然後把超過一個標準值，比如說 controller 超過 500ms，抓出來 refactor 掉。務必讓速度在 production 模式下，可以平均低於 100ms。
3. 上線之後，我會安裝 pingdom 確保網站倒掉（機器或大量 500）即時發簡訊給我，通知 RD 處理。

4. 在初期我會安裝 scoutapp 裝在 server 上，這是類似 munin 工具，但收費。（但我們在後續不忙的階段，會用 munin 去換掉 scoutapp。）會這樣作是剛上線都很忙，應該把精力 focus 在修 app bug 而不是 system administrator & deep monitoring。

5. 上線後一個月要是狀況穩定，我會用 rails_best_practices 這個 gem 掃描一次 code quality 是否有嚴重不恰當的寫法，儘量 refactor 掉。（趁開發壓力較低，又記憶猶新之時）

總之原則是，什麼時候作什麼事，若問題能用錢解決就用錢先解決，因為開發戰力和專注的方向是錢換不到的。

我的團隊，網站上線甚至有一輪檢測 SOP ...

我只想澄清我們的確有自己寫的實力。你可以翻 ruby-china, 和 ruby-taiwan source code 我們貢獻了多少 commit 和實做了哪些 feature，還有 refactor 了哪些部份。

直接把內容貼過來了...

光看上下文，猜測不出來不知道你為什麼想要投入 Rails 界。

是上班無聊，還是作東西有趣，還是夢想有天能做自己的東西？而希望透過走這一條路扭轉。

提供我這五年的故事給你參考：http://xdite-smalltalk.tumblr.com/post/18303489993

這個小 blog 裡面還有一些關於探索自己想要什麼的文章，有時間也可以看一看

T_T (?) 大概是因為我放在 heroku ...?

我覺得你應該問問自己，你自己有什麼樣的人生目標...

37signals 那樣作是有原因的。

1. 把責任移到 controller
2. attr_accessible 不是最好的方案。很容易搞死人，而且有時候沒有解決到問題...

我直接用 http://embed.ly 這樣的服務去作 XD

雖然我覺得這是一個故意要給我難看的帖 (?)

不過很可惜我現在也找不到當時的環境去弄出來了。不知道是不是有人可以幫我找到這樣的環境再作類似的事？

我之前是在 Ruby 1.8.6 + Rails 2.3.1 + ActiveRecord(MySQL) Macbook 1.83 2G + SATA 硬碟上面跑這種 benchmark 的。不用跑到 100 萬。50 萬就爛掉了...

死因就是 memory bloat。不過我想我大概是帶著 ActiveRecord 的印象自動在回。沒看清這題是 MongoDB

https://rails.lighthouseapp.com/projects/8994/tickets/6129

我也遇到類似狀況。後來我就決定還是自己培養年輕人了.....

http://stackoverflow.com/questions/5099460/mass-insert-mongoid # 一次塞 batch 而不是 new 100 萬個 object。

而且我另外的建議是拆十萬條塞一次這樣

不可以用 1 樓這種用法，你等於是 new 100 萬個 object 在 memory 裡，這樣會 memory bloat 搞到你的電腦 crash 的

自己寫的關於 util 類的，我放 lib/assets/ 第三方的比如說是 jquery.ui.* 的我放 vendor/assets/

至於是比如說 project 內獨有，特別是 controller specific, 或者是 feature specific 的，我才放 app/assets

tree

要寫 mysql2

我都有在用了

用 rbenv

class CommonCell < Cell::Rails
  helper Handicraft::Helper
  helper :open_graph
  helper :avatar
  helper :posts
  helper :users
  helper :tags
  helper :techbang_sso
  helper :advertises

  include ActionController::Cookies
  helper HasMobile::ViewHelper

你要不要考慮單獨兩個不同的 model 然後再寫 module 進行 mixin

看起來真是不錯

http://blog.xdite.net/posts/2012/01/15/how-to-design-helper-3/

今天寫了這一篇 Helper AntiPatterns

https://gist.github.com/1391980 # stackoverflow & reddit algorithm

你該不會是用 ActiveRecord 生成物件再儲存吧...