最近のTwitterの使い方

10年以上 Twitterで誰もフォローしていないことでお馴染の私ですがどのようにTwitterを使っているのか謎だと思うので、これまでのこと　そしてこれからのこと・・すべてお話しします。

Tools

専用クライアントは使わずWeb版 https://twitter.com/ を使います。たまに自作Twitterビューワーを作って使いますが、トークンを手動でリフレッシュしているので気分で切り替えます。

他ユーザーと交流もせず通知がいらないのでモバイルのTwitter Appも入れず、見ない時は NextDNS で twitter.com を弾いておきます。

Home

favoriteしておくとTwitter君がいい感じにリコメンドしてくれるのでそれを読みます。バズっている小言みたいな投稿は避け、なんとかをリリースしましたとか転職しました等のめでたい投稿を選んでゆきます。

Post

何か思いついたらブラウザでタブを開いて投稿します。連投で長文を投稿しはじめたら何故か負けた気がするので、最近はブログへ寄せるようにしています。

他のユーザーと交流はあまりしないのですが、何かリプライがあったら見ることはあります。RTした後になんか言うタイプの人もいるのでRT後の発言を収集しておきます。

自分の投稿文章からキーワード抽出して直後の空リプ検索結果を収集するプログラムを作っていましたが、投稿者の文体が癖が強いのかうまく動作してくれません。

Feed

フィード。情報を得たい時は検索します。キーワードはその都度思いついたものを適当に入力します。web3 とか。

検索を使う理由は全ユーザーの発言を見たいからです（太古にはpublic timelineというものがありました）。全ユーザーフォローするのはたいへんそうなので検索をします。

操作ルーティーン

  1. 検索する
  2. jjjjjjjjjjjjjjjjj
  3. u
  4. jjjjjjjjjjjjjjjjj
  5. 外部サイトのリンクを開く
  6. くり返し

jjjjjjjjjjjjjjjjj は1 tweetづつ移動するショートカットです。

u はミュートです。ミュートは重要な機能で、検索フィードをメインにしているとBOTの投稿などのノイズがめっちゃ増えます。それらを効率よく処理するためにミュートしていきます。

フレームワークのシェアを重視しがち

チームで何かアプリケーションを作る時にどんなプログラミング言語を使ってどのフレームワークでどういう技術を使って作ろうか？　と話し合いが行われることがある。この意思決定プロセスは技術選定とか呼ばれている。

そこに出てくるフレームワーク、に限らずソフトウェア技術・ツールの選択基準に大きく関わる「どのぐらいこの技術は使われているのか、主流なのか、シェアがあるのか・今後増えていくのか」という要素がある。

そこでは「たくさん使われている・寡占的な技術ほど良い」という価値観が広く共有されている(業界によって枯れた技術にフォーカスしたり、投資対象としての新技術の範囲を限定したりするから単純にユーザー数というわけでもない)。

その背景には

  1. 開発者の数を増やして規模を拡大する
  2. 開発者人材の流動性が高い
  3. 変化を予測しづらいエコシステムの性質

というものがあると思う。

たくさん採用してすぐやめちゃうのでみんなが使える技術が都合がよく、マイナーな技術を選んでしまうと市場にいる候補者が目減りしたくさん採用できないし、習熟していない人がそれを覚えるまで時間がかかるし(学習コストと呼ばれる)、やってみたブログもGoogle検索でヒットしないし、バグを踏んでも直す人がいなくSaaSのSDKも野良ライブラリしかないので対応する時間がかかる(メンテナンスコストと呼ばれる)。こんな風に理解されている。

「弊社では開発開始時にフレームワーク・アレを選んで元気に開発していましたが、数年経ったら後発のフレームワーク・ソレクトとシェアが逆転したので"採用を考えて"アレグラーからは乗り換えます」的な光景はよく見ると思う。

(ただ、少数派ではあるけど非主流の特定の技術を選択してそれを好む開発者を集めるという戦略も、需要と供給次第なので当然あると思う)

これについてはシェアの高さ意外に直接的・間接的に選ぶ理由もあると思うので一概に「シェア高いかどうかで選ぶのはけしからん」とは僕は思っていなくて、みんなどう思っているんですかね？　というのが率直に聞いてみたいところなのです。

ロードマップ思考とエコシステム　その後

「3. 変化を予測しづらいエコシステムの性質」というものについて全く説明していなかったので補足すると「ロードマップ指向とエコシステム指向」という界隈でよく引用されがちなポストがあるので一度読んでみて欲しい。

essa.hatenablog.com

これが書かれたのはNOSQLの期待が高まっていた2014年の話で、そう考えると当ブログの最近の記事で今だにSQLがわからんとかどうだか言って10年近くやってたのかと関心したのだけど、ここに出てくるエコシステム指向のトピックは結構時代の変化があったなと思う。

本記事のスコープであるアプリケーションを作るためのフレームワークやライブラリのエコシステムで見ると、巨大企業が後ろ盾するOSSプロジェクトがエコシステムの中心にいるというのが特徴的だと思う。

自分の中ではアプリケーション開発に使う道具というものは、ライブラリ100個作って公開するロックスターと100人の仲間がいて、パッチを送り合ってカスタマイズして必要なパーツを組み立てていくような世界観から、細分化された1つの目的を達成するためのライブラリをインストールしたら下位の依存関係から無数のパッケージがついてきてそれらを個別にコントロールできる気はもうしない……　という世界に変わってしまった。

学習としては中心を避けツールが持つ課題や哲学に注目し、それらを実践する道具としては予測できないから多数派を進むのが安全。という見方になる。

これを指して、技術選定の時も「巨大企業が後ろ盾して、多数のユーザーがいて、今後の発展する方向が明確なもの」を好むようになっていって、これはなんか見覚えがあるなと思ったら、ロードマップに従って学習する時の傾向そのものだった。

かくして技術の螺旋に戻ってきた俺たちは・・

speakerdeck.com

Railsオワコン論

人の見方によっていろいろなんですね。一番高いところを知っていて、現状を見た時にそっちのほうが低いので、人気が落ちたというふうに見る人も当然いるわけですよね。人気が落ち続けると消えてしまうので、オワコンと言う人もいます。日本でも海外でも、毎年のように「Rubyは死んだ」みたいなことをブログに書く人がいます。 https://logmi.jp/tech/articles/326541

logmi.jp

ハイプサイクルの頂点との落差がRubyやRailsのオワコン論の印象を呼ぶという話はそのとうりだと思う。

実際に急激なシェアの落ち込みが発生しているのかというと Stack Overflow Insights などを見ても観測できない。

(この話題についてのGoogle Trends同士の比較は「ハイプサイクルは実在する」ぐらいの感想しか得られないことが多い)

「最近は新規プロジェクトのアプリケーション開発にRuby on Railsが使われることが減ったなー」となんとなく思っている(知らんけど)、というのが現在ではないか。

なぜ減ったように思うのかというと

  1. モバイルアプリやSPAのバックエンドとしてWebアプリケーションを要求される場面が増えた
  2. そこではHTMLで構築するViewのテンプレートが必須ではない
  3. より選択肢が増えた

という変化が2010年代に起ったからかと思う。

つまりWebアプリケーションのアーキテクチャが発展してフルスタックウェブフレームワークの利用機会が分解されたと見ることができる。

とはいえ「今年のRailsの死に方は近年まれに見る上物」がジョーク半分だと思うのは、現実に新規の利用機会の減っていったPerlを見ているからだなと思う。

しかしRubyやRailsの場合は新たな試みや実験的な機能が活発に開発されていることからまだそのような時期は早いとは思う。

Railsコミュニティの誰かが言っていたと思うが(曖昧な出所ですみません)「時代の変化に適応し続けるのが生存戦略であり、最新版にアップデートし続ける方が逆に安定する」というのを地で行ってるなと感じる。

タイトルはどう読まれたいかを決める

最近の投稿 でのタイトルは「AはBである構文」で遊んでいるのが分かると思う。

これは「NFTアートは唯一である」という修辞法から学んで気にいって使っている用法なんだけど思ったより色々な意識の変化があった。

そもそもこのサイトはここ数年何だかよく分からないすごそうな著者だけが興味のある技術トピックの話を延々としていた。

タイトルは論文でもなしエッセイでもなしの雲をつかむような言葉選びで、本人的には内容に即した正確な結論をタイトルにつけるべし的なことをずっと考えていたと思う。

最初の変化としてはタイトルをできるだけ短かくするようにしたので、話を単純化しようとするので他人に関心を持ってもらえそうな話題にフォーカスするようになった。

あとは文字数と文節が限られるので、自分の書く内容を正確に表わそうとするのではなく読む人がどう感じて欲しいのかを想像して書くことになった。

『詳解　人間の気持ち』が必要、と言っていた地点から見るとなかなかいい振り返りではないか。

タイトルによって読まれ方を決める例として:

  1. ○○株式会社を退職致しました
  2. 4月の私の近況

の2つは同じ内容が投稿されていたとしても露骨に読まれ方が変わると思う。

今までは「関心が低いとニュースの読者はタイトルだけ読んで反応する」と思っていたが、タイトルによってあらかじめどう読むのかを決めている、と考えると著者がコントロールできる範囲は思ったより広いのではないか。

100人のトロール

Web日記は止まる では「著者が書くことに白けてしまう」ことについて思いあたりがあると反応している人が結構いた。

ただ、これがどういうことが原因で起きているのかを知るとうまく付き合えるのではないかと思ってるので書きたい。

普段10〜20人ぐらいが読んでいるブログが打ち所が悪くSNSなどでバズったとする。

10000人の閲覧が記事を評価し、5割ぐらいの人が「わかる」「それな」的に共感して、3割ぐらいの人が私見を述べるとする。1割ぐらいの人は異論を唱えていて「AはBではない」と感じて、その中の100人ぐらいが「けしからん!」「文章のてにをはがおかしい」となぜか怒っているとする。

この100人をトロールとする。トロールとは怒ることを目的にしている攻撃的な発言者ぐらいの意味で、ネットゲームの世界で元ネタの用語がある。

白けてしまいがちなブログ著者はこのトロールに対しても説得や弁解を誠実に用意しようとしてしまっていると思う。ただ、いやならみるなというのは不誠実な行動に思えるので躊躇ってしまうのだろう。

なので最初にやることはトロールが怒りを目的にしていることを確認することになる。プロフィールを辿り、色々なニュースにどう反応をしているのかを観察する。大抵のトロールは色んな事象について怒っているが、たまに良いことを言っている人もいるので、その時はなかなか見所のあるトロールだなとあらためて元トロールの意見に耳を傾ける——ぐらいのスタンスでいるのがいいと思う。

ポイントは「トロールに見える対象に自分が好かれたいと思うかどうかを自分が決める」という点にあると思う。好かれたいと思わないトロールはあなたの人生の重要な登場人物ではないので説得や弁解に労力をさく必要はない(元トロさんとは和解してください)。

ただ、世の中には自分以外のほとんど他人がトロールに見えているような人もいて、そういう人はどんどん先鋭化して偏っていきそうなので、向き不向きとか居着く環境の問題とかもあるのかもしれない。

Web日記は止まる

2000年代ぐらいにblosxomやtDiaryで熱心にWebに何かテキストを書いていたような人たちは特定の価値観を持っているなと思う。

それがどういうものなのかはすぐ説明できないし、単に特定の人たちのことを指しているのかもしれない。ただ、丁寧に閲覧履歴を見ていけば100人ぐらいは該当するサイト管理人が思い浮べられそうだ。

現在は個人が動画で発信する時代なので、僕の思うこの感覚は次の世代では動画に特別な感情を持ちがちという解釈になっているのかもしれない。

Message Passing

このサイトに辿りつくような人たちはプログラム雑談ポッドキャストの188回以降のエピソードのWebに何かテキストを書くことについての話は共感できるのだと思う。

anchor.fm

Message Passingというのは以下のサイトのことで、ガー社とかファー社とかで就労経験のあるような日米のプログラマーかつ、元々Webで何かテキストを書いていた仲の良い人たち同士で寄稿して運営されていた。

messagepassing.github.io

Webに何かテキストを書くことを一旦ブログと呼ぶが、このMessage Passingの話の中で「ブログを書くにはSNSに投稿する時とは別の能力が必要で、それは筋力のように使ってないと衰えるのではないか」という説が出てくる。これは頷ける部分があるので僕も意識するようにした。

ブログを熱心に書いていた書き手がフェードアウトしてしまう問題については、家庭や職場環境が変化すると活動にさける時間が変わるのかも——というのは一般的に言われてもいるしそのとうりだと思うけど、自分としてはブログを書いて得ていた体験が、社内やクローズドな環境で起こる別の行動によって満されてている、という状況があると思っている。

技術的な話題のできる同僚に恵まれていないとあるプログラマーが、別の職場へ転職したら自分と同じような話が合う人が回りに増えたので、わざわざ外に向って発言する必要がなくなった。とかを想像すると分かりやすい。

ただ生活や環境が変わって書く習慣がなくなる人は次の周期で戻ってもくる、という実感があるのであまり問題視してない(自分が数年おきに繰替えしている行動を見るにそうというのもある)。

それよりは最近は第三者の反応によって書くことに白けてしまい習慣がなくなるという例が結構あって深刻というか残念だなと思う。

Firebaseは難しい

Firebaseを使うと簡単に開発がはじめられる一方思ったように使いこなすのは大変という問題がある。

この大変さは以下のように分けて考えている

  1. Firebase特有の機能を正しく理解するのが難しい
  2. ドキュメント指向データベースで開発していくのが難しい

1. Firebase特有の機能を正しく理解するのが難しい

Firebaseを使って開発する時に

  • データベースにCloud Firestoreを使い
  • ブラウザやネイティブアプリからSDKでアクセスし
  • ユーザー認証をする

という要件を満そうと思うと

が付いてくる(厳密にはFunctionsなしにできるケースもある)。

SDKでFirestoreにアクセスするにはクライアントサイドでクエリを実行しデータを取得する。

このクエリでアクセス制御を実現するためにAuthenticationでアクセス元ユーザーを特定し、Security Rulesを設定しクエリに登場するパスごとの権限を設定する。

要するに従来サーバーサイドで行っていた処理をプラットフォームとクライアントサイドで分担することで、データを取得するための認証やAPIエンドポイントの中身の実装を開発者が省けるようになっている。

このSecurity Rulesの設定自体はドキュメントや開発ツールもありよくできた仕組みではあるんだけど、意図した動作にするためにDBのドキュメント構造も含めて試行錯誤しないといけないので従来のサーバーサイドのWebフレームワークを使って実現するのと比べるとハードルが高い。

なのでそれを回避するために、Cloud Firestoreは使うがAPIエンドポイント内のアクセス制御ロジックは自分でコードで実装しSecurity Rulesは使わないという方法を好む人もいる。

その場合クライアントサイドのSDKが用意したオフラインキャッシュ解決やデータ変更のリアルタイム監視の機能などもあきらめることになる。

2. ドキュメント指向データベースで開発していくのが難しい

リレーショナルデータベースは正規化したデータを要求に応じて柔軟にクエリで読み書きしていくが、ドキュメント指向データベースではデータモデルを要求に合わせないといけないという事情がある。

加えて取得する対象のドキュメントにどんな値が格納されているのか、とかドキュメントの定義を変更したら既存のデータを新定義に移行、などをデータベースへの命令ではなくてアプリケーション側で管理する必要がある。

Firebaseでのアプリケーション開発はクライアントサイドに寄っているので、時系列のことなるドキュメント同士をクライアントサイドジョインしたり、データモデルを都合よく調整するためにCloud Functionsでの非同期処理を繋ぎあわせて工夫したりと、ここが実際に開発している時に難しいと感じている点になっている。

リレーショナルデータベースでのORMなどの周辺ツールの充実によってある程度楽になりそうな予感はあるけど今のところ自分は難しい。

初心者に薦められがち問題

Firebaseはフロントエンドのみで無料でサーバー構築なしに開発を始められるので、プログラミング学習コンテンツのデプロイ先として薦められることが結構ある。

しかし前述のようにFirebaseは難しいので、安全でないアプリケーションが世に放たれるとか、開発の継続や引き継ぎが困難になることを懸念している声もある。

クラウド破産問題

Firestoreはしばしば「実装の問題で高額請求が発生してしまった」というニュースを見かけることがある。

現状DynamoDBのプロビジョニングモードようにキャパシティを設定してコストをコントロールする機能がないので、「閾値アラートを飛して監視」ぐらいしか手段が用意されていない。