關於 #經驗 的內容

在Ruby on Rails 容器化最佳指南（一）我們已經大致說明了製作容器的目的、用途，這篇文章會跟大家介紹如何去撰寫 Production-ready（正式環境）可用的容器鏡像。

如果不想花太多時間在了解細節的技巧上，可以參考如何在幾分鐘內容器化 Rails 專案這篇文章，裡面有有針對容器化所製作的 Ruby Gem 可以快速解決這方面的問題。

在不該使用 Ruby 的 Class Variable 理由這篇文章中有大概提到 Class Variable 的意義在 Ruby 裡面跟我們在其他語言認知到的 static 關鍵字是不同的，那麼實際上到底差在哪裡呢？

在閱讀 mruby 原始碼之前我也想不通，然而在使用不同的技巧組合驗證特性之後，終於理解了 mruby 實作中對 RClass（Class 物件資料）裡面所定義的 iv_tbl（Instance Varable 對照表）的意義。

前陣子跟卡米聊到一個神奇的 Ruby Class Variable 使用問題，才想起來從使用 Rubocop 之後會自動建議避免使用，就很久沒有使用 Class Variable 這個機制。

在 Ruby on Rails 中依舊還是有一部分實作會使用，因此並不是完全不使用。然而，在大多數的時候我們應該避免使用，除了對這個特性不夠了解之外，也是因為我們通常用不到。

今年 COSCUP 的時候前同事 Cindy 分享了 Rails 容器化最佳實踐 這場演講，裡面提到我們在五倍紅寶石在將 Ruby on Rails 專案轉換為容器的一些技巧。

這系列文章會分享一下這個容器化的過程是怎麼判斷、處理以及在過程中需要注意哪些事情。

最近剛好在工作中聊到關於現今工程師的狀況，相比過去我自己在學習寫程式的那個時間點，現在多了很多「轉職工程師」這樣的人存在，也有不少是我認識的人或者朋友。

不過，我們是抱著怎樣的心態去當一名工程師的呢？

這周都在忙 SITCON 的網站，結果就錯過週二寫 PaaS 入門指南的時間了（剛剛看 GA 還發現大家都已經習慣週二來晃～） 這篇文章其實是順便當寒假作業（雖然老師沒強制，不過剛好可以複習跟檢視我對 RWD 的熟悉度）

其實我一直對 W3C 標準跟歷史不太熟，所以沒辦法像許多高手根據標準跟歷史來討論這些網頁技術上的問題。 不過還好，我多少算是有經驗跟實作，以下就從我所「知道」的 Responsive Web Design 來談談吧！

這邊文章大致上會從這些方向去討論：

• Responsive Web Design 的過去
• Responsive Web Design 的現在
• Responsive Web Design 的工具
• Responsive Web Design 的運用

我想又會是篇很長的文章，大家就泡個茶慢慢讀吧 XD

雖然自己不是什麼高手，也沒什麼有建設性的建議，但是最近老爸公司來了實習生，我在跟實習生的互動過程中，發現了一些學生在學習程式上的一些要注意的部分，所以想來分享一下。

（先不討論我怎麼會在老爸公司寫扣，還有實習生怎麼出現的這些神秘問題了 XD）

其實已經有很多前輩已經分享過非常多有用的技巧與方法，這邊就單純以我個人的經驗，還有與實習生接觸後，我在教導實習生使用 Rails 和融入老爸公司開發流程的過程。（雖然以前只有我自己寫扣拉，哭哭）