YAPC::Tokyo 2019 に参加して,OSSとコミュニティについて見つめ直した

面白そうだから参加してみようという気持ちで参加したのが今回のYAPC::Tokyo 2019だった.

Perlの話やプロジェクトの話など,面白い話がたくさん聞けたのだけど,その中でもYAPC::Tokyo 2019 はテーマの「報恩謝徳」に関係した話が印象深かった.

具体的にはOSSとコミュニティと恩についての話で,自分が聴いた中では下の三つの話があった.

songmu.github.io

自分のOSSとコミュニティへの付き合い方について,重ね合わせて考えてみる.

例えば自分はあまりGitHubでコードを書いているわけではない.キャリアの話においてもGitHubを活用という話もあり,負い目を感じている部分もあった.

それが今回のYAPCに参加して,誰もが最初は小さいものから作っていたという話もあり許された気分になったし,もっと言えば自信を持っていいんだなと感じた.id:Songmuさんの失敗談も勇気付けるきっかけになった.

他の人のOSSに関して,「利用しているだけでも貢献している」というのはたしかにそうだなと思った.

逆に考えて,自分がOSSに限らずプロダクトを作ったとして,周りに使ってもらうだけでも嬉しいなということを思い出した.

PRに関してもそうで,単に自分が困っているから変えるという程度でPRを貰ったら嬉しいと思うし,自分もしていきたい.

「自分が困っているからPRを作る,自分でも変更できる内容ものだったからPRする」という気持ちで良いんだと思う.変に最初から世界を良くしようとか考えなくていいし,取り込むかどうか判断するのは自分ではなくコミッタなのだから.

ただ,自分を卑下しているような人にとっては特に,貢献内容の凄さ=修正の大変さと考えがちなのかもしれない.「自分でも変えられる」と言うことは一般的にすごいことではないのだろうと思ってしまう.

それに関連する話で,前夜祭では最近やっているAWS CDKについてLTをした.

AWS CDKは知名度が低く,使ってる人も全然知らないし,日本人のコントリビュータも全然いないという動機から発表した.

AWS CDKを使っている人に懇親会の場でコントリビュートの内容を伝えたところ「すげぇ!」と言われた場面があった.

修正量は別に大したことはないのだけれど,実際に便利になっているということが実感できた.

また,ただ利用者を増やしたいというだけで発表したのだけれど,結果的にOSSやコミュニティへの貢献になっていると気づいた.

自分のことを振り返ってみると本当に多くの情報をコミュニティから貰って,ここまで成長できたと思っている.

OSSやコミュニティを,ただ利用するだけで何も返せなかった自分が,こうやってコントリビュートや登壇で恩返しできるまでになったことは成長を感じている.

まだ駆け出しだけれど,OSSやコミュニティに貰った恩を再確認して,引続き恩を返していきたい.

そして,もっと世界が良くしていきたい.

伝えるための文章を作るのは難しいなと言う話

プログラムは継続的な改善が可能だが,文章は難しい.

例えばプログラミングをしてプロトタイプを作ってそれを伝えるときに,「このコードのこういう問題点は把握していて,今後改善する予定」と書くことはできる.

文章自体だとそうも行かなくて,メタ的に「下の文章は今こういう問題点がありますが後で直します」なんて書くことはできない.

自分はコードを書くのがそんなに遅いわけではないけれど,文章に関しては遅いと思っている問題がある.

なので,できる限り文章を書くスピードを上げるために,前提部分を高めに仮定して本当に伝えたい部分に直接必要な部分だけを書くということをよくやっている.

でも実際の前提部分が足りていないと一気に伝えることが不可能になってしまうし,コミュニケーション不足による追加の手間が発生してしまう.

そうして追加情報が必要になったとしても,情報が更新されたということを発信したり,別の場所に書くにしても情報の分断が発生する.

なので一発で伝わるようにできるのが一番ではある.

「伝えたい人を想定して,その人がどうなっていて欲しいかを目標にする」というアドバイスを目にしたのもあり,相手のことを考えてちゃんと書かないとなぁという気持ちになった.

直近だとエンジニアセミナーへの登壇もあるので,ここから改善していきたい.

hatena.connpass.com

AWS CDKについて

最近趣味でAWS CDK(以下CDK)を触っていて,ECSをCDKで構築してみるということをやったり,CDK本体にContributeをするなどをしている.

そんなCDKについて,触ってみる人が増えたらいいなということでエントリを書いてみる.

CDKとは

Cloud Development Kitの略で,簡単に言えばTypeScriptを書くことでCloudFormationを生成してくれるツールのこと.

AWS公式のツールであり,以下のリポジトリで開発されている.

github.com

メリット

  • TypeScriptによる強力なコード補完
  • 共通パターンをライブラリ化することによる記述量の削減
  • デプロイ時に使える強力なツール群

コード例

Fargateのサービスを動かすサンプルコードは以下.

これを実行すると,VPCが作成され,amazon/amazon-ecs-sampleイメージがFargateで動き,ALBでアクセス可能になるというところまでやってくれる.

import ec2 = require('@aws-cdk/aws-ec2');
import ecs = require('@aws-cdk/aws-ecs');
import cdk = require('@aws-cdk/cdk');

class BonjourFargate extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Create VPC and Fargate Cluster
    // NOTE: Limit AZs to avoid reaching resource quotas
    const vpc = new ec2.VpcNetwork(this, 'MyVpc', { maxAZs: 2 });
    const cluster = new ecs.Cluster(this, 'Cluster', { vpc });

    // Instantiate Fargate Service with just cluster and image
    const fargateService = new ecs.LoadBalancedFargateService(this, "FargateService", {
      cluster,
      image: ecs.ContainerImage.fromDockerHub("amazon/amazon-ecs-sample"),
    });

    // Output the DNS where you can access your service
    new cdk.Output(this, 'LoadBalancerDNS', { value: fargateService.loadBalancer.dnsName });
  }
}

const app = new cdk.App();

new BonjourFargate(app, 'Bonjour');

app.run();

コードのURL: https://github.com/awslabs/aws-cdk/blob/v0.22.0/examples/cdk-examples-typescript/hello-cdk-fargate/index.ts

このように共通パターンをライブラリ化して,記述量を格段に減らすことができるということは,特に多くのリソースを作成したいときにかなり便利に感じると思う.

デプロイ時に使えるツール群

CDKはデプロイ用のコマンドとしてcdk deploycdk destroy があり,TypeScriptで作成したリソースをそのままデプロイすることができる.

またこの他に,YAMLを生成してくれる cdk synth というのもあり,実際に作成されるリソースを確認することも可能.

また,強力なのがセキュリティ周りの警告で,セキュリティグループやIAMに変更が加わると事前に警告を出してくれる.

f:id:cohalz:20190114214638p:plain

これは本当に強力で,ライブラリを使っていると隠蔽されてしまいがちな部分の中でも簡単にセキュリティ周りの変更が確認できる.

ライブラリの概念

CDKでリソースを作成する場合,下の二種類のライブラリを使って書くことになる

  • CFnリソースがそのままTypeScriptのクラスになったCloudFormation Library
    • CfnXxxという名前のリソース
  • 一段抽象化され,デフォルト値の設定や必要なリソースの作成を行ってくれるConstruct Library

基本的にはConstruct Libraryを使えばいいが,すべてのリソースにConstruct Libraryが用意されているわけではないためCloudFormation Libraryが必要になることもある.

難しいところ

Construct Libraryは強力だけど,上手く使わないとハマってしまうこともある

  • 新しい機能に対応していない場合もある
    • 起動テンプレートや管理ポリシーなど比較的新しいリソースなど
  • 生成されるYAMLとの対応が難しい
    • CFnとは違うデフォルト値を設定してくることもある

終わりに

CDKはまだ開発者プレビューだけれども,今の時点で十分に強力なツールであることは間違いない.

また,下の記事で CDK はまだ完成していません。私たちは CDK をクローズな伽藍ではなくオープンなバザールのように作っています。 とあるようにどんどんissueやPRが取り込まれ良くなっていくと思う.

aws.amazon.com

こんなにもこれからが楽しみになってくるソフトウェアは久しぶりでワクワクしているし,これからもどんどん触ったりPRを出したりしていきたい.

今年の目標

というと大々的になりがちなので,裏目標として考えていたことだけど「知り合いを増やす」というのがある.

自分が知っている人を増やすというのはもちろんのこと,自分のことを知っている人を増やすというのを目標に頑張っていきたい.

そもそも,自分の名前をどこかに刻むというのが大好きで,その一環で場所ではなく人に名前を刻むということをやっていきたいなと思っている.

今月もいくつか予定は入れていて,本来の目的もそうだけどこっちも重視していきたい.

自分なりのバーチャルYouTuberの楽しみ方

前の記事で,業界自体は追わなくなったというエントリは書いたけれど,じゃあどうしているのかという記事も書いておこうと思う.

VTuber業界を追うのはやめた - Re:cohalz

普段見ているのはエイレーンファミリーと呼ばれている人たちでこれを例に取って説明する.

エイレーンファミリーと呼ばれている人たちで,メインのチャンネルとなるのは下の2つ.

www.youtube.com

www.youtube.com

この人たちは動画メインで活動しており,不定期の投稿をしている.

ヨメミはゲームや実験動画などの他にドッキリを受ける動画などでいい子感が発揮されているし,

www.youtube.com

夏実萌恵は英語コンテンツとしても面白いし異常な口の悪さも特徴的.

www.youtube.com

面白い動画が見たいという自分の欲求とマッチしているし,それぞれの動画1つ1つは短いというのも嬉しい.

次回にどういった動画が投稿されるのか,いつ投稿されないのかはわからないのでチャンネル登録と右のベルボタンを押して,投稿時には通知が飛ぶようにしてある.

その他の楽しみ方としてはコミュニティに参加するというものもある.

エイレーンファミリー公式のDiscordがあり,日々会話がされている.

ここでは関連イラストを貼るチャンネルがあり,そこ日々Twitterやpixivのイラストが貼られているのも楽しみの一つになっている.

また公式というだけありモデラーのDigitrevx氏や萌恵のプロデューサーComdost,更にはエイレーン本人まで登場することもある.

その他の楽しみ方としては,公式のファンディングサイトに登録して限定コンテンツを楽しむというのもある.

www.patreon.com

www.patreon.com

限定壁紙や動画などが見れる他,動画の説明欄に出資者として名前が載るというのも個人的には嬉しいポイント.

上の画像では見切れているが,下の説明欄に名前が載っている.

また,YouTubeで自分のidを検索したときも凄いことになっている.

https://www.youtube.com/results?search_query=cohalz

そんな感じで,普段どうやって楽しんでいるのかという話だった.

それと,ヨメミ一周年おめでとうございます.

まさか一年前はこんなに応援することになるとは正直思っていなかった.

www.youtube.com

エイレーンファミリーに関する過去に書いた記事もよろしくお願いします.

core.cohalz.co

core.cohalz.co

core.cohalz.co

ECSのawsvpcモードではログドライバにサイドカーコンテナを指定できない

下記の構成でサービスを構築したところ,ログが転送されなかった

  • タスク定義のネットワークモードをawsvpcにする
  • fluentdをサイドカーコンテナにする
  • コンテナのログドライバを127.0.0.1:24224に指定する

起動順がおかしいのかと思い,docker-composeで同様の例を作った

github.com

が,こちらは動く上に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コンテナの数が減り,無駄なリソースも削減できるのもポイント.

dev.classmethod.jp

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業界を追うのはやめてはいたのだけれど,コンテンツの楽しみ方やカバー範囲など,周りに勘違いされていることも多くなってきたので一度文章として整理する.

当時ハマったときの記録はここに書いてある.

core.cohalz.co

業界を追うのはやめた理由としてはいくつかあり,大きな理由は業界が生放送文化へシフトしていったこと.

時間の関係でリアルタイムで生放送を最初から最後まで見ることは難しかったし,途中から見るというのは後から見る事を考えてもやりたくない.そうして,「リアルタイムでは絶対に見ない」という形になった.

生放送が苦手なのは時間の使い方が下手だというのもある,アーカイブを作業用に流すという手もあるのだが,毎回次に流す動画を探したくはないし,事前に再生リストを作って管理するのも手間に思う.

そういったこともあり単に新着動画やニコニコ動画に上がっている関連MAD動画を探す毎日になっている.

自分の本質として,単に「面白い動画が見たいだけだった」という話だったということになる.

また別の理由として,自分が特定の人にしか興味のない人間であるということ.

10年くらい前にニコニコ生放送を見ていたときも,ずっと同じ生主を見ていたように,定住をしてしまうタイプで他の人にあまり興味がない.

そのため,YouTubeのチャンネル登録もめったに増えることはなく,50人程度しかチャンネル登録をしていない.

その中でも自分はエイレーンファミリーとアイドル部が好きで,ずっと応援しているしブログにも書いている.

core.cohalz.co

core.cohalz.co

はてなブックマークでバーチャルYouTuberタグを見てイベントは把握しているものの,全く動画を見る気にはなれない.

Vティーク Vol.2を読んだときに,知らない人が多く登場したということも自分の立ち位置を見直すきっかけとなった.

もちろんVol.2で初登場した人で知ってる人は多かったのだが,Vol.1で特集された人はほぼ全て知っていただけにかなりの衝撃を受けた.

自分は全然業界を把握してないんだなと言う気持ちになり,自分たちのものではなくなったという意識が始まった.

そして,個人的にVTuberという単語が好きではない

バーチャルYouTuberと呼ばれていた時代から,VTuberと言う呼ばれ方が広まるに連れて,上で言及したような生放送文化へのシフトと,業界の広がりが始まったように思う.

それに加え,キズナアイは「VTuber」ではないといったことから「VTuber」と「バーチャルYouTuber」は同一だとは思っていない.

「VTuber」と「バーチャルYouTuber」については下の記事が詳しい.

okimochi-philia.hatenablog.com

自分が好きだったのは「VTuber」ではなく「バーチャルYouTuber」だったということになる.

2018年初期までのあのバーチャルYouTuber界隈が大好きだった.

VTuberという単語が広まり,最近ではVTuberが複数人集まってのバラエティ番組が盛んで,たまにトレンド入りしているように見えるのだけれど,全く見る気にはなれない.

統計を取っているわけではないのでなんとも言えないけれど,全く興味がわかないということは狙っているターゲット層から自分が外れている可能性もある.

そうしているうちに,今夜はNHKバーチャルのど自慢がある.

www6.nhk.or.jp

テレビがないので見ることはできない.様々な場所で活動するようになったのは嬉しいが,盛り上がりに参加できないということもやる気を削ぐ原因になっている.

2019年は,『バーチャルさんはみている』といったアニメ化もあり,業界はどんどん盛り上がっていくのだと思う.

そうした中で自分は業界を追うことは一切やめるようにして,小さいコミュニティの中だけを追っていくという気持ちになっている.

現状続けているエイレーンファミリーやキズナアイに対するサポートは今後も続けていくし,動画を見なくなるわけではない.

ただ,もはや業界を追っているわけではないということだけ伝わってもらえたら嬉しい.