2016年12月20日
#kosendj Advent Calendar 2016
#kosendj Advent Calendar 2016 - Adventar
20日目MIX
ジャンル名は「カラオケ」です。
「準備はいいんかね!?」で始まり、「これでお終いさ」で終わるのは狙いました。
セトリ
- ルンがピカッと光ったら - ワルキューレ
- survival dAnce ～no no cry more～ - TRF
- Pick Me Up - Perfume
- ワンルーム・ディスコ - Perfume
- WILD STARS - μ’s
- Darling!! - 西木野真姫 (Pile)
- Hotel Moonside (Extended Live Version) - 速水奏 (CV:飯田友子)
- レーザービーム (Album-mix) - Perfume
- ショコラ・ティアラ - 三村かな子 (大坪由佳)
- さよならトリップ - Dormir
- Snow Crystal - Another Infinity Feat. Mayumi Morinaga
- Just Be Friends - Dixie Flatline Feat. 巡音ルカ
余談
2016年12月14日
やぎすけ Advent Calendar
やぎすけ Advent Calendar 2016 - Adventar
14日目です。大半がやぎにいなのでプレッシャァ。
Circle CIへの不満
遅い
無料のci serviceに言う文句じゃない気もしますが、とにかくtestがpassするまでの時間が長いと感じていました。
たとえばRubyの2.3.3など、わりと新しめのversionを使おうとすると毎回インストールを実行するので時間がかかります。
werckerなら速そう
そこでwerckerを選択しました。werckerはciを実行する環境がdocker containerの中になるので、適切なcontainerを
選んでやれば環境構築の手間は最低限で済みます。
werckerでmiddlemanのbuild
こちらになります。
box: ruby:2.3.3
init:
build:
steps:
- install-packages:
packages: nodejs
- bundle-install
- script:
name: middleman build
code: bundle exec middleman build
deploy:
steps:
- install-packages:
packages: nodejs rsync
- bundle-install
- add-ssh-key:
host: unasuke.com
keyname: deploy
- add-to-known_hosts:
hostname: unasuke.com
fingerprint: $FINGERPRINT
- script:
name: middleman build
code: bundle exec middleman build
- script:
name: middleman deploy
code: bundle exec middleman deploy
master branchでciが実行された場合は、deploy pipelineが実行されるようにしています。
どのくらい速くなったのか
build ci
deployが発生しない、通常のciが終わるまでに要した時間を適当に5つ抜き出してみました。
circle ci
- 02:53
- 03:19
- 02:59
- 04:45
- 03:12
だいたい3分間といったところ。
wercker
- 01:04
- 00:57
- 01:01
- 00:59
- 01:03
ほぼ1分間という感じ。
deploy ci
deployが発生する場合に、deploy終了までどれだけの時間を要したかを適当に5つ抜き出してみました。
circle ci
- 03:20
- 03:36
- 04:14
- 02:56
- 02:50
これもだいたい3分から4分の間。1回だけ13:06かかったことがあり謎。
wercker
werckerに移行してからあまりdeployしてないのでサンプルが少ないですが、早くなっています。
参考
2016年12月02日
やぎすけ Advent Calendar 略してYAC
やぎすけ Advent Calendar 2016 - Adventar
2日目です。目的とかそういうのはやぎにいがエモい記事を書いてくれました。
やぎ小屋 | やぎすけ Advent Calendar 2016
imas_api_rails
さて、yagi2/imas_api_railsというものを2人で密かにやっていっている訳です。
これはつい最近できたもので、色々rails newした時から変わっていないものがあります。その辺を2日目では俺流に書き換えていきます。
Gemfile
コメントの削除
Remove comments · unasuke/imas_api_rails@8bfdca4
いらないと思って消しました。
辞書順に
Sorting · unasuke/imas_api_rails@fca1a36
あからさまなrailsはまあ置いとくとして、gemは基本的に名前の辞書順にやっていきましょう。やっていきましょうって、別に推奨されてるわけではないです。
bundle update
bundle update 20161202 · unasuke/imas_api_rails@637d0d7
嗜み。
参考にしているもの
Raw Gemfile on Idobata (master - 5adeddb)
この辺の規則はidobataのGemfile styleに倣っています。全部守っているわけではないですが、このスタイルに近づけていくように心がけています。
例えば
:developmentと:testの両方のグループで必要になるgemの記述
は今は守っていませんが、この記述量でそんな気にするほどでもないと思ったのでそうしています。
2016年11月23日
DGMS
昔から「<任意のイベント名>は帰ってブログを書くまでが<任意のイベント名>です」と言われるように、今これを書くことでDGMSが終わります。
DGMSとは、DRECOM、GMOペパボ、Mobile Factory、spice lifeの4社にこの2年ほどで入社した若者達が集まって交流するというイベントです。でした。11月22日に開催されました。
様子
だいたい各社2名ずつ登壇しました。xlsxをうまいこと運用していく話と自作tool、ペパボの手厚い研修制度の話、味噌と便利なプラグインの話、UnityのAssetBundleをうまいことする社内APIの設計、実装の話、レビューの悩みの話、PerlとJSイベントの話などがありました。その他に懇親会、その中での突発LTがいくつもありました。
僕の発表
資料です。
unasuke/DGMS_20161122
事前にSlackで発表テーマを伺ったら「今年n年目だけど今何をやっているのか」という提示を頂きました。
ですが今やっていることに限らず、高専5年生から今に至るまでどういうことをやってきたかという感じの話をしました。やっぱり僕はまだまだ技術的に未熟なので、いろいろに手を出し、首を突っ込んで何を知らないかを知る必要があると思っています。というかそんな高尚でもなく、ただやってみたいからみたいな気持ちでいろいろを始めてみている、というところが正直なところでもあります。
こんなエモい話するつもりでしたっけ。
新卒氏からは「技術力が高い」などと評価されていますが、そりゃあ1年のアドバンテージがありますから、僕も僕の新卒入社した頃よりは自分の技術力が向上していることがわかっています。それでも知らないこと、知りたいことがまだまだたくさんあることもわかっています。
そういう、何を知るべきで何を知らないままにするかというのは、やっぱり自分がどういう人間になっていきたいかというのがまず先にあるべきだと考えています。逆もあるかもしれませんが。
感想
Slack emojiの話でもりあがったり、絵文字ジェネレーターの最高な機能だったり、ようやく @ne_sachirou さんと会うことができたりしました。
DRECOMさんに置いてあるPSVRやoculusを体験させてもらいましたがこれが最高で、僕はMikulusを体験させていただいたのですがこれがライフチェンジングでした。やばい、もどってこれない、そんな感じがしました。強い意志で現実に返ってきました。
絶対買います。
2016年10月23日
sinatraからRailsへ
さて皆さんご存知のProconist.netですが、これはsinatra applicationとして作られました。
そしてsinatra applicationは、いろいろいい感じにしていくとRailsに近づいていく、というのはよく知られたことです。
じゃあRailsにしちゃえということで、しました。
unasuke/proconist.net: The repository links for fighter of KOSEN PROCON.
移行期間がちょうどプロコン本戦とかぶっているので、これもプロコンです。
sinatraの構成
sinatraは、こういう構成で動作していました。
- sinatra
- SQLite
- unicorn
- nginx
- さくらのVPS
こいつをRailsに移し替えるわけです。
ただRailsにするだけではない
とはいえそのまんまロジックをRailsに移し替えるだけではなく、modelの正規化等も行いました。具体的には以下を行いました。
- DB 正規化
- model 分割
- specを書く
- CI導入
- erb → slim
- SQLite → MySQL
- unicorn → puma
- ひたすらcontrollerつくる
DB正規化
sinatraでの、ある高専の作成したプログラムを表すtableは以下のように定義されていました。
create_table "entrants", force: true do |t|
t.integer "contest", null: false
t.integer "section", null: false
t.integer "registry_num", null: false
t.string "school", null: false
t.string "production", null: false
t.string "github"
t.string "bitbucket"
t.string "other_repo"
t.string "slideshare"
t.string "other_slide"
t.string "twitter"
t.string "facebook"
t.string "site"
t.integer "result"
t.string "prize"
end
たとえばschoolは個別に格納されていて、正規化をおこなう余地がありました。また、prizeにはその高専のプログラムが獲得した賞が「カンマ区切り」で格納されているので、これも別々のrecordに格納することでより健全な状態にDBを持っていくことができます。
そこで、このようにtableを分割しました。
# index、datatimeなど省略
create_table "products", force: :cascade do |t|
t.integer "contest_id", null: false
t.integer "section", null: false
t.integer "school_id", null: false
t.string "name", null: false
t.integer "rank"
end
create_table "documents", force: :cascade do |t|
t.integer "product_id", null: false
t.string "document_type", null: false
t.string "url", null: false
end
create_table "prizes", force: :cascade do |t|
t.integer "product_id", null: false
t.string "name", null: false
end
create_table "schools", force: :cascade do |t|
t.string "name", null: false
end
このようにtableの定義を書き換え、8 tablesから11 tablesに分け、正規化をおこないました。
model 分割
DBのtableが分割されたということは、modelも分割されるというのは想像に難くないでしょう。
8 modelsから10 modelsに分割しました。table数と一致しないのはhabtm関連があるためです。
specを書く
sinatraの頃はspecが存在しなかったのですが、Railsに移行するにあたってRSpecとRuboCopを導入しました。
しっかりとした移行をおこなうのであればもとのsinatra appに対してのブラックボックステストをまず作成すべきだと指摘を受けるかもしれませんが、そこまでする気力はありませんでした。
CI導入
そしてspecを書くにあたって欠かせないと言っていいのがCI serviceですが、自分が使いたかったのもあってwerckerを選択しました。
またカバレッジを計測するためにCoverallsも導入しました。記事執筆時点でのカバレッジは89%です。
erb → slim
sinatraのviewは全てerbで書かれていました。僕はerbというか生のhtmlを書くのが本当に嫌で、そういうものは記述量の少ないテンプレートエンジンに置き換えたいと思っているので、slimを使用することにしました。
34のerb filesが、42のslim filesに変換されました。erbが1 file残っているのですが、google analyticsのpartialなので、むしろslimにしないほうが良いかと思いerbのままにしています。
SQLite → MySQL
sinatraのDBはSQLiteを使用していました。これを、DB schemaも変わるということでMySQLに移行しました。
default: &default
adapter: mysql2
encoding: utf8mb4
charset: utf8mb4
collation: utf8mb4_general_ci
pool: 5
username: root
password:
host: localhost
config/database.ymlをこのように定義することで、🍣🍺問題、ハハパパ問題への対応をおこないました。
参考
unicorn → puma
rails 5のリリースということがこの移行のきっかけの1つということもあり、特に理由もなくunicornからpumaに移行しました。
ひたすらcontrollerつくる
あとは、既存のviewに対応するControllerを作成していきました。管理画面用のcontrollerは改装を分けるなどを行い、結果的に17のcontrollerを作成しました。
ヘタにtableを分割したので、controllerが肥大化した部分があり、今後refactoringしていきたいと思っています。
proconist.net/products_controller.rb at caa35ad4 - unasuke/proconist.net
本番VPSへのdeploy
後述しますが、既存のVPSにdeployをすることになりました。しかし(おそらく)sinatraはインスタンスからgit pullをしているので、これをCapistranoによるdeployに置き換えました。
deploy時に、VPS上の環境変数が評価されないという問題があり、login shellを設定するという変更を行いましたが、基本的にはデフォルトの設定をそのまま使用しています。(pumaのrestartだけ変更)
# config/deploy/production.rb
# fetch environment variable from .bashrc
set :default_shell, '/bin/bash -l'
できなかったこと
AWS上に構築
もともとAWS上に構築していきたい気持ちがあったのですが、移行までにかかる手間、酒田 シンジさんとの共同作業のコストを考えると、既存のVPSに構築するのが一番楽でかつ素早いものでした。
Dockerize
またAWS上に構築しないことで、必然的にDockerizeする意味もなくなりました。(ECRを使いたかった気持ちがありました。)
これからやること
specの充実
実装を急いでいた部分もあり、specは不十分です。とくに管理画面のcontrollerに対するspecは全く無いので、カバレッジ90%台まではせめて持っていきたい気持ちがあります。
refactoring
付随して、実装が冗長な部分や汚い部分がいくつかあるので、それを修正していくのも早急に行いたいです。PullRequest待ってます。
監視
uptimerobotによる外形監視のみが有効なので、CPUやMemoryのUsageも見るようにしたいです。
ふりかえって
unasuke/proconist.net: The repository links for fighter of KOSEN PROCON.
大変だったのは、controllerの移行だったと思います。modelを分割したせいで、あるformをsubmitした時に複数のmodelの更新、または作成をする必要があり、paramsからfetchしてくる部分などとにかく泥臭いコードになってしまったと感じています。
次いで大変だったのは、VPS上へのdeployです。慣れないCentOSという環境、そして移行とはいえDBも変わるので、ほとんど一からの構築となると、まっさらの環境へapplicationが動作する状態を構築した経験のない僕にとっては試行錯誤の連発でした。
そしてそれらはいい経験になりました。
あとこの記事を書いている最中にもバグを見つけたので修正しなきゃなあと焦っています。
まず初めにProconist.netというweb applicationを作成し、Rails化という大役を僕に一任してくれた酒田 シンジ(NKMR6194)さん、結局採用されなかったインフラ構成に関してアドバイスをして頂いたやまま(kirikiriyamama)さん、本当にありがとうございます。
Dentoo.LTでの発表
発表の録画(youtube)
発表資料(GitHub)
この日の朝7時まで移行作業をしていて完全に寝不足状態だったので、落ち着いた感じで発表していこうと思っていたのですが、いざ発表となるとスライドの枚数の多さと緊張から完全にハイテンションになって超早口になってしまいました。間に合わせるとはいえ、聞き苦しくて申し訳ない気持ちです。
Gitter部屋
移行のついでに、Gitterで部屋を作りました。
proconist.net/Lobby - Gitter
ここはProconist.netの実装のことや、その他プロコンに関連する雑多な話ができる交流の場として使って欲しいという思いで作成しました。参加について特に制限等を設けるつもりはないので自由に入って(抜けて)いただいて構いません。もちろん、プロコン参加者や高専生に限らず、どなたでも入室していただいて構いません。
ぜひご活用ください。
