• Nginx 設定檔
• 設定 systemd 啟動檔
• Logrotate & Iptables 設定

Nginx 設定檔

由於編譯 Nginx 時把 prefix 設定在 /usr/local/nginx 下，所以設定檔就在 /usr/local/nginx/conf 下，先編輯 /usr/local/nginx/conf/nginx.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

user  nobody; #這邊的 user 和 Rails App 的 user 是不一樣的設定，但是要考慮到 Asset File 的存取，也就是這個 user 必需要可以唯讀 Rails App 的 public 目錄
worker_processes  4;
error_log  logs/error.log  info;
pid       /var/run/nginx.pid; #設定 pid file 的位置，必需和後面 systemd 設定檔一致
worker_rlimit_nofile 40960;
events {
    worker_connections  10240;
}#worker_rlimit_nofile 和 worker_connections：為了突破系統開啟檔案上限的設定，必需一起設定，一般來說 worker_rlimit_nofile 為 worker_connections x worker_processes

http {
  include       mime.types;
  default_type  application/octet-stream;
  access_log logs/access.log;
  sendfile        on;
  keepalive_timeout  65;
  gzip  on;
  send_timeout 600;
  gzip_min_length  1000;
  gzip_buffers     4 8k;
  gzip_types       text/plain application/x-javascript text/css application/xml text/javascript;
  client_max_body_size 100M; #關係到上傳檔案的上限
  passenger_root /usr/local/ruby23/lib/ruby/gems/2.3.0/gems/passenger-5.1.1; #Passenger Gem 的根目錄，會因為使用的 Ruby 版本與 Passenger 版本變化
  passenger_max_pool_size 16; # 最大同時可以存在的 Rails App 行程數，請依照系統的記憶體大小計算，一般應該是 "(總記憶體 x 0.75) / 單一 Rails App 使用記憶體"，例如 4GB 的機器，單一 Rails App 記憶體約 150 就是 ``` 4096 * 0.75 / 150  = 20 ```
  server{
    server_name _;
    location /{
      return 404;
    }
  }# 對應不屬於任何 Virtual Host 的請求，在這裡返回 404 Not Found 的頁面。
  include valid-vhosts/*.conf; #在其它檔案中設定 Virtual Host
}

以下是 Virtual Host 的設定

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

server{
  server_name 5xruby.tw; #Virtual Host 的主機名稱
  root /home/5xruby/5xruby.tw/current/public; #務必設定為 App 的 Public 目錄
  passenger_enabled on; #開啟 Passenger
  rails_env production; # 設定 Rails App Stage
  passenger_ruby /usr/local/ruby23/bin/ruby; #如果這個 App 和 Passenger 使用的 Ruby 版本不同的話就需要指定
  access_log logs/5xruby-access.log;
  error_log logs/5xruby-err.log;
  location ~ ^/assets/ {
    # 讓瀏覽器快取靜態 Asset Pipeline 檔案的設定
    expires 1y;
    add_header Cache-Control public;
    add_header ETag "";
    break;
  }
}

設定 systemd 啟動檔

• 編輯 /lib/systemd/system/nginx.service

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

[Unit]
Description=The NGINX HTTP and reverse proxy server
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/var/run/nginx.pid
ExecStartPre=  /usr/local/nginx/sbin/nginx -t
ExecStart=  /usr/local/nginx/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

• 以 root 身份輸入 systemctl enable nginx 設定開機自動啟動
• 輸入 /usr/local/nginx/sbin/nginx -t 測試設定檔正確與否
• systemctl start nginx 啟動，可以再透過 systemctl status nginx 觀察啟動情形

Logrotate 設定

如果在前面的 Virtual Host 設定中有設定 access_log 或 error_log 的話，就必需要設定 Logrotate 來定期輪替 Nginx log，輪替的設定如下。

1
2
3
4
5
6
7
8
9
10
11

/usr/local/nginx/logs/*.log {
    missingok
    size=20M #單檔超過 20M 為條件
    compress #壓縮舊檔案
    rotate 10
    notifempty
    sharedscripts
    postrotate
    test ! -f /var/run/nginx.pid || kill -s USR1 `cat /var/run/nginx.pid` #讓 Nginx 重新開啟 Log 檔
    endscript
}

對 Rails 產生的 Log 也可以比照辦理

Iptables 設定

現在的 RHEL 系 OS 通常都預設使用 Firewalld 做為系統防火牆，在此先改回筆者比較熟悉的 Iptables

• yum remove firewalld
• yum install iptables-services
• 編輯 /etc/sysconfig/iptables

1
2
3
4
5
6
7
8
9
10
11
12

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 127.0.0.1 -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport ssh -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport http -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport https -j ACCEPT
COMMIT

• systemctl start iptables

到此為止就完成了基本 Rails Stack 的設定。

本篇文章的 Rails Stack 包含：

1. 系統上可以跑多重版本的 Ruby
2. Rails 5
3. PostgreSQL 9.6
4. 使用 Passenger 為 Application Server，Nginx 為 Web Frontend Server

本篇文章適用的 Linux Distribution：

1. RedHat Enterprise 7
2. CentOS 7
3. Fedora 24+
4. 其它 RHEL 衍生的，以 systemd 為啟動系統的 Linux Distribution 們 (理論上)

從乾淨的 OS 開始，步驟大致如下：

• 安裝必要套件
• 安裝 PGDG Repo & PostgreSQL
• 編譯 Ruby
• 安裝與編譯 Passenger / Nginx Extension
• 編譯 Nginx
• 啟動設定
• Logrotate 設定

注意：以下所有步驟皆需以 root 身份或 sudo 執行

安裝必要套件

1

yum groupinstall "Development Tools"，

如果是 Fedora 的話，通常還會有 “C Development Tools and Libraries” 和 “D Development Tools and Libraries” 兩種

1

yum install v8-devel v8 screen libmcrypt-devel wget libxslt-devel libxml2-devel gdbm-devel libffi-devel zlib-devel openssl-devel libyaml-devel readline-devel curl-devel  pcre-devel git memcached-devel valgrind-devel ImageMagick-devel ImageMagick npm geoip-devel pcre-devel gd-devel openssl-devel

套件說明：

主要是針對編譯 Ruby 所需，以及其它常見的 RubyGem 如 RMagick 或是 Asset Pipeline 編譯 JS 所需要的套件等。

安裝 PGDG Repo / PostgreSQL

什麼是 PGDG

PGDG (PostgreSQL Global Development Group) 是 PostgreSQL (以下簡稱 PgSQL) 的開發單位的簡稱，PGDG Repo 是 PgSQL 的官方為各大 Linux Distribution 提供的套件庫。

安裝步驟：

在這邊找到對應的 PgSQL 版本與 Distribution 的對應 RPM Url 後，在 Console 下：

以 Fedora 25 + PgSQL 9.6 為例：

1

rpm -Uvh https://download.postgresql.org/pub/repos/yum/9.6/fedora/fedora-25-x86_64/pgdg-fedora96-9.6-3.noarch.rpm

然後安裝 PgSQL Server 與開發套件

1

yum install postgresql96 postgresql96-devel postgresql96-server postgresql96-libs postgresql96-contrib

請注意如果你安裝的不是 9.6 的話，請將上面的 96 改成對應的版號即可

編譯 Ruby

這邊不使用 rvm 或 rbenv 等 Ruby 版本管理套件，而是採用將不同的 Ruby 版本安裝到不同路徑的方式來解決可能在 Server 上同時運行多版本 Ruby 的需求。

路徑設定原則：

例如 2.3 就安裝到 /usr/local/ruby23，2.4就在 /usr/local/ruby24 以此類推

流程：

• 下載 CRuby source code

1

cd /usr/src && wget https://cache.ruby-lang.org/pub/ruby/2.3/ruby-2.3.3.tar.bz2

• 解壓縮

1

tar -jxvf ruby-2.3.3.tar.bz2

• configure

1

cd ruby-2.3.3 && ./configure --prefix=/usr/local/ruby23

• make

1

make && make install

其它版本可以比照辦理。

安裝 Passenger 與 Nginx Module

• 在執行任何 Ruby 指令前請記得設定系統路徑到要使用 Ruby 版本的 bin 目錄，例如：

1

export PATH=$PATH:/usr/local/ruby23/bin:

或是把以上內容加到 ~/.bash_profile 的尾端，讓每次登入時自動執行。

• 安裝 bundler & passenger Gem

1

gem install passenger bundler

此時要注意安裝的 Passenger 版號，進入 Passenger 目錄編譯 Passenger Nginx Module，以 Ruby 2.3 和 Passenger 5.1.1 為例：

1
2

cd /usr/local/ruby23/lib/ruby/gems/2.3.0/gems/passenger-5.1.1/
rake nginx

• 下載 Nginx 源碼並使用編譯好的 Passenger Module 編譯 (以 1.10.1 版為例)

1
2
3
4
5
6
7

cd /usr/src && wget http://nginx.org/download/nginx-1.10.1.tar.gz

tar -zxvf nginx-1.10.1.tar.gz && cd nginx-1.10.1

./configure --with-http_v2_module --with-http_ssl_module --prefix=/usr/local/nginx --with-http_image_filter_module --with-http_gzip_static_module --with-http_secure_link_module --with-http_stub_status_module --add-module="/usr/local/ruby23/lib/ruby/gems/2.3.0/gems/passenger-5.1.1/src/nginx_module"

make && make install #這裡會將 Nginx 安裝到 /usr/local/nginx 下

至此為止 Nginx 已設定完成，後續操作請看下篇

今年的 RubyKaigi 2016 是我從 2013 以來，連續第四年參加的 RubyKaigi，前面三次除了去年以外都有留下一些紀錄（2013, 2014）

RubyKaigi 是神馬？

RubyKaigi 是日本最大的 Ruby 語言年度研討會，Kaigi 就是日文漢字的「会議」，在日本除了全國性的這個 RubyKaigi 外，也有很多地區性（Regional）的 RubyKaigi，例如去年底我受邀參加的大江戶 RubyKaigi 等。

今年的行程

和去年一樣，今年的 RubyKaigi 行除了參加 conf 外，同時也是敝公司的年度員工旅遊，所以提前在 conf 前一週的 9/3 出發到大阪，9/6 移師到京都，然後在 Kaigi 結束後的隔天 9/11 回台。

團員的構成是包含我在內的 12 名五倍紅寶石正職員工以及 2 位實習生（是的，你沒看錯，在本公司實習就是有這種福利）以及公司的講師和合作夥伴共 4 位一共 18 人。

行程大概是長這樣：

• 9/3 出發，晚上逛街
• 9/4 宅宅日本橋調查兵團組 & USJ 組
• 9/5 京女大交流 & 神戶.rb 交流
• 9/6 移師京都 & 嵐山遊
• 9/7 二条城 & 川崎重工參訪 & pre-Party
• 9/8 DAY1 & Official Party
• 9/9 DAY2 & 一次會 & #RubyKaraoke
• 9/10 DAY3 & After Party
• 9/11 歸國

個別行程的內容由於已經有同事寫出遊記，在此就不特別贊述，可以參考下面的連結：

• 蒼時
• @lctseng
• Roy
• Nina
• Yusheng
• Cat
• Alan
• Treekey
• Sabrina
• 孟穎

會場

會場「国立京都国際会館」應該是今年最大的亮點，很可能也是未來永遠無法超越的經典了，不愧是簽訂過「京都議定書」的地方，除了國際級的內裝和座位數（超過 1700）外，最厲害的就是會場旁的庭院，會有種讓人誤以為是在山中而不是都會區的錯覺。

庭院區的後面還有一個很大的池子，目測大概和花蓮的鯉魚潭差不多的程度，以後有機會一定還要再來看看。

議程

和往年一樣陣容堅強的議程，特色是沒有 Rails 功能直接相關的議程，然後 mruby 相關的議程很多，我個人還蠻期待 haconiwa 這個 LXC 實作的，除了和往年一樣提供日翻英口譯外，今年甚至有幾位日本講者像 @_ko1 和前面提到的 haconiwa 是直接以英文發表，對於一個在日本舉辦的會議來說算是相當不簡單的事情，不過最後總召（日本這邊叫 Chief Organizer）松田大神也在閉幕式時提到因為要節省口譯費用所以鼓勵日本講者們多多以英文發表。

@youchan 的「Isomorphic web programming in Ruby」主要是繼去年的「Writing web application in Ruby」也就是用 Opal = Ruby 語法寫 JS 和 React 後，再加上另一個新的 Gem 去做 Isomorphic，聽起來很炫，不過個人目前還無法突破用 Ruby 語法寫 JS 這個關卡就是。

第二天的 Keynote 講者 Justin Searls 之前就聽 Juanito 推薦過他好多次，除了內容外，演講技巧和 Slide 也都非常棒，可惜今年來不及邀請他在 RubyConf Taiwan 發表了。

這次和前幾年一樣也都有台灣人的議程上榜，其中也有我們家蒼時，和 iCHEF 的 John，今年會場的台灣會眾加本公司大概有 30 上下，應該是除了日本美國以外人數排第三的國家。

週邊活動

和過往一樣，RubyKaigi 這一週從會前一天（週三）到週六，每天晚上都有無限制的酒食 Party，不過和過往不同的地方是–大部份的 Party 都要自費，主要是因為今年超低的票價（Early Bird：10,000 Yen，去年同樣票種是 25,000）無法包山包海之故，唯三免費的是第二天由 Misoca 和 Agile Works 主辦的兩場並行 Party 和我最期待的 #RubyKaraoke（感謝贊助商 Drecom），這次因為沒有終電拘束器（旅館在 KTV 場地附近），最後唱到了 3:30，結束後還一起去吃拉麵，好不開心。

最後的 After Party 還特地請我們家 Nina 妹妹上去發表 LT 推一下即將在 12/2~3 舉辦的 RubyConf Taiwan 2016！

The RubyKaigi 2016 After Party & Lightning Talks! #rubykaigi (@ Gion in Kyoto, Kyōto) https://t.co/6tQD51aC9V pic.twitter.com/gVz4vB4ekM

— tzwm (@tzwm) 2016年9月10日

. @itsmeninayeh 's presentation! #rubykaigi pic.twitter.com/NdYguHWyyW

— Koichi ITO (@koic) 2016年9月10日

總結

從 2013 以來每年都參加 RubyKaigi，每年都有亮點，但對我自己來說最大的變化是每年的同行陣容都不一樣：

• 2013：自己當 LT 講者和社群的朋友同行
• 2014：和同事、朋友以及一群被 Heroku 與日本社群朋友贊助的 Rails Girls 們同行
• 2015：變成公司旅遊行程，團員 6 名
• 2016：團員變成去年的 3 倍（今年不是五倍嗎？）

每年的陣容也反應了人生階段的演變，目前的遺憾是還沒有機會作為正式議程的講者上台，希望未來還有機會。

Let’s Encrypt 運作原理

如官網所示，比較白話一點的流程大概是：

1. 用指令向 Let’s Encrypt 要求產生驗證 host example.com 的檔案
2. LE 給你驗證檔案
3. 你將檔案放在 http://example.com/.well-known/acme-challenge 下
4. LE 會發出 HTTP Request 驗證該檔案是否存在前述 URL 下
5. 如果有，則發放證書

今天要講的是用 Nginx 加上Let’s Encrypt Ruby Cli Rubygem的驗證方法

為何要使用 ruby-letsencrypt-cli 而非 LE 官方版本 CLI

• 不需要 root 權限即可執行
• 函式庫相依性較簡單
• 功能相對單純

安裝 Let’s Encrypt Ruby Cli

安裝方式就是單純的 gem install letsencrypt-cli 即可。

事前準備

• 安裝好 Gem
• 預備好以下目錄：
  • key-directory：放 key 的地方
  • webroot-path：在前述的 step 3 給 LE 做 acme-challenge 的檔案放置目錄
  • 放置 account_key 的目錄，通常會放在你的 home
  • 在你要生 SSL 證書的網站的 Virtual Host 的設定內放置以下設定並重啟 nginx，讓 LE 可以用 http://example.com/.well-known/acme-challenge 的網址認證 ：

1
2
3
4
5
6
7

server{
  ...
  location '/.well-known/acme-challenge/' {
    default_type "text/plain";
    alias /var/www/acme-challenge/;
  }
}

• 註冊 account，執行：letsencrypt-cli register xxx.ooo.com ，產生帳號密鑰 account_key.pem
• 讓 LE 認證你的網站，執行：letsencrypt-cli authorize --webroot-path /var/www/acme-challenge example.com
• 生成 key：cd key-directory && letsencrypt-cli cert example.com，會生成：cert.pem chain.pem fullchain.pem key.pem 等四個檔案
• 設定 Nginx 在 Virtual Host 使用剛才產生的檔案：

1
2
3
4
5

server{
   ...
   ssl_certificate key-directory/fullchain.pem;
   ssl_certificate_key key-directory/key.pem;
}

• 重啟 Nginx，完成

更新 Key

執行

1

letsencrypt-cli manage --days-valid 30 -a :account_key.pem的位置: --webroot-path /var/www/acme-challenge --key-directory /etc/letsencrypt/live :你要更新的 hosts 以空白分隔:

建議把它加到 crontab 中定時執行

問題整理：

• 執行 letsencrypt-cli 出現 Acme::Client::Error::Malformed 錯誤：請降級你的 json-jwt gem 到 1.5.2
• 出現 Account Key Note Found：命令列加上 -a :account_key.pem的位置:
• openssl 版本太舊：openssl 版本建議在 1.0.2 以上，特別是如果要跑 http/2 的話

1. 確認 Ruby 版本在 2.2.1 以上，最好是 2.3
2. 在 Gemfile 設定 rails 的版本為 5.0.0.beta2
3. 同時，確認所有安裝的 Rubygem 是否需要升級，將版號設定好
4. 執行 bundle update
5. 先執行 rails update 確認是否每個檔案都需要更改，先讓每個檔案都被覆寫到，再回頭看 diff 進行必要修改

需要配合升級的 RubyGem

1. kaminari: 請用 Github 上的 Master branch
2. simple_form: 請使用最新版 3.2.1
3. acts-as-taggable-on: 一定要用 Master branch，即使版號看起來一樣
4. rack-mini-profiler: Master branch
5. Rails 相關的 Asset Rubygems
6. Capistrano 升級後配合修改 Capfile 中的版號

這次升級比預料中平穩，沒有花很多時間就完成了。

以上

繼上一篇的 在 Mac / Homebrew 下升級 PostgreSQL 從 9.3 到 9.4 之後，最近由於更換筆電 / 不想用 TimeMachine 加上剛好 PostgreSQL 9.5 發佈的關係，必需重新用 Homebrew 安裝 PostgreSQL 9.5，本來使用了前篇所介紹的方式來移轉舊版 PostgreSQL 9.4 的資料檔，但是很神奇地發現在所有 Rails App 的 DB 中的 schema_migration 表的資料通通遺失了，所以就必需要使用另一種方式來升級。

升級的方式

一般來說有以下兩種

• 從資料檔案 (raw data file) 轉移

  不像 MySQL，PostgreSQL 每個版本的 raw data file 都是不相容的（註：MySQL 也要看 Storage Engine），所以當升級新版的時候是不能直接套用的，PostgreSQL 也提供了 pg_upgrade 指令來幫助升級，這也是前一篇的主題。

• 使用 SQL 檔案轉移

  使用 pg_dump 或 pg_dumpall 等工具將舊 DB Dump 成 SQL 指令的格式，再輸入到新 DB 上即可>

流程

1. 更改資料檔目錄

   Homebrew 預設的資料檔目錄在 /usr/local/var/postgres 請把它移到另一個目錄去

2. 自舊版 PostgreSQL Dump SQL 檔案

   如果還沒有升級新版前，就直接執行

   pg_dumpall -c -f 目的檔案名

   即可，選項 -c 是在 dump 檔中附加移除既存 DB 的指令，可視個人需求決定要不要加。

   要是已經升級新版的話，由於 PostgreSQL 套件的發佈者都很貼心的把所有檔案照版本排列，所以可以用以下的指令開啟一個暫時的 PostgreSQL Daemon

   /usr/local/Cellar/postgresql/9.4.1/bin/postmaster -D /usr/local/var/postgres94/ -k /tmp/pg94/ -p 8822

   選項中 -D 是指定資料檔目錄，-k 是 socket file 的目錄，-p 是 port，要注意這兩者都不能和執行中的新版本重疊，這樣就順利開啟了服務，然後再執行 pg_dumpall -c -p 8822 -h /tmp/pg94 就可以取得 dump SQL 檔了

3. 自 dump SQL 檔還原到新版資料庫中

   在上一步的 dump 指令中就可以用 pipe 一步完成了：

   pg_dumpall -c -p 8822 -h /tmp/pg94 | psql postgres

以上

Single Table Inheritance（以下簡稱 STI） 是我們在 Rails 常用的一個功能，一般來說 STI 在 Rails 的實現方式如下：

1. 一張資料表
2. 多個 ActiveRecord Class 使用這張表
3. 預設用 type 這個欄位來界定這筆紀錄所屬的 class

這樣做的好處是子類別可以用父類別的欄位，主要的缺點是在可能會浪費到不需要的欄位；Rails 之所以這樣設計，主要是因為大部份的 RDBMS 系統除了 PostgreSQL 和 Oracle 以外幾乎都沒有實作 Table Inheritance。

PostgreSQL 的 Table Inheritance

PostgreSQL 的 Table Inheritance 和 STI 最大的差別在於多表繼承，在官網上就有相當詳細的介紹，基本上就是在資料表之間實作出繼承的關係，B 表繼承 A 表的話，則：

• B 表會有所有 A 表的欄位資訊
• 即使日後 A 表欄位有所變動，也會即時反應到 B 表上
• B 表所建立的資料，在查尋 A 表時會全部出現，反之則無

接下來我們就來介紹如何在 Rails 中用 PostgreSQL 的 Table Inheritance 來實作 ActiveRecord 的物件繼承。

期望的 Schema

實作

建立父類別 User

1

rails g model User

1
2
3
4
5
6
7
8
9
10
11
12
13

class CreateUsers < ActiveRecord::Migration[5.0]
  def change
    create_table :users do |t|
      t.string :username
      t.string :password
      t.string :type
      t.timestamps
    end
  end
end

class User < ApplicationRecord
end

建立 sub-class Staff

1

rails g model Staff

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class CreateStaffs < ActiveRecord::Migration[5.0]
  def up
    execute <<-SQL
    CREATE TABLE staffs(level integer,CONSTRAINT "PK" PRIMARY KEY (id))
    INHERITS(users)
    SQL
  end

  def down
    drop_table :staffs
  end
end
class Staff < User
  self.table_name = 'staffs'
end

和原本 STI 的行為不同，由於 ActiveRecord Migration 並沒有內建相關功能，所以需要自行撰寫 SQL 式來建立 Staffs 表，在建立時需實際指定繼承自 users 表，並且將額外附加的欄位等屬性設定進去即可。

在 Model 的程式方面，必需指定子類別的資料表，否則 Rails 會按照 STI 預設行為去使用父類別的資料表（users）。

在這個範例中，在 staffs 表建立的資料都會出現在 users 表上，反之則不會。

1
2
3
4
5
6
7
8
9
10
11
12
13

User.create(username: 'ryudo', password:'12345')
Staff.create(username:'Jodeci',password:'12345')
User.pluck(:username)
   (0.4ms)  SELECT "users"."username" FROM "users"
 => ["ryudo", "Jodeci"]
Staff.pluck(:username)
   (0.4ms)  SELECT "staffs"."username" FROM "staffs" WHERE "staffs"."type" IN ('Staff')
 => ["Jodeci"]
User.count #=> 2
Staff.count #=> 1
User.last
  User Load (0.6ms)  SELECT  "users".* FROM "users" ORDER BY "users"."id" DESC LIMIT $1  [["LIMIT", 1]]
 => #<Staff id: 2, username: "Jodeci", password: "12345", type: "Staff", created_at: "2015-12-31 07:12:16", updated_at: "2015-12-31 07:12:16">

Table Inheritance 會繼承的東西：

• 欄位資訊：包括預設值或是 NOT NULL，也就是在 SQL 建構式中看到欄位敘述的內容。
• 父表上的欄位變動：也就是之後在父表上新增刪除修改欄位的變動，會確實的反應到子表上。

Table Inheritance 不會繼承的東西：

• 欄位資訊以外的全部：包括 Primary Key、Constraint 或是 Index 等。

主鍵重複值問題

這應該是最大的困擾之一，就是繼承的子表的主鍵是可以和父表的值重複的，例如以下的程式碼是可以正確執行的：

1
2

User.create(id:1, username: 'ryudo', password:'12345') #=> 建立 id 為 1 的 User
Staff.create(id:1,username:'Jodeci',password:'12345') #=> 建立 id 為 1 的 Staff

這樣在 users 表會真的有兩筆 id 為 1 的紀錄，而且目前無法用資料庫的方式去迴避這個問題，不過由於兩個 id 之間是共用同一個 Sequence，在不指定 id 建立資料的狀況下，id 的值是不會重複的。

inheritance_column 存廢問題：

在上面的範例中，我們可以看到原本 STI 的 inheritance_column，也就是 type 這個欄位的存在，原本 STI 的設計是：子類別的資料將會自動在 type 上加上類別名稱，查詢 Staff 時也會預設查詢 type 為 Staff 的資料。

這個設計是因為在資料同屬一張表的前提下，必需用一個欄位去區分類別的關係，而在 Table Inheritance 下，由於每個類別有獨立的資料表，在查詢子類別時已經不需要用 type 這個條件了；但是如果在父類別的資料表查詢時，還是需要用 inheritance_column 去區分出這筆資料所屬的類別，否則所有父類別資料表的資料在 ActiveRecord 中會被視為父類別的資料。

多表繼承

其實是有這項功能的，但是目前還沒想到需要使用的場合所以這次就不討論了。

是否要使用這個功能？

好處

• 比起 ActiveRecord 提供的 STI 更趨近於物件化
• 由於資料表是物理上的切分，等於是一種 Partitioning，在資料量大的時候可以提升子表的效能
• 同上，減少欄位或 Index 等資源不必要的浪費

壞處

• Rails 預設不支援相關的 Migration 操作，需手動撰寫 SQL
• 同上，在 Model 的設定上必需客製一些設定

以上！

這篇 Blog 是我和五倍紅寶石的同事趙子皓於 11 月初一同參加了大江戶 RubyKaigi’05 以及 Ruby World Conference 2015 並分別發表的心得記事。

逆邀講

回到今年六月，在準備 RubyConf Taiwan 2015 時，想要邀請連續兩屆來台的 Ruby VM 作者笹田耕一來台發表，但由於他已預定在之後的 RubyConf Portugal 發表所以未能成行，在這信件一來一往中，突然被問到是否可以 11 月的大江戶 RubyKaigi 中發表，驚訝和榮幸之餘想說是一個難得的機會就答應了。

Ruby World Conference–投稿與贊助

和 RubyKaigi 或是 RubyConf 系列的技術研討會不同，這個在 Ruby City — 松江市舉辦的研討會是以「Ruby 的應用和生態」為主，由於敝社原本就是以促進 Ruby 受台灣的程式生態圈愛用為目標，所以就和同事嘗試著投稿看看，沒想到兩個人都順利入選。

除了投稿之外，由於在不論在社群或是公司的方面都受到了日本 Ruby 社群很多照顧，今年本著回饋的心情也贊助了這個活動，也成為了該活動史上第一個海外贊助商。

行程

由於大江戶和 RWC 剛好是在前後週，所以我們在大江戶的前一天（11/7）出發，然後在 RWC 結束後一天（11/14）回台。

大江戶 RubyKaigi

大江戶 RubyKaigi 是日本眾多地區性 RubyKaigi 中，歷史最悠久，規模最大的一個，主辦團隊是 Asakusa.rb，這次的場地在東京的中央區舉辦。

今年，也是第五屆的場地是在一個綜合會議中心，除了 7F 的會場外，在 13F 還提供了一個很大的休息區，休息區除了給大家交流之外還提供了會場畫面的 LIVE 直播。

大江戸Ruby会議05の様子ですよぅ 🌊 #oedo05 #asakusarb pic.twitter.com/lusirCDZiW

— 大江戸Ruby会議 (@OedoRubyKaigi) 2015 11月 8日

門票方面，活動門票是 2,000， 不含午餐，After Party 是 5,000 日元，繼承 Asakusa.rb 對外國會眾友善的傳統，外國人和講者全免。

這個活動和一般認知的技術研討會不同的地方，就是它有許多被稱為「生活發表會」的議程；今年的議程除了兩場 Keynote 外，又分為「Ruby Committers’ Lightning Talks」以及「Ninja Talks」兩種，前者顧名思議就是 Ruby Committer 專屬的 LT 時間，後者則是每場 15 分鐘的短講，會眾約 200 多人。

由於我自己的議程是在下午，所以在之前的議程就只有聽到一部份，以下就我自己有聽到的部份做個簡介：

1. @usa：あいおーのはなし（中譯：有關 IO 的話題）

   講者是 CRuby Windows 版的主要維護者，這篇主要就是在討論 CRuby IO Class 內部實作方式的演進，然後表示他要在 Windows 上 Porting m17n IO 的功能。

2. 松田明：「The Kaigi Must Go On」

   講者是今年五月才在 ModernWeb 登台的大神松田明，內容是關於他接任 RubyKaigi 總召的經過，其中提到了原本去年 9 月 RubyKaigi 2014 之前就已經訂好了今年 Kaigi 的場地與時間，但是因為原本的總召角谷大大生了一場病所以中斷了籌備的事情，本來已經打算停辦了，後來由於他實在太常被國內外朋友們詢問是否還會有下一屆的事情，所以最後就自己出來接任總召了，身為 RubyConf.TW 的主辦人真是感到心有戚戚焉。

3. 中田伸悅：「Best Commits of the year 2015 (仮)」

   講者是被稱為 “Patch Monster” 的，也是包括 Matz 在內的三位被 Heroku 全職聘用的 Ruby Committer 之一，簡短的內容提到了他在今年最滿意的幾個 Commit。

4. 小栁真太：「SQL 脳から見た Ruby（中譯：從 SQL 腦看到的 Ruby）」

   講者和我一樣是 PostgreSQL 的同好，裡面講到如何把 SQL 查詢用 Ruby 語法去實作的方式，後面還提到了 PostgreSQL 的專有語法 with 等在 ActiveRecord 的用法，令人腦洞大開，with 相關介紹可以參照阿土伯大大在 Ruby Tuesday 24 的分享。

5. 西嶋悠貴：「地獄のニューヨーク（紐約）」

   講者是新進的 Ruby Committer，也是在國外工作的日本 Rubyist，裡面提到他在紐約的生活，例如怎麼租房子比較省錢，或是交通問題之類，其中最爆笑的一段就是提到當他在住宅遇到搶匪，逃到樓下對面的 PUB 後，酒保竟然跟他說「總之先來一杯再說，我請客」，遺憾的是似乎沒有公開 Slide。

6. Kei Sawada：「詳解Burn」

   Burn 是一個可以讓你用 DSL 去寫出任天堂 ROM 的Ruby Gem，去年在 RubyKaigi 就有聽到這個令人印象深刻的議程，這次還加上 telnet mode 的功能，後面還提到了一些 g0v。

After Party 和二次與三次會

這次的 Party 是在知名的 Recruit 公司的員工餐廳舉辦，Party 除了啤酒喝到飽之外，料理陣容也非常豪華，同時還有講者繼續白天的話題，現場又跟大家討論了起來。

Party 結束時大概是 9:30 左右，這時很神奇地就會有一群人自動的聚集在一起等待二次會的來臨，二次會在附近的小 Pub 裡續攤，神奇的是在那個場合中，依然看到 Patch Monster 大大在改 CRuby Source Code XD。

由於二次會時偶然提到很想唱歌，所以就變成在附近的 KTV 進行人生第一次的三次會了 XD，最後在快一點時趕上了終電（最後一班電車）回到旅館。

Asakusa.rb

Asakusa.rb 是一個在東京定期舉辦的 Ruby 社群聚會，除了定期聚會以外，也主辦包括前面提到的大江戶，以及每年 RubyKaigi 的 pre-Party，一直以來都很想參加，趁著這次的機會終於可以一嘗宿願。

這次的活動在位於秋葉原附近的永和 System Management 公司舉辦，活動本身沒有主題演講等，比較像是我們經常在動漫畫裡看到的「部活」，也就是社團活動，大概在晚上七點開始會陸續的有人加入，然後有的人會聚在一起討論或是做自己的事。

大概到了 20:30 ，松田大大就開始請大家自我介紹，大概到 9:30 前部活階段就結束了，接下來就移師到附近的居酒屋舉行二次會，這時松田大大突然對我說；「真正的 Asakusa.rb 現在才開始」，然後就是喝酒聊天了，由於小弟的日文不太輪轉，和大家聊天時松田大大還會很貼心的請大家對我「慢慢地講話」，二次會在大概 12:00 左右結束。

Ruby World Conference

和我們熟知的，針對開發者為主的 RubyConf 系列或是 RubyKaigi 不同，在 Ruby 之父的家鄉島根縣松江市舉辦的 Ruby World Conference 專注在「Ruby 的應用」而非技術。

接著週三就前往羽田機場搭上往出云機場的飛機，在下午四點左右到達了旅館，當天晚上有限定講者和相關人士參加的 pre-Party，是在一間很傳統的日式餐廳舉辦，現場請每位講者上來自我介紹，在場和這次大會的 Keynote Spaker 的 Linda Liukas 相見歡，同時也認識了 RG 松江的主辦團隊，由於其中兩位都是媽媽，話題很快就轉移到育兒經上面 XD。

Pre-Party 結束後，主辦單位很貼心的招待大家搭計程車回到旅館，雖然有二三次會但是因為要準備演講的關係只好 Pass。

隔天就開始了 RWC 的正式議程，開場時先請所有的講者到舞台上合照，接著就是一些地方政治人物像是島根縣長等的致詞，和我們對一般政治人物致詞很「搞威」的印象不同，每位的致詞時間都不超過五分鐘，接下來就是 Matz 的主題演講，這次的演講主題是「Second System Syndrome」，內容和不久前 RubyConf Taiwan 2015 的發表沒有很大的差異。

在單軌兩天的議程中，大會提供了「雙向」的即時口譯服務，接下來的議程由於都在準備講稿和練習（我是第二天倒數第二個講者），幾乎都沒有參加到。

會場是在當地最大的會議中心，除了三樓的演講廳之外，在一樓有一個比演講廳還大的攤位交流區，這裡同時也是會眾午餐以及晚上 Official Party 的場地，攤位的外觀和陳列方式感覺比較像台灣每年五六月間舉辦的 Computex Taipei 這樣的商業展覽，贊助商多半也是在展示自己的技術解決方案之類，沒有看到徵才。

除了交流區的攤位之外，還有一樓的地方旅遊介紹以及 Ruby 拉麵攤位，第二天也帶了一組 Ruby 拉麵回家。

三樓會場外還有一個茶席區，穿著和服的妹妹會用傳統日本茶道的方式磨出抹茶和點心然後再端上來給你。

第一天晚上的 Official Party 當然也是酒類無限暢飲，不過由於一直在交流遞名片聊天的關係所以幾乎沒吃到多少東西（淚～），這個 Party 除了吃吃喝喝外，還有奇妙的島根吉祥物 しまねっこ 出沒。

Meeting with Shimanekko, the mascot of Shimane. 😻 @_zzak and my next talk might just be the cat dance. pic.twitter.com/TkgL6zK6hU

— Linda Liukas (@lindaliukas) 2015 11月 12日

另一個讓我印象很深的地方，就是在會場有寄放衣服與背包的地方，超貼心。

Party 結束後，當然也是有各種二次三次會，不過一樣由於隔天有演講的關係，只能在電腦前看著已經完成發表的同事邊唱 KTV 邊發推😂。

第二天全部議程結束後，參加了一場需要事先報名的當地特產啤酒燒肉會，接下來一樣有各種續攤，三次會是和一群日本各地的 RG 主辦人一起交流 RG 主辦的經驗等等，拜同行的日文通子皓的幫忙，可以更加輕鬆的交流了，在整個活動期間認識了許多不同城市的 RG 主辦人或教練，真的很開心。

最後一天的早上，在搭車前往機場之前短暫的參觀了 RG 松江，這邊的規模雖然不大，不過會場的佈置很用心，和台灣不一樣的是，一組的配置是 2 位教練配四位學員，等於是台灣兩組的配置，現場還有機器人…以及 Matz 的立牌。

在活動開場後，有 Matz 和 Linda 的致詞，然後我也突然被拉上去致詞了 XD，再度獲得了另一個人生的成就。

台湾より…！！ #railsgirlsmatsue pic.twitter.com/RBmgXMEH8k

— yadaita (@yadaita) 2015 11月 14日

最後就在各種趕飛機（出雲 -> 羽田 -> 松山）中結束了整個行程。

個人成就紀錄

在這次八天的日本行之中，完成了各種成就，包括：

• 在海外用英文發表技術 & 非技術議題
• 一週內兩次英文發表
• 在英文發表前用日文自介
• 和日本人唱 KTV
• 二次會 & 三次會
• 趕終電

感想

地方的熱情

最讓我印象深刻的，就是在日本這個國家，即使是所謂的「田舍」，也就是鄉下地方的人或是政府單位都會很努力的用實際的方式（而不是炒地皮之類）來振興地方的經濟與發展，像 RWC 這種幾乎由地方政府一手主辦的活動就是一個很顯著的例子，為了吸引外國人參加，甚至不惜重本不計成效（畢竟全場只有 15 來個外國人）的提供雙向口譯服務；同時也認識了許多地方的 IT 公司，像是 Matz 以前所屬的 NaCl 等等，很努力的把工作機會帶回自己出身的地方，這點和台灣是很不一樣的；另外松江的消費水平，像是食宿或交通費用（主要是計程車）幾乎和東京沒有什麼差別。

這次也認識了很多地方 RG 活動，像是神戶、松江甚至是以前沒聽過的塩尻等等的主辦人，他們很熱心的將 RG 活動帶到自己的家鄉，同時很多 RG 的教練，例如敝公司的好捧友五十嵐邦明等人，也會從東京自費（或是公司贊助）過去支援；縱觀 RG 的世界各地活動列表可以發現，日本的都市數量是全世界所有國家最多的，活動的頻率也是最頻繁的，可以感受到他們社群之間互相支援的熱情。

多樣的 Ruby

一直以來 Ruby 在台灣的認知就是 = Rails，甚至還有很多人把 Rails 誤認為一門語言，雖然我也是從 Rails 入門 Ruby，但是在熟練到一定程度之後就開始著眼於 Rails 或 Web 以外的 Ruby 應用；在這次日本行中又再次見識到 Ruby 的多樣性，以及日本人把 Ruby 的應用延伸到各個層面上的努力，像是這次我就認識了用 Ruby 控制都市瓦斯的系統，或是用 mruby 控製太陽能發電系統的公司，而且在大學也有相關的研究，我想除了 Ruby 是日本發明的語言之外，也包括了日本人對基礎研究的動力，這點和台灣是非常不同的。

社群的熱情

有人認為，區別一個國家是否現代化的方式，就是在於其中的人民有沒有一個「對國家主體的認同和想像」而非對個別人物的效忠；我想這點也適用在 Ruby 或是任何的 Open Source 社群上，在日本的 Ruby 社群可以感受到大家對於 Ruby 社群這個主體的認同，各個地區的社群間也會互相支援，例如在我參加 RWC 之前，一直有「這就是很 local 的活動」的刻板印象，不過實際參加之後才發現真的有很多來自東京的 Rubyist 們或公司在會場出沒甚至贊助，包括前面提到的 RG 互相支援，都可以體現出日本的 Ruby 社群有一個共同的認同主體，進而在這個主體之下互相扶持，共同發展的熱情。

最後

整體來說，我認為這次的日本行可說是收獲滿滿，最大的遺憾是因為行程排的太緊加上八天兩場發表的關係，沒有好好的在松江當地觀光；希望明年可以作為普通的會眾參加這些活動。

今年是第五屆的 RubyConf Taiwan，也是第二次以總召的身份主辦這項活動。

Matz Driven Development

去年九月和龍哥帶著一群 Rails Girl 們去參加 RubyKaigi 2014 ，在會前的某個特別 Party 上遇到 Matz，意外的被問到 2015 的 RubyConf Taiwan 何時舉辦，當時因為老婆的預產期在今年 2 月，所以就當場回覆可能無法在上半年舉辦，最後就和 Matz 敲定了大概會在今年的 9 月，所以我們是 Matz Driven Development 無誤。

用公司推動 Conf

剛好在去年的 RubyConf Taiwan 的前夕，考慮到未來的社群發展，和龍哥等人成立了 五倍紅寶石 這間公司來推廣 Ruby，之後經過將近一年的努力經營之後，公司也漸漸開始有能力支援 Sitcon / Rails Girls Taipei / Weekly 和 Ruby Tuesday 等等，在這幾個月，可以說幾乎動用了整間公司的人力在舉辦這個活動。

以往在準備活動時，往往是以草創的心態去做，很多事情的聯繫或處理往往做的不到位或是有失誤的地方，今年要特別感謝敝公司的管理員 Sabrina ，帶領幾位同仁將大部份（對我來說）瑣碎的事務以最洗練的方式處理好，讓我幾乎不需要煩惱講者 / 贊助商 / 預算以外的事情，而且能適時的給我許多建議，讓我發現許多事情其實還可以做的比想像的更好。

Matz is awseome, so we are awesome

• 補助外國講者住宿

  

  來自 11 個不同國家的外國講者們，除了 Keynote Speaker 以外，全部都是自費來台，為了體貼遠道而來的外國講者們，今年特地補助外國講者免費住宿中研院的客房服務。

ホテルついたー。快適〜。

A photo posted by igaiga (@igaiga555) on Sep 9, 2015 at 11:38pm PDT

• 使用 Icecast 做口譯接收解決方案

  去年第一次嘗試在 Conf 做中翻英的即時口譯服務，當時因為場地因素，就找了專業的翻譯社架口譯間以及租借 Receiver；今年因為回到中研院，由於會場具備口譯間以及有 CPRTeam 支援網路的情況下，就決定使用之前 HITCON 使用的 Icecast 做口譯語音廣播的解決方案，讓外國會眾們用自己的手機接收口譯語音，得到了許多正面回應。

"Using Icecast instead of Receiver Equipment", that was a very nice idea! And that helped me so much. Thank you!! #rubyconftw

— ゆかお(Yuka) (@yucao24hours) 2015 9月 12日

お手元のiPhoneにイヤホン差したら同時通訳レシーバーになるのとても便利だ #rubyconftw

— Kakutani Shintaro (@kakutani) 2015 9月 11日

• Pre-Conf Party

  由於經費與人力考量，以往 Conf 前通常沒有正式的活動，今年在 Conf 前兩天在敝礦坑舉辦 Pre-Conf Party，增加一個交流的機會。

Beer and food! Pre-Conf party with so many #rubyfriends #rubyconftw pic.twitter.com/jnR6pBf9FH

— Tina Huang (@tinating_h) 2015 9月 9日

場內

• 茶 / 咖啡贊助商

  去年首次在活動中引進茶贊助商就有相當不錯的回應，後來也引發各大 Conf 爭相採用，今年剛好因為龍哥的關係認識了 iOS 大神張景隆夫妻經營的蘋果貓咖啡，另外剛好實習生的馨儀家裡又是經營茶莊的，就一次湊齊了兩種飲料攤位；連 Tenderlove 大神都表示他覺得這裡的咖啡比他住的西雅圖（星巴客發源地）的還要厲害，聽說連來自比利時的 @lrz 大神都帶了幾包回去。

• 在會場交誼廳舉辦 Party

  從 2012 起，我們就有在第一天晚上舉辦 Official Party 的傳統，前兩屆都在同一間 Lounge Bar 舉辦，雖然不用自己準備，但是需要一筆包場費用，也因此 Party 和 Conf 都要分開購票；今年直接使用會場四樓的交誼廳做為 Party 會場，從外面叫外燴，再配合 Wish8 和 金色三麥贊助的啤酒，除了讓所有人都可以參加 Party 外，沒有座位的設定也讓大家比較容易主動交流。

Start #RubyConfTW pic.twitter.com/uzQmocQTju

— 小影 ☂ (@siuying) 2015 9月 11日

Beer time @ #rubyconftw pic.twitter.com/MhnGcgg8Kp

— 小影 ☂ (@siuying) 2015 9月 11日

• RFID by Codeme.cc

  以往贊助商擺攤，都需要自行收集會眾的資料，對於贊助商和會眾多有所不便之處，今年剛好透過龍哥認識了 PyCon 協辦單位之一的 GliaCloud，他們研發了一套 Raspberry Pi + RFID 打卡的解決方案，雙方討論之後就決定引進這個服務給贊助商使用，也感謝 Andy 和 Django Girl Taipei 的主辦人 Michelle 在場佈與兩天活動的全力支援，誰說不同語言 / 社群之間就不能通力合作呢？

Badges linked with events #rubyconftw pic.twitter.com/QtvAULcUPK

— 小影 ☂ (@siuying) 2015 9月 11日

團隊

• 議程：ihower
• 設計：Rice / 康橋
• 顧問：龍哥
• 統籌：Sabrina
• 場地協調：Rock（OSSF）
• 攝影：徐聖淵
• 執行：Tina / 馨儀 / Nina
• 網站：Nina / 西瓜 / Tina / 蒼時
• 口譯：Sarah / 宜靜
• 司儀：Lillian / 郁蓁
• 場務：Tina / 馨儀 / Nina / 雯晴 / 嘉佑 / Christine / okay / 椽家 / 孟穎 / 宇辰 / 芳妤 / 毓柔 / 佾庭 / 詩晴
• 會場網路：Mouse / Pennyyken（CPR Team）
• RFID：Andy / Michelle（Gliacloud）
• 外交大使：@juanitofatas

結語

感謝贊助商 / 協力夥伴 / Staff / 講者以及許多朋友的幫忙才能促成今年的活動順利舉辦，謝謝大家！

All #rubyconftw staffs with @tenderlove 's cat sticker pic.twitter.com/vtKYiGRnHs

— Mu-Fan Teng (@ryudoawaru) 2015 9月 12日

#rubyconftw Staffs and @masterwujiang after party. pic.twitter.com/mqbOBr3kjy

— Ruby Taiwan (@rubytaiwan) 2015 9月 11日

1

-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8)

這個狀況是從幾個月前突然發生的，Google 之後發現兩種解法：

1. 修改主機 locale 設定

   編輯：/etc/environment 或是 .bash_xxx 等檔案並輸入： LANG=en_US.utf-8 LC_ALL=en_US.utf-8

2. 修改 iterm 設定

將裡面的 “Set locale variables automatically” 取消勾選即可。

相關連結

• https://sskaje.me/2014/01/lc-ctype-issue/#.VOwSjULdVRE

最近在某個和客戶共同開發的專案中，遇到了以下的情形：

1. 專案的 layout / view 經過大幅的改版
2. 改版是把舊 layout（以下簡稱 ver1）的大部份功能改出一份新版 layout / view / controller（以下稱 ver2）
3. 改版後幾乎沒有移除 ver1 重複的部份，因此系統中存著很多其實用不到的 view / controller / route
4. 又因為改版後不想改變在 production env 的 url，所以在路由設定中用了大概是類似的架構：
   • Development 中有 /ver1 和 /ver2 兩個 route namespace，而且有 base uri，意即可能會有 /ver1/products 和 /ver2/products
   • Production 中，這兩個 namespace 的 base uri 會被消除，舉例來說，如果遇到 /products 的 request，系統會先找 /ver2 有沒有 /products，有的話會先使用，沒有再去找 /ver1

所以系統最後就存在一堆功能重疊的 controller / view / layout 了，現在的工作是要移除 /ver1 和 /ver2 中重複的部份。

執行：

基本上就是高科技手工業，程序如下：

1. 找 /ver2 的 route，假設現在的目標是 resources :users
2. 在 /ver1 上找尋類似的 resource
3. 如果有，就把 /ver1 的刪掉
4. 如果不是單純的 Restful CRUD（意指有其它非 index. show, create 等標準 action 的 action）就得要一一檢查在 /ver2 上是否都有相對應的 action
5. 找到所有的 view / helper / asset / controller 中是否有用到 /ver1 上的 url helper method，然後統一取代

以上程序有效的前提是，所有的 URL 都用 helper method 而不用純字串或 url_for 等。

事情聽起來好像不是很難，不過這個專案可怕的地方就在於數百行的 route 中幾乎沒有單純 CRUD 的 resource，所以和同事花上了很多時間在手工上，完成後的問題就是，要怎樣確保沒有遺漏的地方。

於是想到，是否可以將程式中所有用到的 url helper method 集合起來一一做檢查呢？最後想到的解法大意如下：

1. 用文字搜尋的程式，以正規表示式去找出程式碼中使用的 url helper method
2. 將找到的 method 集合產生列表
3. 用列表產生 it 區塊
4. it 區塊中使用 helper spec 去測試 view context 中是否有這些 method

文字搜尋採用目前比較流行的 ack，好處是除了速度快之外又是 Perl 版的 Regexp，比 egrep 內建的更貼近 Ruby 使用的版本

1

ack --noheading -h '[^A-Za-z0-9_.].((ver1|ver2)[\\w_]+?\_(url|path))' app/ --output '$1' | sort | uniq

使用的 ack 參數如下：

• 正規表示式為：[^A-Za-z0-9_.].((ver1|ver2)[\\w_]+?\_(url|path))
• –noheading 不顯示檔案名在頭
• -h 不顯示檔名在左邊
• –output ‘$1’ 只顯示批配的第 1 項

測試的程式大概長的像這樣：

1
2
3
4
5
6
7
8
9
10

RSpec.describe ApplicationHelper, :type => :helper do
  fn = "tmp/url_helpers.txt"
  cmd = "ack --noheading -h '[^A-Za-z0-9_.].((ver1|ver2)[\\w_]+?\_(url|path))' app/ --output '$1' | sort | uniq > #{fn}"
  system cmd
  File.read(fn).split.each do |url_helper_name|
    it "Url helper #{url_helper_name} should be available" do
      helper.respond_to?(url_helper_name.to_sym).should be(true)
    end
  end
end

這樣一跑完就可以放心了。

PostgreSQL 和 MySQL 不同，資料檔格式會隨著小數點二位數以上的版號（9.3 - 9.4）變動，換句話說每當升級版本時，資料檔就必需要升級才可以繼續使用。

升級的方式有兩種：

• 將原本的資料執行 pg_dumpall 後再 restore 回去
• 用 pg_upgrade 命令從舊的資料檔產生出新版本的資料檔。

這邊要講的是第二種情形。

環境限定：

• 可執行 Homebrew 的 MacOS 環境
• 原 PostgreSQL 為 Homebrew 安裝，9.3.x 版

步驟

1. 安裝新的 PostgreSQL

   1 2	brew update brew install postgresql

2. 停止現在的 PostgreSQL Daemon

   1	launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

3. 建立 9.4 的資料庫檔案

   1	initdb /usr/local/var/postgres9.4 -E utf8

4. 使用 pg_upgrade 指令升級 舊PG的資料檔案到 9.4，注意這邊的 9.3.5_1 和 9.4.0 是會依照你的舊版本和實際安裝的新板本的版號而有差異的

   1 2 3 4 5

   pg_upgrade -v \ -d /usr/local/var/postgres \ -D /usr/local/var/postgres9.4 \ -b /usr/local/Cellar/postgresql/9.3.5_1/bin/ \ -B /usr/local/Cellar/postgresql/9.4.0/bin/

5. 將舊資料檔備份，並且讓新資料檔的目錄更名使之變成預設的資料檔

   1 2 3

   cd /usr/local/var mv postgres postgres9.3 mv postgres9.4 postgres

6. 重啟 PostgreSQL

   1	launchctl load ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

7. 檢查 /usr/local/var/postgres/server.log 檔是否有正常啟動 server
8. 如果原本有安裝 pg GEM 的話要重新安裝

以上！

由於有了去年第一次和高見龍等人一同參加 RubyKaigi 2013 的經驗，因此當確定今年的 RubyKaigi時程後，就非常的期待有機會能夠再次參加這場 Ruby世界最重要的研討會。

今年的 RubyConf.tw 2014 ，做為總召，有幸召集到了許多 Rails Girls Taipei 活動的校友們做為志工一起舉辦了這場國際研討會。

會中主要贊助商之一的 Heroku 的代表，也是 Ruby Committer 的相澤步先生提及，或許可以嘗試由 Heroku 公司和日本的社群朋友贊助一些台灣的 RG 校友去日本參加 Ruby Kaigi 2014，當時覺得這個點子非常棒，但又覺得有點不現實。

在七月籌備 RG Taipei-4 時，透過 E-Mail 向相澤先生詢問此事之後，得到了肯定的回覆，於是就著手開始選拔辦法。

在選拔過程中，也用英文向日方提交了每位報名者的近況，包含社群參與度等等的報告，最後在八月和日方一起開會共同決定了三位入選者，神奇的是過程中，本來以為只有 Heroku 公司會出錢，沒想到後來加入了 Spice Life 公司以及好幾位日本的大大，其中有幾位是甚至沒有來過台灣，單純的被 RG 的理念感召，實在是令人非常感動。

另一方面，在規劃這次的日本行之時，就想到是否有機會可以參觀一些日本的 IT 系企業，於是就聯絡了之前認識的日本 Ruby 圈的大大們，才有幸在日本行中參觀到包括 Line / DeNA 等等的 IT 企業們。

成員

Photo by Igarashi Kuniaki

1. 龍哥
2. 大兜（講者）
3. Bruce（講者）
4. Mason
5. Annie（RG 獎助金計劃獲選者）
6. 阿旺（RG 獎助金計劃獲選者）
7. Lena（RG 獎助金計劃獲選者）

參加了哪些活動

可參考下列文章與分享：

• A ruby week in Japan (1) by Annie
• RubyKaigi 東京一週遊 (1) by 阿旺
• 特別講座：Rails Girls vs. RubyKaigi 的 Slide by Annie

• 同上的影片紀錄

結語

一年多前參加 RubyKaigi 2013 並參觀到日本的 RG 活動時，沒想過在台灣可以辦的起來 RG ，更沒想過有機會參與到史無前例的獎助金計劃，只能說 Ruby 社群的力量真的太神奇了！

特別感謝

• Heroku, Inc
• 株式会社spice life
• Heroku 的 相澤 步（Ayumu Aizawa） 先生
• Spice Life 的 五十嵐 邦明（Kuniaki Igarashi） 先生
• Satoshi Gunji 先生
• Hiroshi Shibata 先生
• 松田 明 （Akira Matsuda）先生
• Haruka Iwao 小姐
• Chiaki Shinto 小姐

時間和場地

記得應該是 2013 的 11月左右，和 Matz 確認日期後開始找場地。

本來一開始是想用中研院的，不過和 2012 一樣，Matz 欽訂的日期又沒空了，正在煩惱場地時想到離（當時）工作地點很近的陽明大學，剛好社群的好朋友澤清當時也還在那邊工作，於是在想到的當天就立刻去看場地，由於和澤清所屬單位（陽明大學系合中心）合辦的話可以獲得場地租金的優惠，加上場地狀況整體不差，於是當下就拍板定案，於是和 2012 一樣，又辦在了中研院以外的地方，而且一樣在台北北區。

交通方面，由於是在石牌捷運站步行 10 分鐘的地點，因此沒有造成任何不便。

這次場地的優點：

1. 夠大
2. 兩個場地後面是相通的
3. 很多廳

缺點：

1. 休息區的位子較少
2. 大禮堂和其它廳的人數差距太大（1000 : 240）不過由於我們只有 290 左右的會眾，因此不是問題

Linda Liukas

有鑑於 Rails Girls 在全球各地的蓬勃發展，就決定邀請 Linda 做為本次大會的 Keynote Speaker 之一，雖然一開始會擔心非技術議題大家是否會感興趣，不過看場下大家爭相和她合照的情形也就放心了，果然不愧是 Ruby 界的女神！

其實有趣的是 2014 的 RubyKaigi 也有 RG 相關的議程，看來這應該是趨勢無誤。

設計

這次的官網 / APP，包括所有看得到的平面設計，都是由 RG 出身的 Grace 擔任，和以往相比多出了很多的平面設計物，由於她有許多展場設計的經驗，所以我可以放心的將細節交給她。

Mobile APP

在一個不是以 APP 為主題的 conf 推出了雙平台的 APP，要感謝擔任 iOS 開發的龍哥以及幾位 Alphacamp 的學員，還有擔任 Android 開發的阿旺以及協助她的佳緯。

CFP & 講者

這次的 CFP 讓我最意外的是，在沒有招待食宿機票的狀況下，投稿者裡面竟然有超過一半的外國投稿，有鑑於此，後來也開放了讓這些講者的所屬單位掛上了特別的 Speaker Sponsorship 作為一種回饋。

講者（包括 Keynote）來自於包括台灣在內有七個不同的國家，分佈為：

1. 台灣：10
2. 日本：8
3. 美國：7
4. 香港：1
5. 中國：1
6. 芬蘭：1
7. 比利時：1
8. 新加坡：1

另一個和以往差異較大的，就是出現了高達 4 位的女性講者，如果加上了 LT 的話就有 5 位了，這也算是某種程度的突破吧。

食物 & 飲料

抱歉第一天搞砸了，還好第二天的便當大家還算滿意。

飲料方面，第一次引進了飲料贊助商琅茶，這間也是由幾位前趨勢和 HTC 的工程師創業成立的，現場看起來大家很捧場，後來聽說不少外國會眾都訂了茶葉帶回去。

Party

和 2012 選擇了相同的場地舉辦了 Party，不過這次我們可是把整間都給包下來了，又加入了台灣和日本的 Rails Girls ，整個場面好不熱鬧。

語言與國際化

繼承本大會的傳統，這次的會眾中有將近 1/4 來自超過 10 個不同國家。

受到去年 RubyKaigi 2013 的啟發，為了促進國內外會眾的交流，這次特別啟用了中翻英即時口譯在所有的中文議程上，也因此把所有的中文議程都排在了第一天。

為了節省經費而不找口譯公司，從 ptt 口譯版上募集到了兩位超優秀的口譯 Sarah 和 Kylie，她們除了專業能力和資歷外，重要的是對整個活動的負責態度，像是在活動前一個月場勘，或是主動聯繫講者溝通演講內容等，讓我覺得能請到她們真的非常幸運。

Rails Girls 特別講座

原本在 conf 的隔日，打算按照日本的 RubyHiroba 的方式，舉辦一個 Unconference 的活動並且混合 RG，不過在和出身於 RG 的 Hazel 討論後，決定趁著這次邀請到 Linda（Rails Girls Co-Founder） 的機會來舉辦一場特別的座談會活動，也因此促成了「姺語言力-程式新市場，女孩新火花」的舉辦。

一開始邀請的講者是國內的大神唐鳳和 Linda，活動進行中加入了原本在台下當聽眾的 Matz 和 @headius，讓整個座談變得更加精采。

在這裡必需特別推崇 Hazel，在整個講座的籌備過程中，她持續的和 Linda 以及唐鳳討論座談的細節，另外也要感謝這次的場務組長包子幫忙聯繫媒體等事宜，另外也要感謝 TEDxTaipei 贊助了活動場地，以及 Lena 贊助了活動 LOGO 的設計。

同時也要感謝 Inside 的編輯，也是 RG 校友的 Liz 對 Linda 進行的深度採訪，還有贊助拍攝的 Retina Studio

Rails Girls Staffs

自從 2013 的 9 月開始舉辦第一次的 Rails Girls Taipei 之後，就認識了許多優秀的 Rails Girls 們，加上受到去年在日本看到很多 RubyKaigi 的 staff 都是女性工程師等的啟發，覺得應該可以試著在 RG 中招募 staff 看看，結果報名者超乎想像的多，最後幾乎所有的會場 staff 都是來自 RG 校友。

同時這個亮點也引起了在場許多外國朋友的注意，也進而造就了日後的 RubyKaigi 獎助金計劃。

個人以為，RG Staff 對 Ruby 社群的最大意義並不是因為她們是正妹或女生，而是讓受惠於社群學習到 Ruby 的校友們有一個產生正向循環並回饋社群的機會。

總結

感謝 ihower 給我擔任總召的機會，也由於有幸參加 RubyKaigi 2013 受到了許多啟發，把 RubyConf Taiwan 的特色延續下去並成功的辦出一屆國際化又有特色的程式語言研討會，謝謝大家！

Next Time？

預計於 2015.09，敬請期待！

Database View

在Wikipedia中的說明為：

1

檢視表 (View) 是在關聯式資料庫中，將一組查詢指令構成的結果集，在實體資料表中的改變都可以立刻反應在檢視表中

通常我們會為了特定目的，例如將某些特定條件的查詢變成一張虛擬表之類的原因，來製作一些View，例如：

我們會用以下的方式建立一個View：

1
2
3
4
5
6
7
8
9

CREATE VIEW orders_products_users AS
SELECT
orders.user_id,
users.name,
orders.product_id,
products.name
FROM
orders JOIN users ON users.id = orders.user_id,
JOIN products ON products.id = orders.product_id

以後我們要使用這個view時只要：

1

SELECT * FROM orders_products_users;

即可

但是普通的view本身並沒有真正的儲存資料，預設情況下它只是一個查詢的捷徑而已，而且也不能透過update view來更新資料，所以對於使用Rails等ORM的人來說，即使已經有一些「把view當model」的Gem（例如activerecord-database-views）推出，還是會覺得是一個比較雞肋的功能。

Materialized View（以下簡稱M-View）

今天要介紹的這個功能和普通的View的差別，就在建立出來的view是一個查詢狀態的「快照」（Snapshot），在快照建立後，只要不更新（Refresh），即使對原本的table有任何的變更，這個M-View裡的資料也不會有任何變化，因此就可以做到前面所說的，讓後台更新的資料不影響到前台的功能，接下來讓我們來看看如何使用這個功能。

Postgresql的Materialized View

這個功能原本是出自於Oracle，號稱「開源的Oracle」的PostgreSQL也在本文撰時最新的穩定版本9.3加入了該功能，參考資料。

建立Materialized View

1
2
3

CREATE MATERIALIZED VIEW table_name
    AS query
    [ WITH [ NO ] DATA ]

例如：

1

CREATE MATERIALIZED VIEW mymatview AS SELECT * FROM mytab;

以上指令會以「SELECT * FROM mytab」的查詢式建立一個名為「mymatview」的M-View，而且在refresh之前，mymatview的內容不會受到原本mytab更新的影響。

結尾的WITH DATA 和 WITH NO DATA的差別是在，會不會在建立時就把當時的資料填進去，如果WITH NO DATA的話，就必需要再使用refresh才可以把資料填進去。

更新Materialized View

1

REFRESH MATERIALIZED VIEW  M-View的名稱

一旦下了這個指令後，就可以將現在的資料內容更新到指定的M-View上

移除Materialized View

1

DROP MATERIALIZED VIEW  M-View的名稱 [CASCADE | RESTRICT]

顧名思義，即完全移除該M-View，CASCADE意即在移除此物件實「一併移除相關物件」。

Materialized View的注意事項

1. 和普通View一樣，不可以用UPDATE或INSERT等更新內容
2. 如果建立了M-View後，要移除關聯的資料表時需要用CASADE方式一併移除相關M-View，否則會無法移除。
3. 可以多層重疊，意即可以透過「查詢M-View建立其它M-View」

Materialized View的用途

1. 加速部份查詢 和一般View不同，M-View佔有獨立表空間，所以查詢M-View不會影響到關聯的資料表，意即如果我們將一些複雜或費時的查詢的結果用M-View建立快照的話，可以透過查詢該M-View節省下一次查詢的時間，例如某個交易資料表如果有10年份1000萬筆的話，將某一年份的交易資料獨立查詢到一個M-View之後，要查詢該年份的交易資料只要查詢該M-View，就不需要在查詢中scan全部10年份的交易資料了。
2. 實現資料版本控制 這是我原本想要使用的目的，這個功能可以玩的地方還很多，例如我們

範例

今天假設有如下的表

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

CREATE TABLE spree_products
(
  id serial NOT NULL,
  name character varying(255) NOT NULL DEFAULT ''::character varying,
  description text,
  available_on timestamp without time zone,
  deleted_at timestamp without time zone,
  slug character varying(255),
  meta_description text,
  meta_keywords character varying(255),
  tax_category_id integer,
  shipping_category_id integer,
  created_at timestamp without time zone,
  updated_at timestamp without time zone,
  CONSTRAINT spree_products_pkey PRIMARY KEY (id)
)

然後我們建立如下的M-View

1
2

CREATE MATERIALIZED VIEW spree_products_mview AS
 SELECT * FROM spree_products;

然後我們看現在的 spree_products表內容如下： 此時table和M-View的資料應該是一致的，此時我們將資料表的一些資料刪除：

1

DELETE FROM spree_products WHERE id = 16;

此時id為16的紀錄已經被移除 但是M-View的資料還是一樣的，如下圖 這時如果我們下了REFRESH的話：

1

REFRESH MATERIALIZED VIEW spree_products_mview;

M-View的資料就會和資料表上一樣了

以上是簡介Materizlied View在PostgreSQL的作用，接下來我們還會針對如何用Rails / ActiveRecord操作這個功能作出說明。

• 一月, 在WebConf Taiwan 2013 發表「非典型貧窮網站維運經驗分享」
• 二月, 舉辦[Ruby 20週年慶祝趴] (https://kktix.com/events/ruby20)
• 四月, 接棒ihower主辦Ruby Tuesday以及Ruby Taiwan社群, 開始Ruby Tuesday 22
• 五月底, 和社群朋友一同參加Ruby Kaigi 2013, 並發表Lightning Talk向世界的Rubyist們介紹了Ruby Taiwan社群
• 七月, 在Ruby Tuesday 24發表日本行心得, 該場Ruby Tuesday也創下了史上最多與會者的紀錄(報名115, 實到100)
• 九月, 和龍哥與泰安共同舉辦了第一屆Rails Girls Taipei; 九月底離開Resume Companion
• 十一月, 舉辦第二屆Rails Girls Taipei, 接任RubyConf Taiwan總召

回顧2013, 最多事件發生在經營Ruby社群方面, 雖然從小以來對辦活動或是搞社團都不太熱衷, 參與社群最初的目的也只是想要精進自己的技術和交朋友, 不知不覺Ruby社群就變成生活重心之一了, 參加RubyKaigi 2013期間的所見所聞也對我產生了很大的衝擊, 明年的目標有：

• 成功舉辦RubyConf Taiwan 2014
• 讓某個該上線的網站上線(秘)
• 讓上述的網站正常營運
• 持續經營Rails Girls 社群
• 在國外的conf發表talk或session
• 學好日文
• 學好英文

加油！

以下是我和高見龍 以及泰安 共同主辦第一屆Rails Girls Taipei活動的心得

Rails Girls社群

有關於Rails Girls社群的介紹可以參考Open Foundry或 Inside的介紹, 在此就不再儹述。

緣起

女性, 在台灣的程式社群屬於稀有動物的範疇, 一般來說在各大程式研討會中女會眾的比例通常在百分之三或以下, 所以一開始知道有Rails Girls這種活動(或著可以說是社群)時並不是特別感興趣; 轉捩點是四月和高見龍一起開有心人課程時, 發現竟然有意外多的女性學員(約佔全部學員的四分之一), 讓我們重新考慮舉辦這個活動的可能性; 研究了一下之後, 發現他是可以自由申請主辦的, 因此在五月初準備Rubykaigi 2013的行程與演講時, 就試著填寫了主站上的申請表單, Rails Girls的創辦人Linda Liukas也很快的就回應我, 讓我加入了世界各地Rails Girls活動的主辦群中。

加入「世界各地的Rails Girls主辦群」之後, 就是可以加入Railsgilrs.com網站的Github Repository, 以及修改或新增網站的內容, 使用Repository內的資源(圖片/素材)之外 還有加入Rails Girls的maillist; 除此之外都要由當地的主辦人自行張羅。

在日本的見聞

我在五月底至六月初和高見龍一同前往日本參加Rubykaigi 2013時, 有幸和日本Rails Girls的主辦人柴田博志先生討論了如何教不會程式的女生上手Rails的方式, 他講到了一個重點「藉由copy & paste, 讓學員有成就感」。

在Rubykaigi三天的議程中, 我們觀察到女性會眾的比例是遠超過5%的, 也藉機在現場認識了許多女性會眾, 發現之中甚至有原本不具程式經驗, 卻因為參加過Rails Girls活動後主動來參加RubyKaigi的女會眾; 而在Rubykaigi後一天舉辦的Ruby Hiroba的主題活動Rails Girls, more extended中, 同行的高見龍也現場觀察了日本這邊的活動情形, 如名稱上的「more extended」所示, 這是普通Rails Girls活動的進階版, 是採取由學員選擇有興趣的主題, 例如前端或後端技術等, 和熟練這些主題的教練一對二或三的教學形式, 在現場就近直接觀查教學的情形, 對於我們日後的主辦也很有幫助; 整個3+1天的活動之中的所見所聞, 都增加了我們的信心和決心。

(在RubyKaigi會場和Rails Girls的學員中澤(中)以及知名的mrubyist Yamane(右)合照)

開始籌辦

從日本回來之後一直忙於各種事件, 直到七月才有空開始, 除了本來就決定要一起主辦的高見龍之外, 剛好社群的朋友泰安對於這個活動都很有興趣, 因此我們就決定一起主辦這個活動。

泰安的夫人本身是一位業餘的畫家, 就請他畫了現在各位看到的這個Logo

贊助商

由於這個活動規定不能向學員收取門票, 所以最重要的是找尋贊助商; 想到之前上課的學生阿姿是國內非常知名且歷史悠久的和女性有關的網站非常婚禮verywed的員工, 於是請她幫忙介紹引薦該公司的老闆與技術主管, 在簡短的會談闡明本活動的宗旨後, 該公司也欣然同意贊助本次活動, 順帶一提的是該公司是台灣極少數以女性員工為主的網路公司, 連程式都是以女性員工佔多數, 感謝非常婚禮的幫忙。

場地

一開始由於並不知道會有多少人報名, 決定以小而精的場地為主要的考量, 就選擇了在各大程式語言社群中頗負盛名的CLBC慶隆商務俱樂部為第一順位的場地選擇; 在談完贊助後立刻前往預約, 也很幸運的預約到了想要的時間; 並且獲得老闆Tyler的同意讓我們用公益團體的優惠價格計費, 在此必需要再次的感謝CLBC。

報名

事先大家最擔心的就是會沒有學員, 畢竟現狀就如前面所提, 程式社群的女性成員是非常稀少的, 不過事後證明這些擔心都是多餘的; 中午開放報名後, 不到2小時就超過了150人, 更在第二天下午時已經超過了320人, 只好提前關閉註冊, 接下來篩選學員的工作反而是最花時間的, 大概花了將近十天在review報名資料上, 由於場地限制的因素, 最後只能選出31位的學員。

學員的資歷方面真的是臥虎藏龍的等級, 有位學員甚至曾經在大陸的百度這種超巨型網路公司工作過, 也有學員特地從台中兩天都當日搭高鐵往返參加的, 最值得一提的是一位來自花蓮數位機會中心的老師, 為了知識傳承, 特地從東部海邊北上來參加活動。

選取標準

如同國外創立這個活動的原意, 加上參考日本方面的選取標準後, 我們希望選擇的是比較沒有其它程式經驗的人, 然後重要的是, 在自介中說明以下兩件事：

1. 為什麼妳想參加這個活動？
2. 讓我們了解妳是一個怎樣的人？

事前準備

雖然之前已經有一點教Ruby的經驗, 不過教完全新手的事, 從學生時代以後就沒體驗過, 這次我們決定由一位教練負責2位學員, 因此從社群徵求了15位朋友來擔任教練的工作, 在Ruby Tuesday#25的會後進行了第一次的討論; 決定了教學方向後, 教材的部份就由泰安負責主編, 其他教練協助編輯, 成果可以在Github上看到; 加上一位公費留學過歐洲, 英文非常流利的教練@JuanitoFatas幫忙翻譯了Rails Girls Guides為主的很多文件, 讓我們雖然是首次主辦, 但各方面規模與完整性並不輸給國外。

現場狀況

雖然已經主辦過如RubyConf Taiwan 這樣的年度國際研討會, 第一次主辦完全以女性為主的活動, 不免還是會擔心出席率等等的問題; 不過活動一切順利, 教練和學員的互動也出乎意外的良好, 可能是因為女生之間一起學習的關係, 一般程式社群中新人女會眾的集體沉默現象在這邊完全不復見, 學員都全程參與, 也沒有遲到早退的問題, 真是可喜可賀。

After Party

教學之外, 這個活動的目的之一是促進學員和教練之間的互動, After Party也列在官方的Guides內, 因此事先就宣布並徵詢學員的參與意願; 場地方面, 想要維持品質以及營造互動的氛圍, 決定要以Lounge Bar為主, 經友人推薦之下, 選擇了費用上不算便宜的TRIBECA, 由於學員需要自費, 原本以為會變成教練與Staff們為主的聚會, 最後還是有超過一半的學員參加, 大家也聊到了十點才散會。

感想

Ruby真的是一門神奇的語言啊, 原本只是基於想要改變社群性別分布不均這個現狀的心情, 從國外引進並舉辦了這個活動, 卻得到了遠遠出乎意料的反應與成果, 看來21世紀的程式學習趨勢真的不是說說而已, 今後也會繼續這個活動下去, 感謝活動過程中一路相挺的朋友們, 謝謝大家。

假設今天我用PostgreSQL的schema功能來做一個BSP服務的話, DB內的schema會分成兩大類：

• 管理用schema(只有一個)
• Blog Schema(有無數個, 每個的結構相同)

一般狀況下, 我們在使用ActiveRecord連接PosttgreSQL時可以在連接選項設定使用Schema, 像這樣：

1
2
3
4
5
6

development:
  adapter: postgresql
  encoding: unicode
  database: SHOPON_development
  pool: 5
  schema_search_path: base, blog1

schema_search_path的預設值是public, 如果照以上設定, 當你執行任何migration時會先從base這個schema執行起, 也就是所有的migration都只會跑在base這個schema上面,

但場景回到Rails/ActiveRecord上, 假如你要做一個BSP, 一般而言你有以下幾種方式：

1. 管理端(管理BSP的)和服務端(Blog服務本身)分別各自一個Rails Application目錄, 然後各有各的migrate
2. 將兩端放在同一個Rails App裡

如果用一般的方式migrate, Rails會依照你database.yml裡設定的schema_search_path的順序找第一順位來執行migrate; 這樣你要如何migrate你的資料到不同schema呢？

今天要講的就是將兩端放在同app裡的方式, 也就是

1. 在migrate檔內設定只能在服務端schema或是管理端schema執行
2. 有單獨migrate管理端和單獨migrate服務端的功能

實現1.的方式如下：

1
2
3
4
5
6
7
8
9
10
11

class CreateSites < ActiveRecord::Migration
  def change
    if ActiveRecord::Base.connection.schema_search_path == 'base' #base為管理端schema
      create_table :sites do |t|
        t.string :subdn
        t.string :name
        t.timestamps
      end
    end
  end
end

簡單來說就是當現在的 schema_search_path 不等於base則不執行create_table的動作; 如果是服務端, 則反過來設定schema_search_path不為base或public即可, 更進一步的可以將這兩種檢查寫成ActiveRecord::Migration的module, 像這樣：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

module ActiveRecord::MultitenancyMigration
  def must_migrate_in_base #管理端
    if ActiveRecord::Base.connection.schema_search_path == 'base'
      yield
    end
  end

  def must_migrate_in_site #服務端
    schema_search_path = ActiveRecord::Base.connection.schema_search_path
    if !schema_search_path.index('base') && !schema_search_path.index('public')
      yield
    end
  end
end

ActiveRecord::Migration.class_eval do
  include ActiveRecord::MultitenancyMigration
  extend ActiveRecord::MultitenancyMigration
end

由於migration檔的內部可能是以self.up(class method)或是up(instance method)的方式編寫, 因此需要同時include和extend這個模組。

實現2.的方式如下：

需要建立for 管理端以及 for 服務端的task 來migrate 各自的schema

1
2
3
4
5
6
7
8
9
10
11
12

namespace :base do
  task migrate_db: :environment do
    ActiveRecord::Base.connection.schema_search_path = 'base'
    Rake::Task['db:migrate'].invoke
  end

  task rollback_db: :environment do
    ActiveRecord::Base.connection.schema_search_path = 'base'
    Rake::Task['db:rollback'].invoke
  end

end

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

namespace :site do

  def check_subdn_exists
    if ENV.has_key?('SUBDN')
      ActiveRecord::Base.connection.schema_search_path = ENV['SUBDN']
      yield
    else
      puts "Please assign SUBDN first!"
    end
  end


  desc 'Migrate Database of Individual site, have to assign SUBDN paramater!'
  task migrate_db: :environment do
    check_subdn_exists do
      Rake::Task['db:migrate'].invoke
    end
  end

  desc 'Rollback migration of single site'
  task rollback_db: :environment do
    check_subdn_exists do
      Rake::Task['db:rollback'].invoke
    end
  end

end

簡單來說就是在migrate前先切換schema, 然後用Rake的指令呼叫原本的db:migrate/rollback出來, 當然你也可以寫一個task是去掃現存的服務端列表然後再各自migrate, 如果要寫在controller或model的話, 則必需先require rake然後再load Rakefile才行。

以上

It’s my pleasure to join the world-class Ruby seminar RubyKaigi2013, as one of the organizers of Ruby Taiwan community, I wish to let the world know the exist of our community, so I plan to submit this LT.

由於是第一次在海外以英文發表, 又是只有五分鐘的LT, 如果用一般的形式會很難控制時間, 因此就想到了高橋流的方式, 在準備的過程中不斷反覆觀看高橋征義在台灣的LT影片以及簡報來練習; 對於鋪梗也是費盡心思, 感謝@ihower在去年RubyConf Taiwan 2012的十六字箴言, 以及在Rubyist Magazine將其日語漢字化的柴田先生@hsbt; 另外由於會眾日本人佔多數, 在講稿上採取英日文並行的方式, 這點要特別再特別的感謝旅居日本的台灣人Rubyist侯大偉@davidhou_tw的全力支持, 大偉不但幫我翻譯, 甚至還請了日本朋友幫忙review, 我跟他致謝時他說：「還是慎重點好 畢竟你代表台灣宣傳阿」這句話時, 真的整個超感動又熱血的.

Since this is my first time to speak outside of Taiwan and it’s a 5 mins LT session, I decided to use the Takahashi-method on my talk. I watch Takahashi-san’s slide and screencasts again and again to meditate and practice my speech. Special thanks to @ihower’s opening slide at RubyConf Taiwan 2012 and @hsbt’s Japanese translation on Rubyist Magazine gave me some content on the slide. I write both Japanese and English on my slide because the biggtest part of audience are Japanese. I have to appreciate David Hou who is a Taiwanese Rubyist working and living in Japan for translating my slide to Japanese. He even asked help from a Japanese friend. He said to me: “We should be more careful, you represent the Ruby Taiwan community after all” when I expressed my thank to him. He really moved me!

另外一個最後引起日本朋友們關注的就是桐島梗了, 其實會有這個梗是因為自從去年Rubyconf Taiwan 2012後就有在關注日本Ruby大神們的推特, 適逢今年3月時日本舉辦的大江戶RubyKaigi03其中一場由CRuby GC的作者中村成洋@nari3的演講桐島、Rubyやめるってよ持續引起大神們的討論, 看了簡報之後雖然不是很懂但是對其中引用的電影聽說桐島退社了感到興趣, 看過之後再回頭看中村的簡報就能夠理解那些梗了, 個人以為那句「戰鬥吧！這裡是我們的世界」是整個電影, 同時也是我自己參與社群經營活動的精神之體現, 作為結尾是非常適合的.

I found the most eye-catching point of my presentation for Japanese is the 「Kirishima」’s ネタ. In fact I started to follow many Japanese Rubyist’s twitter after the RubyConf Taiwan 2012 last year. I noticed Narihiro Nakamura’s presentation named 「Kirishima, stop using Ruby」 which is retwteed many times after the 「Oedo RubyKaigi 03」 on March this year. I am extremely interested by the slide’s subject which is a movie named 「The Kirishima Thing」, so I can understanded what Nakamura expressed in his slide after watched the movie and deeply impressed by it. I decided to use the most important line of the movie “Fighting, this is our world!” as the last page of my slide because I think it is the spirit of both the movie and the reason of why I join the operation of our community.

上台前一直很擔心這些梗會沒有用, 前一天晚上由於和龍哥隔天都要上台的關係緊張到幾乎沒睡; 不過現場的反應真是超乎想像意外的好, 結束後也陸續接到幾位日本朋友們的鼓勵, 真的非常窩心, 感謝你們!

I almost can’t sleep on the eve of LT and worried about if my slide can’t attract the audience. Fortunately I finished the speech and it seemed the audience’s reaction was good. I must show my gratitude for beging metioned by many Japanese Ruby friends on Twitter as below:

@ryudoawaru ありがとうございました！lightning talk最高でした！

— Akira Matsuda (@a_matsuda) 2013年6月1日

練度たかい #rubykaigi #rubykaigia

— Kakutani Shintaro (@kakutani) 2013年5月31日

I would like to go to RubyConf Taiwan 2014〜

— SHIBATA Hiroshi (@hsbt) 2013年6月2日

Awesome taiwan ruby community! @ryudoawaru

— Tatsuya Sato (@sato_ryu) 2013年5月31日

@ryudoawaru わたしも小学生の時からのファンです！ 素敵なLTでした、TwのRubyカンファレンスに行ってみたくなりました :)

— やきとりい (@yotii23) 2013年5月31日

@ryudoawaru 良いLTでした(бвб)！

— すずきみほ SUZUKI Miho (@adzuki34) 2013年5月31日

@ryudoawaru LT素晴らしかったです！ありがとうございました！

— Yuki Nishijima (@yuki24) 2013年6月1日

.@ryudoawaru さんが #rubykaigi 2日目のLTでスライドに桐島を使っていたのは、@nari3 の大江戸03のスライドを見て興味を持ち、映画を探して観て大好きになったからだとか(台湾語字幕あるそうです)。台湾rubyistに桐島届いてた！

— O-Show (@oshow) 2013年6月2日

神奇的是, 在LT投影片上傳slideshare後的隔天竟然登上了slideshare的「Hot on Facebook」首頁排行榜, 真的是又驚又喜

It was a miracle that on the third day of RubyKaigi2013, my slide was in the 「Hot in Facebook」 area of Slideshare’s homepage.

感謝高井先生的照片, 拍的非常好.

Thanks to the high quality photo taken by Naoto Takai.

這趟日本行真的是收獲多多, 接下來還會有幾篇文章介紹; 整個從準備到上台的過程中, 心裡一直想就大偉的話, 要讓世界知道Ruby Taiwan社群的存在, 今後一樣會持續努力

I learn so much on Japan this time, and I will write many blog posts to represent my journey. On the process of preparing the presentation, I always remember what David said and try my best to let the attendee know what we(Ruby Taiwan community) do and I will continue my work in the future.

Thanks to all awesome staffs of Rubykaigi and community friends in Japan, また台湾で会お！

附上簡報檔以及當天Live如下：

達人出版会是由日本知名Rubyist, 也是高橋流簡報術的作者「高橋征義」成立, 目的是透過實踐「敏捷出版」的方式出版技術系的日文純電子書籍, 這邊有一份非常詳盡的介紹文章

最早知道這個網站是在RubyConf Taiwan 2012時高橋的LT時提及的

由於個人對於其中一些在台灣可以稱為是非主流或不可能出版的書籍有興趣, 因此日前OSDC.tw 2013時, 在席間和高橋提到是否有機會將其中一些書籍翻譯成中文版, 甚至是在該平台出版中文原生電子書的事情, 沒想到高橋的回應意外的積極, 於是就不自量力的在高橋先生的首肯之下接下了這個任務, 目前正在募集譯者以及校稿志工

譯者

• 懂日文, 基本上能看得懂日文技術書輯的程度即可
• 懂一定程度的技術, 在達人出版會的架構中, 會有叫作「Reviewer」的校稿志工擔任實體出版社中編輯的任務, 因此譯者即使不是技術方面的強者也沒有關係
• 最重要的就是興趣, 有愛最重要
• 既然書有賣錢, 因此譯者是有酬勞的, 目前規劃是用計件的方式, 不過如果想用版稅的方式也是可以討論的

校稿志工

• 對書本相關的技術有一定程度的認識
• 在翻譯的過程中協助譯者
• 校稿工作

對譯者和校稿志工們而言, 線上出版和實體出版最大的不同就是書籍本身可以一直改版, 所以不會有實體書那樣的壓力; 雙方協同進行翻譯工作可以同時提升日文以及技術能力, 名字會列在書上也算是一個成就.

下面是目前我覺得比較有特色可以翻譯的書籍：

• つくって学ぶプログラミング言語　RubyによるScheme処理系の実装
• 入門Chef Solo - Infrastructure as Code
• きつねさんでもわかるLLVM
• FuelPHP Advent Calendar 2012
• Ruby環境構築講座 Windows編
• 徹底解剖「G1GC」 アルゴリズム編
• エキスパートObjective-Cプログラミング ― iOS/OS Xのメモリ管理とマルチスレッド

有意者請mail: ryudoawaru at gmail.com 給我, 或在下面留言

目前(5/3)為止的募集情況： 校稿志工x3(包括我), 從開始募集譯者一天竟然已經超過10位, 由於報名情形遠超乎想像, 因此之後將請報名者至此填寫基本資料後再試翻作為參考, 謝謝大家！