第13羽 ひと目で尋常でないもふもふだと見抜いたよ
この記事は ごちうさ住民 Advent Calendar 2014 - Adventar 2期1羽(つまり13羽)です.
タイトル通り ひと目で(コンピュータに任せて)尋常じゃないもふもふ(ごちうさ住民が移住可能な動画)だと見抜こう と思います
唐突ですが,こちらが作ったサービスになります
ごちうさ難民はどこへいったのか
どんなサービス?
動画IDを入れるとその動画の難民救済力を数値化します.
やっていることは,コメントの類似度をとっているのですが、技術詳細はまた別記事に書こうと思います.
2014夏アニメではどこが受け入れ先になってたっぽいのか
さて,ごちうさ難民の受け入れ先を見つけるという問題だったので,ごちうさ一期が終わった直後の2014夏アニメの中から一番親和性の高いものを発表します.
映えある受け入れ先認定アニメは
http://pyon.hi-king.me/view/1405322065
でした.おめでとうございます.
普通の女子校生が【ろこどる】やってみた。 第1話「【ろこどる】はじめてみた。」の難民救済力は1521で, 難民キャンプ レベル
素晴らしいスコアです.
ちなみに,ごちうさ住民との乖離が大きいコメントも表示されるので,ろこどるがどうすればよりごちうさに近づけるかがわかります.
ろこどるに多いコメとして ["w", "かわい"], ごちうさに多いコメとして ["おまかわ", "ぶひい"] が挙げられるので,ろこどるは笑いに走りすぎて,萌え豚への配慮が足りないということもできるのかもしれません.
アニメごとにどういう傾向があるのか
難民と親和性が高いもの
http://pyon.hi-king.me/view/1397120254
一週間フレンズ。 第1話「友達のはじまり。」の難民救済力は1437で, 難民キャンプ レベル
藤宮さんの可愛さに癒やされていた難民も多いでしょう.コメントの傾向を追うと,一週間フレンズがごちうさになるためにはブヒリティが足りなくて,可愛さと笑いが多すぎるようです."あ"のコメはおそらく"ああああああああ"の叫びが正規化されたもの.一週間フレンズにそんな叫ぶシーンありましたっけ?
難民と親和性が低いもの
http://pyon.hi-king.me/view/1405996527
やはり全体的に男が多いアニメは親和性が低いです.他には蟲師とか.具体的なコメでいうと,"ぶひいいいいい", "おまかわ"が不足してるみたいですね.それと遊☆戯☆王は"!?"とか"は?"とかの成分が強いので,展開に突っ込みながら観たい人向けなんでしょう.
ゆゆ式は人生
http://pyon.hi-king.me/view/1365661495
ごちうさに続いて二台難民発生源だと思っている伝説のアニメ,ゆゆ式というものがあるのですが,ごちうさを1クール -> ゆゆ式を1クール -> ごちうさを1クール...とやることですべての難民を生まれる前に円環の理に導けるのでは!すごいこと思いついちゃった,と思ったのでゆゆ式一話の難民救済力を調べました
難民救済力は1351で, 難民キャンプ レベル
たしかになかなか高いが,最上級の称号まではいかなかったんです.不服なのでパラメタの方も確認
結構食い違ってるんですねー.ゆゆ式に多いのが[w, かわいい, キマシ]で,ごちうさに多いのが[おまかわ, ぶひい]となっています.たしかにごちうさは,日常系のジャンルの中では最大級のあざとさを誇っているため,同ジャンルと比較するとブヒリティが高すぎるのかもしれません.一方で,そういう男性視聴者へのアピールが見え隠れするごちうさよりも,ゆゆ式のほうがキマシ力は高いということが言えるのでしょう.僕ももう少し若かったらごちうさのあざとさが鼻についていたかもしれません.
ちなみに,ゆゆ式は哲学なのでごちうさのほうが"ここ哲学"コメが多くなっているのは誠に遺憾ですし,アルゴリズムを改善する必要があります.
結論
推薦アルゴリズムを部分的に実装した(評価部分)ので,残り半分(探索部分)は皆さんが動画IDを入れてみてください.僕は皆さんが作ってくれるログを追って最大値の救済力を誇る動画をさがし,癒やされたいです.
この記事とサービスは会社から有給休暇をもらって作りました.心ぴょんぴょん!
10万円で開発用ラップトップを買うなら
自宅で使ってる開発用PCがそろそろスペック的に辛くなってきたので,新しいマシンを購入しようと思っていろいろ比較してました.たしかUltrabookは$100くらいを目指してるはずなので,まぁ10万円も出せばまともなマシンが手に入るだろう,と.しかし意外とこの予算で満足な開発機を探すのは大変でした.
求めていたスペックは,とにかくCPUとメモリを盛りたいのと,勉強会などで外出するために,大きすぎないもの.ということで以下の3条件
- ivy bridge以降のcorei7, 4コア以上
- メモリ16GB
- サイズは15型まで
ちなみにOSはLinux使うのでokで,オフィスなどもいらない.グラボは悩みどころではあるけれども必須ではないです.
結局見つかったのは以下のマシン,Thinkpad E440のみでした.
基本的にハイスペックラップトップは画面サイズが大きい物が多いです.また,期待してたUltrabookはCPUが貧弱だったり希望のスペックにカスタムすると15万を超えてきたりします.というわけでお安い小型ハイスペックラップトップはLenovo一択でした.
スペック表(カスタム後)
カスタマイズした項目は!で示してます
価格(税込・クーポン*1適用後) | ¥105,678 |
!プロセッサー | インテル Core i7-4702MQ プロセッサー (2.20GHz, 6MB, 1600MHz) |
初期導入OS | Windows 8.1 (64bit) |
導入OS言語 | Windows 8.1 (64bit) - 日本語版 |
!ディスプレイ | 14.0型HD+液晶 (1600 x 900 光沢なし) - ミッドナイト・ブラック |
グラフィックス | インテル HD グラフィックス |
Security Chip | セキュリティー・チップ(TPM)あり |
!メモリー | 16GB PC3-12800 DDR3L (2スロット使用) |
キーボード | 日本語キーボード |
!指紋センサー | ウルトラナビ, 指紋センサーあり |
内蔵カメラ | カメラ(HD 720p対応)あり、マイクロフォンあり |
!ハード・ディスク・ドライブ | 1TB ハード・ディスク・ドライブ, 5400rpm |
!マイクロ・ハード・ディスク | 16GB マイクロ・ソリッド・ステート・ドライブ (キャッシュ) |
オプティカル・ドライブ | DVDスーパーマルチ・ドライブ |
!バッテリー | 6セル Li-Ion バッテリー (62Wh) |
電源アダプター | 65W ACアダプター |
ワイヤレスLAN アダプター | ThinkPad IEEE 802.11b/g/n ワイヤレスLAN (WiFi準拠)1x1, Bluetooth4.0 |
付属品言語 | 日本語 |
標準保証 | 1年間 引き取り修理 |
WWAN Misc Parts | その他の WWAN/mSATA パーツ - WWAN または mSATA カード・フル (F1) |
必須項目のカスタムをしたうえで,画面の解像度が5kで上げられたのと,システム用SSDとバッテリも安価にグレードアップできたので追加しときました.安くて楽しそうだったので指紋センサーもつけたけどこれは無駄になるかもしれない.
*1:カカクコムのもの+週末クーポン
jenkinsで全てのブランチをテストし続ける
jenkinsでCIをしている時に,レポジトリへのpushがあるたびに,pushされたブランチをテストしたいことがあります.一つのブランチだけをテストするのではなくて,全てのブランチを逐次テストしておくってことです.さぁどうしよう.
おおまかな流れは以下
- レポジトリへのpushをjenkinsに通知
- gitプラグインでmasterブランチに移動
- そのpushの情報をjsonで受け取る
- jsonからブランチ名を取り出してチェックアウト & pull
- テスト
push通知 -> masterブランチ取得まで
githubのレポジトリ設定からWebhooksを設定
- payload URL = http://path/to/jenkins/job/core_hook/buildWithParameters?token=token
- payload versionはjsonに設定
- tokenパラメータはとりあえず任意の文字列
Webhookを受け取る準備(jenkinsのプロジェクト設定)
- ビルドのパラメータ化 -> 文字列 -> payload
- ビルドトリガ->リモートからビルド -> 先ほどつけたtoken
gitレポジトリをビルドする準備
- gitプラグインをjenkinsに入れておく
- jenkinsの公開鍵(/var/lib/jenkins/.ssh/id_rsa.pub)をgihubに登録しておく
- ソースコード管理 -> Git -> Repository URL -> 対象レポジトリ
- ソースコード管理 -> Git -> Branches to build -> master
- この時点でブランチ名を取得する方法が思いつかなかったのでとりあえずmasterにしておいてあとでcheckout
ここまでで、レポジトリになにかpushがあるたびにjenkinsがmasterブランチを取得してくる、ことができるようになりました.
payloadからパラメタ展開 -> テスト
あとはjenkinsのプロジェクト設定の"ビルド -> シェルスクリプト"にベタベタと書いていきます.
このシェルの中では$payloadという変数でgithubから渡されたjsonにアクセスできるので,こっからjqコマンドでレポジトリ名を取り出すだけ.
レポジトリ名は"ref"というキーで入ってたので
echo $payload|jq -r '.ref'
で取得 (-rは生の文字列で出力という意味).
結局jenkinsに書いておくシェルスクリプトは以下になります.
git fetch origin git reset --hard origin/`echo $payload|/usr/local/bin/jq -r '.ref'|sed "s/refs\/heads\///"` # このあとにやりたいテストをかく
※checkout,pullじゃなくてreset --hardに修正しました
おわりに
- 全ブランチの継続テストができました
- これでテストし忘れる開発者がいなくなる
- シェルでやる以外にいい方法ありそうだけどな…
- このテスト結果を開発者ircに流して運用しています