Mastodonについてのあれこれ

Mastodonについての話題がここ数週間の内に破竹の勢いでかけめぐっています。ここまでの勢いというのはTwitterができたばかりの2007年のころが思い起こされ、とてもなつかしい気持になっています。

Mastodonとの出会い

わたしがMastodonのアカウントを作ったのは日本で話題になり初めた四月十一日の夜遅くであり、少し遅いです。前職の同僚と飲んでいる際に話題となって、その場でmastodon.cloudにアカウントを作りました。その後、日本人が多くいるという話を聞いたmastodon.nil.nu (現 mstdn.jp) にアカウントを移して、mstdn.jpでの二度のデータベース削除の末にPawooに落ち着きました。

結果としてわたしとMastodonアカウントは@ykzts@pawoo.net@ykzts@mstdn.jp@ykzts@mastodon.cloudの三つに加えて、検証用に自分で立てたインスタンスのアカウントである@ykzts@omanko.pornの合計 四つです。少し作り過ぎてしまったかな? と思わなくもないので、これ以上のアカウントを取得する予定はありません。ほかのインスタンスで「@ykzts」というユーザー名のアカウントが存在していても、それはわたしではない別の人でしょう。

Pawooの運営元であるピクシブ株式会社は何年も前からイラスト投稿サイト「pixiv」を運営しています。そうしたつながりからか、Pawooには絵を描かれる方が多く参加しています。当然 Pawooにおいてもイラストを投稿されていて、ローカルタイムラインにおけるイラストの比率は非常に高くなっています。性的な話題も多くあり、人を選ぶようなインスタンスではあるかと思います。

ですが、だからこそわたしにとっては都合が良く、そしてとても居心地の良い環境です。わたしはこうした場所を待ち望んでいたのかもしれません。

Mastodonインスタンスの運用

さて、MastodonのバックエンドにはRuby on Rails (Rails) でフロントエンドにはReactが使われています。この両フレームワークはわたしがこれまで公私ともに使ってきたものであり、わたしの技術スタックと見事に合致するものでした。両フレームワークを用いたウェブアプリケーションの運用についての知見もありますし、また実装についての知識もないわけではありません。

技術的にある程度は触れそうだと思い、Mastodonのアカウントを最初に取得してからちょうど一週間後である四月十八日にさくらのVPSの契約をしてMastodonのインスタンスを作りました。勢いで取ってしまったomanko.pornというあまりにもはずかしい名前のドメイン名での運用になっています。

現在は登録の受け付けをしていませんが、ルール決めや説明文についての記載をおえたら登録の受け付けを開始しようかと考えています。これまでわたしが培ってきた知識を動員したものになっているのでさくらのVPS 1台で動かしているにしては高速に動かせるのではないかと思っています。このはずかしいドメイン名のインスタンスにどれほどの人が登録しようと思ってくださるかは未知数ですが、それなりの人数は抱えることができるのではないかと期待しています。

omanko.pornのインフラ面

サラリーマンであるわたしは平日の昼間に趣味で運用しているサーバーの面倒を見ることは難しい状況です。そのため、運用における手間を最小限に留められるようにDockerDocker Composeを使っています。使っているdocker-compose.ymlはGitHubのリポジトリーにNginxの設定ファイルと一緒にまとめてあるので、ある程度の参考にすることができるのではないかと思います。ただ、わたしのインスタンスに依存する記述も多いのでそのまま使うことはできないでしょう。あくまで参考にできるだけでしょう。

またMackerelのプラグインとしてmackerel-plugin-mastodonも作りました。これはMastodonインスタンスの「サーバー情報」のページから確認できるユーザー数、投稿されたトゥートの数、接続しているインスタンスの数を定期的に取得して、Mackerelでグラフにプロットしてもらえるようになります。Mackerelを使うことによって、ユーザー数が閾値に達しそうな時にアラートを鳴らすことができるので便利なのではないでしょうか。

Mastodonへのコントリビュート

前置きが長くなりました。ここからが本題です。

Mastodonはまだ生まれたばかりです。最初のコミットがされてから、まだ一年も経っていません。まだまだ成長の余地が多くあります。

「Mastodonインスタンス運用」の節でも書いたように、Mastodonで使われている技術はわたしの技術スタックと合致しています。MastodonはGNU Affero General Public License Version 3 (AGPL) でオープンソースソフトウェアとして公開されていることもあり、わたしの微力でも開発に少しでも役立てられるのではないかと思い、Mastodonの上流に対するコントリビュートも少しずつしています。

この記事を書いている時点で、32個のPull Requestsを送り、ありがたいことにその内 29個をmergeしていただいています。日本語への翻訳や細かいバグの修正が主ですが、少しでも貢献ができているのであればうれしく思っています。

Mastodonの原作者 (一番初めにコミットをした人) であるGargron氏は現在 Patreonで寄付者を募り、フルタイムでMastodoonの開発を行っています。日本からでも「Gargron is creating open-source software | Patreon」から簡単にGargron氏のパトロンになることができるので、比較的貢献はしやすいかと思います。

ここ数箇月で大きなお金を使う事情が何度かあったため、わたしは残念ながらGargron氏に対して月に10USDの貢献しかできていません。その分、開発での貢献ができれば……と考えています。

Mastodonに対して少しでもお世話になっている、もしくはなりそうだと思われた方は「Gargron is creating open-source software | Patreon」からGargron氏のパトロンになると良いでしょう。リターンとしてGargron氏を含めたMastodonの開発者やMastodonのインスタンスを管理している人たちが集まるチャット (Discord) への招待もあります。パトロンになっても損をする要素はないかと思います。

参考までにわたしのメールアドレスはykzts@desire.shです。Gargron氏のパトロンになった上で、余剰のお金があるのであればわたしにも寄付としてAmazonギフト券をいただけたらな、と思います。

Mastodonインスタンスの運用やMastodon開発における検証をするためのコストといったものが少なからずかかってしまいそうなので、金銭的な対価が少しでもあるととてもうれしく思います。わたしからのリターンとしてはMastodonの開発や運用における知見を共有することといったことしかできませんが、よろしければよろしくお願いいたします。

優秀なエンジニア

わたし自身が優秀なエンジニア (ソフトウェアエンジニア) であると他者から評価される、されないといったことは正直 興味を抱くところはない。評価とかを気にすることなく自身が興味を抱いた技術についてひたすら知識を深めていくだけである。

だが、自分では自分のことを優秀だと思っているし、優秀だと言うようにしている。

雇ってもらおうと思い、企業の面接に行くときは当然 自己のPRをする。もちろん嘘を吐くことはないし、そもそも嘘は吐きたくない。なのでやってきたことや、やりたいことを正直に言うだけではある。そこで自分が優秀であり採用することによって、どのような利を得られるかと説明する。

そのわたしの説明を聴いて (「聞いて」ではないはずだ) 納得をした上で採用してくれた人がいる以上、わたしがわたしのことを優秀ではないと言うのはその人たちに対する裏切りでしかない。

そんな不誠実は、わたしはしたくない。わたしは誠実であるために、自分が優秀であると言い続ける。

とは言うが、わたしを雇っても凡百のエンジニア十人分の活躍ができるというわけではない。一人で十人分のコミットをすることはできず、そしてするつもりもない。だが十種類の人間を雇わなければできないような幅広い職域の作業を一人でできる。

決して手が速いわけではない。知識が広く、ただ単純に汎用性が高いというだけ。

それが優秀であるかどうかは異論があると思う。だが、わたしはわたしが誠実であり続けられるように自分を優秀と言う。言わなければならない。

「それ」を必要とするところに行くというだけの話である。

Mediumで読んだ本の感想を書き始めた

Mediumで読んだ本の感想を書き始めた

少し前からMediumで読んだ本の感想を書いています。無事 三日坊主にならずに続いたので、こちらでも共有します。

読んだ本の感想を書き始める前に三日分の文書を書き溜めて、Mediumの機能で予約投稿を設定してから始めたため、三日坊主にならずに済ませられました。ストックがもうなくなってしまったので、勝負はこれからです。

もともとはこのブログにも読んだ本や見たアニメの感想といった技術以外のことを書いていましたが、こちらのブログは技術ブログとしての位置付けを強めたいと考えています。

というのも、技術ブログと認識してこのブログを訪れたかたから、技術以外の話は必要ないと言われたからというのがあります。自身としても自己の技術的知見を公開する場を確立しておきたいと考えていたため、これを機に……ということで分けます。

こちらでも、あちらでも、どちらの記事も読んでいただけたら、幸いに思います。

BaberuTV 進捗報告

BaberuTV 進捗報告

少し前から作っているBaberuTVだが、順調に開発が進行している。

わたしの技術検証という側面が強い都合上、機能の追加のペースはどうしてもゆるやかになってしまっている。だがMaterial-UIを使うことによって見た目に関してもそれなりに見られるものになってきたのではないかという自負がある。

DockerとDocker Composeを使うことによって、手元の環境をさして汚すことなく開発環境の構築を行えるようになった。現在は静的ページのみなのでGitHub Pagesにデプロイしているが、将来的にはサーバーサイドレンダリングをすることを視野にいれている。そうした場合はEC2やHerokuといった場にデプロイすることも考えなければならないので、今のうちからDockerで環境の構築が簡単にできるようにしておけて良かった。

Go言語をおぼえる前に開発環境構築に手間をかけたくなく、Dockerの勉強をはじめたのだが、いつの間にかGo言語よりもDockerのほうに夢中になってしまっていた。Go言語の習熟ができていないというわけではないのだが、しかしDockerのほうに割いた時間のほうがはるかに多い。そしてDockerのほうが楽しめてしまっている。これは正直に言って予想外であった。

また現在はClosed Betaで語れることは少ないがCircle CI 2.0も良い具合に使えている。問題が全くないというわけではないが、サポートの対応もそれなりに早く好印象である。はやく正式に提供開始されて欲しいものである。

GitHubのリポジトリーのドキュメントもそれなりに整備した。開発環境の構築もDocker Composeのおかげでしやすくなったのではないだろうかと思う。

BaberuTVは今月中にトップページをランディングページの体にして、v2.0.0として公開しようと考えている。今は開発環境やドキュメントの整備、そしてユーザーの目に触れる部分の調整に力を入れている。機能拡充については四月以降に進めていきたい。

「技術力」とはいったいなんなのか

ここ数年、ずっと自問自答している。

W3Cの勧告やRFCといった技術仕様や、言語やツールのREADMEを読むことによって得られる知識を持っているだけで「技術力」があると言えるのか、と。

多くの技術は、「読む」という行為によって容易に得ることができる。極論を言ってしまえば、読むことさえできれば誰でも「技術力」を得られるというのがわたしの持論である。

「読む」という行為に障壁を感じたことが薄く、「技術力」がないと自らを称す人のことは正直に言ってしまうと理解に苦しむ。「読む」だけでは技術が得られない、というのであればわたしは「技術力」がないということになってしまう。

また、わたしの「技術力」に対して一定の評価をして、雇用という形でそれ表現している人たちが存在する以上、自らの「技術力」がないと言うことはどうしても礼を失することになってしまうのではないかと考えてしまう。

「技術力」とは、いったいなんなのだろうか。

FacebookやTwitterをしばらくひかえます

ここ数箇月の間にさまざまな悪いことが重なってしまい、FacebookやTwitterといった推敲をほとんどせずに投稿を行うような場ではネガティブなことばかり書いてしまう兆候が見られます。これはわたし自身にも、わたしの投稿を見てくれている方のどちらにも良くないことでしょう。そのため、少し落ち着くためにどちらもしばらくひかえることにしようと考えています。

アカウントを削除したり、通知を無効にしたりはしていないため、なんらかのアクションを取れば反応を返すことはするかもしれません。ですが、確実に反応できることは保証はしません。ちょっとさまざまなことで立て込んでいることもあり、どうしても多くのことが鈍くなってしまっています。なにかわたしに連絡したい用事があるかたはメールでお願いします。

とは言いますが、わたしの活動の様子はGitHubamakanから確認することができると思いますので、それほど気になさらずとも構いません。落ち着いたらFacebookやTwitterにも戻ります。

2017年の春から開発者として働き始める人が読むべき技術書

わたしがソフトウェア開発者として働くようになってからもう何年も経ちますが、通読した技術書は0です。技術書を読まなくてもソフトウェア開発者として働き続けることはできます。

この技術書を読まなければならないといったことを半ば強制的に言ってくる人の言葉には耳を貸さなくても大丈夫です。

もし、強く技術書を買うよう要求してくる人がいるのであればその人に本を買ってもらいましょう。そういうことができるのは若者の内だけです。

技術書を読めと言うのならば、そうした責任を持つべきです。とくに働き始めの人はまだお金も少なく、ほかの書籍と比べると高価な技術書を購入することは難しいのですから。