Swiftがこの先生きのこるには

Apple系デベロッパーの人たちがSwift普及のいかんともしがたい現状について話していたので考えてみた。

サーバーサイド用途

サーバーサイドSwiftは現状あまり利用したいケースが見当たらず、モバイルアプリ開発組織のマイクロサービス開発の共通化においてはJVMが枯れているのでKotlinの方に傾きがち。

WindowsやVSCodeやIntelliJ系の非Xcode系開発環境のサポートのハードルも越えるぐらいモチベーションが必要である。

ただユーザー規模はそこそこあり、DenoやDartやHaskellが有効な程度にはWeb開発用途には使えると思われる。苦労しそうだけど。

Wasm化

Wasmにしてブラウザサイドでコードを動かそうという向きもある。拡張用途では周辺ツールの多いRustやCのライブラリ資産のポートもありレッドオーシャンであることは変わりないが、Swiftに限らずWasmアプリケーション化はstdlibを動かす部分(ランタイムというんですかね?)を含めたコードサイズとの闘いも上乗せされそう(にもかかわらずJSのが早かったり)。

あるとしたらiOS/macOSアプリケーションのコードをピンポイントでWeb活用して共通化、という使われ方を想像した。

iPhoneがあと20年ぐらい使われる

iPhoneが今後10年ぐらい使われ続けてそのアプリ開発にSwiftが使われ続けるのは想像にやさしいところだけど、2040年となるとSwiftにももうひとまわり大きな変化が起きていそう。そうしたらSwiftはもっと広く使われているのではないか。

新世代デバイス向けのスクリプティングレイヤーに採用される

3Dゲームを作る時に使われるUnity並に普及したXRスタジオな何かを拡張する手段としてLLVMコードが要求され、なぜかSwiftが組込まれて使われていくという世界線が来る。

Xcode for Windows

Appleにもナデラ的なリーダーがあらわれクロスプラットフォームな開発者取り込み戦略を進めてゆく。なぞの魔術WinObjCとかではなく、Apple自身がWindowsネイティブに動くアプリケーション開発環境を開発する。

ただなんやかんやでみんなそれぞれWebViewで実装し、Electronプロセスを立ち上げ続けるのであった。

新ブラウザ発表

突如としてSafariに変わるまったく新しいエンジンを積んだブラウザをAppleがリリースする。それでは期待されたWeb標準APIが充分に完備され、JSでアプリが作成でき、envoyのようなアーキテクチャでSwiftでブラウザ拡張も作れる。そしてSwiftはWASM生成元として地位を確立するのであった(私はRustで書きます)。

サーバーレスSwift

Testflightのような力技でAppleがどこかのmBaaSを買収。Xcodeからワンボタンでデプロイ可能になり、Apple系デベロッパーはもうこれ以上VPSを借りなくていいんだよ・・と御告げが来る。

あんまり使われなさそう。

まとめ

Appleの将来に依存し過ぎている

メディアに出ているひろゆきを見て10年越しにモヒカン族 (ネット用語) を理解したような気がする

報道番組でのひろゆきの芸風を見てマジレスおじさんの役割を担っているなと思っていたのだけど、それはモヒカン族 (ネット用語) で説かれていた特性に似ているなと思った。

ひろゆきのやっていることは

1. 問題について比喩を使って単純化する
2. 解決方法について空気を読まずに発言する

これの繰替えしであると言える。

比喩を多用するのは自分の視聴者に問題を分かりやすく説明する手段で。「空気を読まない解決策」というのは一部の人には感情的には受け入れられづらいけど客観的には問題に対する論理的に正しい答えであると感じる、ぐらいの意味。

問題を単純化する過程で自分の意図と似わない抽象化がされると詭弁や論点ずらしに感じる人もいそうだなと思った。

でもなんかどこかで聞いたことあるような……　と感じてモヒカン族 (ネット用語)のことを思い出した。

ちょっと検索してみたら「J-CAST ニュース」の記事でotsuneさんによって似た解説がなされていた。

漫画『北斗の拳』の悪役雑魚は平和な村に出没し、村民を斧で殺戮する。一方、ネット上の「モヒカン族」のイメージは、「誤字脱字の指摘は人格否定とは思わない」「ネット上の場の空気が読めない」「殺伐とした議論を求む」「理系の淡々としたノリ」「詭弁と例え話と断言を使いこなす」などだ。 「正しいけれど、シラケる発言」をするので、イラつく。また、古くからネットに接しプログラムやシステムに強い人が多いようで、単なる「荒らし」ではなく、「ぶっきらぼうなのでぎょっとするが、実は単なる天然で悪意が無く、淡々と指摘をしている学者肌の人」が真の正体だとotsuneさんは見る。 https://www.j-cast.com/2006/10/22003464.html?p=all

ひろゆきの場合、飄々とした態度を取るのでぶっきらぼうというよりは、研究分野の専門家が「素人質問で恐縮ですが——」と投げていくるような威圧感があるのだろう。

これらの芸風は掲示板上のテキストでの相互コミュニケーションと相性が良さそうに見えるけど、まさかこれが令和インターネットの動画世代でバカウケするとは思っていなかったので意外な感じだけど、よく考えてみたら匿名掲示板のジャーゴンが巡り巡って若者語やギャル語になっていたのを繰替えし見てきたので既定路線なのかもしれない。

若者にウケるのはなんだろう・・みんな年長者に空気を読むのに疲れているから心地良いんですかね?　といってみるテスト。

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

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

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

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

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