慕凡(@ryudoawaru)'s blog

目前還沒想到

將 5xruby.tw 升級到 Rails 5.0.0.beta2

| Comments

最近將敝公司 5xruby.tw 的官網的 Rails 版本升級到 5.0.0.beta2,具體的升級 commit 主要在 5d7587d,以下是一些步驟說明:

  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 中的版號

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

以上

在 OSX 下升級 Homebrew 安裝的 PostgreSQL(dump 版)

| Comments

前言

繼上一篇的 在 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

以上

Table Inheritance in PostgreSQL

| Comments

前言

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 等。

主鍵重複值問題

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

測試title
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 的設定上必需客製一些設定

以上!

大江戶 RubyKaigi 05, Asakusa.rb 以及 Ruby World Conference

| Comments

這篇 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 直播。

門票方面,活動門票是 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 除了吃吃喝喝外,還有奇妙的島根吉祥物 しまねっこ 出沒。

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

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

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

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

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

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

個人成就紀錄

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

  • 在海外用英文發表技術 & 非技術議題
  • 一週內兩次英文發表
  • 在英文發表前用日文自介
  • 和日本人唱 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 2015

| Comments

今年是第五屆的 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

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

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

  • Pre-Conf Party

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

場內

  • 茶 / 咖啡贊助商

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

  • 在會場交誼廳舉辦 Party

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

  • RFID by Codeme.cc

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

團隊

  • 議程: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 / 講者以及許多朋友的幫忙才能促成今年的活動順利舉辦,謝謝大家!

解決用 Mac 登入 Linux 主機時出現的 Locale 警告訊息

| Comments

前陣子用 Mac 登入遠端的 Linux 主機時常常遇到一個有點討厭的訊息:

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

自動化測試 Rails 中的 URL HELPER

| Comments

前言:

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

  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

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

在 Mac / Homebrew 下升級 PostgreSQL 從 9.3 到 9.4

| Comments

前言

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 2014之旅以及 Rails Girls Taipei 獎助金計劃

| Comments

緣起

由於有了去年第一次和高見龍等人一同參加 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 獎助金計劃獲選者)

參加了哪些活動

可參考下列文章與分享:

  • 同上的影片紀錄

結語

一年多前參加 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 小姐

RubyConf Taiwan 2014

| Comments

按照往年的慣例,這篇也拖稿了超級久。

時間和場地

記得應該是 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,敬請期待!