ブログのリセット

blog.kyanny.me

Re:のRe:ブログになっていて何やねんという感じだけど関心のある話題だったので反応。

関係ないけど本来のTumblrマイクロブログはこういう使い方をしていた気がする。

閑話休題、自分自身がブログサービスのプロバイダーにいるエンジニアでユーザーたちのことを好きだったらどうするかな、というのを考えていた。

エクスポートツールを勝手に作るのはたぶんやると思う。現にnoteからJSONファイルをダウンロードするツールを速攻作っている。関係者を説得してオフィシャルに実行できるのかはパワーバランスとか人間関係とかあるので自信はない。

note自体はMarkdownを変換して投稿するツールも自作するぐらい使っていた。IPアドレス確認事案(以後、本件と呼称します。以後出てきませんが)の際にnoteの考えるユーザー保護の考えとのズレを感じて使わなくなってしまったけど……

エクスポート機能もMarkdownエディタも、note社のロードマップ自体にはあるようだ。

noteは2022年4月の発表会では、エクスポート機能について「開発が遅れている」と説明していました。 https://news.yahoo.co.jp/byline/yamaguchikenta/20220526-00297873

自分は一般的なブロガーより「サイトが死後にどうなるか」という話題を頻繁にしていると思うのだけど、行動は結構矛盾していてサイトのログやアーカイブドメイン契約はしょっちゅう消失してしまっている。

バックアップとしてはてなグループを使っていたこともあるんだけど、はてなグループ自体が解体されてしまった。

このブログも無数にある投稿先の候補から選んでいる1つだけど、あんまり使い分けるポリシーも定まっていない。

あまりアーカイブの保護をがんばらない理由は、めんどくさいのというのもあるけど、インターネットに公開されているものを他人が自由にできる権利の方を大切に思っているからだと思う。

なくなって困る人自身が保存し、公開すべきであるという意思を持つ人によってホストされてほしい。

例えば趣味のWebデザインというサイトには他人のサイトを転載するためのページがある。

こういう厄介おたくそうなウェブのコンテンツに対する思想は『パターン、Wiki、XP』という本が売れていた時代に結構持っている人々がいた。

その環境の影響を僕も受けているのだと思うし、みんな大好き東亜飯店画像という内輪ネタがあるんだけど、これも僕はそのコンテキストで使っていた。ほんとかよ。

贋作NFTアート

トークンが紐づいたこの画像こそがオリジナルだ、だからオリジナルの所有権を手に入れるためにトークンを買ってくれ」というのを別のトークンでやった場合、大多数の人たちは「どっちのトークンが本物か」を判別できないのではないか。どちらも「トークンが紐づいた同じ画像」ではあるので。

■ - @kyanny's blog

同じことを思っていたので想像してみた。

なんらかのアート作品がトークンAとトークンBとしてマケプレにあるとする。

(ちなみにこの分野は知識がないので情報は正確ではないが、ただしい知識を得たら訂正する気はある)

トークンを見る

自分が買い手側なら  https://etherscan.io/ などで履歴を見てみる。

取引が行われていたらその量などを見る。

そこで差があったらトークンAの価格はこれぐらいだな、トークンBはこのぐらいだからどっちを買うかと決める、

しかし、明くる日の朝に目がさめたらトークンCで同じ画像がアナウンスされていた。トークンAもトークンBも贋作だったのである。

スマートコントラクトでなんとかする

数量限定トークンにはECRだか何だかの仕様とOSS実装があって。スマコンはそれを継承している。

なのでそのスマコンのアドレスから発行したトークンを辿って本物かどうか特定する。

とかできるの?(知らない)

個人的にはFirefoxのアドオンがあなたの個人情報を抜いてないかどうかインストールする前に解凍してJS読みましょうと言われる並にめんどくさい。

偽スマートコントラクト登場

しかし、明くる日の朝に目がさめたらスマートコントラクトDで同じ画像がアナウンスされていた。昨日のスマートコントラクトが偽物だったのである。

私はかぶっていたメタマスクのその場に叩きつけ、星新一SSSBTDAOミートアップへジョグで出掛けるのであった。

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

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

サーバーサイド用途

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

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

ただユーザー規模はそこそこあり、DenoやDartHaskellが有効な程度には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も入れず、見ない時は NextDNStwitter.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検索でヒットしないし、バグを踏んでも直す人がいなくSaaSSDKも野良ライブラリしかないので対応する時間がかかる(メンテナンスコストと呼ばれる)。こんな風に理解されている。

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

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

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

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

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

essa.hatenablog.com

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

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

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

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

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

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

speakerdeck.com

Railsオワコン論

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

logmi.jp

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

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

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

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

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

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

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

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

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

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

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