この記事は "What We’ve Learned From A Year of Building with LLMs" という記事を著者の一人である Eugene Yan さんから許可を得て翻訳したものです。 https://applied-llms.org/ Thank you for giving me a permission to translate this wonderful article! 著者の方々 Eugene Yan Bryan Bischof Charles Frye Hamel Husain Jason Liu Shreya Shankar 原文の公開日 2024/６/8 今は大規模言語モデル（LLM）を使った開発がとってもエキサイティングな時期です。この1年間で、LLMは実世界のアプリケーションに対して「十分に良い」ものになりました。そして、年々良くなり、安く

こちらに触発されて「そういや俺も手が痺れて色々やってたしな、共有したろ！」と思い筆を取りました。 過去形っぽく書いていますが今でも油断して悪い姿勢で作業し続けると痺れが再現します。 ひどい時は無理せず休みましょう。 手の痺れの原因 手の痺れと一口に言っても原因は実に様々ですが、痺れている部位でどの神経が痛めつけられているかわかるので、それである程度特定することができます。 私の場合は主に手の外側、小指と薬指が痺れる範囲でした。 この範囲の場合、圧迫されているのは尺骨神経という神経のため、考えられる疾患としては肘部管症候群、胸郭出口症候群、頚椎ヘルニアのあたりでした。 引用: 尺骨神経とは？解剖・支配筋・感覚枝 https://www.doctor-1.com/archives/2110 色々MRIやらCT取っても確定診断は出なかったのですが、後述する分離型キーボードを導入してかなり楽になっ

こんにちは。 スキーマから何かを生成するのが大好きな seya と申します。 追記 今後は基本お手製スクリプトは書かないで ChatGPT にお願いした方がいいと思います。 ------------- 追記 終わり ------------ 今の会社では REST API のスキーマを OpenAPI で記述しているのですが、それを活用して何かしらを生成するスクリプトをよく書いています。 そんなネタがそれなりに溜まってきたので一挙大放出しようというのがこの記事です。 具体的には次のようなものを作りました。 TypeScript の型と API の生成 by aspida テストのための Factory 関数の生成 msw handlers の生成 API スキーマから生成のデメリット まず初めに、"生成"というのはとても生産的に感じますが、デメリットも存在するので触れておきます。 一番大き

私個人の Flutter 歴も早数ヶ月程になってきたのですが、ちょくちょく雰囲気で使っているなーと感じるものが出てきたり(BuildContext や WidgetsBinding など)、描画のタイミングでバグが出た時にフワッとネットで見た記事通りに書いて解決したりなどの場面が出てきました。 それでもとりあえず動くアプリケーション開発はできなくないのですが、ちゃんと自信を持って開発したい & もう一段 Flutter 力を上げたいので本腰入れて Flutter がどう描画しているのかを調べてみたので、その結果をまとめてみました。 同じような課題感を抱いている方の足がかりとなれば幸いです。 はじめに: この記事のスコープ 最初にこの記事で話す「描画の仕組み」とは具体的に何を指すのかを述べます。 前提として、Flutter は大きく次の3つの層から成り立っています。 Flutter arch

以前こんな記事を書きまして、こちらではいわゆる Rails とかである Factory Bot みたいな感覚で使えるものが欲しいなと思い作りました。 ただ、実際にこれを使ってテストを書き始めてみたものの、すぐにまだ足りないものを見つけました。 それは relation を持つもののデータを作るのがめんどくさい default のデータを書くのがめんどくさい の2点です。これらが解ければユニットテストのデータ準備周りで困ることはなさそうだと思い、ソリューションを考えてきたのでご紹介します！ relation を持つもののデータを作るのがめんどくさい まずこちらですが、relation の持ち方については次の二つがあるのでそれぞれ個別に考えます。 foreign key を持っているパターン 中間テーブルで紐づけているパターン foreign key を持っているパターン こちらに関しては P

GraphQL クライアントの選び方について 現状大きく次のような選択肢があります。 Apollo Client Relay Urql 他に react-query や SWR などの GraphQL に特化していないものを使うこともできるらしいがあまりメリットがピンときていない GraphQL クライアントにやってもらいたいこと 上記は Web の GraphQL クライアントの比較しか書いておらず、他のプラットフォーム(Flutter とか)でも選定軸が持てるように、もう少し "GraphQL クライアント" と呼ばれるものに何を期待しているのかを書き出してみる。 graphql リクエストを送れる 最低限の機能です。 エンドポイント、認証トークン は共通のものとして準備して、あとはクエリをのっけたらリクエストが作れたらいいでしょう。 キャッシュを保ってくれる キャッシュの正規化ってな

自分ではあまり使ったことがないのですが、最近他所のデザインシステムの実装なんかを眺めていて <Stack.Item> のようにあるコンポーネントのプロパティとして他のコンポーネントを定義するパターンを何度か見かけて、どんな時に有効なのかを考えてみたくなった次第です。 具体例 Shopify のデザインシステムの中にある Stack と Stack.Item が当てはまります。 これらのコンポーネントは次のようにセットで使われます。 <Stack> <Stack.Item fill> <Heading>Order #1136</Heading> </Stack.Item> <Stack.Item> <Badge>Paid</Badge> </Stack.Item> <Stack.Item> <Badge>Fulfilled</Badge> </Stack.Item> </Stack> //

何かを好きになるのに、理由なんているかい？ ~セ・ヤ (B.C.2525)~ 出会い あれはおよそ4年前のことでした。 2016年の冬、寒さに震えていた私はフロント未経験の身でありながらフロントの技術選定をしなければならなかったのです。 その頃のフロント界は混迷を極め、 React もまだ枯れておらず、Angular は2系が1系と大きく違うことから叩かれ、Vue が名乗りを上げようとしていました。「フロント界隈は動きが速い」というフレーズも流行語大賞になりそうな勢いでした。 そんな中選択肢・考えることの多さに絶望していた私は React を試しに触ってみました。 そして「思ったより覚えることないし、独自文法とかも少ないからミスってもリカバリー効きそうだな」と直感的に思いました。 はっきり言ってしまえば雰囲気で選んだのですが、今ならこの時の直感は間違っていなかったと自信を持って言えます。

最近 React コード生成機を作っていて「一番文句言われなさそうな React コンポーネントの書き方ってなんだ…？」と改めて疑問に思ったので考えてみました。 結論から言うと以下の形をデフォルトにするのが良さそうかなと思いました。 function vs. アロー関数 -> アロー関数 型は基本的に VFC でつけて、 children が欲しい場合は明示的に props に追加する return を省略可能な時省略するか -> しない props を destructure するか -> しない派だったけどした方がいい気がしてきた const Hoge: React.VFC<Props> = ({ title }) => { return ( <Fuga title={title} /> ) } ちなみにですが、大事な前提として TypeScript を使うことを前提としています。(型

最近余白の実装について見直す機会があったので、考えをまとめてみました。 TL;DR Grid なら grid-gap flexbox なら flex-gap にしたい(が、safari が対応してないので記事執筆時点では使えない) 適切な padding を指定する 複数の同一のマージンには Stack、それ以外には Spacer コンポーネント 前提: 子コンポーネントは親コンポーネントの"レイアウトのスタイル"を知ってはならない まず前提として「子コンポーネントは親コンポーネントの"レイアウトのスタイル"を知ってはならない」です。 (太古に書いた記事から具体例を引用) 例えば、こんな感じのアイコンが複数並べたコンポーネントが存在するとします。 アイコンの間にはmarginが等間隔でありますね。 このmarginをアイコンコンポーネント内で定義していたとしましょう。 さて、他のページでこ

プロジェクト間で必要とされる node.js のバージョンが違うことはままあり、そのために皆さん nvm や nodebrew などのツールを使っておられることだろうと思います。 今回それ系統で Volta というツールを知ったので紹介いたします。 Volta - The Hassle-Free JavaScript Tool Manager Volta の特徴 セットアップが比較的簡単 Rust製で速いらしい 実行する node のバージョンなどをプロジェクトのディレクトリに入るだけで自動で切り替えてくれる npm や yarn でグローバルインストールした時も、どのディレクトリでインストールされたかを自動で記録するため、コマンドラインから直接コマンドを実行できつつもプロジェクト毎に違うバージョンを使うことができる node だけでなく npm や yarn もプロジェクト毎に固定できる

はじめに あくまで一個人の意見なので絶対的な解ではないというのと、どっちをデフォルトに選んでも普通にアプリケーション開発してて困ることはほぼほぼないと思うので、そこまで気を揉むことでもない、ということだけ最初に述べておいて意見をしたためます。 TL;DR アプリケーション開発では基本的に type でおk Declaration merging したい時だけ interface ライブラリ開発のような使う側で拡張したい(Declaration merging したい)時は interface とりあえずチームでどっちをデフォルトにするかは統一しといた方が気持ちいい type と interface の違い 機能的にはそんなに大きな違いはなく、個人的に判断に関わるのは次の3つかなと思います。 interface では Declaration merging がされる。type ではされない

この記事のシリーズでは私がフロントエンドに関して思っていることを徒然に語っていこうと思います。 ちょっと長くなり過ぎそうなので以下の4つに分けて書いていこうと思います。 1.概念的な話 - フロントエンドアプリケーションとは何でできているか フロントエンドアプリケーションを保守性とユーザへの価値提供を両立して開発するために、アプリケーションを抽象化して、いい感じの設計をする必要があります。 これの土台作りをするために概念としてフロントエンドアプリケーションとは何なのかを考えていきます。 2.技術的な話 - フロントエンドアプリケーションはどのように実行されるか Webフロントエンドはブラウザで実行され、表示のためには HTML, CSS, JS が必要です。当たり前のことではありますが、実際に開発を進めていく上では概念だけでなく、実際に動く How の部分を知る必要があります。 これらの要

CSSで三角を作る方法と言えば border でした。 私も三角を作りたい時は 「css 三角」 で検索、コピペして調整して作っていました。 ですが最近 clip-path というプロパティによってより分かりやすく三角が作れることを知ったので共有いたします。 ちなみに IE 以外では大丈夫そうです。逆を言うと IE 対応しなければいけない人は引き続き border で三角を作る必要があります。ここまでお読みいただきありがとうございました。 clip-path を使った三角の作り方 こう CSS を書くと .sankaku { background-color: blue; width: 16px; height: 20px; clip-path: polygon(0 0, 0% 100%, 100% 50%); } こうなります。 どこの点を結ぶかは clip-path で指定して、高さと

フロントエンドの開発が初めての人が意外と抜けがちな観点をまとめてみました。 初めにざっくりと概要を話すと「デザイナーが作るデザインでは表現しづらいもの」をまとめたものになります。 デザイナーが作るデザインは静的なものなので(たまにがっつりプロトタイプを作ったりもありますが)、いわゆる"状態"を表現するのが難しかったり抜けたりしがちです。 具体的に言うとローディング、Empty、エラーなどです。これらをよしなに補完できるフロントエンドエンジニアはデザイナーからもきっと「頼りになるぅ！」と思われること間違いないでしょう。 と言うわけでそんな例を紹介していきます。 今後も思いついたら追加する可能性が無きにしも非ず。 ローディングを出そう こう言うクルクルするやつとか こんな感じでシュインシュインするやつがあります。 基本的にユーザがアクションを起こした時に待たせる場合は必ず表示させましょう。 ロ

というのを使っていて思ったのでレポを書いていきます。 mabl とは - 基本的な機能 ざっくり言うと E2E テストをお手軽にメンテできるツールです。 こんな感じでポチポチ画面を操作していくと、それで実行したアクション(ボタンやリンクをクリックするなど)を自動で記録してくれて、E2E のテストを作成することが出来ます。 コードを書かずに　E2E　テストをサクッと作れちゃうのが魅力な訳ですが、それだけではありません。そんなすごいところを紹介していこうと思います。 mabl のここがすごい Auto Healing 何やら回復魔法みたいな感じでかっこいいですが、何かというと E2E テストがコケるようになった時に自動で修復してくれる機能です。 例えばボタンの位置が変わってしまっても、同じ文脈であろうボタンを自動で探して修復したりしてくれます。 E2E での辛さといえば、やはりテストのメンテナ

export const FirstVideoConfig: VideoConfig = { sections: [ { title: 'イントロダクション', bgmSrc: '/audio/bgm/honobono-wartz.wav', backgroundVideo: '/video/cyber-bg.mp4', afterMovie: '/video/yukkuri-opening.mp4', talks: [ { text: 'ねえねえ魔理沙', speaker: 'reimu', id: '59f8c2cd81334be5ab5cdc7899fad286', audioDurationFrames: 25, }, { text: 'なんだ霊夢', speaker: 'marisa', id: '0ba332a465c3404a870de15cad021407', audioD

本記事の多くは Inspect モードを前提に解説しています。 下記に Dev Mode に対応した解説を書いてみたのであわせてご参照ください。 https://codezine.jp/article/detail/18000 エンジニアにデザインツールの知識・習熟は必要か？ しなくても仕事はできると思うのですが、あるとよりクオリティの高い仕事ができることは間違いありません。 という訳でエンジニアがエンジニアとしての仕事をしていく上で「Figma のこういうことを知っておくと良さそう」という知識をまとめてみました。 ユースケースを考える まず始めにデザインは作らないはずのエンジニアが Figma を使う時にどんなユースケースがありそうかを考えてみます。 デザインを元に実装する時 デザインから何かを生成したい時(コードとか画像とか) 自分でちょこっとデザイン修正しちゃう この辺りがあるかな〜

SQLのチューニング方法 昔Qiitaで書いたものをzennにうつして、若干の修正、追加をしてみました。 ORACLEでの経験を元に書いていますがコストベースのリレーショナルデータべースなら大体共通の考え方だと思うので他にも使えると思います。 SQLのチューニングといえば比較的容易に済むインデックスをとりあえず作成する。といった対応を取られがちですが、数万レコード程度でのデータ量ではあまり効き目がなく（自分の経験則）、どちらかといえば、結合順が大幅に狂ってたりすることが原因のことが多かったりします。よって本当にインデックスがないことが原因なのか？を熟考する必要があります。（例えばID以外のフラグとかコードに単項目indexを貼ってるのもみたことがあります。怖いけど実話） また、インデックスを作りすぎるとオプティマイザが狂いやすくなって他のSQLにも悪影響を及ぼしたりするので結構熟慮して追加