というと大々的になりがちなので，裏目標として考えていたことだけど「知り合いを増やす」というのがある．
自分が知っている人を増やすというのはもちろんのこと，自分のことを知っている人を増やすというのを目標に頑張っていきたい．
そもそも，自分の名前をどこかに刻むというのが大好きで，その一環で場所ではなく人に名前を刻むということをやっていきたいなと思っている．
今月もいくつか予定は入れていて，本来の目的もそうだけどこっちも重視していきたい．
自分なりのバーチャルYouTuberの楽しみ方
前の記事で，業界自体は追わなくなったというエントリは書いたけれど，じゃあどうしているのかという記事も書いておこうと思う．
普段見ているのはエイレーンファミリーと呼ばれている人たちでこれを例に取って説明する．
エイレーンファミリーと呼ばれている人たちで，メインのチャンネルとなるのは下の2つ．
この人たちは動画メインで活動しており，不定期の投稿をしている．
ヨメミはゲームや実験動画などの他にドッキリを受ける動画などでいい子感が発揮されているし，
夏実萌恵は英語コンテンツとしても面白いし異常な口の悪さも特徴的．
面白い動画が見たいという自分の欲求とマッチしているし，それぞれの動画1つ1つは短いというのも嬉しい．
次回にどういった動画が投稿されるのか，いつ投稿されないのかはわからないのでチャンネル登録と右のベルボタンを押して，投稿時には通知が飛ぶようにしてある．
その他の楽しみ方としてはコミュニティに参加するというものもある．
エイレーンファミリー公式のDiscordがあり，日々会話がされている．
ここでは関連イラストを貼るチャンネルがあり，そこ日々Twitterやpixivのイラストが貼られているのも楽しみの一つになっている．
また公式というだけありモデラーのDigitrevx氏や萌恵のプロデューサーComdost，更にはエイレーン本人まで登場することもある．
その他の楽しみ方としては，公式のファンディングサイトに登録して限定コンテンツを楽しむというのもある．
限定壁紙や動画などが見れる他，動画の説明欄に出資者として名前が載るというのも個人的には嬉しいポイント．
自分たちの支援でここまでこれたの嬉しいね… pic.twitter.com/8AEtIN2837
— ボラギノールを口から摂取する犬 (@cohalz) October 27, 2018
上の画像では見切れているが，下の説明欄に名前が載っている．
また，YouTubeで自分のidを検索したときも凄いことになっている．
https://www.youtube.com/results?search_query=cohalz
そんな感じで，普段どうやって楽しんでいるのかという話だった．
それと，ヨメミ一周年おめでとうございます．
まさか一年前はこんなに応援することになるとは正直思っていなかった．
エイレーンファミリーに関する過去に書いた記事もよろしくお願いします．
ECSのawsvpcモードではログドライバにサイドカーコンテナを指定できない
下記の構成でサービスを構築したところ，ログが転送されなかった
- タスク定義のネットワークモードをawsvpcにする
- fluentdをサイドカーコンテナにする
- コンテナのログドライバを127.0.0.1:24224に指定する
起動順がおかしいのかと思い，docker-composeで同様の例を作った
が，こちらは動く上にfluentd-async-connectを外してみると起動順によるエラーが発生するので，原因は起動順でもなさそうという感じになる．
fluentd-max-retriesの数を増やしたりしてもダメで，/var/log/dockerを見に行くとこんなエラーを発見．
time="2019-01-04T12:56:45.789694666Z" level=error msg="Failed to log msg \"\" for logger fluentd: fluent#send: can't send logs, client is reconnecting"
ログを追加するたびに上のエラーが流れるので，やっぱりlocalhostに繋げられてないことがわかる．
以上のことをAWSのサポートに聞いてみたところ，以下の回答をもらった．
- awsvpcモードではタスクにENIを付与する
- ログドライバはタスクではなくdockerデーモンの動作となり，コンテナインスタンス本来のENIを使う
- そのためログドライバはタスクのENIに対して通信を行わず，ログが転送されない
つまりfluentdは関係なく，awsvpcモードでのログドライバ全般で起こりうることだということ．
回避策として，fluentdコンテナをawsvpcモードのサイドカーではなく，インスタンスごとに立ててネットワークモードをhostモードにするという方法を教えてもらった．
各ホストに1つだけコンテナを配置するという構成を取る場合，サービスタイプにDAEMONタイプを指定するのが便利だということも教えてもらった．
fluentdコンテナの数が減り，無駄なリソースも削減できるのもポイント．
awsvpcモードにおいてログドライバ全般で転送先にサイドカーはやめようという話だった．
というわけで，動作するタスク定義(一部)は以下．
ログをfluentdに送りたいコンテナのタスク定義
"logConfiguration": { "logDriver": "fluentd", "options": { "fluentd-async-connect": "true", "fluentd-address": "127.0.0.1:24224", "fluentd-max-retries": "30", } }, "networkMode": "awsvpc",
fluentdコンテナのタスク定義
"portMappings": [ { "hostPort": 24224, "protocol": "tcp", "containerPort": 24224 } ], "networkMode": "host",
VTuber業界を追うのはやめた
結構前からVTuber業界を追うのはやめてはいたのだけれど，コンテンツの楽しみ方やカバー範囲など，周りに勘違いされていることも多くなってきたので一度文章として整理する．
当時ハマったときの記録はここに書いてある．
業界を追うのはやめた理由としてはいくつかあり，大きな理由は業界が生放送文化へシフトしていったこと．
時間の関係でリアルタイムで生放送を最初から最後まで見ることは難しかったし，途中から見るというのは後から見る事を考えてもやりたくない．そうして，「リアルタイムでは絶対に見ない」という形になった．
生放送が苦手なのは時間の使い方が下手だというのもある，アーカイブを作業用に流すという手もあるのだが，毎回次に流す動画を探したくはないし，事前に再生リストを作って管理するのも手間に思う．
そういったこともあり単に新着動画やニコニコ動画に上がっている関連MAD動画を探す毎日になっている．
自分の本質として，単に「面白い動画が見たいだけだった」という話だったということになる．
また別の理由として，自分が特定の人にしか興味のない人間であるということ．
10年くらい前にニコニコ生放送を見ていたときも，ずっと同じ生主を見ていたように，定住をしてしまうタイプで他の人にあまり興味がない．
そのため，YouTubeのチャンネル登録もめったに増えることはなく，50人程度しかチャンネル登録をしていない．
その中でも自分はエイレーンファミリーとアイドル部が好きで，ずっと応援しているしブログにも書いている．
はてなブックマークでバーチャルYouTuberタグを見てイベントは把握しているものの，全く動画を見る気にはなれない．
Vティーク Vol.2を読んだときに，知らない人が多く登場したということも自分の立ち位置を見直すきっかけとなった．
もちろんVol.2で初登場した人で知ってる人は多かったのだが，Vol.1で特集された人はほぼ全て知っていただけにかなりの衝撃を受けた．
自分は全然業界を把握してないんだなと言う気持ちになり，自分たちのものではなくなったという意識が始まった．
そして，個人的にVTuberという単語が好きではない．
今まで意図的に使わなかったけどなんかほぼ標準になったしもう「VTuber」って略称使うかなぁ
— カマキリの卵からカマキリの代わりにぞろぞろと産まれてくる犬 (@cohalz) May 12, 2018
バーチャルYouTuberと呼ばれていた時代から，VTuberと言う呼ばれ方が広まるに連れて，上で言及したような生放送文化へのシフトと，業界の広がりが始まったように思う．
それに加え，キズナアイは「VTuber」ではないといったことから「VTuber」と「バーチャルYouTuber」は同一だとは思っていない．
「VTuber」と「バーチャルYouTuber」については下の記事が詳しい．
okimochi-philia.hatenablog.com
自分が好きだったのは「VTuber」ではなく「バーチャルYouTuber」だったということになる．
2018年初期までのあのバーチャルYouTuber界隈が大好きだった．
VTuberという単語が広まり，最近ではVTuberが複数人集まってのバラエティ番組が盛んで，たまにトレンド入りしているように見えるのだけれど，全く見る気にはなれない．
統計を取っているわけではないのでなんとも言えないけれど，全く興味がわかないということは狙っているターゲット層から自分が外れている可能性もある．
そうしているうちに，今夜はNHKバーチャルのど自慢がある．
テレビがないので見ることはできない．様々な場所で活動するようになったのは嬉しいが，盛り上がりに参加できないということもやる気を削ぐ原因になっている．
2019年は，『バーチャルさんはみている』といったアニメ化もあり，業界はどんどん盛り上がっていくのだと思う．
そうした中で自分は業界を追うことは一切やめるようにして，小さいコミュニティの中だけを追っていくという気持ちになっている．
現状続けているエイレーンファミリーやキズナアイに対するサポートは今後も続けていくし，動画を見なくなるわけではない．
ただ，もはや業界を追っているわけではないということだけ伝わってもらえたら嬉しい．
2018年まとめ
やったことベースで列挙すれば振り返るのも簡単なのでは，と思ったのでやってみる
OSS
滑り込みで200コミット行っていた
GitHub - cohalz/keepalived-ec2: A cookook for using keepalived in EC2-VPC environment
- chefでEC2使ってkeepalivedする場合のcookbook
GitHub - cohalz/cloudformation
- cloudformation置き場だけど，分離しても良い気がする
GitHub - cohalz/update_name: update_name by Go Lambda
- LambdaとCloudWatch Events使ったupdate_name
GitHub - cohalz/vscode-md2hatena: Convert Markdown to Hatena langage on VSCode
- vscodeでMarkdownをはてな記法に変換
GitHub - cohalz/todo-cdk-sample
- cdkでecsサービスを乗せる練習
- 証明書自動更新基盤
GitHub - cohalz/slagg: API to aggregate multiple slack channels.
- slackの投稿を別チャンネルへ集約
意外と作ってたけど，放置気味のもあるからもうちょっと良くしたい
Contribute
Add required IAM permissions to README by cohalz · Pull Request #11 · yuuki/grabeni · GitHub
- 誤植の訂正と記述が抜けてた部分を追加
Add PostAccountUpdateProfile by cohalz · Pull Request #259 · ChimeraCoder/anaconda · GitHub
- プロフィール変更する関数の追加
fix(aws-ecs): fix wrong descriptions by cohalz · Pull Request #1143 · awslabs/aws-cdk · GitHub
- 誤植の訂正
aws-cdkは他にもプルリクしてるけど，まだマージされてないのがいくつかある
技術記事
もっと数書ける気がするな〜って感じだし増やしたい
バーチャルYouTuber関係
このころはVTuberという略称も広まってなかったはず core.cohalz.co
よくまとまってた雑誌だと思う core.cohalz.co
バズってガジェット通信から転載依頼が来た core.cohalz.co
3分スピーチ用 core.cohalz.co
ここまで成功した人もいない core.cohalz.co
感動した core.cohalz.co
アンチスレとなんJに晒されてブログのアクセスが数倍になった core.cohalz.co
めちゃくちゃ網羅してるのでエイレーンファミリーの本スレに晒されてべた褒めされてた core.cohalz.co
もう一年経つんだなぁという感じで，だいぶ状況も変わった気がする
旅行関係
2月 高速バス・電車乗り継ぎで東京から鹿児島まで移動
4月 青森・秋田・岩手
7月 札幌・函館
9月 郡山・沼津
10月 鳥取
11月 香港・姫路
12月 高槻
もっと行ってる気がしたけど意外とこれくらいだった
グルーヴコースター関係
GROOVY FESTIVAL 5, 6のサイト制作，エントリー，当日スコア集計
感想
リンクがあると振り返るのもかなり楽だな〜と思ったので，積極的にアウトプットしていきたい
引き続き来年もよろしくお願いします
追記
そういえばこんな事を言っていた
来年は立場を生かしてジェネラリストの方向を目指して頑張っていきたい
— 鳴き声の他に狼煙を使って通信する世代の犬 (@cohalz) December 27, 2017
ゆううきさんみたいな資産価値のある文章も書きたいしめるさんみたいなエモい文章も書きたい
文章のことしか書いてないけど，最近あんまり情熱をかけてエモい文章を作っていない気がする
文章に向き合うことをしっかり行っていきたい
Slackの投稿をまとめて一つのチャンネルに流すbotを作った
この記事は PMOB Advent Calendar 25日目の記事です．
チャンネルにbotを追加するだけで，そのチャンネルの発言を特定のチャンネルに流すことができるbotを作った．
こんな感じで，チャンネルの投稿を別のチャンネルに流すことができる
構成図
botがチャンネルの発言をAPI Gatewayに送信する
API GatewayからのイベントをLambdaが受け取る
チャンネルやユーザの情報がDynamoDBに保存されているか確認する
保存されていなければSlack APIに問い合わせる
問い合わせた情報をDynamo DBに保存
取得した情報を元に投稿先チャンネルへ投稿
何故作ったのか
- 複数チャンネルを巡回する手間の削減
- 分報チャンネル追うの大変
- TwitterのTLみたいに混ざったら面白そうという気持ち
使うためには
- Slack APIのtoken
- 投稿するためのincoming webhook
- slack botを追加しEvent Subscriptionsでmessage.channelsのイベントを受け取るようにする
ハマったところなど
ユーザやチャンネルの情報がidで渡されてくる
こういう構成にする事になった理由として，イベントではidが渡されてくるため，名前を引くためにAPIを使うことになった
Slackのイベントタイムアウトは3秒
タイムアウトが3秒しかなく，それまでにイベントに対してのレスポンスを返さないともう一度イベントが送信されてしまう
そうすると投稿先チャンネルへ二重投稿されてしまうため，できる限りすぐレスポンスを返せるようにしないといけない
今回はDynamo DBを使って，そこに情報が保存されていたらそれを使うことでタイムアウトまでにレスポンスを返せるようになった
終わりに
最初は遊びで作ってたものだったけれど，意外と面白いし実用性もあって良かった
分報が全部流れるとどのくらいの流量になるのか気になる
今回作ったリポジトリはこちら
『Docker/Kubernetes 実践コンテナ開発入門』のサンプルアプリケーションをAWS CDKでデプロイした
この記事は PMOB Advent Calendar 18日目の記事です．
前回は，『Docker/Kubernetes 実践コンテナ開発入門』の4章をコンソールからECSクラスタを構築し，その上でアプリケーションを動かすまでをやった．
『Docker/Kubernetes 実践コンテナ開発入門』のサンプルアプリケーションをECSに載せる - Re:cohalz
今回はそれをAWS CDKを使って，デプロイしてみた．
作成したリポジトリをサンプル用に公開したのが以下．
気をつけたところなど
細かいところはリポジトリを見てもらうとして，気をつけたところや工夫したところをまとめる．
まず，DBは試行錯誤の途中で作り直されるのが面倒だったので，RDSに変更した．
ロググループがデフォルトで削除保護がかかっており，作り直しでエラーになるため，retainLogGroup: falseを追加した．
サービスディスカバリの追加を関数化して扱いやすくした．サービスも削除保護が掛かっているのでそれを外した．
Dockerボリュームを使うにはプロパティを上書きする必要があったのでそれをやった．
ALBは初めにaddContainerしたコンテナを負荷分散用コンテナとして扱う動作をするようなのでnginxを先に追加した．
終わりに
AWS CDKはまだ開発者プレビューという状態で，気を付けることがあったり破壊的変更もよく出る感じだけれど，こういったECSクラスタなどをさっと作るには便利だと思った．
この構成と同じものををCloudFormationで作成しようと思ったら1200行ほど書かないといけないので非常に楽になる．(その分何が作られるのかしっかり把握しないといけないけれど)
