ドキュメントベースではないWebアプリケーション

Four Eras of JavaScript Frameworks

JSのアプリケーションフレームワークを4世代に分けて解説する記事

今のSPAはGoogle Maps等の始祖的なAjaxアプリケーションから直接由来したというより、スマートフォンアプリのユーザーインターフェイスの再現が下地にあると思っているので近い考えた書かれていて同意した。

ユーザーが操作する範囲をWidgetとして定義する開発方法から、開発者が分割単位をコントロールするコンポーネントベースのGUI開発や関数型プログラミングの適用も、XAMLでMVVMと言われ出した頃から僕も知ったので近い時代感を受けた。

新興のフルスタックフレームワーク世代のものはMPAへの回帰が進んでいると思う。

ただし現在のJavaScriptアプリケーションはブラウザの描画とDOM操作の手続きで表現するドキュメントベースの従来のアプリケーションから、ダウンロードしたコードをオンザフライ方式で再生してグラフィックを描画するデスクトップアプリケーションに段々変わっていっている。

よく槍玉に上りがちな、Rails vs SPAな議論だとこのドキュメントベースではないWebアプリケーション開発の変化にあまり焦点が合わないなーと日々感じてる。

Edge Functionsはブラウザ

Cloudflare Workers

Cloudflare Workersのようなサーバーレスなコンピューティングプラットフォームとしてここ数年活発な「エッジサーバーでプログラムを実行する環境」(呼び方が定まらないので一旦Edge Functionsとする)でアプリケーションを作る*1とブラウザが通信する先にもう1つブラウザが存在するような妙な感じを覚えていた。

例えばNext.jsのAPI Routesなら書いたコードはNode.jsで動くので頭をサーバーサイドモードにすればいいが、Cloudflare Workersで動くエンドポイントを書く時はそうでない…… おまえ、ブラウザなのか? みたいな

でもよく考えたらこれらのプラットフォームはSpiderMonkeyやらV8やらのブラウザと同じJavaScriptエンジンを組み込んだ実行環境を持っていて、APIも環境の制限(TCP接続とかファイル読み書きとか)も似ているからそう感じても当然かと思った。

1年ぐらい前のThe Changelog PodcastでRyan Dahlが出演してDenoやDeno Deployについて語っていた回でDenoはブラウザのAPIとの互換性を持たせるデザイン意図を語っていた

changelog.com

And by the way, I should be explicit - Deno is trying not to have an API. Deno is trying to be the web browser API. Deno is trying to not have a specific Deno API, but just - if you want to encode a string into a uint array you use a text encoder. We don’t have a special Deno API for that. https://changelog.com/podcast/443#t=01:04:08.04

だからWeb Workersのようなメインスレッド以外で動いてドキュメントの描画には関与しない処理がたまたまリモートにあって、レスポンスを返してくる。と考えるようにした。

developer.mozilla.org

ブラウザの中のさらにその中のWeb APIの一部だろうという話はあるんだけど「Edge Functionはブラウザ」のがタイトルとしてカッコよかったのでいいじゃないですか。

開発者から見たメンタルモデルは上記とも言えるんだけどアプリケーションのユーザーからして見たら実行コンテキストは外部だし、取り扱うデータもすべてのユーザーを横断するものの可能性もあるしで若干ミスリードかもしれない。

ブラウザじゃなくてもEdge Functionsはフロントエンド領域だろうという例で、時雨堂 SaaSの技術スタック解説でCloudflare Workersはフロントエンドに分類されているというのもある

zenn.dev

Web APIまわりの議論

最近特に"なんとかEdge Functions"がたくさんリリースされているように見えるのはDeno Deployの仕組みを他社(SupabaseやNetlifyのこと)に提供する拡大戦略が背景にあるようだ。

https://deno.com/deploy/docs/subhosting

Node.jsやDenoでブラウザと汎用プログラミング環境用のAPI互換性を上げることの是非についても議論があり、以下を読んだ

yosuke-furukawa.hatenablog.com

scrapbox.io

Edge Functionsのような環境でブラウザ向けのコードを取り込もとしている時流があると思うので関連しそうだ。

一方Cloudflare WorkersではNode.jsのランタイムにあるAPIを独自に互換性を持たせるような動きもあって、これは逆のアプローチだなと思う。

blog.cloudflare.com

Edge Functionsでアプリケーションを作ることを中心に考えると、VercelなどはNext.jsでがっつりNode.jsのAPIに依存しているからこっちのが都合が良さそうで、Remix陣営は後発の利でいろんなPaaS向けのアダプタをサポートする用にデザインされており(間も無くDeno Deployも使えるようになる)そんなに恩恵はなさそう。

*1:Edge Functionsで動くアプリケーション: https://github.com/laiso/isucholar_cfworkers とか

中田敦彦のYouTube大学チャンネルについて

www.youtube.com

中田敦彦YouTube大学がどういうものかというと、チャンネルホストの中田敦彦さんが自分の興味のあるトピックについて本を読み、それについて学校の授業のように視聴者に講義をする。といった体裁を持つYouTubeチャンネルである。

テレビ時代から中田敦彦を知るマスなファン層には「ためになる」と好まれていて、ちょっと斜に構えたネット民からはいくつかの理由で迎合されていない。ぐらいのポジションにいる。

本の要約チャンネルの側面

このチャンネルの基本スタイルは特定の本(参考図書と呼ばれる)の内容をホワイトボードに要約し、それを前後編1時間弱の時間で解説するという動画が多い。

複数の本を1つの動画の同じテーマとして取り扱う場合もあれば、1冊の内容をそのままの時もある。

動画に取り上げる本については「許可を取っている」と本人は発言していた(出版社に?)。

ただ動画のタイトルや概要から書籍のタイトルが分かるようにはなっておらず、サムネイルでの情報はテーマぐらいしか分からないが動画の中身は本の話をしている(たまに書影が載っていることはある)。

過激な意見が出てくると「私ではなくこの本の著者が言っていること」というエクスキューズが度々出てくる。よく「このチャンネルは誤った情報を発信しているのではないか?」という批判を見かけるけど、内容の信憑性は本に依存している。

「資産運用や投資について大量の情報を発信しているが本人は興味がすごくあるのでたくさん調べているだけど、実践はまだしていない」「せどりやネットビジネス・個人M&Aのノウハウを発信しているが本人はやったことがない(「収入が少なく投資する資金がない」という視聴者のフィードバックへのアンサーとして制作されたなどの文脈があったりする)」みたいな状況がよく起きている。

これらの動画がどのように制作されているのかが以下のドキュメンタリー動画で語られている

www.youtube.com

これを観て気付いたこととしては、動画で見える部分はかなりテンションを上げている。舞台に上るような感覚だろうか。考えて見ると当然なのだけどあまり意識していない部分だった。

あとテレビ番組のように綿密にコンテンツの構成を準備している。

コミック解説動画の不思議

本の要約だけでなく特定のコミックシリーズのストーリーを全部解説する。という趣旨の動画がいくつかある。

www.youtube.com

コミックを読めばいいのでは? なぜ絵のないストーリーだけ視聴したい人がたくさんいるのが疑問だったけど、動画は動画で結構面白い。

なので視聴者的には中田敦彦が演じる講師の立ち振る舞いや表現を楽しんでいる、という部分が大きいのだろうと思った。

フリーアジェンダポッドキャストではこれを「落語のようなもの」と表現していた。

www.youtube.com

これは言い得て妙で、自分は脚本と演出と演者がそれぞれ機能化している演劇のようなものをイメージした。

物語の脚本を実演するのではなくて、ノンフィクションの情報レポートを著者にかわって代弁する違いはあるけど。

勉強した内容を発信する

「勉強した内容をコンテンツとして発信する」やっていることはこれなんだけど、はてなんか既視感あるなと思った。

そうソフトウェアのエンジニアが学習したことをQiitaやZennに投稿するあの行為に似ているのだ(そして強い人にSNSでツッコまれる)。

そう考えると数々のツッコミは「公式ドキュメント読め」が言いたいことなんだなと思う。

実際僕も中田敦彦YouTube大学チャンネルで存在を知って購入した本がいくつかある。

strobofmでもソフトウェアエンジニアの2人がこのチャンネルについて感想を述べている。

strobo.fm

好奇心は資源のようにコントロールが難しいので、継続的に本を読むだけでもかなり実現が難しいことだと思う。

オリジナル動画

本の要約ではないオリジナル講義の動画がいくつかあって、むしろそっちのが面白い。

政治家の派閥争いをかけあい調に語る動画はいくつかある。出馬した候補の個人サイトのWeb日記の過去ログ全部読んでいたりして、この話題好きなんだろうなというのが分かる。

www.youtube.com

世界史の動画もいくつかそうっぽいんだけど、僕が興味なかったのでまだ観てはいない。

最近読んで意外に良かった本(1)『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』

なぜこの本を読んだのか

いくらかぶりの本をたくさん読みたい期が来たので最近はよく本を読んでいる。

普通にKindleなど電子書籍プラットフォームで普段は購入しているんだけど、ここ1年ぐらいaudible.co.jp を契約して使っている。

Audibleで配信されているタイトルは限られているのでもう読みたい本はあらかた読んでしまっていたので、次は普段読まなそうな本も読んでみることにした。

この本は2016年に発刊されたタイトルであるんだけど、SNSでフォローしているような身近なソフトウェアエンジニアが何人か薦めていたのもあって気になってはいた。

なぜこの本を読んでいなかったのか

正直この本は書影だけ見て誤った方向に釣られていた。全然中身も確認せずに

「なぜ、あなたの仕事は終わらないのか。それはスピードが遅いからである。マイクロソフト(権威)でWindows 95を開発した著者(権威)の教えに従い。この本を読んでハイスピードで仕事をこなす術を学び、ビジパとしてハイパフォーマンスを発揮して出世して年収を上げようスタンフォードマッキンゼーハーバード(語尾)」

——こんな読者向けだろうなとたかを括っていた。

そして僕は簡素な語彙や表現で読み砕きしやすいように編集されたビジネス新書とか自己啓発書みたいなジャンルを全体的に軽んじている傾向があるので、なんかこの本も同じジャンルに入れてしまってスルーしていたようだった。

どんな内容か

本書は著者が自身の経験から編み出した「ロケットスタート仕事術」を解説する本である。

ロケットスタート仕事術は要約すると「スケジュールの前半2割の期間で8割の進捗を出すのを目指すように時間を使うと見積りどうりに仕事が完了できる」というもので、前半に完了を寄せることをロケットスタートと表現しているようだ。

これはアジャイル開発が目指す所に似ているな〜というのが最初の感想だった。しかし本書の中にはアジャイル開発への参照はないし著者の経験は2000年以前のキャリアが中心になっているので、経験則から同じ地点に自力で辿りついているのだとしたら感心するばかりである。

アジャイル開発手法との共通点

アジャイル開発に近しい話をしているが本書では、組織やチーム・プロジェクトマネジメントの話ではなく個人のタスクの話に焦点が置かれている。そこが明確に区別できそうな点である。

またアジャイル開発の取り扱う範囲は非常に広いので、ここでは単に見積りや計画づくりの一部の具体的なプラクティスは似てくるよねという話をする。

スパイク

本書に出てくるテクニックで、見積りに自信がない時は調査期間を設け、その期間内に8割の完了を得られたら見積り期間を5倍にして確定する(得られなかったら見積りを修正する)。というものがある。

これはエクストリームプログラミングのスパイクと共通している。自分は見積りできる状態になるまで着手する、と理解している。

不確実性の高い作業から先に始める

リスクのありそうな作業は後回しにせずに前半に集中して「ロケットスタート」するという記述が登場する(反対にリスクの少ない作業は後半に落ち着いて行う)。

プロトタイプ

プロトタイプで目に見える成果を作ってフィードバックを得る話が出てくる。著者の場合はWindows 95のグラフィックシステムのデモがこれにあたるようだ、

まず終らせる

最初に顧客に価値を届けて、そこから改善をするというのが多数のバグがある状態で出荷されたWindows 95の成功譚として語られている。

アジャイルではないけど "Done is better than perfect" にある。ただこの言葉は有名だから単にネタ元なのかもしれない。

www.wired.com

遅延評価勉強法

6章では英語学習を例に「必要になった段階で実践するために学習する」という方法が解説されている。

これは僕と同世代の人(Web2.0ブームがあった頃)は心当たりがあるかもしれないけど遅延評価勉強法で示されている方法に近いと思う。

lukesilvia.hatenablog.com

ただ自分の中ではもう少し抽象的に理解していて物事にボトムアップで挑むかトップダウンで入るかという問題だと思っているけど。 以下の記事ではデメリットにも触れられていて確かにそうだと納得した

medium.com

僕としてはボトムアップトップダウンも両方やればいいと思うけど、対象に興味持つ・関心を失う・飽きる・ダルいけどモチベ上げる。という部分のコントロールが一番難しいもんにゃんねぇ〜と日々思っている。

「ここで界王拳を発動します」

集中力の深さを「N倍界王拳を使う」というドラゴンボールZ比喩で説明している。

このため本書には「ここで20倍界王拳を使います」「まだ2倍界王拳でいいでしょう」など界王拳という言葉が100回ぐらい出てくる。

ビジネス書かと思ったらいきなり情緒的な文章が続いてちょっと面白い。「さぁ、はやくおめえらも超サイヤ人になって」

f:id:laiso:20220305071257p:plain:h200(c)集英社

シニアとジュニアの視点の違い

時間管理に失敗する例として何人かのジュニアなプログラマーのエピソードが出てくる。

それを読んでいたら考えさせられることがあったので書いてみる。

(前提として)自分で締切を決める→期限に間に合わず失敗。どの例もこんな感じだ。

僕らはみんな昔はジュニアやマジュニアだったので、この失敗する側の心理状況も理解できる。

それはジュニアの限られた経験の範囲の視点から見ると誠実な仕事の成果というのは「依頼された仕事を可能な限り短納期で実現する」という部分に重きが置かれていることにある。

なので楽観的見積りが採用され、悲観的見積りは不誠実であるか能力不足であるかのように受け取ってしまう。

一方シニアになってくると不確実性を減らして組織の計画をコントロールするのが誠実という価値観になってくる。

本書で出てくる見積りについての心構えはこのシニア視点寄りではあるけど、期間内の完了を担保することに最適化したらしたでデメリットもある。

見積り法則に「おぼろげながら浮かんできた工数の3倍」などの係数Nを持っているシニアは多い。本書に出てくる「2:8の法則」も係数の一種である。

問題は見積り→成否のフィードバックを繰替えすうちに期間が上振れして、見積り精度としては悪化していくが、しかし期限は守られるので下方修正するインセンティブがなくなるというものである。

こうなると仕事が終わるけど期待値より遅い。遅いけど計画どうりに進行することが良しである。「ベンダーがボタンを追加するのに2ヶ月かかります*1」という状況になる。

正しく完了する遅い仕事を改善するために、技術的負債解消に活路を見出し、クリーンアーキテクチャドメイン駆動設計、リライトプロジェクトなどに時間が使われることもある。

ICとしては、もし見積り精度を正すための適切なフィードバックをもらう機会のない大企業のシニアだったら本人は順調に業務をこなしていると思い込んでいるけどまわりからの評価は仕事しない窓際おじさん(性別は問わない)枠になっているかもしれないし、スタートアップだったら短期計画のみ成功し製品や組織は成長しないという死を迎えるのかもしれない。

最終的な成否は結果をビジネスで判断することになるから、世の中で「ビジネスや経営が分かるエンジニア」が求められる背景にはこのような事情があるのではないか。知らんけど

Windows開発秘話

著者がプログラマーとして仕事術を身に付け、独立した後にそれを方法論として確立するまでの過程が3章の実体験のエッセイパートで描かれる。

僕にとって著者の中島さんの印象は、ブログLife is beautiful*2の管理人であり、初代Node.jsのPromise実装にコールバック関数の修正パッチを送った直後にPromiseごと削除されたことで有名なmasuidriveさん*3と共同でPhotoShare *4というInstagramのようなSNSをiPhone3Gの頃に作っていた人で、最近はメルマガを発信しているからブログでの更新は見かけなく、あまり過去の経歴を追ってみたことがなく、インターネットより前の世代でグラフィカルインターフェイスに専門があるプログラマーなんだなぐらいに思っていたので、本書のストーリーで補足できてよかった。

Windows開発秘話といえばNTの闘うプログラマー *5であり、伝説のプログラマーといえばデビッド・カトラーだよなという印象であったが本書はリリースできないCairoに業を煮やして9xチームに移る話なので、闘うプログラマーと時間軸の違う別視点なのかと思うけどそういえば闘うプログラマーを読んだのも結構前なので内容をよく覚えてない。

Windows 95を開発するチームに在籍してGUIのプロトタイプのデモをしたりポインティング操作の開発を手掛けた。というような部分が描かれていた。

ちなみに本の帯の「マイクロソフト伝説のプログラマー」の伝説の部分についてはは「コードレビュー担当者の候補が側に居ない時は架空の清掃員・ジョーがレビューしたと書いておく」という行動を繰替えしていたのが伝説になっていた。とネタ明かしされていた。

サトシシについてはたまにウェブメディア上で編集されたインタビュー記事などで「Windows 95の父」「右クリックを作った」「ゲイツとやりあった」等の誇張表現を見かけてほんまかいなと思っていたが、本書で見られるエピソードは抑え目であることからあれはメディア側のPVハックか何かなんですかね(謎である)

[PR]アフィリエイトリンク

*1:ベンダーがボタン追加するのに2ヶ月問題は見積もりのみではなく、分解すると複数の要因がある

*2:https://satoshi.blogs.com/life/

*3:https://masuidrive.jp

*4:PhotoShare https://www.itmedia.co.jp/bizid/articles/0810/09/news011.html

*5:闘うプログラマー https://www.amazon.co.jp/dp/B00GSHI04M

OSSへの寄付の月予算を$10にした

 

Money does many

1年ぐらいOSSへの寄付を続けていて、今期は予算倍増いけるなと思ったので月予算を$10にすることにした(いずれ収入の何%みたいなルールを設けるのがいいなと思っている)

寄付するプロジェクトはこういう基準で選んでる

  • 自分が使っていてなくなったら困る
  • マイナーであまり寄付されていない

ということで現在のAquaSKKのメンテナをやってくれているbanjunさんのスポンサー枠とserverless-nextjs.jsっていうプロジェクトを設定することにした。

github.com

opencollective.com

AquaSKKLinuxデスクトップユーザーが使いがちな日本語入力のmacOS版で、依存が強過ぎるので何度かやめようと試みたけど無理だったので今寿命内はあきらめて、ソフトウェアの提供が長く続く方に努力することにした。

GitHubレポジトリを見てもらえばわかるけどこのソースコードを自力でメンテナンスするのは超たいへんで、自分で保守できるようにするよりメンテナに任せる方が楽というのを、ユーザーみんな思っているはず。

serverless-nextjs.jsはAWSのサーバーレス環境でNext.jsをまともに動かすのに必要な基盤になっているプロジェクトで存続が怪しそうなので参加することにした。

このプロジェクトはソースコードも結構読んだのでメンテナンスもできるけど、自分が使わなくなる可能性もある。

他に検討したプロジェクト

opencollective.com

laravel-adminっていうLaravelの管理画面フレームワークも普段多用してて、中国コミュニティの人たちが頑張って作っているから登録したかったんだけど、仕事のみで使っているので直接の恩恵を受けているのは僕の取引先法人氏だなと思ったので、ここはエンタープライズ枠にとっておくことにした。

opencollective.com

HackMDっていう台湾の小さい会社が作ってるWebベースのMarkdownエディタがあって、メモツール難民である僕でも継続してずっと使っているのでこれは必要なソフトウェアだと思っていたんだけど、一応企業なので個人プロジェクトの方を優先したくて見送った。来期に期待。

ちなみにメモツール難民でもあるし同時にタスク管理ツール難民でもあるんだけどタスク管理ツールは本当にしっくりくるものがないのでずっと自作してる。しかも自分で作ったものすらしっくりきてないのでタスク管理ツールという概念自体人生に必要なのでしょうか——という域に達っしつつある

Ionic Portalとモバイルハイブリッドアプリ

Ionic Portalとは

iOSAndroidのネイティブアプリの一部にIonicで作ったWebアプリケーションを組込めるようにする開発環境。2021年9月にリリースされた。

ionic.io

命名はHTMLのportalタグを意識しているものだと思われる。

developer.mozilla.org

WebとiOS/Androidネイティブを統合したハイブリッドアプリ(日本ではなぜか"ガワネイティブ"と呼ばれることがある)を構築するためのベストな方法はないものか〜と探していた時にニュースを見かけたので検証をしてみた。

利用料金

開始は無料。商用利用時にアプリの年間収益によってライセンスが適用される。現在はARR1Mドル超えたら問い合わせしろと書いてある。

似た技術

React Native

React技術でネイティブアプリを作るためのフレームワーク。ライブラリとして既存のアプリに組込める。

Integration with Existing Apps · React Native

Strada

Hotwireで構成したWebアプリケーションをWebViewで動かしてOSネイティブな機能を呼び出せるよう統合したもの。

HTML Over The Wire | Hotwire

Trusted Web Activity, TWA(Android)

Progressive Web AppをChrome Custom Tabsで読み込んでAndroidアプリに統合する機能の名称。ネイティブアプリ部分のコードはユーザーが自由に書ける。

Trusted Web Activity - Chrome Developers

Ionic Portal = Micro Frontendsなのか

公式サイトにはMicro Frontendsと書いているけどマーケティングのために入れている文言っぽいので深追いはしていない。

デプロイを分散できてないから狭義のMicro Frontendsではない。Monorepoチュートリアル を見ても、Modular App Developmentのが近い。

ハイブリッドアプリについて

ハイブリッドアプリの試みは歴史的に見ると死屍累々ではあるんだけど*1 アプローチとしては枯れているので現場では結構使われている。

最近見かけた事例だとメルカリShopsがハイブリッドアプリ構成になっていた。

engineering.mercari.com

ハイブリッドアプリの目的

様々なモバイルアプリフレームワークの選択肢ある中、ネイティブ+Webのハイブリッドアプリにする目的としては以下がある。

ネイティブアプリファースト

技術的な制約によりすべてをWeb技術で作りたいわけではなくて、あくまでネイティブアプリが主軸にあって一部の画面をWebアプリケーション化することで開発コスト削減と保守性の向上がしたい。

このためネイティブ実装をする箇所とWebアプリケーションとして作る箇所を適切にコントロールできるのが好ましい。

オンラインアップデート

App Storeへのアップロードを通さずにアプリをアップデートすること。機能としてはover-the-air (OTA)対応と呼ぶこともある。

ハイブリッドアプリの場合、これはWebViewで読み込む先がインターネット上のURLなので自動で適用される。

しかし従来のIonic App, Cordva Appではアップデートはアプリのパッケージに含めるJavaScriptやHTMLを生成し直してアプリストアで再配布する必要がある*2。この場合OTAには対応していないがオプションはあるので後述する。

Ionic Portalの使い方

Getting Started Guide - Ionic Portals

ドキュメントがここにある。要約すると以下の流れになる

  1. 既存のiOS/AndroidアプリにIonicPortalsモジュールを組込む
  2. ネイティブアプリのリソースにIonicで構成したWebアプリケーションをバンドルしIonicPortalsから呼び出せるようにする
  3. ネイティブアプリの使いたい箇所でIonicPortalsからIonicアプリを呼び出して画面に表示する

この部分のソースコードは公開されていて内部的にはCAPBridgeViewControllerやCapacitorWebViewを活用している。

github.com

Ionic Portalでオンラインアップデート

Ionic Portalはそのままだとアプリに組込まれたローカルなWebViewで実行されるのでオンラインアップデートには対応していない。

オンラインアップデートを実現するためにはAppflowのLive Updatesという別の機能へ対応する必要がある。

ionic.io

Ionic Portalがどういう用途に向いていそうか

既存のネイティブアプリへの埋め込み

既にIonicでアプリを構成しているならそれをネイティブアプリに組込むのは簡単で、Ionicチームもそういう用途を想定していると思う。

https://github.com/ionic-team/portals-ecommerce-demoリポジトリでも一画面ごとに全部分割して個別のWebViewで描画するストーリーで開発してある。

Webアプリケーションから直接OSネイティブな機能を呼び出したいアプリ

Ionic PortalのコンテキストからはCapacitorプラグインが利用できるため。デバイスのカメラ機能や位置情報取得を呼び出すことができる。

ただ、OSネイティブな機能の呼び出しはハイブリッドアプリのネイティブ実装部分で行えばいいという方針ならIonicを経由する理由は薄い。

ハイブリッドアプリの課題

先のメルカリShopsの事例にあるようにハイブリッドアプリ構成時にはネイティブアプリのみだと必要なかった独自の工夫が必要になる。

サンドボックス

OSネイティブな機能の呼び出しをJavaScriptのようなバイナリの外のリソースから呼び出す仕組みを作る時に、不正な呼び出しを防いだり安全性を担保する必要があって、それができてないフレームワークApp Storeレビューによって弾かれるケースがあった。

メルカリShopsではWebアプリケーションのドメインとネイティブ実装のレイヤーでこれを対応して、オンラインアップデートを生かしたままネイティブ実装の処理をJavaScriptの関数でブリッジ呼び出し可能にしている。

Ionicやその基盤のCapacitorでの基本戦略ではローカルなWebViewに限定することでサンドボックス化が実現されている。これによってオンラインアップデートをする場合にAppflowのLive Updatesを組込む必要がある。

認証

ネイティブ実装と独立した複数のWebView間でログインしたユーザーのセッションを引き継ぐ必要がある。

メルカリShopsではメルカリ本体の認証APIを使って認証されCookieでセッションが継続される。

https://github.com/ionic-team/portals-ecommerce-demo ではネイティブ実装部分でSwiftやJavaで個別に実装して、それをIonicプラグイン化してWebアプリケーションからも参照するという方針が示されている。

この他にも公式ドキュメントでは必要になった呼び出し時にインジェクションするなどの例がある。いづれにせよハイブリッドアプリ特有の認証レイヤーが必要になってくる。

ionic.io

まとめ

  • Ionic Portalは複数のIonicアプリを既存のアプリに組込みやすくするもの
  • ハイブリッドアプリ技術はまだ発展の余地がある

*1: ハイブリッドアプリ駄目じゃん例としてよくあげられるニュース: Facebook:「HTML5に賭けたのは間違い」発言の技術的な理由と反応

*2: オンラインアップデートの障壁はReact NativeやExpoでも条件は同じ

2021年に作ったモノや技術をふりかえる

f:id:laiso:20211224210727j:plain

前回までのあらすじ:2020年に作ったソフトウェアや開発技術をふりかえる - laiso

Write Code Every Day

プログラマーの人にありがちな趣味だと思うんだけどWrite Code Every Day (John Resig - Write Code Every Day)を2008年ぐらいからやっていて、昼に仕事でコード書いて夜になったら自分の楽しみのために何か作るか〜というのを繰替えして生活してる。

John Resig の記事との違いは今読みながら比較していたんだけどGitHubに上げるっていう部分はやらなくなってしまった。クレデンシャルとかハードコードしてるやつとか半分他人のコードコピペしたやつとかの清書がめんどくさいというのがあるし、クローラーなどは自分だけが使うぶんにはいいけど公開した方が迷惑になる——みたいなジャンルのコードが結構あって段々省くようになってしまった。

作ったソフトウェアもポートフォリオとして収めてゆくゆくは個人開発で一発当てるぞ! という自意識を持っていたんだけど最近はとりあえず自分や知り合いだけが使えるプロトタイプをたくさん作ってすぐ捨てるという行動になってる。

便利なものを思い付いても実際に作ってみるまで便利か分からんから作りながら考えてるみたいな状態なので、まずは他人に使ってもらうためのエネルギーをかけずに作ること自体を目的にしだした。

YouTubeを観るやつ(Google Drive/Serverless Next.js Component etc)

コーディングってものづくりするクリエイターのイメージがあると思うんだけど、僕は「ブラウザとかアプリケーションを操作してウェブサービスを使う」という行動と同じ目的でスクリプト書いてサービスを使うっていうのをよくやってて、この時は「消費者としてプログラムをインターフェイスにしてコンテンツにアクセスしてるな」っていう気持ちでいる。

YouTubeTwitterを見るツールもその類で何個も作って使っていて、今年はYouTube関連のものを多く作った気がする。

チャンネルは個人とかグループとかが開設してて事務所に所属して出演者たちがプロデューサー兼監督兼編集兼なりを全部自分たちでやってるようなのを好んでる。芸能人やテレビ番組的に作られてるやつはあんまり観てない。VTuberやTuberやゲーマーがやってるストリーミング配信も多い。

ライブ配信はたいてい長時間に及んで全部観てられないので、多くの人は切り抜き動画っていうファンが善意で編集して複製してる動画が主流のようだった。ただ僕は複製しないでも見たいところだけ見られるツールがあればいいんじゃ? と思ったので、自分で作ることにした。

まずはYouTubeライブチャットリプレイコメントを取得して*1自分のGoogle Driveに保存しておくことで動画の任意の箇所を検索して再生できるようにした。これのフロントエンドにNext.jsを使った。

最初は Vercel でホストして動かしていたんだけど転送量などの無料プランの制限の限界が来たのでAWSに引越した。AWSにしたことで料金も月5ドル以下になった。

この過程で制限を越えたままVercelを使い続けるとアカウントのすべてのアプリケーションが HTTP 402 Payment Required を返すようになるというのを知った(Payment Requiredなのは来訪したユーザーじゃなくて管理者なのでは?という話もある)。刃牙の家っぽい。

「402 Payment Requiredやlaisoォ!!」 *2

ヘルプページによると一度402の刑になると30日間凍結されるらしいから待っていたんだけど、全然解除されなかったので反省文を2回ほど送ったところ今は解除してもらえた。

ちょうどAmplify Console がISRに対応したというニュースが来た頃で*3 Amplifyで組んでいたんだけどうまく動かなかったので、ソースコードを見に行って中身がServerless Next.js Componentであることが分かったので直接使うことにした。

直接使ったらうまく動かなかった部分も分かったのでついでに直してプルリクエストしたら取り込んでもらえた。ので以下を書いた。

デスクトップ版

ライブチャットリプレイの取得はChrome拡張でYouTube上に組込むバージョンや、オンブラウザで動いてElectron 経由でSQLite3に保存して全文検索かけるリアルタイムバージョンも作ってみたんだけどやはりデータ容量や検索速度を気にしなくていいぶんGoogle Driveを使い続けるのがよさそうだった。安いし。

でもこの時にVue3をいっしょに試した。Vue 3にする場合、コンポーネントライブラリの選択が曲者で、いろいろ探した末 Element Plus に落ち着いた。

Chrome拡張やElectronは数年ぶりに使ったんだけどどちらもIPCのAPIがこなれてて使いやすくなっていたので、また何か作りたい。

ギガッ

「独自ツール開発してYouTube動画観てる」というのを人と話してて、それを他の人でもできるようにするにはどうすればいいんだろう? と思って作ってみたのがこれ(新しめのチャンネルに対応してない)。ネタバラシすると「草」で検索して並び替えてるだけ。

そういえばVercelの無料枠を使いきったのはGIGAZINEで紹介されたせいだった。GIGAZINEゆるせねぇ・・

自然言語解析(Mecab/Gensim etc)

上記はgrep草ことAIなんですけど、チャットの投稿のメッセージには時間とテキストがあるのでテキストを解析したら再生時間 XX:XX 秒の特定の箇所に話題のメタデータを付けたりコメントの感情が変化したことを検知できるのでそれを使ってなんかできないかなーと思っていろいろ試していた。

基本戦略としては形態素解析でバラしてWord2vecで分類してっていうのとシンプルなネガポジ判定なんですけど、テキストが短か過ぎるのかあんまり予想どうりの結果にはならなかった。もうちょっと基礎知識があれば改善できるかもしれない。Gensimっていうライブラリをよく使った

NotionのページをFlutterアプリにするやつ(Server-Driven UI/Flutter)

AirbnbがGraphQLでネイティブアプリのコンポーネントを動的に組替えてるっていう記事に触発されて似たようなの作りたいと思って書いてたアプリ。

仕組みは簡単でNotion APIで接続したユーザーが共有したページとDatabaseのブロックデータを取ってこられるので、定義に従って用意されたFlutterアプリのコンポーネントで再生するというもの。

Notionのページ情報には他のページへのリンクも含まれるのでFlutterのNavigateをうまく使うと画面遷移も組替えることができる。宣言的UI万歳。

ただ

  • Notion APIがまだ対応してないパーツがある(カラム分けやRemarkや)
  • Authorizationがネイティブアプリで使いづらい

という諸問題もあり、完成できてない。

パーツは待っていれば対応されそうだけど、Authorizationは例えばユーザーが notion.so で権限を許可したら→中間サーバーにリダイレクトして→myapp://にまたリダイレクトして→アプリのメモリ内に存在するUUIDをチェックして——というフローがもうちょっとなんとかスマートに実装できないのかねと気になってる。

Flutterについては以下の本を副読本に買った

Riverpod

よくあるProviderを使ったコンポーネント間のデータ管理しか作ったことなかったんだけど、次世代のState-Managementフレームワークとして聞いていたRiverpodを導入してみた。結構前の記憶なので忘れちゃったけどReact HooksのプリミティブなAPI使っているようなイメージだった気がする。便利だった。

FlutterKaigi 2021 で知ったんだけど、Riverpodの代替としてGetXというパッケージを使っている人たちもいるらしく、そっちも気になってる。

従来型SPA代替技術(Hotwire/Livewire/Inertia.js)

ウェブアプリケーションフレームワーク界隈では最近はSPA代替技術の開発が盛り上っていてRails 7.0には標準でHotwireが使えるようになった。

Stradaはまだリリースされてなく。噂では来年になるらしい*4

SPA代替技術は先行するLaravelのLivewirePhoenixLiveViewASP.NETBlazorあたりとセットで「JavaScript以外で動的なUI書く」のを語られることが多い(flutter_webも入れていいかもしれない)。

JavaScript以外で書くと言っても多くの処理はクライアントサイドのJavaScriptライブラリのエンジンが肩代わりしていて、フレームワークのユーザー側に簡単なレールが提示されてそれに則ってUIを作るというスタイルが一般的になっている。

プログラミング言語の話に終始しがちだけど重要なのはAPIサーバー/クライアント/UIバインディングの定型的なコードをなくしてる点だと思った。その点でスキーマコードジェネレーター系も同カテゴリに入れていいのかもしれない。ReactやVueのコンポーネントをサーバーサイドのテンプレートファイルにすることを目指すInertiaも意欲的なので注目してる。

個人開発という点ではHotwireの筋の善し悪し以前にPostgreSQL/MySQLサーバーの維持コストが嵩みがちなのでRailsやLaravelの出番はあまりなかった。後述の新興DBaaS勢が今後目立ってくるようになったら試しに組合せて運用してみるかもしれない。

Twitter(俺だけ)便利ツール

YouTubeと同じくコンテンツ消費のためにプログラミングしてる例なんだけど、僕はTwitterが公式に用意してるフォローの機能を使わずにリストとか検索系のAPIを叩いて利用しているのでそれを今年も保守していた。

その過程で「検索結果を綺麗にするために大量にMuteする」っていう機能が必要で、"AWS"で検索すると特定の動物園情報が来訪客が含まれたり"GCP"で検索すると医療情報やメイド喫茶が出てきたりするのから自分の欲しいクラウド関連のニュース関連だけに絞るためにやってる。

しかしTwitterのMuteの挙動上「Muteしたけど検索結果に残るアカウントある」とか「usernameはそもそも無視したい」などの問題があったので自分のプログラム側でフィルター処理を作ることにした。これの構築にSvelteKitを使ってる

SvelteKit特有の機能たしいて使ってないんだけどVercelアカウントはバキの家にされちゃったのでNetlifyにデプロイして便利に使ってる。Twitterログインはちょっと癖があった

本当は難しいツイ消し

ツイート全部消すのはAPI制限上難しい=最大何件までしか遡れない。っていう問題を聞いて、じゃあ世の中のツイ消しサービスはどうやって実装してるんだろうと思って調べていた。

簡単に説明するとTwitterアーカイブダウンロード機能でエクスポートできるJSONファイルにidが載っているのでそれをユーザーにアップロードさせてパースすることで1つ1つ削除APIを叩く。という方法を実現しているようだった。

この処理はぱっと想像してみてもサーバーのリソースを結構食いそうで、みんな有料機能として提供していた。

有料サービスを使ってもいいんだけどGitHubtwitter-cleanerというGoで書かれたプログラムを公開している人がいてそれを実行するのが良さそうだった。便利賞なので数ドルsponsorで送った。

動作確認していたら自分のツイート全部消えたけどまぁいいか。的な

チャットの話題提供BOT(Cloud AutoML)

f:id:laiso:20211224212219p:plain

チャットにインターネットのおたく(この場合パソコン愛好家の意です)がリンクをシェアするとそれについて各自が話出すみたいな作法があるんですけど、だいたい情報源のサイトやTwitterなりが限られているし話している話題も偏ってるから、おたくが好きそうな話題を自動でシェアできるようにならない? って思ってBOTを作っていた。

Slackのログをエクスポートしてきてリンクを抜き出しトレーニングデータにする、機械学習でいい感じに機械が学習。情報源となるニュースサイトのリンク一覧と付き合わせてニュースサイトに更新がある度に「このリンクは%ぐらいお宅のおたくが好む」っていう数字を出してくれるので、閾値を上まわったらそれをBOTがチャットに投稿する。という流れで実装した。

このトレーニングとモデルのデプロイにCloud AutoMLを利用した。

CSV掃き出してAPIで自動化するだけなので超簡単にできるんだけど、トレーニングするために僕のクレカに5000円づつチャージされていて遠い目になってきたので停止してしまった。

BOTの動作環境はCloudflare WorkersとDeno Deployを比較してCloudflare Workersにした。

エッジで動くアプリケーション

余談だけど今はブラウザ向けのJSは軽くして重い処理はサーバー側のBFFの裏のNode.jsに任せるっていうのが一般的だけど、こういうフロントのサーバーがCDNの軽いランタイムで動くようになるとNode.jsで書いてた重い処理の全面にHTTPベース完結する軽い層が必要だなとRemixを使っていて思った。Micro Frontendsの将来かもしれない。

日英日翻訳

f:id:laiso:20211224212407p:plain

機械翻訳を重ねがけして精度を上げるみたいなライフハックが話題になっていて*5、たしかに確かにやったことあるなーと思ったものの毎回フォーム操作するのが面倒だなと思ったので1クリックでできるようにした。

これに早くからVue3に対応していたIonicを使った。レスポンシブデザインなUI何も考えずに作れて楽だと思う。Angularでずっと使っていたけど最近はReactやVueでも書ける。

Compose Multiplatform

JetBrainsがAndroidJetpack Composeのマテリアルコンポーネントをデスクトップやウェブにも適用できるCompose Multiplatformっていうフレームワークを公開していて注目してる

出てきた時は「Kotlin版Flutterだ!」と思ったんだけどソリューション的にはElectronとかJavaFXでアプリケーションを書く時の代替手段になりそうだった。

次世代IDE Fleet のフロントエンドをこれで作っているのでは? と予想しているんだけど、公開されている情報は見あたらない(中の人がKotlinとC++で書いてると言ってるのは見た)

Kotlin経由でReactコンポーネント書くサンプル がお気に入り

DBaaS(PlanetScale/Supabase)

Firebase以降の新興のDBaaSが色々出てきていてPlanetScaleとSupabaseを定期的にチェックしてる

PlanetScaleは個人開発者の文脈でいうとHeroku Postgres アドオンで格安でウェブアプリケーション動かしたかった人の選択肢として朗報だと思う。裏側にVitess クラスタがあって(たぶん)ユーザーとしてはネイティブのMySQLドライバーでORMからインターネット越しにアクセスできる。

Isomorphic JavaScript勢にも向いててLambdaでコネクションプーリングどうするのという問題もエンドポイントの向うで解決してくれていた

SupabaseはフロントエンジニアフレンドリーなSDKを提供するBaaSでそれがFirebaseとの差別化になっているようだ。

こちらもアジアリージョンにPostgreSQLサーバーを立ててくれてネイティブドライバでアクセスできる。クライアントサイドから使う時は基礎技術のPostgREST をベースにしたSDKを使ってDSLでアクセスし、認証認可もする。

このためフロントエンドがDB触るためにバックエンドAPI構築するっていう作業が省けるし、バックオフィスの管理画面は別途好きなウェブフレームワーク使うのとかできる(スキーマ管理がごちゃりそうだが……)。

コンポーネントが全部公開されててマイクロサービス思ち帰りセットになっているので、例えば自分のAWS環境にSupabaseと同じ環境を作ってDBはRDSにして使うってことができるのだと思う。

Ethereum

スマートコントラクトをデプロイしてWebアプリと連携して動かすっていう開発に再入門した。2018年ぐらいにもやっていたので開発環境自体は分っていたんだけど、色々こなれててフロントエンドエンジニアが触りやすく進化していた。

開発ツールはHardhatが使いやすかった。TypeScriptをサポートしていたりAPIクライアントにweb3.jsの代替としてethers.js を使っているのでドキュメントがあったりする。

ネットワークの入口となるノードサービスと開発プラットフォームはAlchemyを使うようにした。使ったことないけどクライアントサイドライブラリとかNFT便利API機能とか付加価値が付いてくるようだ。

ネットワークはなんとなくPolygonってやつ使ってる。理屈はよく分からんがwebpackとesbuildみたいな関係ではと解釈してる。

トークンにひもづくアセットはIPFSネットワーク上に置くのが通例らしい。Pinataをゲートウェイに使っている例が多かった。

Solidityを使ったアプリケーション開発は、翻訳なのでちょっとバージョンが古めだけど以下の本が良かった

ブロックチェーンを使って何かおもしろいものが作れそうかというとまだまだ知識が足りてないのでピンときてない。Web3ビジョナリストの言う利点は分かるけど、ユーザーとしての自分は特に求めてない、ぐらいの塩梅にある。ソフトウェア開発というより経済学とかの素養が必要なのか? と疑ってる。

でも今のところERCのプロポーザル見てるのが一番勉強になるかもしれない。

Solana

早い安いRustが書けるみたいな触れ込みで知って。Rustを書く理由を求めていたのでEthereumを一緒に入門した。Solidityなかなかいいなと最近思えてきたのであんあり動向をチェックしてない。

SQL

去年SQLを何回勉強しても分からないと書いたけど*6 実際に分からない=身についた感触がないのはデータベースを使ったプログラミング全般だと思ったので再入門した。

今年は以下2つの本を読んだら大分苦手意識が減った。

今まではORMのAPIレベルで思考していて、このAPIを使う時に発行されるSQLはこれで——という手順を踏んでいたけど実は逆で、SQLでもNoSQLでもクエリを基準に構造を考えることが重要だと思った。

  1. アプリケーションの機能に対してSELECT/INSERT/UPDATE/DELETEクエリを考える
  2. そのクエリがシンプルにできるテーブル設計を考える
  3. 考えたクエリをORMのAPIで再現する
  4. アプリケーションのプログラミング用に型付けする(DBの詳細は隠す)

というやり方に宗旨変えしたらうまく組めるようになった

MacBook Air(Apple M1)

一番安いMacBook Airを買った。

開発に使う場合、コンパイル速度とディスク容量が足りなくて困ってる。

とくに

がディスクを馬鹿食いしていて消したり入れたりして運用でカバーしてる。今ならProにしそう。

Xiaomi 11T Pro

iPhone 11 をずっと使っていたんだけどMNPを期にXiaomi 11T Proに機種変した。120W急速充電というので10分ぐらいで充電が完了するので、給電を習慣にしなくてよくなった。

まとめ

  • パソコンを使うこととコードを書くことが地続きの生活にある
  • WebのUI開発はもうひと段階の変化が起きそう
  • 良いお年を