別にしんどくないブログ

正直しんどいので更新はゆるくやります

Node.js Core Collaboratorになった 〜なるまでを振り返った〜

表題のとおりNode.jsのCollaboratorになりました。
f:id:Shisama:20181108193251p:plain

最初のPull Requestが2018-05-03なので約半年かけてなりました。
この半年を振り返りたいと思います。
Node.jsのCollaboratorになりたい方やContributeしたい方の役に立てれば幸いです。

ContributeするきっかけになったのがLekoさんがNode学園 29時限目で発表された以下のスライドでした。
(参加していないのですが・・・。すみません。。)

speakerdeck.com

このスライドをきっかけに#node-contribution のslackチャンネルでのやりとりを見たり、実際のPull Requestを拝見させていただきました。
Slackはhttps://iojs-jp.slack.com/から参加できます。

このあと、同僚のid:taminifと主催している関西Node学園 1時限目でNode.jsをビルドして最新版を使ってみようという発表をしました。ちょうどNode.js v10がリリースされるタイミングでした。

ちょっと変更してビルドして動かしてって遊んでいて、ソースコード読むのにも慣れてきたので何かコントリビュートできないかなと思い、OpenになっているIssuePull RequestWatchしていました。

僕はC++が得意なわけではないのでドキュメントの修正やテストの追加ならできそうと感じました。しかし、この時はどのテストが不足しているかもわかりませんでした。

First Pull Request

その後、同僚がLTするということもあってNode学園 30時限目に参加しました。
そこで古川さん id:yosuke_furukawaにお会いし、どこから始めたらいいか相談したところ「fsがPromiseになったところはテストのカバレッジが低いんじゃないかな」と教えてもらいました。
実際root/internal/fs/promises.jsカバレッジは80%を満たしていませんでした。

テストのカバレッジレポートはNode.js Code Coverageで見ることができます。

そこでfsのPromiseのテストのカバレッジを上げるためにできそうなところを初Pull Requestを出したのが以下です。

github.com

初めてのnodejs/nodeへのPull Requestは「これでいいんだろうか」と不安でした。ドキュメントと他のPull Requestを何回も見て問題ないか確認しました。
ちなみにIssueやPull Requestの作り方やコミットメッセージの書き方はnode/CONTRIBUTING.md at master · nodejs/node · GitHubに記載されています。

node/doc/guides/contributing at master · nodejs/node · GitHub にも詳しい手順は記載されています。

CODE_OF_CONDUCTという行動規範も必読です。

Coverage Driven

そこからはずっとカバレッジを上げていました。テストを書いているとバグやドキュメントの不備を見つけることがあります。そういったものを修正することでテストだけではなくユーザーが使うものに貢献することができます。
世界中の多くの人に使われているプロダクトなのでバグの修正は遠く離れた国の誰かの助けになっているかもしれないし、ドキュメントに載せたサンプルコードや説明は公式ドキュメントとして世界中の人のリファレンスになっていると思うとやりがいあると思います。

僕のNode.jsへのContributeの方法はカバレッジ駆動でした。
Node.jsへのContributeはテストから初めてみるのはお勧めです。
慣れてくるとソースコードが結構読めるようになります。
あと、カバレッジが低いところのテストを書いていると知らなかったAPIを見つけることができるのでユーザーとしても学習できると思います。

マルチプラットフォーム

ご存知の通り、Node.jsはWindowsmacOSLinuxで実行できるようになっています。
それら複数OSでも問題なく動作することを保証するためにCIを使って検証しています。
Pull Requestを作るとまずTravis CIでlintとtestが実行されます。
Pull RequestがApproveされていくとCollaboratorの方がCIを実行してくれます。Jenkinsで動いています。
このCIがすごくて、様々なOSでビルドやテストを同時に並列で行います。様々なLinuxディストリビューションmacOSWindowsで実行されます。

f:id:Shisama:20181106021044p:plain

僕は普段macで開発しているのですが、環境によってテストが失敗することもあります。
また、OS依存の機能もあるので可能であれば複数のOSでテストをPull Requestを作る前に実行されることをお勧めします。
僕は普段はmacOSを使っていますが、LinuxWindowsのマシンで確認することもあります。
Windowsmacしか手元にないという方もいるかと思います。
僕もmac上で書いたコードをLinuxで動かしたいときがあります。そのときのためにDockerfileを作りました。
Node.jsの開発環境を作るのが手間って人もこのDocker上で開発していただけると思います。

github.com

あと、npmのパッケージに影響がないかどうかを調べるテストもあります。

github.com

Nominating

コミット数を増やしていくとContributorsに表示されるようになりました。
しかし、Collaboratorになるには他のCollaboratorの方からの推薦が無いとなれません。

node/GOVERNANCE.md at c774dc31988d8a3205a08968c1794f6589b9af06 · nodejs/node · GitHub

「もうそろそろCollaboratorの推薦があるころかな」と思っていたあたりから結構時間がかかりました。
このとき内心では「なれないのでは・・・」と不安を感じました。
ですが、とにかくここでは終われないし、Contributeすることは楽しかったので諦めずに少しずつコミットしていきました。

ある日、TSCメンバーのAnnaさんからTwitterでフォローされて何事かと思ったら「メール送ったよ」ってツイートに対する返信があり、メールをチェックすると"Would you be interested in becoming a collaborator on the Node.js core repository?"とのことだったので、もちろんYesと答えてしばらくするとNominatingのIssueが作られました。

github.com

その後、JoyeeからメールがあってCollaboratorに追加する作業を行うonboarding sessionを行いました。

onboarding sessionはCollaboratorに追加する作業です。Collaboratorとリアルタイムでやりとりします。

onboarding sessionの前に以下のonboardingに関するドキュメントを必ず読んでおいてください。僕は読まずにonboarding sessionをやってしまい、かなり時間がかかりました。
Joyeeには本当に申し訳ないことをしてしまった・・・
node/onboarding.md at master · nodejs/node · GitHub

以下はonboarding sessionで作ったCollaboratorに追加するPull Requestです。

github.com

そして今に至る。といった流れです。

Collaboratorになると

コードレビューを行うことができます。
masterにマージすることができます。
CI(Jenkins)のジョブを実行することができます。
Collaborator Summitに参加することができます。
Node.jsのチームメンバーになります。

英語

Node.jsに限らずOSSにContributeすることで多くのことが学べますし、世の中の役に立つ実感を感じますしやりがいがあります。 みんなもっと使っているOSSへのContributeすればいいのにと思います。
僕の周りでOSS活動をしない人はやはり英語に抵抗があるみたいです。しかし、そこは自動翻訳やオンライン辞書などのサービスにどんどん頼ればいいと思います。
元々英語を扱う仕事をしていたこともあって英語自体に抵抗がなかったですが、Google翻訳を多用しました。(僕はWeblioの中の人ですがWeblio翻訳は使ってな・・・)
まず自分で英文を書いてみて、それをGoogle翻訳で日本語にして意味がわかれば多くの場合通じます。
それでもやっぱり英語は勉強した方がいいです。
onboarding sessionのときは英語でリアルタイムなやりとりをします。
僕はGoogle Hangoutで音声通話で行ったのですが、英語力無さすぎてJoyeeには大変迷惑をかけてしまいました

最後に

ここまで長い文章に付き合ってくれたあなたに素敵な耳寄り情報です。
11/23、11/24に開催される東京Node学園祭にはNode.jsのTSCのメンバーやCollaboratorの方々が海外からも多数来日します!日本ではここでしか聞けない話をしてくれます!
2日目の11/24に学園祭内で開催されるCode And LearnはNode.jsに初めてContributeするまでをCollaboratorがサポートしてくれるハンズオンです。Node.jsにContributeしてみたい方はぜひご参加ください!他にも面白いハンズオン企画があります!
現地で会いましょう!

nodefest.jp

これからもNode.jsにContributeしてもっと良くしていくので、Node.jsをみんな使ってくれると嬉しいです!

あと関西でもNode.jsのコミュニティをもっと活発化したいので関西の皆さん一緒にやっていきましょう!!

『NETFLIXの最強人事戦略』を読んだ。

会社の同僚から勧められて『NETFLIXの最強人事戦略~自由と責任の文化を築く』を読みました。 内容としては評判通り良かったです。人事だけでなく、経営者や組織やチームをマネジメントする方にもおすすめです。 僕は人事ではなくエンジニアですが、会社費用で勉強会やカンファレンスに参加できる制度など作ってみたり、育成やチームビルディングなどのエンジニアリング以外のことにも精を出しています。そういう活動を行う中でどうすればハイパフォーマンスを出し続けるチームを作れるのかを学びたくてこの本を読みました。

NETFLIXの最強人事戦略 自由と責任の文化を築く

NETFLIXの最強人事戦略 自由と責任の文化を築く

本文中でも紹介されていますが、もとになったculture deckという1500万回以上閲覧されたスライドです。

www.slideshare.net

また、最新のculture deckについてはNETFLIX社の採用ページで公開されています。

jobs.netflix.com

culture deckの日本語訳は以下のブログで読むことができます。

tkybpp.hatenablog.com

上記のリンク先を読んで興味を持った方は書籍も楽しめると思います。 人事担当である著者がハイパフォーマンスな組織作りのために取り組んだことが、NETFLIXの歴史とともに書かれています。

ここでは個人的に良かったところをピックアップして残しておきたいと思います。

"ネットフリックス文化の柱の一つは、「徹底的に正直であれ」だ。"

全体を通して「正直であること」の重要さが繰り返し書かれています。 悪いことに関しても言いにくいことに関しても、隠すより正直に話した方が良い結果が得られる経験はみなさんもあるのではないでしょうか。

"従業員の忠誠心を高め、会社につなぎ止め、キャリアを伸ばし、やる気と満足度を上げるための制度を導入することが、人材管理のしごとだとする考えである。そのすべてがまちがっている。ビジネスリーダーの役割は、すばらしい仕事を期限内にやり遂げる、優れたチームをつくることである。それだけ。"

"人は仕事に娯楽を求めない、学びたいのだ"
これは自分が成長できる場を求めている人が多いことが裏付けていると思います。全員がそうではないと思うが、成長できる場にいることで充実感を得られることはあると思うので、成長できる場を作れるようにしたいと思いました。もちろん自分も常に学びたい意欲があるので、そういった機会を大切にしてくれる仲間と働くことを大切にしていきたいと思いました。

"成長が始まったばかりの段階で莫大な先行投資をするということは、ビジネスモデルを成功させるために時間をかけていられないことを意味する"

"事業そのものの性質や課題も変化し続けていた。これに合わせて、私達の発するメッセージもたえず確認し更新していく必要があった。これは永遠に続けなくてはならない仕事だ。"

"相手のいないところで不満をぶちまけたことを反省する。そして次に、同じ内容を感情を交えずに話す方法を練習した。また問題行動の具体例を挙げ、解決策を提示することも大切だと教えた。こうしたルールにしたがえば、対話はとても建設的なものになる。"

感情を交えずに話すことは難しいと思います。どうしてもヒートアップしてしまうこともあります。ただ決まってそういったときに建設的な話ができたかというと経験上ほぼ無いのでここに書かれていることはぐさっと刺さりました。

"うまく話せるようになるには、練習が欠かせない。鏡の前でやってもいいし、パートナーや友人を練習台にしてもいい。話すつもりのことを実際に声に出して練習すれば、自分の声のトーンを聞くことができる。録音するのもお勧めだ。"
僕は勉強会などで登壇することがあるのですが、練習時に録音を行うようになって後から聞き返すことで客観的に振り返ることができるようになり良い練習方法だと効果を実感しています。スマートフォンで録音するアプリもあり試しやすい練習方法なのでお勧めです。
また、人に聞いてもらうのが一番良いです。素直なフィードバックをいただけるのは恵まれたことだと感じています。僕は会社の人や妻にたまに聞いてもらっています。

"透明性を徹底すれば、誰もが自分の支持した立場に責任をもち、事後的に批判することも少なくなる"

これはチームで何かをするうえでは結構重要だと考えています。僕の場合はそれがWebサービスの開発なのですが、例えばアーキテクチャに関する方針や大事な設計部分に関してはなるべくチーム内で事前に共有して合意や承認を得るようにしています。
GitHubを使っているのであれば、Pull Requestがあるので自然とこの流れになります。一人の責任にならないようにして、失敗を恐れないようにしなければ変化は生まれないと考えています。

"人材の濃度を高く保つことに徹底してとりくまなくてはならない"
すごい同僚と働けることがモチベーションの向上に繋がるのは前述した「成長できる場」を求めることと関連していると思います。
社内で切磋琢磨できる環境が用意されていなければ、いい給料でもどこかで虚しさや飽きを感じることはあるのではないでしょうか。

"私がネットフリックスで真っ先にやったことの一つが、給与制度と人事考課のプロセスを切り離すことだった"
人事考課制度は、時間がかかって非効率だと説いている。確かに時間がかかります。しかも人事考課を行うのは役職に就いている方が多いのでそのコストは大きいと感じます。ネットフリックスでは人事考課で給与を決定するのではなく、その人が会社に与える利益に基づいて給与を決定しているみたいです。ネットフリックスでは定期的に他社の面接を受けに行くことを推奨していてネットフリックスが他の会社と遜色ない水準の報酬を与えているかチェックさせているそうです。これが最も効率的かつ確実だと。

"企業は従業員に報酬の根拠を説明する努力を惜しんではいけない。"
報酬に関する情報を従業員と共有することで偏見を減らし、業績への貢献について正直に話し合うことができるとのことです。
確かに入社時期や性別や学歴など様々な要因で成果に見合わない報酬を受け取っている人は多いと思うし、それが嫌で退職する人も多いと感じます。

"人事考課が何らかの重要な経営指針の改善に役立っているというたしかなデータを見つけられないのなら、廃止を働きかけることを強くお勧めする。"

"新しく採用した人材が職務に適していないことが判明した場合、問題があるのはその人ではなく採用プロセスだ。たんに不適当な人材を採用してしまったというだけで、その人の責任では断じてない!自分に非があると思わせてはいけない。"
他の会社ではすごく活躍できるのに、今の会社では活躍できていないって人は大勢いると思います。僕が勤めている会社の中にもそんな感じがする人はいます。(今の会社以外で一緒に働いたことないので想像ですが)
ネットフリックスでは積極的に解雇しているそうです。それでもほとんどの人が受け入れているそうです。

"あなたの仕事は、彼らに力を与えることではない。彼らの力を認め、時代遅れの方針、手続き、制度を廃止して、力を解放することだ。それさえ行えば、彼らはパワフルになる"
これは読者を人事担当に見立てて語りかけるように話しかけている最後の1文です。
昔からこうだからという理由で続けている非効率な社内制度や手続きはないだろうか?同僚に対して承認ではなく批判ばかりしていないだろうか?お互いが正直に話合えているだろうか?そういうことを見直さなければならないと考えさせてくれる良い本でした。

繰り替えしになりますが、人事だけではなくチームで働く人すべてにお勧めできる内容になっていると思います。250ページ弱で文体も堅苦しい感じではないので読みやすいのでもし機会があれば読んでみてください。

最後までお読みいただきありがとうございました。

プレゼンテーション資料作成に手書きメモを活用する

10/27(土)にサイボウズ株式会社の大阪オフィスにて開催された 【ヒカ☆ラボ】有名サービス開発エンジニア登壇のLT大会 - connpass で登壇させていただきました。

今回の登壇資料を作る際、メモ帳に手書きしながらアイデアを出すのが役に立ったので紹介しておきます。
完成した資料はこちら。

speakerdeck.com

登壇資料を作る作業って結構時間かかりませんか?
慣れている方はパパっと作れるみたいですが、僕は時間がかかる方です。

通勤の時間を有効活用したいのでiPhoneを使って調べものをしたり内容を考えたりしています。 その際に思い浮かんだものをメモしだしてみると、メモした内容から派生してどんどんアイデアが出てくることに気づきました。

最近話題になっている『学びを結果に変えるアウトプット大全-樺沢紫苑』にも「タイピングよりも手書きの方が、成績も上がるしアイデアも出る。」と記述されています。
プリンストン大学とカリフォルニア大学の研究によってタイピングより手書きの方が記憶の定着やアイデア出しにおいて良い結果が出ているそうです。

メモ帳に書いてみてわかったことは手書きの方が一枚の面に対する自由度が高いことです。
当たり前ですけど線や図なども手書きの方が簡単に書けますし、フォントの大きさなんていちいち選択しなくてもいいので思い浮かんだことをすぐに書き出せます。

f:id:Shisama:20181028144539j:plain

上の写真は実際のメモです。

f:id:Shisama:20181028144648p:plain

一部内容が変わっていますが、メモを元に作成したスライドです。

あと、通勤の電車では座れないこともしばしばあります。その場合でもA5ぐらいなら片手でメモ帳を持ちながらメモすることぐらいなら可能です。
僕が使っているメモ帳はメルカリさんに頂いたRollbahnのメモ帳です。これが大きさといい書きやすさといい使い勝手が良いです。
メルカリさんありがとうございます!

f:id:Shisama:20181028150529j:plain

Amazonでも売っています。

www.amazon.co.jp

iPadスタイラスペンというのも試してみましたが、メモ帳の方が書き心地は良かったです。
手のひらが画面に触れて書き込まれたり、ペンで書いてもきちんと書き込めなかったりして思い浮かんだことをメモに即反映できませんでした。
しかし、写真などや元からある図に対して書き込んだり、コピペしたりするときはiPadが優れていました。
それぞれの利点を活かして使い分けるのがいいと感じています。

他にも資料作成に関して「私はこうやっているよー」とか実践していることがありましたら、ぜひぜひ教えていただけると嬉しいです!

builderscon tokyo 2018に参加・LTしてきた

控えめに言っても最高だった。

builderscon.io

builderscon、昨年は存在を知ったのが開催後だったので楽しそうだなーと思いながら動画などを観ていた。 お祭り感あって楽しそうと感じていたし、特定の技術ではなく幅広いジャンルを扱っている大型カンファレンスは珍しいので行ってみたかったので参加できて良かった。

聴講したセッションに関してですが、すべて良かった。本当に色々な話を聞けた。「知らなかった、を聞く」をテーマとしているだけあって全セッションで知らないことがあった。本当にどのセッションも面白かった。聞けなかったセッションも動画が公開されるのを楽しみにしている。 僕がベストスピーカーに投票した3セッションに関して感想を少し書きたいと思います。

JavaCardの世界

speakerdeck.com

とにかく話がうまい!予備知識ゼロだったのにもかかわらず楽しく話を聞けたのはスピーカーの話がうまかったからだと感じた。

おそらく使う機会が無い技術の話だけど全然聞いてて飽きないのすごいと思う。 あと、Q&Aのときも質問を「〇〇がXX という質問でよろしいでしょうか?」と聞き返していたのがすごく良かった。これは真似したいと思った!

これがベストスピーカー賞取ったのは文句なし!めちゃくちゃ面白かった! おめでとうございます!

なぜエンジニアはパフォーマンス計測しないのか

speakerdeck.com

これに関しては期待していたものとは全く違ったけどすごく楽しめたし、刺激を受けた!

話の内容としてはガジェットを使って身体のことを計測して可視化する内容だったのだけど、出てくるガジェットが欲しくなる内容だった。 ほしいものリストに追加しまくったわw

睡眠分析は以前からしたいと考えていてiOSアプリ使ったりしたがイマイチだったのでwithings sleepはほしいなと思った。 あとJINS MEMEも良さそうだなと思った。 やっぱり散財しそうだ・・・。。

RDB THE Right Way ~壮大なるRDBリファクタリング物語~

speakerdeck.com

前回ベストスピーカーということでかなり期待して一番前の席で聞いた。期待通り最高だった。自分の中ではこれが一番良かった。聞いていて思ったことは「そうだよなー」「わかってはいるけどなー」みたいな感じでしたが今まで自分の中で漠然と頭の中にあったものが言語化された感じがしてすごい聞き入ってしまった。1時間を感じさせない感じで最初から最後まで面白かった。内容としてはRDBの論理設計と物理設計の話で、物理設計の前にモデリングをちゃんとしましょうといった内容だった。物理設計から先にやりがちだよなーと思ったので今後は気をつけなければいけないと感じた。

あとすべてを司るスーパーテーブルに関しても「うちにもあるなー」と感じていて、なんとかしようと心に誓った。

説明やワードチョイスがとにかく上手でした。「技術的負債にはチーズと腐った牛乳がある」とかもうまい例えだなと感じた。

あとそーだいさん自身も魅力的な人だった。とにかく明るい!終わった後の宴会の場でもとにかく明るく誰に対しても同じように接する人間性は素晴らしいと感じた。

実はPHPカンファレンス関西のときは共通の知人に少し紹介されたのですが全然話できなかったので、今回少しお話できて良かったです! ベストスピーカー賞3位おめでとうございます!

チームでテストを書くために

speakerdeck.com

自分のLTに関しても少しだけ触れておく。

内容に関しては、もう最初から技術的な話はしないでおこうと決めていた。 なぜなら自分が得意な分野(Node.jsやJavaScript)に関しては話す場はいくらでもあるからだ。 で、今回はなぜテストの話をしたかと言うと、自分が会社の中で築いたもので一番注力していたものであり、聴講者の中には何かを感じてもらうことができる内容だったのではないかと考えたからだ。 しかもテストのノウハウではなくチームビルディングに近い内容にしたのはbuildersconという幅広い内容を扱うカンファレンスだからこそ発表できる内容だったと思う。

本番は緊張してしまって思うように喋れなかったのが悔やまれるが経験値は上がったと思う。 昨年はHTML5 Conferenceで話して、今年も大舞台で話ができたことは本当に良い経験になったと思う。

あがり症はなんとかしないとな・・・関西Node学園で司会しているときは全然なんともないんだけどな・・・

発表の最後にも話したけど、今回の発表を聞いてテストを書き始めたって人が出てきたら本当に嬉しいし来年のbuildersconで知見を発表してくれたらめちゃくちゃ嬉しい!

最後に、スタッフの方に関して スタッフは本当に連携がよく出来ていてすごく丁寧な対応をしてくださった。 ありがとうございました。お疲れ様でした!

buildersconは内容、スタッフ、スピーカー、ご飯、うまい棒、何をとっても最高だったと思う。 また来年も行きたい!今度はぜひ登壇枠で!!

ブログサービスはどれが良いのか

ブログをはじめました

はじめましての人ははじめまして。職業はWebエンジニアです。

ブログを始めようと思ったきっかけ

ブログ、昔やったことあったけど長続きしなかった。このアカウントとは違うし、どのアカウントかももう覚えてない。

それに技術ネタはQiitaに書いているし、普段思うことはTwitterに書いている。

Qiitaは良いサービスだ。しかし、自分の考えとかポエムみたいなことは書かないほうが良いと個人的には思っている。それでも良いものは良いのでそれ自体は否定するつもりはもちろん無い。楽しく読ませてもらっているし、気が変わってポエム記事を書くかもしれない。タイトルがそういったものでも、なぜそうしたのか裏付けが書かれていたりするし知見が詰まっているれば面白いと感じる。

では、Qiitaには書くような技術ネタではないしTwitterでは収まらないものをどこに書けばいいのかと思ったらブログだなってところに行き着いた。

自分の考えを文章にしたい欲求をどこかで消化したかった。

 ブログサービスはどれが良いのか

どのブログサービスを使うのがいいのかは悩んだ。

最初はmediumにしようか悩んだし、JekyllとかGatsby使って自分でいじれるようにしても面白いかと思った。しかし、mediumは英語でブログ書きたくなったときのために取っておくかと思い、JekyllやGatsbyはたぶん記事書くよりそっちをいじる方が楽しくなっていつまでたっても記事書かないことになりかねないと思ったためやめといた。

結局、そんなこと悩んでいるヒマがあったら1つでも記事書いてみたらいい、もしくはテーマ決めて使い分けるとかすればいいとか思うと何を使うかはどうでも良くなった。嫌になれば移行すればいいわけだし。

なぜはてなブログにしたかというと、よく読むブログがだいたいはてなブログだったからっていう単純な理由。あと、はてなのエンジニアの知り合いの方々に気を遣ったw

ま、正直何でも良かったと言えば何でも良かった。最初からはてなかmediumって考えてたし。今のところ書きにくいと感じていないのではてなブログを選んで良かったと思っている。

何を書くか

このブログはまだテーマは決まっていないが、どこかに着地したいとは考えている。もしかするとQiitaに書かずにここに技術のことばかり書くかもしれない。

最近勉強会を始めたり登壇したりしているので、ただの宣伝にはならないように気をつけながらも宣伝はしていくことになると思う。

リンクの回は終わってるから意味ないんだけど・・・

nodejs.connpass.com

 

最後にこのブログ名「別にしんどくないブログ」は敬愛するギタリストの「別に危なくないコラム」を元に自分が更新するのも読者が読むのもしんどくならないように心がけていくためにこういったブログ名にした。

でも、子供と遊びたいしコード書きたいし映画も観たいし本も読みたいしギター弾きたいしとか色々な欲求を考えるとブログ書く優先度低いwたぶん更新頻度悪いと思うw