Code interpreter のキラーソリューションは表データの可視化っぽいけど、入力テキストとファイルソースによってテキスト生成とファイル出力ができるという点に着目すると色々活用の幅が広がる。 中でも、今までは入出力トークンに含まれる必要があったソースコードデータを外部ファイル化できるので、「リポジトリを丸ごと食わせる」などの従来トークン制限上実現できなかったことが外部システム連携なしで簡単に可能になったのが嬉しいポイントだった。 この特性を生かして最近OSSの静的コード解析というかコードリーディングをChatGPTにやってもらっている。 以下のサンプルでは脆弱性診実習用アプリ（通称「やられサイト」）のSQLインジェクションを発見してもらうという会話をした。 chat.openai.com 以下ではaws-load-balancer-controller や openai-pr-re

www.youtube.com Meta(当時Facebook)のReact Core Teamの主要人物たちに直接インタビューしたドキュメンタリー動画 タイムライン 2012年まで 最初はFacebook社内でReactが普及するまでの道程。 当時世の中的にはクロスブラウザの解決策はjQueryに落ち着き、モバイルアプリ化の流れでAPIサーバーとViewは切り離される傾向にあり、JavaScriptのクライアントサイドで大きいアプリケーション作るためにMVCフレームワークとか取り入れないとね〜という雰囲気だった Facebook社はマーク・ザッカーバーグがHTML5に賭けていた頃*1にBolt.jsというFacebook版Backbone.jsを開発していた 広告プラットフォームのコードは当時Bolt.jsを中心に構成されていたが、Jordan Walkeが関数型プログラミングのアイデア

と思ってやってみたら結構実現できてウケたので解説します。 はじめに 最近のGPT(LLMs)アプリケーション開発界隈は「プロンプトの内容を試行錯誤して結果を期待する」フェーズから「LLMsの特性を生かした今までできなかった自動化を実現」という段階が訪れつつあって楽しい時期です。 LlamaIndexというOSSではDBのスキーマと自然言語からSQLを自動生成してその場で実行するというクレイジーな機能があるのですが(A Guide to LlamaIndex + Structured Dataを参照) これと同じ発想でソースコード全体からpatch(patch - Wikipedia)を生成してその場で適用するというアイデアを思いついたのでしばらく検証していました。 「コミットメッセージを先に書いてそれを満すコミットをGPTに生成してもらう」ようなイメージ。 書いたコードはpmonというコマ

(インターネットやめろジェネレーターで作成) Ruby on Rails生みの親であり最強の逆張りおじさんであるところのDHHが昨年あたりからしきりに脱パプリッククラウドの主張をしている。 これは彼らの会社が運用しているBasecampやHEYのインフラをAWSから自社保有のベアメタルサーバーへ移行しようとしているからで、実際に移行作業は進んでおり、今後5年間で700万ドルのサーバー費用を節約できるだろうという見込みがあるようだ。 world.hey.com world.hey.com あとタイトルに「サーバーレスをやめろ」と書いたけどDHHのファンボである筆者の誇張表現であり、サーバーレスというキーワードに関しての言及は正確には以下のポストを読んで欲しい。 world.hey.com この文章における「the computing cycles」とは、一台のコンピュータが持つ計算能力全体を

Apple系デベロッパーの人たちがSwift普及のいかんともしがたい現状について話していたので考えてみた。 サーバーサイド用途 サーバーサイドSwiftは現状あまり利用したいケースが見当たらず、モバイルアプリ開発組織のマイクロサービス開発の共通化においてはJVMが枯れているのでKotlinの方に傾きがち。 WindowsやVSCodeやIntelliJ系の非Xcode系開発環境のサポートのハードルも越えるぐらいモチベーションが必要である。 ただユーザー規模はそこそこあり、DenoやDartやHaskellが有効な程度にはWeb開発用途には使えると思われる。苦労しそうだけど。 Wasm化 Wasmにしてブラウザサイドでコードを動かそうという向きもある。拡張用途では周辺ツールの多いRustやCのライブラリ資産のポートもありレッドオーシャンであることは変わりないが、Swiftに限らずWasmアプ

2000年代ぐらいにblosxomやtDiaryで熱心にWebに何かテキストを書いていたような人たちは特定の価値観を持っているなと思う。 それがどういうものなのかはすぐ説明できないし、単に特定の人たちのことを指しているのかもしれない。ただ、丁寧に閲覧履歴を見ていけば100人ぐらいは該当するサイト管理人が思い浮べられそうだ。 現在は個人が動画で発信する時代なので、僕の思うこの感覚は次の世代では動画に特別な感情を持ちがちという解釈になっているのかもしれない。 Message Passing このサイトに辿りつくような人たちはプログラム雑談ポッドキャストの188回以降のエピソードのWebに何かテキストを書くことについての話は共感できるのだと思う。 anchor.fm Message Passingというのは以下のサイトのことで、ガー社とかファー社とかで就労経験のあるような日米のプログラマーかつ、

個人でWebサービスを継続的に運用するのは金がかかってかなわんという問題がある 「個人開発」だと定義が曖昧なので自己資金かつ赤字のプロジェクト(Webサービス)ということにする。 そういうプロジェクトではプロダクトオーナー=自分、開発者=自分、予算管理者=自分というロールになるので予算管理者としてコストを図る必要がある(ここでいうコストはWebサービスを実現するアプリケーションのランニングコストのこと)。 通常はみんな自分の人件費を0として計算していると思う(逆にいうとそれが負債という考え方もできると思う)。 ただしメンテナンス時間とコストのトレードオフもあるので、人件費0ではあるけど有限の時間は別軸として管理しているのが普通だと思う。極端な例だと「コスト削減できるけどメンテナンス時間10倍になる」というのは避けられる。 仮に個人開発のプロジェクトの予算を月数千円から高くても1万円ぐらいか

Cloudflare Workers Cloudflare Workersのようなサーバーレスなコンピューティングプラットフォームとしてここ数年活発な「エッジサーバーでプログラムを実行する環境」(呼び方が定まらないので一旦Edge Functionsとする)でアプリケーションを作る*1とブラウザが通信する先にもう1つブラウザが存在するような妙な感じを覚えていた。 例えばNext.jsのAPI Routesなら書いたコードはNode.jsで動くので頭をサーバーサイドモードにすればいいが、Cloudflare Workersで動くエンドポイントを書く時はそうでない……　おまえ、ブラウザなのか？　みたいな でもよく考えたらこれらのプラットフォームはSpiderMonkeyやらV8やらのブラウザと同じJavaScriptエンジンを組み込んだ実行環境を持っていて、APIも環境の制限(TCP接続とかフ

前回までのあらすじ：2020年に作ったソフトウェアや開発技術をふりかえる - laiso Write Code Every Day プログラマーの人にありがちな趣味だと思うんだけどWrite Code Every Day （John Resig - Write Code Every Day）を2008年ぐらいからやっていて、昼に仕事でコード書いて夜になったら自分の楽しみのために何か作るか〜というのを繰替えして生活してる。 John Resig の記事との違いは今読みながら比較していたんだけどGitHubに上げるっていう部分はやらなくなってしまった。クレデンシャルとかハードコードしてるやつとか半分他人のコードコピペしたやつとかの清書がめんどくさいというのがあるし、クローラーなどは自分だけが使うぶんにはいいけど公開した方が迷惑になる——みたいなジャンルのコードが結構あって段々省くようになってし

Airbnb’s Server-Driven UI System(Ghost Platform) とは何か Airbnbが社内で取り組んでいる最新UI開発システム Ghost Platformとそのコンセプトの名前 元Airbnb AndroidエンジニアRyan Brooksによるポストを参照 A Deep Dive into Airbnb’s Server-Driven UI System | by Ryan Brooks | The Airbnb Tech Blog | Medium A Deep Dive into Airbnb’s Server-Driven UI System どういうものか サーバー(API)からデータと画面構造(UI)を配信して各プラットフォームで再生する仕組み UI言語部分を抽象化したもの Web、iOS、Androidに対応する なぜ画面構造を配信するの

ClubhouseのiPhoneアプリは各所でお馴染みのObjective-Cライブラリが使用されており、アプリ自体は最先端のムーブメントながらもUIからはシニアの職人技を感じます。根拠はないですがアプリの実装もObjective-Cでゴリゴリ書いてそうです。 ここではそんなObjective-Cライブラリの一部を紹介します。 IGListKit https://github.com/Instagram/IGListKit Instagram開発チームのコレクションビューの差分描画最適化のノウハウが詰ったライブラリです。 アプリの肝となるフィード系の画面で使われています。 UIScrollView+InfiniteScroll https://github.com/pronebird/UIScrollView-InfiniteScroll 無限スクロールを実現するライブラリです FlagP

Hotwire https://hotwire.dev/ Turboを中心としたウェブアプリケーションのアーキテクチャの要素技術やコンセプトをPRするための名称 Hotwireというライブラリがあるわけではない 役割としてはMicro FrontendsとかReactのlearn once, write anywhereなどに似ている アプリケーション実装言語非依存だけど現状Railsアプリケーションしか実用できる基盤がない Hotwireの思想 アプリケーション開発者の生産性を上げることを目的にしていること サーバーサイド言語でフロントエンドを実装したいアレではなかった プログレッシブ(段階的に利用可能)であること 必要な技術だけを使い無駄なことをしないことで効率化する Hotwireが列挙する技術は1つづつ有効にできる クライアントサイドでViewを差分更新する現在の主流のシングルペー

2020年に作ったソフトウェアや開発技術をふりかえる で分かったことばかり書いたけど相変わらずなんべん勉強しても分からんな〜と思うことも多いのでそれもリストアップしてみることにした。 SQL 10年以上触っているはずだけど集合のイメージが頭に入ってこなくて全然文を組み立てられずにいる。ゆるふわORMを適当に使ってる。 CSS 10年以上触っているはずだけど制約のイメージが頭に入ってこなくて全然レイアウトを組み立てられずにいる。ゆるふわTailwindCSSを適当に使ってる。 Unity 何回もダウンロードして教材を買ってるんだけど。アセットを組み立てて何か意味のあるものを作るっている状態まで行かない。Flashは使いこなしていたはずなのになぜ UIデザイン 作る時に一定の理屈っぽいこだわりがあるんだけど、何か自分で作るというところまでいかない上に、深く理由を考えたことすらなかったので、こだ

概要 よくある年末っぽい日記の記事です。 だいだいこれどうりのバランスでソースコードも書いてる 言語はなんでもいい時はNode.jsで書く。移植性が高いので。複数人でメンテしそうな時はTypeScriptを採用し、プライベートの時は型を完全に無視する PHPはほぼLaravel。ビジネスのみの関係 Swiftはそんなに書いた記憶がないけどアプリのメンテをしてたと思う Vueも仕事で使っていたけど最近はReactに傾いてる Objective-Cは書いてない グラフに含まれてない部分だとAndroidアプリでKotlinを使って、データ分析でPythonを書いた このグラフは GitHub Profile Summary Cards っていう便利ツールを使わせてもらって自動生成している。 記録方法 コードを書く時はおもむろに ~/tmp 以下にディレクトリ掘ってIDEを開きはじめるので実質そ

Endless road | During our roadtrip we turned off the highway… https://www.flickr.com/photos/98063470@N00/326044514 GitHubリポジトリ Covid19Radar に対して起ったことがかなり特殊な状況だったため、開発を追い掛けていた視線からレポートをします。 この記事の著者について 代表作のない個人アプリ開発者(かなしい) Covid-19 Radar Japan の人ではない GAFAMやCode for Japan の人でもない 4/8 Covid-19 Radarを発見する Covid-19 Radarとは、この時点ではシンガポールのTraceTogetherの日本版を目指した個人開発者 廣瀬一海さんのアプリのリポジトリ 4月にContact Tracing技術について

はじめに とにかく次の10年を生き残りたい - 怠惰を求めて勤勉に行き着く を読んでいて、かー自分もここ10年ぐらい同じような内省をし続けていたではないかと深く共感したので、その過程で身に付けたやり方を書くことにしました。 目的 プログラミング技術を学習する目的を決めます。僕の場合は ソフトウェアエンジニアとしての市場価値を上げる(他のエンジニアから尊敬されたい)とか 素晴しいアプリケーションを作れるようになりたい(エンジニア以外からも尊敬されたい) というものがあります。人によってはこれが「GAFAMNに入り渡米してメジャーデビュー」「OSSで一発当てる」「とにかくお金を稼いでアーリーリタイヤ」など様々かと思うので各自考えてください。 テーマ 目的が決ったら次は学習するテーマを決めます。僕の場合は「○○エンジニア」と呼称されている領域ごとに「この分野で先進的なネタは何だろう」というのをリ

Firebase Advent Calendar 2019 の17日目です。16日目はKesin11さんの「Firebase Emulator Suiteをフル活用してTDDで開発しよう」でした。 はじめに FirebaseプロジェクトでCloud Firestoreを利用する時は通常Node.jsによるCloud Functionsでトリガーとなる処理を記述します。その他には関連するAPIサーバー、WebアプリのフロントエンドのSSR、バックエンドの非同期処理など、多くの場面でCloud Functionsが活用されています。 この開発→デプロイサイクルをお手軽に行ってくれるのがfirebase-toolsというnpmモジュールです。JavaScriptでFunctionを実装し、firebase deployコマンドを実行するだけでFirebaseプロジェクト用のCloud Funct

pxhere.com*1 ここ数年、新規に開発するモバイルアプリのリードになる機会が何回かあり。プロジェクトの開始時期に毎度、README.md に開発方針を記述していたのだけど、いつも似たような内容になり公共性がありそうなのでそのままブログにした。 普段から「今回はアーキテクチャは何を採用しましょうか?」みたいな段階から議論がはじまるのを避けた方が建設的だと思っているので、その思想が反映されている。 想定する状況 我が社はこれからゼロからモバイルアプリを使ったサービスを提供するところであり、人手は少ないが開発初期段階から技術に投資する意気込みはあり、いずれはサービスの大ヒット、組織の大規模化を見据えて段階的に成長するアーキテクチャをバーンとやっていきたい。 事業領域は例えば決済サービスやビジネス系のモバイルアプリを想定している。 これは何? iOSアプリのソフトウェア設計面についての現時

iOSDC Japan 2018 に採択されたトーク「iOSエンジニアが知るべきProgressive Web Apps開発のエッセンス」のブログ版記事です。 CfP提出後に内容は二転三転しまして、当初は最新Web開発事情について技術的に突っ込んだ内容にしようと目論んでいたのですが、「iOSエンジニア」へ「伝えたいこと」という軸で作っているうちにこの内容に落ち着きました。 当日聞きに来てくださった方、声をかけていただいた方。このような場を下さったiOSDCスタッフの方々にはたいへん感謝しています。 Introduction📛 昨年末 SafariにService Workersが実装され「iOSがPWAをサポートした」というニュースが業界内で話題になりました。 (※Progressive Web Apps 以降 PWA という略称で話します) この時話題になっていたSafariのPWAサ

photo by pexels.com *1 この記事を書いたきっかけ niconegoto.hatenadiary.jp 「PinQulをクローズします」にて事業のふりかえりをしている文章の中に「アプリビジネスは完全にダウントレンドにある」という一節があって、ここから話題が広がっていったのを機に上記の記事を読みました。そして色々思うところがあったのです。 アプリビジネスは完全にダウントレンドというのは自分も前から思っていた。リッチな体験、通知を遅れることはアプリの利点だが、他PFからの流入なども含めたプロダクトのコアな検証はwebモバイルが1番早いはず。— sadakoa (@sadako_a_) August 16, 2018 (Twitter上で多くの共感を集めた投稿) 例えば「モバイルアプリがWebに負けはじめた理由」ではWebアプリがモバイルアプリに比べて優れているでろうという点