前書き エンジニアを始めて14年、独立して9年経つ。 この仕事を始めた時に「さすがに眼が悪くなるかな」と思ったが、40過ぎていまだに裸眼1.5/2.0だ。(昨年はどっちも2.0。) ↓今年の検査結果(右列が昨年) これはなんなら、始めた時より眼が良くなっている。(始めたころは1.2/1.5だった。) 先日知人のエンジニアと話していると、彼は200人規模のエンジニアを抱える会社でリーダーをしているが「メガネをしてないエンジニアなんて会った事ない」と驚かれた。 実はそこに秘訣があるのでシェアしたい。 ちなみに妻はこの方法で片目だけだが0.9 → 1.2になった。 結論 「平行法を覚えろ」 これに尽きる。 遺伝の影響か ちなみに自分の親族・家族は実は須らく眼が悪い。 逸話的にも、若くして眼鏡を掛けていた父が、母をお見合いで最初に見た時に、「こいつも眼鏡掛けてる。」「もし子どもが出来ても全員目が悪
はじめに フロントエンド開発において、効率的かつ一貫性のあるモック生成は非常に重要です。本記事では TypeSpec、Orval、Storybook の 3 つのツールを使用して自動生成でモックを実現する方法を紹介します。 TypeSpec は、大規模な API を提供するために Microsoft が開発し、使用している新しい API 記述言語です。 Orval は、OpenAPI 仕様から TypeScript のクライアントコードを生成するツールです。これにより、最新の API 仕様に基づいたクライアントコードを常に保持し、API との通信がスムーズに行えるようになります。 Storybook は、コンポーネントを独立して開発・テストするためのインタラクティブなツールです。コンポーネントの見た目や動作を個別に確認できるため、UI の一貫性を保ちながら効率的に開発を進めることができます
はじめに Playwright を使うことで比較的簡単に E2E テストを実装することができます。しかし、通常テストコードは実装したら終わりということではなく、継続的にメンテナンス(保守)が必要になります。その際に保守しやすいように実装するため、Playwright の公式ドキュメントに記載されているベストプラクティスの中で参考になりそうな部分を確認しておこうと思います。 テストの独立性を高める 可能な限りテスト間の依存が無いようにして、テストを分離すると良いというプラクティスです。各テストが独立していることで、 1つのテストが失敗しても他のテストに影響しない テストの順序を考慮する必要がない テストをシンプルに保つことができる あたりのメリットがあるかと思います。また、特定の処理(例えば特定の URL に遷移する処理)の繰り返し実装するのを避けるために before and after
Introduction to Database Connection Management Patterns in TypeScript.pdf
たまに言っちゃうので自戒も込めて。 正しくは「Google Cloud」 2 年以上前に公式からアナウンスが出ています。 Google Cloud Platform が Google Cloud に名称変更 お客様のエクスペリエンスをシンプルにし、プロダクト間の一貫性を保つために、Google Cloud Platform は Google Cloud という名称になりました。 (以下略) Google Cloud の新しくなったホームページのご紹介 | Google Cloud 公式ブログ さらに、 Google Cloud Japan の Zenn Publication の記事内でも以下のように紹介されています。 コラム: Google Cloud? Google Cloud Platform? GCP? (中略) 実は 2022 年の 6 月に、公式ブログ でブランディングが変更さ
TypeScriptへRustのようなResult型の導入をお勧めする記事や言説が多いので導入してみましたがあまりよくなかったです。という共有になります。 Result型を導入しても try-catch からは逃れられない これに尽きます。 Result型を導入したあと、try-catch を末端に押しやってそこ以外はResult型のみの世界を実現しようと、おそらくみんな考える。でもそれは機能しない。 実際にやってみるとこんなコードが多発する。 function hoge():Result<void> { try { // fn()は綺麗な世界の実現のためResult型を返すようにしてある。この関数のようにね。 const result = fn() // ここで例外が発生する処理が必要になる return ok(result) } catch(e) { return err(e) } }
株式会社IVRy (アイブリー)のエンジニアの kinashi です。 IVRy では設定画面の Web アプリケーションは Ruby on Rails と Next.js で構成されています。 I/F 定義には OpenAPI を使っていて、各リポジトリから Git のサブモジュールで参照し、スキーマ駆動で開発しています。 2022年の夏にリプレイスをし、今の構成になってから早1年半、1ファイルで管理していた OpenAPI の定義も1.3万行ほどになりました。 リプレイスに関する記事はこちら 定義の追加や編集、レビューなどが辛くなっているので、1ファイルでの定義から脱却したい! ということで、徐々に分割を行っている最中です。 なぜ今までファイル分割していなかったのか スキーマ定義通りの実装にするため、バックエンドでは committee-rails 、フロントエンドでは openapi
Background これまでVitestでコンポーネントのテストを行う時は、jsdom や happy-dom を使ってブラウザ環境を偽装していました。しかし、偽のブラウザ環境を使うことは多くの問題があり、また開発者はテスト以外でどこにも存在しない環境を作り上げるという不毛な作業が必要でした。 この問題を解決するために、Playwright や Cypress などのテストフレームワークは Component Test をサポートしています。しかし、UnitテストでPlaywrightやCypressを使うのは少々Fatであり、Reactのhooksなどのテストをすることができません。 Vitest Browser Modeを使用することで、Vitest上でComponent Testが可能となり、これらの問題を解決できます。 Installation Browser ModeのSetu
プログラマ、テスト駆動開発者 和田卓人 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。『プログラマが知るべき97のこと』(オライリージャパン、2010)監修。『SQLアンチパターン』(オライリージャパン、2013)監訳。『テスト駆動開発』(オーム社、2017)翻訳。『事業をエンジニアリングする技術者たち』(ラムダノート、2022)編者。テストライブラリ power-assert-js 作者。 日本におけるテスト駆動開発(以下、TDD)のエバンジェリストとして知られる和田卓人さん。TDDが世に出て20年あまりが経ち、開発者の間でその名が広がっています。その一方で、和田さんは「TDDの本来の意味を知らなかったり誤解したりしている人たちもかなり増えている」といいます。 今回は、TDDは本質
はじめに どもども、インフラ案件で奮闘中の井上弥風(いのうえみふう)です。 現在プロジェクトでELB(Elastic Load Balancing)を使用しており、その内部機能を完全に理解したいと思い、この記事を書きました。 この記事について この記事の最終的な目標は、「ELBとは何か?」を深く理解し、それを自信を持って説明できるレベルになることです。 しかし、ELBを完全に理解するためには、まず基本的なロードバランサーの概念を押さえる必要がありました。 そこで、この記事ではELBの根底にあるロードバランサーとは何かという点に焦点を当てていきます。 ELBの詳細については、この記事の後に公開予定の「ELBってなんやねん」という記事で詳しく取り上げます。 ELBに興味のある方は、ぜひそちらもご覧ください。 記事のゴール この記事を通じて、ロードバランサーがどのようにしてトラフィックの負荷分散
WindowインスタンスプロパティcachesclosedconsolecookieStorecredentiallesscrossOriginIsolatedcryptocustomElementsdevicePixelRatiodocumentdocumentPictureInPictureeventexternal 非推奨 fence Experimental frameElementframesfullScreenhistoryindexedDBinnerHeightinnerWidthisSecureContextlaunchQueue Experimental lengthlocalStoragelocationlocationbarmenubarmozInnerScreenXmozInnerScreenYnamenavigation Experimental navigato
タイトルは初見時の自分の気持ちでした。内容は結構あっさりしたもので、5分あれば読めると思います。 「あーなるほどね」となった方はわざわざ読む必要がない記事っぽいです。 型の互換性チェック 一言で言ってしまえばそういうことです。KとUが互いに置き換え可能かどうかを確認しています。 これがKとUのままだと分かりづらいのですが、適当な型に置き換えてみると分かりやすいです。 type Test1 = [1, 1] extends [1, 1] ? true : false; // true type Test2 = [number, number] extends [number, number] ? true : false; // true type Test3 = [string, string] extends [string, string] ? true : false; // tru
日本で生成AIと言えば、OpenAIのChatGPTがその代名詞。この傾向は日本でのオフィス開設も加わって、さらに高まっているが、そのOpenAIやGeminiをはじめとする多様なAIサービスを提供するグーグルと並んで存在感を示している企業がある。 このジャンルに注目している方ならばご存知だろうが、AnthropicというAI専業ベンチャーである。AnthropicはOpenAIの運営方針に異を唱えるメンバーがスピンアウトした2021年創業の生成AIスタートアップで、アマゾンとグーグルが巨額を出資していることでも知られる。 滑らかな文章を生成するClaude 同社の大規模言語モデル“Claude(クロード)”はその性能の良さから注目されていたが、特に注目を集めるようになったのは、今年3月4日に発表されたClaude 3からだろう。特徴的な性能や機能もさることながら、印象的だったのは生成する
state は複数のコンポーネント間で独立しています。React は UI ツリー内の各コンポーネントの位置に基づいて、どの state がどのコンポーネントに属するか管理します。再レンダーをまたいでどのようなときに state を保持し、どのようなときにリセットするのか、制御することができます。 このページで学ぶこと React が state の保持とリセットを行うタイミング React にコンポーネントの state のリセットを強制する方法 key とタイプが state の保持にどのように影響するか state はレンダーツリー内の位置に結びついている React はあなたの UI のコンポーネント構造をレンダーツリーとしてビルドします。 コンポーネントに state を与えると、その state はそのコンポーネントの内部で「生存」しているように思えるかもしれません。しかし、実
はじめに はじめまして、セキュリティエンジニアのSatoki (@satoki00) です。今回はブラウザの開発者ツールのネットワークタブから隠れて、Webサイト内の情報を送信する手法をまとめます。所謂Exfiltrationというやつです。中にはCSPの制限をBypassするために用いられるテクニックもあります。CTFなどで安全に使ってください。 前提 発端はWeb上でテキストの文字数をカウントできるサイトが閉鎖する際の話です。カウント対象のテキストデータがサイト運営 (やサイトを改竄した攻撃者) に盗み取られていないかという議論が巻き起こっていました。「盗み取られていない」側の主張は、ブラウザの開発者ツールのネットワークタブにリクエストを送信した形跡がないというものでした。ここで ブラウザの開発者ツールのネットワークタブに表示がなければ外部へデータを送信していないのか? といった疑問が
ムーザルちゃんねるのzaruです。今回はムーさんと、Tailwind CSS初心者が絶対ハマる落とし穴について話しました。Tailwind CSSを使い始めた人、あるいはまだ使ったことがない人には是非見てほしいです。すでにこの落とし穴から抜け出している人はあるよねーって感じで眺めてください。 すごいサムネイル… ハマるポイント クラス名の動的指定 クラス名のコンフリクト クラス名の動的指定 例えば、通常は背景を青だけど、エラーの時は赤くしたい。そんなときにJavaScriptでクラス名を組み立てると以下のように書きがちです。bg- と -500 は固定なので変化する red blue だけ変数で組み立てるやり方です。 const color = error ? 'red' : 'blue'; <div class={`bg-${color}-500`}></div>
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く