來自Det!C的牢騷～

(前略，因為不知道要寫什麼引言XD)

這陣子一個很苦惱我的問題，
就是在solr傳出來的結果是依照關聯性(score)排序，但下了query後，卻變成用primary key排序。
因為Ruby語法還不熟，加上不知道用什麼關鍵字去Google，整個卡關卡超大，
總之，是備忘用筆記。

原則上，最初的一步是在solr的fl參數，將score加上去，像是 :fl => "score, id"這樣，
才會把比對的分數一併傳出來

問題來了，在query時要用solr的id去作，同時用score的分數作排序
後來才知道應該要傳hash進去，以下則是邏輯上的思考
(由於id是primary key，因為不會重複，所以作為hash的key)
(而不同的id可能會有相同的score，所以score作為hash的value，拿score當key會天下大亂XD)

# res is the result of solr
key_array = res.map { |k| k['id'] }
value_array = res.map { |v| v['score'] }
id_and_score_array = [key_array, value_array].transpose
id_and_score_hash = Hash[*id_and_score_array.flatten]

這樣target_hash就是我要的hash了

最後是query時要用到sort來根據score作排序，但拉資料要用id來拉

post_find = Post.find(key_array)
post_score_array = [post_find, value_array].transpose
post_score_array.sort! { |a,b| b[1] <=> a[1] } # sort by value
@post = Hash[*post_score_array.flatten].keys

這樣@post就是依照solr的score去排序了，但以上顯然是很不漂亮的寫法XD
所以改成以下寫法，就可以得到排序後的結果了

id_score_hash = Hash[*res.map { |h| [h['id'], h['score']] }.flatten]
@post = Post.find(id_score_hash.keys).sort {|a, b| id_score_hash["#{b.id}"] <=> id_score_hash["#{a.id}"]}

前略(誤)
總之開始在新環境後，接著就是學習Ruby on Rails
排版不是很好看，還請見諒 

學習流程如下：

1. Getting Started with Rails
   中文化 
   (1.5 手刻Getting Started with Rails)
2. XDite的2010 Ruby on Rails 書單 與 練習作業
   還有ihower的作業: 簡易論壇系統

相當建議新手照著Getting Started with Rails先全作一遍
用Scaffolding去作也沒關係，先熟悉一次流程，大致了解一下整體運作
（若本來就有相關經驗的話可以跳過Scaffolding這段，直接手刻）

參考資料如下：

• Ruby on Rails 實戰聖經
  
• Rails API Documentation
• Try Ruby!
• Google大神XDDD (這其實用最多)

那麼開始筆記，分享一些整體遇到的重點、問題與解決方案

事前準備，好的機器與好朋友（無誤），前者方便你使用，後者亦同（喂喂）
好的版本控制跟上手的編輯器，可以幫助不少，建議是git作版本控制，因為很多資源可以撈阿XD
看一下網站上的前兩章了解一下基本概念

=以下都在ubuntu 10.04底下，使用Ruby 1.8.7與Rails 3.0.7完成，沒用RVM=
用中括號的數字，表示是Getting Started with Rails內的章節，像是[7.3]就是該網頁上的7.3的部份

那麼，作為第一篇網誌，就聊聊Det這好人的一些瑣事吧(笑)

我猜不少人會認為說，一個待退的員工，在工作上的事情理當不需如此操心。
事實上，在其他同仁的評價中，將離職的員工是該如此。
但若是沒有其他人可以代替你的職務，或許你會跟我一樣，帶著些微而又不必要的責任感。

是的，小弟我就是有著這種窘境，
雖然我已經被公司放生很長一段時間了，其實搞不好上頭也不清楚我平常再做些什麼。
實際上上頭覺得怎樣並不重要，問題在同僚與客戶上，有著許多你會想努力去解決，但又無能為力的情況。
而你只希望，同僚可以好過一些，至少不會被客戶追著打，但最後還是無能為力。

做設備的，似乎不該像軟體業一樣，在機器還沒ready前就出貨，苦的是無盡維護的人員與實做跟修改的程序師。
（軟體業一般來說，會先推出後再加以patch，不太可能等到軟體完全成熟後再推出）
可以想像，未被發現的設備機構限制，得由軟體去避開(而且你還不知道哪裡有問題，通常是採到地雷後才知道)，
然後設計部的只會說這是硬體限制(而且是他們尚未得知的)，主管只會要你把大便吃下來，跟人體蜈蚣一樣。

問體在此，原本嶄新的機構便是為了加速流程，
但礙於硬體限制，軟體為了避開，而迫使加大流程時間，這樣硬體的優勢立刻蕩然無存。
那個，可以想像有三種解決的方案：
1. 客戶認賠，皆大歡喜
2. 公司認賠，機台回收重做
3. 軟工認賠，程式砍掉重練

顯然的真相永遠只有一個。


工作上的好人，就先點到這邊，反正對於待退員工來說，這些都只是牢騷。