やぎすけ Advent Calendar 2016 - Adventar
16日目です。やっていきましょう。
さて、今のdevelopment branchではtestが落ちるので、直していきましょう。
Remove unneed controller tests · unasuke/imas_api_rails@56d92f3
GET
しかないので、それ以外は消します。
Define character fixture · unasuke/imas_api_rails@3b78b84
天海春香さん。
Fix test url · unasuke/imas_api_rails@874afe9
indexはまだなにもないので、allに対してテストするよう変更します。
Check response body · unasuke/imas_api_rails@bb50504
response.bodyにちゃんとcharacterがはいっているか確認します。
Add test characters#search without params · unasuke/imas_api_rails@a3bc2a5
searchにparamsがない場合のtestを追加しました。
やぎすけ Advent Calendar 2016 - Adventar
14日目です。大半がやぎにいなのでプレッシャァ。
遅い
無料のci serviceに言う文句じゃない気もしますが、とにかくtestがpassするまでの時間が長いと感じていました。
たとえばRubyの2.3.3など、わりと新しめのversionを使おうとすると毎回インストールを実行するので時間がかかります。
そこでwerckerを選択しました。werckerはciを実行する環境がdocker containerの中になるので、適切なcontainerを 選んでやれば環境構築の手間は最低限で済みます。
こちらになります。
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が実行されるようにしています。
deployが発生しない、通常のciが終わるまでに要した時間を適当に5つ抜き出してみました。
だいたい3分間といったところ。
ほぼ1分間という感じ。
deployが発生する場合に、deploy終了までどれだけの時間を要したかを適当に5つ抜き出してみました。
これもだいたい3分から4分の間。1回だけ13:06かかったことがあり謎。
werckerに移行してからあまりdeployしてないのでサンプルが少ないですが、早くなっています。
#kosendj Advent Calendar 2016 - Adventar
ジャンル名は「哀愁」です。
もっとうまくならなきゃ……
死霊です 👻 #fukuitech
— うなすけ(ミートアップ) (@yu_suke1994) 2016年12月3日
Web appつくるなら何を知らないといけないの? https://t.co/zUQNn0s6oU
logの話するの忘れたなと思いました。
D言語やっていきたい。ドメインやっていきたい。webサイトやっていきたい。
以上です。
やぎすけ Advent Calendar 2016 - Adventar
2日目です。目的とかそういうのはやぎにいがエモい記事を書いてくれました。
やぎ小屋 | やぎすけ Advent Calendar 2016
さて、yagi2/imas_api_railsというものを2人で密かにやっていっている訳です。
これはつい最近できたもので、色々rails new
した時から変わっていないものがあります。その辺を2日目では俺流に書き換えていきます。
Remove comments · unasuke/imas_api_rails@8bfdca4
いらないと思って消しました。
Sorting · unasuke/imas_api_rails@fca1a36
あからさまなrails
はまあ置いとくとして、gemは基本的に名前の辞書順にやっていきましょう。やっていきましょうって、別に推奨されてるわけではないです。
bundle update 20161202 · unasuke/imas_api_rails@637d0d7
嗜み。
Raw Gemfile on Idobata (master - 5adeddb)
この辺の規則はidobataのGemfile styleに倣っています。全部守っているわけではないですが、このスタイルに近づけていくように心がけています。
例えば
:developmentと:testの両方のグループで必要になるgemの記述
は今は守っていませんが、この記述量でそんな気にするほどでもないと思ったのでそうしています。
秋吉 Advent Calendar 2016 - Adventar
メニューを見ます
タレが来ます
第一陣
第二陣
ごちそうさまでした。
昔から「<任意のイベント名>は帰ってブログを書くまでが<任意のイベント名>です」と言われるように、今これを書くことでDGMSが終わります。
DGMSとは、DRECOM、GMOペパボ、Mobile Factory、spice lifeの4社にこの2年ほどで入社した若者達が集まって交流するというイベントです。でした。11月22日に開催されました。
だいたい各社2名ずつ登壇しました。xlsxをうまいこと運用していく話と自作tool、ペパボの手厚い研修制度の話、味噌と便利なプラグインの話、UnityのAssetBundleをうまいことする社内APIの設計、実装の話、レビューの悩みの話、PerlとJSイベントの話などがありました。その他に懇親会、その中での突発LTがいくつもありました。
資料です。
事前にSlackで発表テーマを伺ったら「今年n年目だけど今何をやっているのか」という提示を頂きました。
ですが今やっていることに限らず、高専5年生から今に至るまでどういうことをやってきたかという感じの話をしました。やっぱり僕はまだまだ技術的に未熟なので、いろいろに手を出し、首を突っ込んで何を知らないかを知る必要があると思っています。というかそんな高尚でもなく、ただやってみたいからみたいな気持ちでいろいろを始めてみている、というところが正直なところでもあります。
こんなエモい話するつもりでしたっけ。
新卒氏からは「技術力が高い」などと評価されていますが、そりゃあ1年のアドバンテージがありますから、僕も僕の新卒入社した頃よりは自分の技術力が向上していることがわかっています。それでも知らないこと、知りたいことがまだまだたくさんあることもわかっています。
そういう、何を知るべきで何を知らないままにするかというのは、やっぱり自分がどういう人間になっていきたいかというのがまず先にあるべきだと考えています。逆もあるかもしれませんが。
Slack emojiの話でもりあがったり、絵文字ジェネレーターの最高な機能だったり、ようやく @ne_sachirou さんと会うことができたりしました。
DRECOMさんに置いてあるPSVRやoculusを体験させてもらいましたがこれが最高で、僕はMikulusを体験させていただいたのですがこれがライフチェンジングでした。やばい、もどってこれない、そんな感じがしました。強い意志で現実に返ってきました。
絶対買います。
さて皆さんご存知のProconist.netですが、これはsinatra applicationとして作られました。
そしてsinatra applicationは、いろいろいい感じにしていくとRailsに近づいていく、というのはよく知られたことです。
じゃあRailsにしちゃえということで、しました。
unasuke/proconist.net: The repository links for fighter of KOSEN PROCON.
移行期間がちょうどプロコン本戦とかぶっているので、これもプロコンです。
sinatraは、こういう構成で動作していました。
こいつをRailsに移し替えるわけです。
とはいえそのまんまロジックをRailsに移し替えるだけではなく、modelの正規化等も行いました。具体的には以下を行いました。
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に分け、正規化をおこないました。
DBのtableが分割されたということは、modelも分割されるというのは想像に難くないでしょう。
8 modelsから10 modelsに分割しました。table数と一致しないのはhabtm関連があるためです。
sinatraの頃はspecが存在しなかったのですが、Railsに移行するにあたってRSpecとRuboCopを導入しました。
しっかりとした移行をおこなうのであればもとのsinatra appに対してのブラックボックステストをまず作成すべきだと指摘を受けるかもしれませんが、そこまでする気力はありませんでした。
そしてspecを書くにあたって欠かせないと言っていいのがCI serviceですが、自分が使いたかったのもあってwerckerを選択しました。
またカバレッジを計測するためにCoverallsも導入しました。記事執筆時点でのカバレッジは89%です。
sinatraのviewは全てerbで書かれていました。僕はerbというか生のhtmlを書くのが本当に嫌で、そういうものは記述量の少ないテンプレートエンジンに置き換えたいと思っているので、slimを使用することにしました。
34のerb filesが、42のslim filesに変換されました。erbが1 file残っているのですが、google analyticsのpartialなので、むしろslimにしないほうが良いかと思いerbのままにしています。
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
をこのように定義することで、🍣🍺問題、ハハパパ問題への対応をおこないました。
rails 5のリリースということがこの移行のきっかけの1つということもあり、特に理由もなくunicornからpumaに移行しました。
あとは、既存のviewに対応するControllerを作成していきました。管理画面用のcontrollerは改装を分けるなどを行い、結果的に17のcontrollerを作成しました。
ヘタにtableを分割したので、controllerが肥大化した部分があり、今後refactoringしていきたいと思っています。
proconist.net/products_controller.rb at caa35ad4 - unasuke/proconist.net
後述しますが、既存の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上に構築していきたい気持ちがあったのですが、移行までにかかる手間、酒田 シンジさんとの共同作業のコストを考えると、既存のVPSに構築するのが一番楽でかつ素早いものでした。
またAWS上に構築しないことで、必然的にDockerizeする意味もなくなりました。(ECRを使いたかった気持ちがありました。)
実装を急いでいた部分もあり、specは不十分です。とくに管理画面のcontrollerに対するspecは全く無いので、カバレッジ90%台まではせめて持っていきたい気持ちがあります。
付随して、実装が冗長な部分や汚い部分がいくつかあるので、それを修正していくのも早急に行いたいです。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)さん、本当にありがとうございます。
この日の朝7時まで移行作業をしていて完全に寝不足状態だったので、落ち着いた感じで発表していこうと思っていたのですが、いざ発表となるとスライドの枚数の多さと緊張から完全にハイテンションになって超早口になってしまいました。間に合わせるとはいえ、聞き苦しくて申し訳ない気持ちです。
移行のついでに、Gitterで部屋を作りました。
ここはProconist.netの実装のことや、その他プロコンに関連する雑多な話ができる交流の場として使って欲しいという思いで作成しました。参加について特に制限等を設けるつもりはないので自由に入って(抜けて)いただいて構いません。もちろん、プロコン参加者や高専生に限らず、どなたでも入室していただいて構いません。
ぜひご活用ください。
突然ですが、社内の出費がやばい3人組で、お弁当をつくって持ってこようという話になりました。発案は僕らしいのですが、全く記憶に無いです。 弊社社員でこれを読んでいる方、昼にお弁当を食べているあの3人は出費がやばい組です。よろしくお願いします。
前置きはともかくとして、実際こういうお弁当をつくっていました。
ごはん、ごま唐辛子しそ昆布、玉子焼き、ウイニー、ミートボール、ほうれん草の胡麻和え(冷食)です。味としては優勝です。
とりあえず1日目、気を張らない感じでつくったものです。自炊を久しくしていなかったので、肩慣らしと言うか、勘を取り戻すというか、そんな感じです。
ごま唐辛子しそ昆布は、昆布館で買うことができます。めっちゃおいしいです。優勝の秘訣です。
我が家では、この玉子焼きとウイニーはお弁当レギュラーメンバーなので、毎回登場します。
あと書くのが面倒なので省略しますが、毎食フリーズドライのお味噌汁を食べています。
ごはん、ふりかけ(旅行の友)、なすの肉みそ炒め、玉子焼き、ウイニーです。味としては優勝です。この日以降、お弁当を会社でレンチンすることを学びました。優勝の秘訣です。
なすの肉みそ炒めは、キッコーマン うちのごはん なすの肉みそ炒めに、この前の週に行った塚田農場で貰った味噌を加えました。 おいしかったです。
ふりかけはCTOからだいぶ前にもらったものです。
ごはん、ふりかけ(鰹みりん)、玉子焼き、はんぺんのベーコン巻き、お惣菜のコロッケ、ウイニーです。味としては優勝です。
お惣菜のコロッケは2日目の晩御飯の残りです。はんぺんのベーコン巻きは、先輩が持ってきたお弁当レシピ本に載っていたのをつくりました。優勝の秘訣です。
このふりかけも、CTOからだいぶ前にもらって持て余していたものです。この日で貰った分は使い切りました。
アスパラガス、ほうれん草、ベーコンのコンソメパスタ、ウイニー、きんびらごぼう(冷食)です。味としては優勝です。
玉子が切れているのに気づかなかったため、玉子焼きはありません。
パスタは、3日目の先輩のレシピを真似してつくってみました。味がちょっと薄くなっちゃって失敗かな、という感じです。とはいえ優勝は優勝です。あともっとほうれん草を入れるべきと指摘を受けました。優勝の秘訣です。
会社でランチの日だったので、お弁当はつくっていません。
以下、優勝の記録です。
出費3人衆のうちで、一番お弁当経験豊富な先輩にいろいろアドバイスをいただきました。ちなみに僕含むあと2人は経験が無に等しいです。
「洗うのが面倒だから、お弁当箱は洗いやすいものを選ぶと良い」とのことでした。
僕が使っているお弁当箱は、Afternoon Teaのこれのネイビーです。 パッキンと蓋が一体化していて、部品が少ないので洗うのが楽です。
意識していないと野菜を入れるのは難しく、しかし緑がないと見た目が寂しい(3日目のお弁当参照)ので、緑色のカップを買うと良いとのことでした。
お弁当を始める!といったらやままさんとらいむさんがシンカテック 抗菌 お弁当カップ 角型 ベジカップ L | amazonをプレゼントしてくれたので、これを使っています。
「1人ぐらしの自炊は節約にはならない」などという話も聞きますが、実際どうなのか、かかったコストを比較してみます。
渋谷近郊のランチが大体1000円で、晩御飯も外食として、昼夜外食で済ませると1食800円と見積もっても1日で1600円、4日+1食(金曜は会社ランチのため)として7200円が消費されます。これは極端な計算だと思いますが、それでも5000円前後になるのではないかと思います。
今回のお弁当で購入した食料品の合計金額は、3088円でした(晩御飯の自炊分を含む)。どうでしょうか。渋谷近郊で毎食外食するよりは安くつくと思います。毎食はなまるうどんや小諸そばにするよりは高価かもですね。
1週間分にしては高いと思うかもしれません。これは、必要になった調味料の購入や、そもそも割安な大量購入をせずに余らせないよう割高な食料品を購入していたせいかもしれません。
実際はこれに加えてお弁当箱などのイニシャルコストが発生しますが、考えたくないので無視します。
とにかく、朝早く起きるようになりました。と言っても8時とかなので怒られるかもしれませんが、以前は10時とか14時に起きていたことを考えると大きな成長を感じます。
そしてまた、夜寝るようになりました。起きれないと困るので、2時とかに寝ていたものを0時頃には寝るようになりました。それでも以前は寝すぎですね。しかし睡眠は重要です。
あと、レシピを見ずに作れる料理のレパートリーがあまりに少ないので、お弁当活動を通じて料理スキルの向上を目指したいです。とりあえず今余っている食材に何品か追加で買ってコンソメスープを作ることを目論んでいます。
先輩が持ってきた数冊のレシピ本のなかに、「休日には肉を煮よ」と書いてあった気がするので、3連休、肉を煮るかもしれません。その様子はブログにする予定はありません。