WasmerのWinterJSのベンチマーク結果はあやしい

「WinterJS 1.0」の記事がシェアされていたので読んでいたのだけど「Bunより速くなった」と書かれていたので何事と思ってチェックしてみた

wasmer.io

ベンチマークの文書は以下に公開されている

github.com

で、まずエラーがめっちゃ出てる

Socket errors: connect 155, read 108, write 0, timeout 29

それはいいとして(よくないが)、肝心なところはJarred Sumnerも指摘しているけどwrk -t12 -c400でリクエストの並列処置性能を測っているというのに違和感がある

winterjsサーバーはhyper(tokio)で書かれていてリクエストごとにマルチスレッドでコアを使ってSpiderMonkeyでスクリプトを実行してる

シングルスレッドなBunで条件を近づけるならreusePortオプションをLinuxで使ってマルチプロセスでBun.serve()するか、Workers APIを使うとかやりようはありそう

bun.sh

なのでWinterJSのサーバー実装だけマルチスレッドなので並列処置性能が高い(それはそう)という結果だと思った

「Webサーバとして処理速度が速い」と言えば間違ってはいないんだろうけど'Blazing fast speeds than Bun...'から想像する内容とはギャップがある

ただ私の環境(M1 Macbook Pro)では並列パラメータをいくら調整してもBunの方が速かったのだけど……

そしてwrk -t1 -c1にすると4倍Bunの方が秒間リクエストが出ていた。これは直感どうり

# WinterJS
❯ cargo run --release -- --version
winterjs 0.4.3
❯ cargo run --release -- ./simple.js
❯ wrk -t1 -c1 http://127.0.0.1:8080
Running 10s test @ http://127.0.0.1:8080
  1 threads and 1 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    71.60us  212.70us   5.55ms   99.48%
    Req/Sec    16.67k     0.92k   19.30k    81.94%
  119422 requests in 10.03s, 13.67MB read
Requests/sec:  11910.93
Transfer/sec:      1.36MB
# Bun
❯ bun -v
1.0.31
❯ bun bun-simple.js
❯ wrk -t1 -c1 http://127.0.0.1:8080
Running 10s test @ http://127.0.0.1:8080
  1 threads and 1 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    24.30us   49.42us   2.73ms   98.13%
    Req/Sec    47.46k     2.00k   50.59k    85.15%
  476904 requests in 10.10s, 54.58MB read
Requests/sec:  47221.50
Transfer/sec:      5.40MB

とはいえWinterJSのようなソフトウェアを作ってしまえるWasmerの人たちはすごいと思う

ただWasmer EdgeはWasmをデプロイするサービスだし、なぜかWinterJS自体をWasmにして動かそうとしていて、これを作った理由が謎だけど

Tips: ビルドエラーの解決

pythonバイナリのバージョンでwinterjsのビルドが失敗する時は以下で指定できる

❯ PYTHON3=/usr/bin/python3 cargo build -r

lldがないとビルドできない

❯ brew install llvm
❯ brew link -f llvm
❯ which lld
/opt/homebrew/opt/llvm/bin/lld

追記

シングルスレッドなBunで条件を近づけるならreusePortオプションをLinuxで使ってマルチプロセスでBun.serve()するか

やりました

zenn.dev

最近使ってる便利シェル関数: gh copilot suggest -t shell

「iOSシミュレータを起動するコマンドがあったんだけど忘れた」というような状況で便利

copilot() {
    gh copilot suggest -t shell "$@"
}

alias c="copilot"

忘れたのでコマンド履歴から検索してくることもままならない。そんな時はこう

❯ c launch ios sim

Welcome to GitHub Copilot in the CLI!
version 0.5.3-beta (2023-11-09)

I'm powered by AI, so surprises and mistakes are possible. Make sure to verify any generated code or suggestions, and share feedback so that we can learn and improve.

Suggestion:

  open -a Simulator

? Select an option  [Use arrows to move, type to filter]
> Copy command to clipboard
  Explain command
  Revise command
  Rate response
  Exit

Copy command to clipboardして実行する

gh copilotはGitHubが提供しているCLI

docs.github.com

難点としては結構間違ったことも言う。だが、ゆるしてやってくれ

Sallybox Plus をゆずってもらった

Sallyboxはレバーレスコントローラーで、Plusは15ボタンのやつ

front

キーボードでスト6やってると書いていたら、世界の@k_katsumiさんがくれた

PCキーボードの半分ぐらいの幅で第一印象はちっちゃと思ったけど慣れた

普段分割風キーボードを使っているので*1、左手と右手が近くて狭く感じだけどそれも慣れた

弁当箱みたいなサイズ感にRaspberry Piの基盤みたいなやつが入っててボタンはキーボード軸

back

Hit Box の幅は 406.4 mmなので半分程度のサイズだけどHit Boxは触ったことないから比較できない

モダンの時のボタン設定。「プロゲーマーがキーボードでランクマッチしてみた【マゴ】」をキーボードに設定していたのを移行した

クラシック。右手親指に投げがあると押しやすい気がする。「同時押しボタンを絶対に設定すべき理由- シノビチャンネル」によると投げボタンがあった方が便利らしい

キーボードで真空波動とか出せる気がしなかったのでモダンしか使ってなかったけどこのコントローラーならいけそうだったのでクラシックに切り換えようと思ってる

東京都同情塔:テキスト生成AIブームにふさわしい芥川賞受賞作

『東京都同情塔』は第170回芥川賞受賞作品で、「ChatGPTを駆使して書かれた」と話題になっていてたので気になって読みました。

この記事はあらすじに含まれないストーリーについて言及しています。

あらすじ

日本人の欺瞞をユーモラスに描いた現代版「バベルの塔」 ザハの国立競技場が完成し、寛容論が浸透したもう一つの日本で、新しい刑務所「シンパシータワートーキョー」が建てられることに。犯罪者に寛容になれない建築家・牧名は、仕事と信条の乖離に苦悩しながらパワフルに未来を追求する。ゆるふわな言葉と、実のない正義の関係を豊かなフロウで暴く、生成AI時代の預言の書

感想

メディアでは権威ある文学賞までもAIにハックされたと技術の発展を煽るような論調でしたが、私の印象では「文学界までAIブームに乗ってきた」というものでした。

作中の世界の重要なこととして対話型AIに人々が重度に依存しているのですが、その部分にはあまり宣伝で触れられていません

私も「生成AI時代の預言の書」という部分にまんまと釣られたということです

物語は2026年の架空の東京都を舞台にしていていわゆるパラレルワールドになっています。

実際のザハ・ハディドの国立競技場の初期案は、最終的には採用されませんでした。

巨大建築の建設は覆るのは不可能なので、この世界は訪ずれることのありえない現実というのを表わしていると感じます

作中には新型コロナに関する具体的な記述はないものの、パンデミック自体は起こっていて、さらにこの世界では東京オリピックは延期せず強行されたことになっています

この実際の歴史との誤差が結構絶妙で、私が掘り下げたい部分です

まず文章(テキスト)生成AIという用語を使っていなく「文章構築AI」と一貫しているのは意図的だと思います

新たな作品を生成しているのではなく既存の価値観を他者を傷つけないよう中立的に組み立て、構築している。という表現と建築のメタファーだと思いました

朝日新聞デジタルの取材記事にもこの設定の背景が出てきます(有料記事なので中身には触れません)

全体的にAIの構築する文章に社会が依存しつつもそれを好ましく思ってないような記述が多いです

作中で「AIネイティブな世代」の青年として描かれている人物はAI使って文章を書くことを批判的に捉えています

彼女の積み上げる言葉が何かに似ているような気がして記憶を辿ると、それがAIの構築する文章であることに思い当たった。いかにも世の中の人々の平均的な望みを集約させた、かつ批判を最小限に留める模範的回答。平和。平等。尊厳。尊重。共感。共生。質問したそばからスクロールを促してくるせっかちな文字が脳裏に浮かぶ。彼らがポジティヴで貧乏な言葉をまくし立てる様を一度イメージしてしまうと、いくら彼女の声がしていても、すべてがAI-builtの言葉としてしか聞こえなくなった。そしてなぜか僕は、文章構築AIに対しての憐みのようなものを覚えていた。かわいそうだ、と思っていた。他人の言葉を継ぎ接ぎしてつくる文章が何を意味し、誰に伝わっているかも知らないまま、お仕着せの文字をひたすら並べ続けなければいけない人生というのは、とても空虚で苦しいものなんじゃないかと同情したのだ。けれどもちろんAIには、苦しみも喜びも人生もなく、傷付くこともないのだから、別に意味のない同情だ。人間だからといって誰しもが難なく言葉を扱えるというのでもないけれど、少なくとも人間は喋りたくないときには黙ることができる。

なので犯罪者の身の上に共感して新宿御苑側のタワーマンション機能を持つ刑務所で手厚く保護する先鋭化した「訪ずれない世界」で文章構築AIが支配的な影響を持つことで逆説的に現在の未来はそうならないことを望んでいるように思います

以下は著者の会見の発言です

この作品は、言葉で何かを解決しよう、言葉で対話をするということを、あきらめたくないと思っている方のために書いた作品と思っています。言葉で解決できないことというのは、何によっても絶対に解決できないと私自身は考えております。

「言葉による解決、あきらめたくない」芥川賞の九段理江さん会見 - 産経ニュース

builder.ioでのLLMを使ったサービス開発の実際

builder.ioのSteve Sewell(CEO)が書いた「まだChat Completions APIで消耗してるの?」というトーンの記事を読んだ

builder.ioはQwikの開発元で知られるCMS SaaS(Qwikの話は出てこない)

www.builder.io

www.builder.io

記事はVisual CopilotというFigmaのデザインをReactコンポーネント等のコードに変換する機能の裏側について解説している

「FigmaをReactコンポーネントに変換!」だけだとプロ驚き屋アカウントに消費されて右から左に流れていきそうなニュースバリューだけど、昨今のLLMs App開発についての実践的なアーキテクチャの話とopinionatedなことが書かれているのが面白かったので紹介します

この2つの記事で言いたいことは「ChatGPTというハンマーが万能過ぎてすべてが釘に見えるけど、それぞれのタスクを分解して個別に解決した方が効率的」ということだと思う

ディープラーニング全盛(バズワードとして)の時にコンサルが「ディープラーニング以外で解決しましょう」と提案してもエグゼクティブにはあんまりウケないという状況のように、この記事も思ったほど話題になっていなかった(Hacker Newsには一応コメントが多数ある)

複数のLLMを連携させてAgentを作るという話題は活発だけど、実際にLLMを活用して現実のプロダクトにどうやって適用しているのかという部分に注目した

アーキテクチャ

Visual CopilotはFigmaからJSXなコンポーネントに変換するのに以下のパイプラインを辿る

https://www.builder.io/blog/train-ai

Identify imagesはデザイン上の画像を認識し、Build layout hierarchyはHTMLの構造解析、Apply stylesはCSSのスタイル情報、Turn to (basic) codeは内部コード表現(Mitosis?)の生成、Customize codeはそれをReactやSvelte形式に変換することだと思う

このうちIdentify imagesとBuild layout hierarchyをGoogle CloudのVertex AIで実装して、Apply stylesとTurn to (basic) codeはコードでロジック書いて、Customize codeは既存のLLMをファインチューニングして使っているらしい(時期的にgpt-3.5-turbo?)

またデータセットの運用が重要という話が出てくる。Visual Copilotでは人間が変換結果を確認してフィードバックして精度を高めていったらしい

記事の結論としては

  1. 最初に既存のLLM(例えばGPT-3やGPT-4)を使用してみる
  2. コストやカスタマイズ性の問題がある場合は、独自のモデルをトレーニングする
  3. データセットの運用で品質を上げる
  4. コードで実装できる個所は書く

という方法が推奨されている

Visual Copilotでは最後の工程のみをLLMで行い、その事前処理は従来の機械学習モデルと変換コードで実装された

感想パート

「Apply stylesとTurn to (basic) code」の変換処理実装するのEasyじゃねぇ・・ と思いつつも、それぞれを比較してこの人たちの能力から見ればそうなのでしょう

一見ChatGPT以前もそう作っていたのでは? と思うかもしれないけどGPTが汎用的に賢いので肝であるデータセットの自動生成のタスクにも役立つという環境の違いはあると思う

冷静に考えるとVertex AI便利話に読めるけど、この頃はGPTのVision APIも公開されていなかったので現在なら物体検知のプロトタイプを作るのは更に捗るのかもしれない

コストについては自前した方がOpenAIより優位だとは思うけどVertex AIを使っているのでそことの比較になってくるのでは…… と思った

コードで実装したぶんがLLM使わなかったので削減されたと解釈するべきか

Vertex AIは個人的に趣味でデプロイして使っていたことあるんですけど一晩のトレーニングで諭吉sが吹っ飛んだ経験があるので、あまりインディーデベロッパーの用途に優しい印象はない

安く使う方法があるのか代替手段があるのか是非読者にご教示いただきたい

今はGPUを買って自宅サーバーでやろうとしている

更新されたら真っ先に聴いているおすすめポッドキャスト

ポッドキャストはリスナーの存在が見えづらいらしく聴いてるとアピールしないと更新停止してしまいがちなので定期的に感想を書いていく

聴く環境について

クライアントはGoogle Podcastを使っているんですけど終了してしまうし*1最近はSpotifyに誘導されがちなので、今後移行先をどうしようか迷っている

そもそもGoogle Podcastの購読一覧ってどこから見るんだろうと疑問だったが、https://takeout.google.com/からエクスポートしてくれやということらしい

ポッドキャストの探し方

Google Podcastはエピソード単位の検索に優れていて、それが愛用している理由だった(やめないで)

たとえばGoogle Podcasts - rustはで検索すると日本語でRustについて話してそうなポッドキャストが見つかる

あとはPodcast Freaksという地道にテック系のポッドキャストを収集して公開しているページがあるので、そこから見つけたポッドキャストも多い

はてなユーザーにはお馴染の近藤さんがやってるLISTENもある

専用のポッドキャストクライアントアプリが必要なプラットフォームはカバーできてない

BUSINESS WARS / ビジネスウォーズ

BUSINESS WARSはいわゆるプロのラジオドラマ制作会社が作っているコンテンツで、アメリカの現Amazon子会社の本番組*2をニッポン放送が権利を持って翻訳して配信しているようだ

art19.com

内容はトヨタ vs ホンダ、任天堂 vs ソニーなどの「企業VS企業」の争いを物語調に演出して、1時間x全5回程度のボリュームの連続ラジオドラマにしている

仮想通貨戦争回ではサトシナカモトがデスゲーム主催者よろしく合成音声でしゃべっててウケた(ラジオなのでしゃべらないと表現できない)

News Connect あなたと経済をつなぐ5分間 #ニュースコネクト

podcasters.spotify.com

News Connectはいわゆる時事ニュースのポッドキャスト

日刊配信との週まとめ回とゲスト特別回がある

ホストの野村さんは箕輪厚介さんとNewsPicks本のレーベルを立ち上げた人、というのをこの前知った*3

週まとめ回に出てくる塩野さんという人はググると ライブドア—— とサジェストされるぐらいこの業界では有名な人で、色んな分野に見識が深く、シンプルに話がうまい

あと音楽に詳しい。YouTubeにファンが作ったDJ塩野というプレイリストが存在する

Off Topic // オフトピック

Off Topic // オフトピック

Off Topic // オフトピック

  • Off Topic
  • テクノロジー
  • ¥0
podcasts.apple.com

Off Topicは米国のテック業界のことを毎回ストリーラインを作って話してくれる番組

ホストの草野さんと宮武さんのプロフィールはよく存じあげていないのだけど毎回入念に準備して話を作り込んでて感心する

fukabori.fm

art19.com

fukabori.fm は毎回技術的なテーマを決めてその分野に詳しいゲストを呼んで深堀りしていく番組

冷静に考えるとどんな分野のゲストが来ても深堀りできるホストのiwashiさんがすごくない?

NTT Comの中の人が登場すると環境が特殊なのでやたら濃い話をして帰ってゆく・・

バンクーバーのえんじに屋

art19.com

バンクーバーの日本人コミュニティの人達が出てくるポッドキャスト。週1で配信されてる

ブログ界隈的にはバンクーバーのうぇぶ屋の人がやってる

日本とカナダ(含む北米)ではIT業界にはこういう違いがあるよね、とかキャリア系の話が多い

日本人エンジニアは海外に進出せよとか渡米して給料N倍とかの絶妙な古参ブロガーらしい発信テクニックでよく界隈でバズってる

texta.fm

texta.fm

texta.fm

  • Design and Engineering team at PIXTA
  • テクノロジー
  • ¥0
podcasts.apple.com

ピクスタという会社のポッドキャスト

おそらく技術顧問のt_wadaさんと壁打ちしてたらこれ公開してよくない? ってなったやつ

このブログの読者なら絶対好きそうなソフトウェアアーキテクチャの話が多いのでお勧めした

プログラム雑談

podcasters.spotify.com

プログラム雑談は週1で更新されるkarino2さんの一人しゃべりなポッドキャスト

同じくここのブログ読者は好きそうなのでおすすめした

内容はプログラミングそのものに関する話題やFIREやなろう系小説の話とか

一周回ったシニアなプログラマー向けの番組かと思いきや、感想をみると若者も結構聴いているらしい。人徳のなせる業か

Misreading Chat

misreading.chat

Misreading ChatはMorritaさんとMukaiさんが交互に読んできたコンピューターサイエンスの論文を解説するポッドキャスト

そもそも周りにコンピューターサイエンスの論文を日常的に読んでる人がいないので希少な情報源になってる

分野によっては全然言ってること分からないんだけど2人が理解してるのでなぜか聴いてるだけで自尊心の高まりを感じる・・

mozaic.fm

mozaic.fm

mozaic.fmは次世代Webについて語るためのポッドキャスト

フロントエンド属性のエンジニアにおすすめ

月1でEcosystem回とPlatform回に分かれていてだいたいめっちゃエピードが長い

Ecosystem回ではフロントエンドまわりのニュースをキャッチアップして参加者で議論していく

Platform回は各ブラウザーベンダーのアップデート全部見るというマニア向けなコンテンツをしている

kkeethのエンジニア雑談チャンネル

art19.com

以前はkkeethさんが朝活と称してYouTubeかどこかで配信したトークを撮って出ししているポッドキャストだった

今は形態が変わっているようだが詳しくは理解していない

フロントエンド系のネタとHR系の話が多い

更新頻度x継続が鬼なのでよく目につくようになり定着した

購読一覧

以下はエクスポートした一覧のOPMLをCSVに変換したものです。ただのリストなので折り畳み表示にします

ザッピングしながら感想を書いたので息切れしてしまって紹介できなかったおすすめポッドキャストが残っているんだけど、また別の機会に書かせてください

購読一覧
#strobofm,https://strobo.fm/index.xml
10X.fm,https://anchor.fm/s/559fd878/podcast/rss
ajitofm,https://ajito.fm/index.xml
Algolia Podcast,https://algolia.fm/feed.xml
Autify Japan Podcast,https://anchor.fm/s/154fc620/podcast/rss
Background.radio,https://anchor.fm/s/4a05f894/podcast/rss
Backyard Hatena,https://anchor.fm/s/7aad9de4/podcast/rss
Burning cast,https://anchor.fm/s/22818cac/podcast/rss
BUSINESS WARS / ビジネスウォーズ,https://rss.art19.com/business-wars-jp
CEREAL TALK / シリアルトーク,https://anchor.fm/s/4f8170dc/podcast/rss
Cryptic,https://feeds.castos.com/020p2
dely Tech Talk,https://anchor.fm/s/6924abf8/podcast/rss
devchat.fm,https://anchor.fm/s/3b652dc8/podcast/rss
DroidKaigi.fm,https://fm.droidkaigi.jp/feed.xml
e34,https://e34.fm/rss.xml
EM . FM #EMFM - Spotify for Podcasters,https://anchor.fm/s/70a2c40/podcast/rss
engineer meeting podcast,https://feeds.soundcloud.com/users/soundcloud:users:117239062/sounds.rss
few-shot.fm,https://anchor.fm/s/e69c9d70/podcast/rss
FREE AGENDA by hikaru & yamotty,https://anchor.fm/s/147f7150/podcast/rss
fukabori.fm,https://rss.art19.com/fukabori
FUNTERACTIVE Radio,https://anchor.fm/s/55a83bbc/podcast/rss
furoshiki.fm,https://anchor.fm/s/50bf64f4/podcast/rss
Future Tech Cast,https://anchor.fm/s/2890e980/podcast/rss
Good to Great(グッドトゥーグレート),https://anchor.fm/s/11decd38/podcast/rss
Greenに書けない転職ウラ話ラジオ,https://anchor.fm/s/4c3bd64c/podcast/rss
h173.club,https://anchor.fm/s/9d93c798/podcast/rss
HashHub Podcast,https://stand.fm/rss/620ca7e1eb302d8b48e6c6e5
hikifune.fm,https://anchor.fm/s/8d50d4c/podcast/rss
jamming.fm,http://feeds.soundcloud.com/users/soundcloud:users:588841827/sounds.rss
kkeethのエンジニア雑談チャンネル,https://rss.art19.com/kkeethengineers
LayerX NOW!,https://anchor.fm/s/55a49944/podcast/rss
Learning cast,https://anchor.fm/s/79bb6d8/podcast/rss
LFK mobile DevPods,https://lfk-devpods.linecorp.com/feed.atom
LISTEN NEWS,https://listen.style/p/listennews/rss
London Tech Talk,https://anchor.fm/s/d904331c/podcast/rss
Metaverse FM - メタバース/VR/ブロックチェーンについて、現役エンジニアが語ります,https://anchor.fm/s/7dbecd50/podcast/rss
Middle Aged Developers,https://anchor.fm/s/6cb3ad28/podcast/rss
Misreading Chat,https://misreading.chat/category/episodes/feed/
MOSH.fm🌞,https://anchor.fm/s/66006700/podcast/rss
mozaic.fm,https://feed.mozaic.fm/
Muddy Web Podcast,https://anchor.fm/s/c9c3bf44/podcast/rss
NDS FM,https://nagaokadevelopersstudy.github.io/ndsfm/feed.xml
News Connect ~あなたと経済をつなぐ5分間~,https://anchor.fm/s/81fb5eec/podcast/rss
nextstep.fm,https://feeds.soundcloud.com/users/soundcloud:users:281879883/sounds.rss
normalize.fm,https://anchor.fm/s/67a9c1a0/podcast/rss
note Tech Talk,https://anchor.fm/s/622bef64/podcast/rss
Nstockのラジオ,https://anchor.fm/s/99b01140/podcast/rss
Off Topic // オフトピック,https://anchor.fm/s/7369a14/podcast/rss
Ossan.fm,https://ossan.fm/feed.xml
PHPの現場,https://php-genba.shin1x1.com/rss
PMラジオ,https://anchor.fm/s/600aa478/podcast/rss
Pod de Engineer,https://anchor.fm/s/12948d58/podcast/rss
Podcast by Genesia.,https://anchor.fm/s/5ca1f318/podcast/rss
PositiviTea,https://positivitea-secrets.us/feed/
PROTOTYPE.FM,https://feeds.acast.com/public/shows/6483f08d4f789000115c9159
Rebuild.fm,https://feeds.rebuild.fm/rebuildfm
rehash.fm,https://feeds.podcastics.com/podcastics/podcasts/rss/5199_2a7b208397764ef47f4ce403a9bbc9b0.rss
rel.ax,https://anchor.fm/s/e644aa34/podcast/rss
render(fm),https://rss.art19.com/render-fm
resize.fm,https://anchor.fm/s/416f2048/podcast/rss
Sansan Tech Podcast,https://feeds.soundcloud.com/users/soundcloud:users:554143311/sounds.rss
SBCast.,https://sbc.yokohama/feed/podcast
Shinagawa Agile Talks #shinagile,https://anchor.fm/s/9b465dc/podcast/rss
SmartBank.FM,https://anchor.fm/s/8ae8599c/podcast/rss
START/FM,https://anchor.fm/s/4ac8c9a0/podcast/rss
Startup Chat,https://anchor.fm/s/242a0e80/podcast/rss
STILL RENDERING // スティレン,https://anchor.fm/s/40a74b4/podcast/rss
Studyplus Engineering Podcast,https://anchor.fm/s/60d040c0/podcast/rss
systemand.online,https://systemand.online/feed.xml
Tech-Talk with SRG,https://anchor.fm/s/e535de60/podcast/rss
terapyon channel,https://anchor.fm/s/14480e04/podcast/rss
texta.fm,https://anchor.fm/s/330a9488/podcast/rss
The Perfect Introvert,https://api.substack.com/feed/podcast/623637.rss
Today I Learned,https://anchor.fm/s/367f0040/podcast/rss
ToraLab.fm,https://anchor.fm/s/46d5ea08/podcast/rss
Trivial Solution,https://anchor.fm/s/6bda154/podcast/rss
UIT INSIDE,https://uit-inside.linecorp.com/feed.atom
Unlearn.fm,https://anchor.fm/s/6d3f5ee0/podcast/rss
w2o.fm,https://w2o.fm/feed.xml
Wantedly Engineering Podcast,https://anchor.fm/s/64205bfc/podcast/rss
web3FM,https://anchor.fm/s/5d5ba88/podcast/rss
XCrossing,https://feeds.zencastr.com/f/wQGcVPNH.rss
yancan.fm,https://www.yancan.tech/feed.xml
Yarukinai.fm,https://yarukinai.fm/feed.xml
yatteiki.fm,https://yatteiki.fm/feed.xml
Yokohama North AM,https://anchor.fm/s/1e60bd50/podcast/rss
yome.fm,https://yomefm.github.io/feed.xml
yskoht/podcast,https://yskoht.github.io/podcast/feed.xml
Zero Topic - ゼロトピック -,https://anchor.fm/s/1617b040/podcast/rss
アクシオンポッドキャスト,https://anchor.fm/s/15ccae4c/podcast/rss
あたらしい経済ニュース(幻冬舎のブロックチェーン・仮想通貨ニュース),https://feeds.soundcloud.com/users/soundcloud:users:459848829/sounds.rss
エンジニアと人生,https://rss.art19.com/shu223
エンジニアリングマネージャーの問題集,https://rss.art19.com/engineermanager
お元気ですか.fm,https://anchor.fm/s/65c3f018/podcast/rss
カミナシSaaS FM,https://anchor.fm/s/5ca4aa04/podcast/rss
きのこるエフエム,https://anchor.fm/s/a7f362c/podcast/rss
キマグレエフエム,https://anchor.fm/s/31978840/podcast/rss
ゲーマーの流儀 / アール,https://feeds.transistor.fm/3cd107cc-0c4a-468d-83fb-d20addd9a756
ココナッツテック fm.Coconuts.tech,https://anchor.fm/s/4881bfd0/podcast/rss
サブスクライバ,https://anchor.fm/s/84e2304/podcast/rss
しがないラジオ,https://feeds.soundcloud.com/users/soundcloud:users:294673416/sounds.rss
スタートアップオフレコ対談,https://stand.fm/rss/64c240bed4e2cbde26c179a1
タメ口.fm,https://anchor.fm/s/e654577c/podcast/rss
ツナギメエフエム,https://anchor.fm/s/8426c10c/podcast/rss
てくてくFM - わからないが少しわかるラジオ,https://anchor.fm/s/732ccd60/podcast/rss
てくてくラジオ,https://anchor.fm/s/6df56fdc/podcast/rss
ハラケンタのグローバル漫遊記 / 「シリコンバレーエンジニア ✕ グローバル ✕ プロフェッショナル」,https://anchor.fm/s/58a458a0/podcast/rss
バンクーバー ぼんやログ,https://listen.style/p/van-bonyari/rss
バンクーバーのえんじに屋,https://rss.art19.com/vancouverengineers
ひまじんプログラマーの週末エンジニアリングレッスン,https://rss.art19.com/07ef6b45-d4fc-4d94-b211-e02a27b7e2a6
プログラム雑談,https://anchor.fm/s/68ce140/podcast/rss
プロダクトマネージャーのキャリアラジオ,https://anchor.fm/s/85c0f398/podcast/rss
プロレポラジオ ~エンジニア採用や組織に関する課題解決を目指します~,https://anchor.fm/s/e87cda10/podcast/rss
ほっとテック,https://anchor.fm/s/86693634/podcast/rss
マンガのラジオ,https://www.omnycontent.com/d/playlist/67122501-9b17-4d77-84bd-a93d00dc791e/57423c3f-266b-4d1f-ab2c-ad050070c990/48f314b3-2398-4d47-b87f-ad0500718022/podcast.rss
ゆとりっ娘たちのたわごと,https://anchor.fm/s/6e491dbc/podcast/rss
ゆるコンピュータ科学ラジオ,https://anchor.fm/s/7cd923f4/podcast/rss
ゆるテク,https://anchor.fm/s/adf8dcb8/podcast/rss
ゆるふわPodcast,https://rss.art19.com/f414b397-96fb-42c5-aa9d-04baa2cde5ac
ゆる言語学ラジオ,https://radio.ken-horimoto.com/feed/podcast/
よわよわえふえむ,https://anchor.fm/s/4feefc9c/podcast/rss
りっちゃ・りょかちのやいやいラジオ,https://anchor.fm/s/599cf528/podcast/rss
人生fm,https://kirimin.github.io/jinseifm/feed.xml
今出川FM by Nota,https://anchor.fm/s/8de09a9c/podcast/rss
前田ヒロ,https://hiromaeda.com/feed/
名無しさんのポッドキャスト,https://feeds.buzzsprout.com/1154831.rss
完全理解.FM,https://anchor.fm/s/a3630c38/podcast/rss
楽しいラジオ「ドングリFM」,https://feeds.soundcloud.com/users/soundcloud:users:170031062/sounds.rss
歴史を面白く学ぶコテンラジオ (COTEN RADIO),https://anchor.fm/s/8c2088c/podcast/rss
海外スタートアップレポート「シリコンバレーによろしく リターンズ 」,https://anchor.fm/s/29b92318/podcast/rss
火曜日のおフロ,https://anchor.fm/s/2b3dd74c/podcast/rss
白金鉱業.FM,https://shirokane-kougyou.fm/feed.xml
科学のラジオ ~Radio Scientia~,https://omny.fm/shows/kagaku/playlists/podcast.rss
覇権FM,https://anchor.fm/s/93c815ac/podcast/rss
言語化.fm,https://anchor.fm/s/8239c4c0/podcast/rss
論より動くもの.fm,https://anchor.fm/s/927f758c/podcast/rss
近藤淳也のアンノウンラジオ,https://anchor.fm/s/ab502c78/podcast/rss
銀の弾丸ラジオ,https://anchor.fm/s/13df46f8/podcast/rss
    

これを作るためのPythonスクリプト

import xml.etree.ElementTree as ET
import csv
import os

tree = ET.parse(os.path.expanduser('~/Downloads/Takeout/Google Podcasts/Subscriptions/Subscriptions.opml'))
root = tree.getroot()

# CSVファイルを開く
with open('output.csv', 'w', newline='', encoding='utf-8') as csvfile:
    writer = csv.writer(csvfile)
    # ヘッダーを書き込む
    writer.writerow(['text', 'xmlUrl'])

    # XMLのデータを反復処理する
    for outline in root.findall('.//outline[@type="rss"]'):
        text = outline.get('text')
        xmlUrl = outline.get('xmlUrl')
        writer.writerow([text, xmlUrl])

むしろOPMLファイルをそのまま張っておく https://github.com/laiso/laiso/files/13803644/Subscriptions.opml.csv

2023年に書いたコード

「2023年のふりかえり」ではPythonやJavaScriptのコーディングの話ばかり出てくるけど、これって今年全体から見ると1割以下だなぁと思ったのでGitHubのメトリクスを見ながら振り返ることにした

laiso.hatenablog.com

言語ごとのコミット数

vn7n24fzkq/github-profile-summary-cardsというのが生成してくれたグラフ

profile-summary-card-output

Python はデータ分析サーバーをFastAPIで書いてるのでその分と、Swiftは記憶にない

他の大部分はLaravel を使った複数のプロジェクトになる

PHPの話

PHPの仕事が欲しいわけではないのであんまりPHP書ける人ブランディングをしてこなかったけど9割はPHPやテンプレートHTMLを粛々と書いてると思う

レガシー管理画面アーキテクチャなのでReactやVueどころかjQueryでフロントエンドの処理書くこともない

ただLaravelやPHPに存在する機能を積極的に使おうとはしていて常にlatestなバージョンに追従している

PHP8はmatch構文が他言語みたいに書けて面白くて、enumも外部ライブラリなしで導入できる

Type declarationsはボーイスカウトルールで立ち入った区画を整備して帰っていく方針で付けてる

型の不一致はテスト時にTypeError吐いてくれることもあれば、PHPStormがコーディング時に教えてくれる時もある

Laravelの話

Laravelの諸機能は自作のオニオンアーキテクチャみたいなものを定義しなくてもある程度レールに乗っていくだけでバリデーションと権限管理をコントローラーから分離してくれたり、Active RecordでDBとモデルを分離したり、DIコンテナで実行時に実装を差し替えられたり、などの知られたデザインパターンを適用していってくれて、僕のような片手間PHPerに都合がいい

お気に入りはEventsのオブザーバーパタンで、1対多関係の非同期処理への派生が作りやすい

laravel.com

処理を追うのに知識がいるトレードオフがあるけど全部手続き処理を書くより単純になるなら使う、ぐらいのバランスで採用してる

Laravelの標準機能ならなんでも良いのかといえば、そういうわけでもなくEloquentのAPI Resource(Railsのjbuilderみたいなやつ)などは ネストの奥の方で愚直にJSONシリアライズループしてN+1な手続きを発生させて遅くなっていることがプロファイラみてると発見できるので普通の手で書いたforループで置き換えたりしてる

開発手法の話

普段の機能実装のフローとしてはいきなりDB設計とかテストコードとかを書き始めるわけなくて、最初は単一ファイルにトランザクションスクリプト(ビジネスロジックをベタ書きしたもの)を書きはじめる

Railsだとrails runnerがあるけどLaravelだとないので、make:commandで適当なエントリーポイントを作って、そこに機能開発に必要な画面の裏側の処理だけ先に作る

この時点ではテストファーストもしてないしUIの実装も全く手をつけていない

コーディングで設計の作業をしているイメージ

以前はテストケース内でこれをやっていたが設計が定まらないとテストコードの設計も決まらないのでこうなった

全体の手順としてはビジネスロジック→DB設計→モデル→ビュー→コントローラーの順

  1. Commandで実行可能なトランザクションスクリプトを作成
    1. これによってデバッガを使いながらコーディングができる。Webアプリケーションの中に書き始めると手動操作が発生してしまうがスクリプトではじめるとショートカットキーで実行できるのでイテレーションサイクルが早められる
  2. DBに変更が必要ならこの時点でmigrationを追加
    1. (1)でユースケースを先に書いてるのでスキーマをそれにあわせて発行したいSQL文からtableをつくる
  3. DB入出力を完成させる。これでDB設計→モデルまで一旦終ったことになる
  4. このデータをモデルとして、(1)で書いたコードをコントローラーに持ってきて、画面に表示するビューのUI部分を作る
    1. 場合によってはこの段階でプロトタイプにしてUXレビューにまわす(抽象的な仕様だと手戻りがだいたい発生する)
    2. ビューを定義した時点で新たな事実が分かって前提が変わるので(2)をやりなおしたりする。マージ後に手戻りさせるとマイグレーションが2つになってしまうけどこの段階ならまとめられる
  5. 次にビュー→コントローラーのフェーズに移る。(1)で書いたコードをパラメータと関数に分離してパラメータはリクエストから入力+バリデーションするように変更
  6. 抽出した関数を任意のモデルに移動。複数のモデル(≠DB table)を横断する処理はChatGPTに名前を考えてもらって単一責務な専用のクラスにする
    1. 自分で命名するとHogeModelServiceみたいな名前になりがち
  7. (6)の自動テストを書く
  8. テストで実装の差し替えが必要になったらinterface定義してDIで差し替える

上記は新機能開発というか更地に機能を建てる時の手順なんですけど、機能改修の時も4-5あたりから合流して同じフローに乗せてる

テストの話

テストコードの方針についてもボーイスカウトルールで積み重ねていっているんだけど、とくに重視しているのはバグの再現コードをテストにしてリグレッションテストを入れるという作業

バグを修正しないといけないという状況は=ユーザーにとって重要なコードということがはっきりしているので、テストで保護する価値も高いと考えている

ユニットテストはコードの分離さえ積み重ねていけば前進できるけど、E2Eな統合テストはコンテキストが多用でテストケース1つの価値が低くなることもあるので、無理せずそういうテストの保守はせず消して手動テストケースのスプレッドシートに移してる

スプレッドシート上で言語化できるってことは自動化できるやろと当初は思っていたんですけど、そううまくはいかなかった

ということは私達は言語化していないことを暗黙的に検証してることが多いので、運用しながら監視などのアプローチをそろそろ加えるべきなのかもしれない

Codecovで計測してる数値以下のように増加が見込めたが「内部品質向上のためにN%達成」という目標は立てずに「前期N%増減→それによって何か影響あったかなかったか」という指標として見てる

codecov

ただこれらの開発方針はソロ開発している都合で好きなようにやっている反面があり、分業してたりチーム開発でナレッジを運用しつつだったりすると事情が変わってくるのかもしれない

たとえば世の中によく広まっているEntityとRepositoryを作ってビジネスの語彙で内部DSLでユースケースを記述して—— っていう戦略を最初は真似してやってみていた

この戦略はファイルが増えるぶん複数人で作業しても衝突しない反面、EntityがDBのtableの定義に寄せられて開発ラインごとに新規tableを定義してファイル分割するようなドメインモデル貧血症問題を起こしがちだった

それを自分たちの環境で何が必要なのかを自己認識していった結果できたのが上記の1.〜のフローになってる

エンジニア10倍いたらそんな過程踏まずに一気にリノベしてマイクロサービス化していたかもしれない

GitHub上での活動

以下はtarao/oss-contributionsが生成してくれた集計結果*1

「LMQL v0.0.6.1で日本語が通るようになった」 の時のプルリクエストがあるだけで、とくに目立った活動はしていないことが分かった

zenn.dev

Contributors1
Repositories2
Commits31
PRs 3
Reviews
Issues 1
1 commit 2 PRs
eth-sri/lmql
★2,868
1 commit 1 PR
Pull requests
jzillmann/pdf-to-markdown
★884
1 PR
Pull requests

ついでに2021-2022年の集計するのも忘れてたので出してみた

2021年はVercelやAWS Amplifyを使ったアーキテクチャの研究をしていったっぽいが、2022年は記憶にも記録にも残ってない

2021年

Contributors1
Repositories3
Commits17
PRs 3
Reviews
Issues 1
1 commit 3 PRs 1 issue
vercel/vercel
★11,669
1 PR
Pull requests
serverless-nextjs/serverless-next.js
★4,321
1 commit 1 PR 1 issue
Pull requests
Issues
serverless/blog
★182
1 PR
Pull requests

2022年

Contributors
Repositories
Commits51
PRs 1
Reviews
Issues 3

*1:tarao/oss-contributions: 個人/組織のOSS貢献を可視化する https://tarao.hatenablog.com/entry/2021/06/14/160248