2022年のインターネットをふりかえる

2022年の技術トピックをふりかえる でプログラミングその他はふりかえったので、インターネット的なこともふりかえることにした

ブログ論系

Web日記は止まるなどを投稿するとなぜかいつも週刊はてなブログ編集部に刺身☆ブーメランさん(誰)とセットで紹介されるようになってて、それはそれでありがたいことではあったんだけど、この話題に反応する人々はいつもの老人会的な面々なので、もっと若者向けを狙っていきたい弊ブログとしてはしまった、またやってしまった・・的な気持ちになっていた。

b:id:laisoを停止したのもこのままこのへんのコミュニティーの一員であり続けるのも飽きてきたなぁと思ったのであって2023年はもうちょっと変化が欲しいなと思っている。

突然最近やってる日記の書き方で三行日記をはじめてすぐやめたり。

あとは最終出社画角画像とは何かがたくさん読まれたようだけど何でこれを投稿するモチベーションが出たのか謎。なぜか六本木ヒルズ勤務を自慢するなと怒っている人が一定数居た(僕は荷物の搬入でしか訪れたことない)

オフライン

ひさしぶりに日本行ったことを書いたが自分の中の物価がバグってしまっていることに気付いてハッとした。

物価がバグるとは何かというと物を購入する時に「日本円でいくらだな→高い/安い」というフローをいつも通っているんだけど為替レートのダイナミックな変動とか日本での暮らしを忘れ過ぎて商品にたいして自分が支払う妥当な価格が分からなくなってしまっていた。

Web3

上半期ぐらいはWeb3の話題が活発で、Web3のここがすごいやWeb5について投稿していたがこの辺に注目していた人たちは今はジェネレーティブなAI技術の方面を話題にしていそうではある。

僕はマリモや4コマ漫画のNFTグッズのトークンを買ったり、ライブラリを試したりや技術記事を読んだりを相変らずしてるけどとくに便利なものっは作れそうにない。

Twitter

最近のTwitterの使い方のように癖が強めの利用法をしていたんだけど、タイムラインをごちゃごちゃにする仕事などに上がる一連の買収騒動に乗じてこれはやめるチャ〜ンスと思ったので更新しないようにした。

ただアカウント消すと社会との繋りが経たれてしまうような心配もあるのでどうしようかと考えている。

Mastodonなどの代替プラットフォームもそんなに新鮮味を感じなかったので、今後どうなるのか注目している。

最近読んで意外に良かった本(1)『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』メタバース本3連発『テクノロジーが予測する未来』あたりをピックアップしたが他にもたぶん100冊ぐらいはノンフィクションの本を読んでいて、Android端末でのオーディオブック環境がたいへん役にたった。

感想を書いてない中で特に気にいっているのはジェームズ・クリアー式 複利で伸びる1つの習慣という本で内容は忘れてしまったけど習慣をどうやってコントロールするかみたいなライフハックとか自己啓発書めいた本だったと思う。

動画

中田敦彦のYouTube大学チャンネルについてはメインチャンネルはあまりチェックしてなくてトークチャンネルの方がおもしろいと思う。ポットキャスト的に倍速にして音声だけで聴いてる。

STREET FIGHTER Vの競技シーンもシーズン3のCAPCOM Pro Tourぐらいからチェックしていて(同じゲーセンに来てた人たちが出てくるから)、格ゲーチェッカーに出てくるような大会は全部見てる。EVO 2022覇者のカワノ選手のサイン入りTシャツをなぜか持ってる。2月にあるであろうEndingWalkerと日本のプレイヤーの対決が楽しみ。

YouTubeのリコメンドにはVTuberとゲーム実況、SFV、ビジネス系動画あたりがよく出てきて釣りサムネ切り抜き動画っぽいチャンネルは推薦オフになるように整理してる。

漫画

Kindleで200冊ぐらいは購入した気がする。ラインナップをみたらおまえらみんなタイムリープしてるな的な面子だった。これがゲーム的リアリズムよ(知らん)。

年末に東京卍リベンジャーズ(1) (週刊少年マガジンコミックス)を一気読みして、ヤンキー漫画のぶっ殺すには、「転倒させ立ち上がれなくする」「暴行して意識をなくす」「刺殺・銃殺」ぐらいの3段階ぐらいの死の概念があるな、というようなことをのんびり思っていた。

アニメ

オッドタクシーを楽しく観た。

ゲーム

十三機兵防衛圏 - SwitchEVE ghost enemies - Switch大逆転裁判1&2 -成歩堂龍ノ介の冒險と覺悟-をプレイした。

あとMacでできるSteamのゲームとしてVampire SurvivorsRust(所有権システムとかがない方)で遊んだ。

ソフトウェアと金

OSSへの寄付の月予算を$10にしたはそのまま続けた。来期はもっと増やしてもいいと思いはじめているけど、AquaSKK並に依存度の高そうなプロジェクトは今のところないのでそれなら時間を使ってAquaSKKをメンテナンスできる方が健全かなと思いはじめている。

Swiftがこの先生きのこるにはで示したようにiOSが廃れてしまったらmacOSを常用することはなくなってLinuxデスクトップに移行するんだけど、10年ぐらいはなさそうだし……

AquaSKKは一生依存しそうな一方、serverless-nextjsは最近は使ってない(各種PaaSがホスティングをしてくれるようになってきたので)。

Wear OSアプリ開発入門

まわりで流行っていたので Xiaomi Mi Smart Bandを購入して、3年ぐらい付けていて「腕に時計があると正確な時間が分かって便利なのでは????」ということに気付いたのだけど、そうなると次は自分で自由に機能をカスタマイズしたくなりスマートウォッチ的なものが欲しくなってきたのでGalaxy Watch5を買った。

Galaxy Watch5もしばらく使っていて、腕でモバイルOSが動いているとプログラムが動かせて便利なのではということが段々分かってきたのでこれからWear OS互換のスマートウォッチ向けのAndroidアプリ開発をはじめたい人への案内の記事を書くことにした。

バイスを選ぶ

スマートウォッチは色々なメーカーから出ていて選ぶのが大変なんだけど「自作Androidアプリが動く」の条件だと現実的にはWear OS 3系を搭載したSamsungのGalaxy WatchGoogleのPixel Watchぐらいしか選択肢はないと思っていて(情勢の伺える記事:2022年を振り返る。スマートウォッチ編)、自分の場合はPixel Watchが近場で売ってなかったのでGalaxy Watchにした。

Watch Faceを作る

Watch FaceというのはOSでいうデスクトップ環境の部分で、プログラムを作成して細かくカスタマイズ可能になっている。

簡易的なものはSamsungが提供しているWatch Face StudioをPCにインストールすると作成できる(Googleデベロッパーサイドにもsamsung.comからダウンロードせよと書かれている)*1

内部的には独立したAndroidアプリになっていてコードで記述することもでき、androidx.wear.watchface.Rendererをオーバライドして画面の描画命令を作っていく。

以下にサンプルレポジトリがある。

https://github.com/android/wear-os-samples/blob/main/WatchFaceKotlin/app/src/main/java/com/example/android/wearable/alpha/

Jetpack Composeでアプリを作る

Wear OS向けのマテリアルコンポーネントが用意されていて、Android Studioで開始できる。

developer.android.com

前述のリポジトリにもいくつかComposeのサンプルがある。

https://github.com/android/wear-os-samples

デバッグ環境を用意する

エミュレータと実機でデバッグできる。基本はエミュレータで開発し、実機でしか動作確認できないセンサー系のE2Eは実機を開発者モードに変更してやってる。

developer.android.com

エミュレータを使った開発風景。これは転倒を検知するイベントがGalaxy Watch5に備わっていてそれを使った機能をComposeで書いてる。

Viewを使ったサンプルコードが以下にある(動作確認のために実際に転倒しろと書いてある・・)

developer.samsung.com

Health Connect

Health ConnectはAndroidが提供するヘルスケアデータのハブとなるプラットフォームのことで、これを使うことでWatchで収集したデータを自分のアプリで活用できる。

developer.android.com

たとえばGalaxy Watchで収集したデータをGoogle Fitで集計して可視化したり、逆にサードパーティのアプリで入力したデータを自分のアプリで読み込むなどができる。

動作端末(Android)に以下のサービスを入れておく必要がある。

play.google.com

アプリのサンプルが例によってGitHubにある。

https://github.com/android/health-samples/

Health ConnectAndroid Phone向けの連携アプリで、Health ServicesWatch向けのComposabらないViewのプロジェクトで、Health Platformが歴史的経緯以下略みたいなやつ。

自分はWatch向けのアプリを書きたいのでHealth Servicesを参考にした。

コラム: 脱スマートフォン

スマートフォンを所持せずWatch単独でどこまでできそうかをここ最近試行錯誤していたが

ぐらいは余裕でこなせそうで、「移動時にスマートフォンタブレットを持ち運ばずにWatchのみで過す」という生活はすでに実現できそうだった。

今回買ったGalaxy Watch5はWi-Fi版にしたので単独で通信できないのだけど、次に何か入手する時はセルラー対応版にして、スマホを捨てて生活してみようと思う。

制約としてはディスプレイの小ささと入力系操作の貧しさがあるので、音声入出力とかUIで工夫しないといけなさそうではある。

*1:OSが合体したり色々あった https://business.nikkei.com/atcl/gen/19/00297/053100015/

2022年の技術トピックをふりかえる

それはベンツなんよ

総括

今年はコードをよく読むようにした。

技術的にはひき続きPaaSやクロスプラットフォームの動向に注目した。

デファクトの移り変わりを感じるので来年以降はGoやGraphQLに手を出していきたい。

去年のエントリ: 2021年に作ったモノや技術をふりかえる

今年やったこと

コード読み

去年はコードを書くことに注力していたので今年は一転コードを読んでいた。

プログラム雑談ポッドキャストを聞いていて「コード読み」っていう言葉がよく出てくるので聞きながらそういえば自分もこの分野が好きだなと思い出したので意識してやることにした。

丁度、最新技術のトレンドだけ俯瞰しているのに学びを感じなくなってきたのでより潜りたい気持ちがあったのでそれを満せたと思う。

IntelliJ IDEAで全言語のプログラミング環境が楽に揃っているのが心強い(Samuraismさんありがとう)。

読んだ成果はメモして主にzennに投稿している。

zenn.dev

ソースコードを読んでると「これってどうやるんだろう?」という時の具体的な語彙が増えていくのでリポジトリを検索してGitHub IssuesやDiscussionsに辿り付くことが多くなった。

そういう時に特定のGitHub Issues単位で更新を購読しておくと、コメントが付いた時にメールを受信するので、新機能の実装などの時にリリースされる前に一早く気付いてテストすることができるようになった。

最初にテストするので問題の発見も早くなるし、開発したばかりなので開発者が議論に参加している可能性も高くて良い。

Platform as a Service(PaaS)

Vercel Build Output

mozaic.fm(ep110 Yearly Ecosystem 2022)でも同じ話があったけど今年はPaaS各社が次々に独自のNext.jsアプリケーションのホスティングに対応しはじめた。

zenn.dev

zenn.dev

zenn.dev

これを実現しているのがVercelのBuild Output API (v3)で、どういうことかというとBuild Output APIでNext.jsのウェブアプリケーションをVercelにデプロイする時の中間ファイル形式が定まって公開されたので、それに従って各社が変換されたファイルをデプロイして動くように接続するっていうことがやりやすくなった。ということだと思う。

これはNext.jsに限ったことではなく、Nuxtでも応用されてVercel上でISRが動くような計画がされていた。

zenn.dev

さらにこの仕組みはVercelの中でホストされているAWS Lambdaを経由したランタイムのハックにも使うことができて、自分はSwiftやRailsを動かして遊んでいた(今ならWasmのがいいかも)

zenn.dev

zenn.dev

(ちなみに遊び過ぎてまたBANされてる)

Cloudflare Workers

2022年はCloudflare Workers周りに怒涛のアップデートがあって連日ひくぐらい新機能が発表されていた。

VercelがフロントエンドのAWSとたまに言われていたりするがCloudflareは直球にAWSと同じ領域にサービスをどんどん展開してきている。

サービスの中核にあるのはService bindingsというやつで、これを使っていい感じにサーバレスアーキテクチャやってくれということらしい。

zenn.dev

直近の関心事としてはtcpクライアントのAPIで、これがあるとHTTP経由でDBを呼び出すしかなかった部分がネイティブドライバーやORMを使えるように変わるので注目している。

zenn.dev

一方Deno Deployは既にTCPアウトバウンドに対応しているらしい(?)

deno.com

ただORMのPrismaはネイティブドライバーにはまだ対応していなかった。

zenn.dev

Web Standard APIs

Cloudflare WorkersやFastly Compute@EdgeのようにブラウザのWeb Standard APIsに近い環境のJavaScript実行環境を提供するPaaSがいくつか出てきて、それらはCDNのEdgeサーバーで動かすことを想定されているんだけど、ここでアプリケーションも動かしてしまう。という方向に発展してきた。

laiso.hatenablog.com

Deno DeployやバックエンドがCloudflare WorkersらしいVercelのEdge Functionsのこのカテゴリに入れていいかもしれない。

これからコンテナ仮想化技術になぞらえてJavaScript Containersと呼んでいくらしい。

laiso.hatenablog.jp

今まで「重い処理やライブラリをNode.jsのSSR側に逃がしてフロントエンドを高速化」という発想でいたので、逆にサーバー側も切り詰めないといけなくなって最初は戸惑った。

この流れにうまく乗ってWeb APIsファーストなアプリケーションフレームワークにしたのがRemixHonoでどんどん勢力を延していっている。

laiso.hatenablog.jp

BunではWeb Standardが使えるが、 逆に言えば、それら以外にWebアプリを作る手段がない。 つまり、Expressが動かないのだ。 これが重要なキーになる。 https://yusukebe.com/posts/2022/how-i-got-2k-stars/

初期のGoogle App Engineの時のように、一見不自由に制限された環境の中で新しいものができていく感じがわくわくする。

Bunについては気になったのでコミットログからソースコードを読んでいた。最初の方のドキュメントにはesbuildをzigで書き直すプロジェクトだったということが書かれていた。

自分はなんでここからNext.jsのサーバーが立ち上がるんだ、という部分が気になったので以下を調べていた。

zenn.dev

安データベースを求めて

昨年と同様に最小限のFirestoreとAlgoliaを使ってFirebaseは難しいと思いながらツール開発をしていたが、個人開発のコストはDB次第を投稿してからはSQLite系の活用に関心を持った。

LitestreamをCloud RunやVPSで動かしてみたり。fly.ioのディスク上やCloud Storage FUSEに直接置いてみたり。

辿りついた先が発展的バージョンのLiteFSで、これからはLiteFSを中心にバックエンドを開発していこうかなーと計画している。

zenn.dev

zenn.dev

その他にはAlgoliaのかわりにGoogle Driveを使って全文検索する仕組みを構築してる。

zenn.dev

ただ同時に、安さを求めて調査のためにクラウドサービスにバンバン課金しているので本末転倒感はある。

クロスプラットフォームなアプリケーションフレームワーク

ハイブリッド(WebView)アプリのアーキテクチャを考えていて、Ionic Portalを見つけたのであらためてハイブリッドアプリの意義を考えていた。

laiso.hatenablog.com

その結果一番必要なのはネィティブアプリのオンラインアップデートだなと思ったのでローカルWebViweアプリであるIonic Portalは使わなかった。

今のところオンラインアップデートを第一に考えるならExpoのEAS Updateに乗るのがベターそうではある。

WebView関連ではTauriのモバイル対応にも注目した。Tauri on mobile 現状確認会時点では本当に実現できるか怪しいと思っていたが半年後に完成させてきて驚いた。

zenn.dev

一方Hotwire Stradaはあれから音沙汰がない。こっちはこっちで厳しそうだがHEY Emailアプリは順調にアップデートしているしいつかリリースされるのかも。

laiso.hatenablog.com

新世代MPAs(Multiple-page applications)

AstroQwikのこと。

最初にIsland Architectureというキーワードを知ってそこから今までとは違う文脈でMPAが使われだしていたので気になって調べていた。

前MPAsは「SPAじゃないもの=PHPRailsのテンプレートエンジンを使ってサーバー側でHTMLを描画するもの」という意味で読んでいたがどうやらSPA→SSR→SSG→Jamstack→MPAと合流してきたらしい。

つまりSPAのJavaScriptアプリケーションをページごとに分解して生成、動的なCSRをIsland ArchitectureのようなHydrationが別途加わるので完全な静的サイトではなく動的なアプリケーションにもなる。

しかしこういうHydration戦略の他にもReactのSSR StreamingがありNext.jsのRSCがあり、HydrogenLiveViewシリーズやBlazorのようなWasmナニカを含めたら画面を作る技術の大渋滞がすごい・・

しかもWebフロントエンドのアーキテクチャって最近はどんどんモバイルアプリ系にも影響を与えてくるのが常なので、そのうちServer-Driven UIのようなシステムと合体してモバイルアプリもストリーミングレスポンスで画面全体を組み立てるようなアーキテクチャが普通になったりして……

PHPエンジニア業

閑話休題、趣味開発で最新技術がたくさん出てくるのは普段の仕事で使っているのが退屈な技術が中心であることの反動というのがあって、退屈な技術というのは悪い意味でもなくてBoring Technologyエッセイに出てくるような意味で、要は技術の種類より重視する問題があるということ(人手不足、とか)。フレームワーク乗り換える必要なしの考えにも通ずる。

boringtechnology.club

で退屈な技術筆頭であるLaravelアプリケーションを今年も書いていた。

今年は一緒に開発していたチームメイトがユニットテストのDB接続を全部スタブ定義するタイプのエンジニアで、Mocks Aren't Stubsなどを上げつつ改宗を促していたんだけど、まぁ自分の方が間違っている可能性もあるよな〜と思いしばらくモック多用スタイルで書いていた。

1年書いた感想としては、やはりモック多用は私たちに向いていなかったと思う。なぜならスクラッチからプロトタイピングしながら開発しているプロジェクトなので常にカバレッジが低くて、そこにモックによってテスト対象の粒度が細かくなったことによってモックテストを書いてあるが結合した結果は検証できてなくて、テストはパスするが動かないという場面によく立ち合って直していた。

モックは控えめに。

システムエンジニア

PHPエンジニア業の傍ら今年はよく要件定義や基本設計だけやって後は開発ラインに流すためにドキュメント書く、みたいな言わゆるSWEじゃなくてシステムエンジニア(SE)っぽいこともよくやっていた。

ドキュメント書いているうちに自分で実装できちゃうよな〜と思いながら形式的にこなしていたけど、なかなか思ったより難しくて苦労した。

何がそんなに難しく思うんだろうと考えていたんだけど、コードを書くことで業務知識の理解を担保していたんだなという部分だけスッポリ抜けている感じがして、あーはいはい、ここの仕様は分かりますが、よく分からん。コード読むか。みたいな虚無っぽいフローになっていた(自分でドキュメント書いてるのに)。

なのでSIerでこの辺の業務をソツなくこなせている人は優秀だったんだなという感想を持った。

シーケンス図やフローチャート書く時にMermaidを使ったがこれはVSCodeでコーディングできるのが快適だった。

laiso on Speaker Deckなどを見ても分かるとうり自分はプレゼン資料作りとか図解が苦手で、あまり満足のいくものが作れたことがない。

これは思考をテキスト=散文からスタートして、その後に構造化して、すべてが完了してから意図が伝わるよう図を付け加える。というやり方がうまくいっていない気がしていてて、最初からイメージで捉えて物事を考えたいなぁというのが現在のところ。

最近、なんでも図解という本を読んでいるんだけど、これぐらいのシンプルなルールなら真似しやすいのでやってみる。

インフラエンジニア業

ソースコードを書くなど単純な作業は外部に委託するなど柔軟な対応 をしているので、そのぶん保守系の開発やインハウスなAWSリソース管理などを重点的にやっていた。

今年の大きなテーマは2019年に構築したEKSクラスタのNodeを新バージョンに総入れ替えするついでにEC2インスタンスをEKSマネージドなNode Groupに移行するというものだったけど無事無事故で完遂できた。

最初の構築時にシステム基盤をECSかEKSかにするかをかなり迷ったけど、10個ぐらいの御互いに呼び出し合うアプリケーションを一人で管理しないといけないから、システム境界を曖昧なままにして必要であればEC2インスタンスやコンテナにシェルで入って泥くさい対応もできるようにする必要があったのでEKSにして良かった。

ただの偶然だけどJason Warnerが言ってた「まずAppsに分けろ」の方針になっていた。

来年やりたいこと

Go言語でWeb開発

「スタートアップの開発に参加するならgolang履修必須」程度に身の回りのプロジェクトで使われているぐらいに偏ってきたのでGoでひととうりのバックエンド書いて運用したい。

自分はちょうど10年前ぐらいにこの動機で片手間にRailsアプリの保守ができるようになった。

あとGraphQLも導入したい。

実践的なWebフロントエンド開発

自分は本業はテンプレートjQueryを使った管理画面エンジニアリングしかしていなく、SPA以降のアーキテクチャは趣味で書いたり学習していたりするだけなので実践的なスキルはあんまりない

Web Speed Hackathon 2022 を勝手に開催するをやっていたら専業フロントエンドエンジニアはこういう最適化をしているのね……と大変さが分かった。

これを業務でやるならもっと経験を積みたいなと思ったので来年は大きめのアプリケーションを作ってみたい。

モバイルアプリ開発の学び直し

モバイルアプリ開発はキャリアの半分をiOSエンジニアとして過ごしたので自分の中ではやればできる枠=後回しになっていたがもう数年も経つし「昔開発していたらしいマネージャー」ぐらいの感覚になっていて今の一線の開発現場に入るには学び直しが必要かなと思っている。

Androidアプリ開発も既存のソースコードちょろちょろいじるぐらいなら余裕だけど、ベストプラティクスを自分で考えたりするぐらいの余裕はない。

いい機会なのでJetpack Compose, SwiftUIの世代からまた入門したい

データ分析、統計処理、機械学習

学習意欲はあるはずがやりたいことと関心が結びつかないのであまりモチベーションが高くない状態。

数理系の基礎教養が不足していて理論に関心を持てない要因かもしれない。

最近活発なAI系サービスやツールも使ってみる、ぐらいのところから始めてみたい。

『世界で一番ゴッホを描いた男』とプログラマー

深センの大芬という街でゴッホの複製画を20年に渡り描く趙小勇という職人の男性に密着したドキュメンタリー(原題はChina’s van Goghs)。

215. 見てない映画を紹介します | Ossan.fm で知ってウォッチリストの中にあったので消化した。

身に覚えのあるクリエイターに打ち所悪く刺さる蟹工船的な作品、ぐらいの予備知識しかなかったが、実際に観てみると、なんとなく想像していたよりもはるかに面白かった。

プログラマーにも刺さると思う。

engineerとdeveloperでレスバが始まるやつじゃん

趙小勇は20年という長い期間ゴッホの複製画を描いて生計を立てている。複製画はオランダのアムステルダムなどのヨーロッパ方面に納品され販売されているらしい。

この仕事が儲かり、金になるからやっているというわけではなく、ゴッホの絵を描くことが好きだからやっている。

むしろ低賃金で全然金にならなく過労働なので職人は減っている。工房には趙小勇と同じく志しを持った絵描きたちが集まり日夜ゴッホを書いている。趙小勇の妻も同じ工房の職人。

さながら大規模システム開発現場の末端組織のSEのようである(本作内の複製画の商流に多重請負のような構造があるわけではない)。

趙小勇はキャリアが長いので後輩や弟子を指導する立場もある。成果物の品質を自身でチェックし改善したり、自分の望む技術に進んでよいのかとキャリアに悩む若手に助言をしたりとシニア的な振舞いもしている。

みんなの士気を高めるためにゴッホの映画上映会を開催したりする。TGIFに『ソーシャル・ネットワーク』再生するEMじゃん。

一方自分のキャリアにもかなり悩んでいて、このまま複製画を描き続ける人生でいいのかと日々自問自答している。

ゴッホの原画を自分の目で見ることでその答えがわかると考えた趙小勇は貧しい生活の中、大金をはたいてアムステルダムゴッホ美術館を行くことを決意した。

たぶんシリコンバレー行くぞみたいな心境だと思う。

出発前にパスポート手続きに帰郷し、親戚たちと過した後昔のことを思い出したのか趙小勇はカメラに向って自身に学歴がない=貧しくて学校へ通えなかったことを語る。

自分もCS学ばず高卒でプログラマーやっている立場なので分かるで〜と思いながら聞いていた。

そしてゴッホ美術館に出向く場面はこの作品の一番の見所であるんだけど、映像でしか表現できてなさそうなものを文字で説明するのは無粋なのでここは見てほしい。

僕が注目したのはアムステルダムで自分の複製画が納品先で実際に販売されているのを見た時の趙小勇の反応。自分の作品が市場でどのような価値を持っているものとして扱われているのか、というのを彼が期待していたものとギャップがあったようだ。

20年越しにそれが分かるというのもなんともせつない。

帰国した趙小勇はオリジナル作品の制作に乗り出すんだけど、この辺も見てて「代表的プロダクト」を残したい個人開発者の心理をついてるなーと思った。

kentarokuribayashi.com

ハッカーと画家」という有名なエッセイにハッカープログラマー含む)と画家は似ているという話が出てくる。

practical-scheme.net

本作品になぞらえると、意図せずして大企業に搾取されている形になってしまうOSSメンテナーの問題などにも通じるだろうか。

タイムラインをごちゃごちゃにする仕事

www.businessinsider.jp

この記事は「ツイッター改悪の張本人ではあるまいか」みたいな反応をする多くの人と、もうちょっと実際を理解している業界の人のマジレスが少数という感じでシェアされているのを目にした。

「タイムラインをごちゃごちゃにする仕事」は原文も確認してみたけどmessing up your timelineと書いてあったからこの機能が不評を買っているというコンテキストが含まれていて妥当な訳だと思う。nabokov7さん本人もそう書きそう。*1

Homeの推薦機能については記憶にある限り業界の人でもポジティブに受け取っている人は見たことなかったが、僕は便利に使っていた。ただ最近のTwitterの使い方にあるとうり一般的な利用法ではなかったと思う。

タイムラインへ知らない人混入や、巻き込みリプライに怒る人、というのは僕の中ではツイッター2大よく分からんポイントだった(あってもなくても快不快を感じない)。*2

これらの機能がツイッターや広告主に好ましいものであったのであろうことは想像に難しくないが、年単位でツイッターを利用しているユーザー層にとっては迷惑極まりない機能で、プラットフォーマーに対して物言わぬようなライトユーザーには受け入れられており数字として観測できていたということだろうか。

ツイッターは常に成長し続けないとプラットフォーム(SNS)を維持できないだろうから、既存ユーザーが変更を受け入れざるを得ないっていうのはあると思うんだけど、この話には2つの観点があると思った

  • ユーザーの求める体験とプラットフォーマーの指標が異なる *3

    • 指標を追求すると一部ユーザーを憤慨させることが正解になってまう
    • それこそがユーザーの求める体験である(ディストピアだよ派)
  • ユーザーが保守的な体験を求めてそれをプラットフォーマーが満そうとすると長期的に維持できなくなっていく

    • ということはユーザーは衰退し続けるプラットフォームを次々に乗り換えていくことを求めていることになる
    • 古参だらけで維持されているなぞの怖い過疎コミュニティというのがインターネットにたくさんあるが(はてなとか)ああいうのが永久に維持されるのが完成系なのか
    • なんか社会問題とか環境問題とかに構造が近い

それはそうとそろそろ次のプラットフォームでも流行ってくれないかなと思う。

*1:日本語記事でニュアンスが伝わらないというのもある https://twitter.com/hydrakecat/status/1598198314469838849

*2:mixiの足あと機能がなくなって怒るというのも似てる

*3:https://twitter.com/nabokov7/status/1598495480945999872

YO 、朋輩、ヤマト運輸株式会社 & Githubber

github.co.jp

これはひどい的な文脈でシェアされていたので中身を読んでみた。

SIerの業界とか上流工程の世界の価値観が濃縮された文書なのかなと予想したが、「ソースコードを書くなど単純な作業」のパワワな部分以外はそこまで偏りはない印象を受けた。

記事はビジネスメディアによく見られる全身にバズワードを浴びたような文体で、大量の修辞表現から実際の現場感の想像する作業が読者の手に委ねられている。なぜかこういう言葉遣いの文章を読んでいると モブ・ノリオ『介護入門』を思い出して懐しい気持ちになる。

「内製化」という用語が18回、「DevOps」が8回登場する部分に注目したい、この2つのキーワードが内容の中心になっている。要点を抜き出すと以下のようになる

  • ヤマト運輸株式会社は内製化によって外部システム会社を使った開発を削減する
  • 内製化にあたって100人のエンジニアを採用した
  • GitHubソースコードを管理するようにした
  • とはいえ外部システム会社はひき続きいい感じに使いたくもある

以下では記事にある各リリックを読み解いてゆく

「DevOps開発体制を構築・浸透させる上ではデータグラビティ(データの蓄積によりビジネスに与える影響力が高まること)がより重要になるため、ソースコードの維持・管理で最も信頼でき、かつ付加価値の高いGitHubを選択することは自然な流れでした」

GitHub便利」という事が書かれている

一歩進んだ内製化:アウトソーシングの削減だけでなくアーキテクチャデザインやコードのガバナンスも視野に

本文を見出しに圧縮することで生成された文章っぽい

GitHubを活用したソースコードのガバナンス

アカウントとリポジトリを権限管理すること

アーキテクチャのデザイン 標準化が実行可能なメンバーによるコアな開発は内製化し、ソースコードを書くなど単純な作業は外部に委託するなど柔軟な対応が必要です。

「標準化が実行可能」が何を指すのかは難しい、自社規定に従って作業が可能、もしくは上流工程のスキルセットの話かもしれない。

ソースコードを書くなど——」はウォーターフォールの詳細設計書を翻訳するような作業を指しているのだと前後の文脈から想像。

コーディング自体を軽視しているのだとしたら、内製開発プロジェクト「EAZY」のエピソードと繋っていないように思えるので既存ウォーターフォール開発との対比の表現だと思われる。

どこまで自社のコアコンピタンスを内部リソースとして持つかを見極めることにより、1歩進んだ内製化の道も見えてきます

ハイブリッド・アジャイルみたいな前向きな主張。システム子会社との政治的要因も絡みそうだし面倒くさそう。

見出しでは「一歩進んだ」だったが「1歩進んだ」になっている(細かい)。

さらに、AzureとGitHubによって内製化を進めると、これまでサイロ化していたナレッジが社内共有され、横展開しやすくなるという効果が表れているという。

「社内のシステム分かる人が増えて良かった」と理解した。

将来的には、ソースコードに付加価値があることを経営陣にも説明できるようにしたいと中林氏は期待する。

「経営陣はソースコードに興味がないのは必然」

そうですーランキング

Slackなどのビジネスチャットの場で使われる、そうですという返事のバリエーションについて考える

そうですー

長音を付けると醒めた印象を与えるらしく敬遠されがちである

そうです〜

そうですー問題を解消するための代案。良い塩梅と思う層と軽薄過ぎると感じる層がいるらしい。

そうです。

句点を付けることで厳格な印象を与えることがあるらしく敬遠されがちである

togetter.com

そうです!

感情表現に乏しいテキストコミュニケーションでは実際の知性より2段階ぐらい馬鹿を演じることでトントンよ、という成功体験から得られる技法。

〜を組み合わせたり!!の数によって知性を調律する。

けんすう on Twitter: "感覚の問題ですが「!」はもはや敬語になっていて、「。」はぶっきらぼう、感じの悪い表現になっている、というのがあって、僕も。はすごい使いづらい感じになっています! https://t.co/N22r9BEChQ" / Twitter

そうです❗

おじさん構文のように若年者側に寄せようと試行されたそうです!の亜種。

そうです🙇‍♂️

クセになってんだ ・・ 🙇‍♂️を付けることで相手を敬いたい気持ちが・・

テキストではなくリアクションでsoudesizeする文化が根付いているSlackのそうです。

そうです!!!111

「よし!おまえら飲みに行くぞ!!!111」などのネットミームを含むそうです。Perl界隈かあやしいわーるど住人の可能性がある。

技術ブログで使用すると若者にtypoとして指摘される。

あ—— そうです————

ザ・ファブルを読み終わったばかりの人