ポエム特化のZenn2との噂の「しずかなインターネット」を使いはじめたので、ユーザーとしてどんな技術が使われているのかを確認していく。 sizu.me おもむろにbuiltwith.comにかけてみる。 builtwith.com ここで分かる情報はブラウザのDevTools眺めてても得られるのであまり収穫はない。 前段にCloudflareのCDNサーバーがいて Next.jsで生成されたレスポンスを返している ことがわかる。 この時点ではキャッシュのみCloudflareなのか、Pages/WorkersでNext.jsのSSRごと動かしているのかは判断できない。 認証 Set-Cookie: __Secure-next-auth.session-token=が含まれているのでNextAuth.jsを使っているのが分かる。 next-auth.js.org Emailでサインアップする

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アプ

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

目次: 就活日記 (0) エントリー - laiso そろそろ就職するにあたって、退職しないと就職することができないので就職する前にまず退職をしました。 思えば私のプログラマーとしてのキャリアも6年ばかりとなりました。 ところで私は当時勉強が出来ない奴はプログラマになれ！ - IT戦記 を読んでプログラマになったクチで、この記事にはたいへん励まされました。 しかし当然順風満帆なプログラマー人生ともいえず。マイナスからのスタートでした。これはとくに精神面や比喩的な意味というわけではなく、低賃金の肉体労働をしばらく生業にしていたため単に総資産がマイナスでした。 そもそも私が一番最初にプログラマーをこころざしたのは、うだつが上がらない十代を地方ですごしていた時分です。 社会的脱落者として場当たり的に日銭を稼ぎ、賃料が不要な家で暮していた為稼いたぶんをそのままビデオゲーム筐体に投入する、などという