Presentation slides: タワーズ・クエスト、バルテス、Postman 共催セミナー - 開発失敗につながる偏ったテストしてませんか？ プロが教える本当に考えるべきテストバ…

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? レンダリングとメモ化についてようやく理解したので書く なぜこの記事を書こうと思ったのか Reactを学び始めてから、props の渡し方、配列処理のメソッド、ユーティリティ関数の使い方、カスタムフック、定数の扱い方、コンポーネントの切り分け、さらにはアトミックデザインといった多くの概念に触れ、理解する必要がありました。現場での約1年間の経験を通じて、これらの要素がようやく整理でき、ある程度の自信を持って活用できるようになりました。 特に、長い間課題だった「レンダリングとメモ化」に関する理解も深まり、自分なりの言葉でまとめられる段階に来ま

9月26, 27日に開催され、めちゃくちゃ盛り上がったRails World 2024でKamal 2が発表されました。Kamal 2はRuby on Railsを作った37signals社が、自社の人気サービスをデプロイするのに使用しているツールです。 37signals社はAWS等のクラウドに年間で$3,201,564を使った(2022年: 日本円で4.5億円ほど)らしく、一方でAWSを使ってもインフラ系人員の削減もほとんどできなかったので、全然割に合わないからもうクラウドはやめて自分たちのサーバを使うと宣言しています。Kamal 2はそのために作られた、本格的なデプロイツールです。 （ちなみに自分たちのサーバを使うと言ってもオンプレミスでサーバを運用するというのではなく、さくらの専用サーバに近いイメージです） Dockerベース Docker化されたアプリなら何にでも対応 (Rail

ユネスコ無形文化遺産登録から10年を経て、登録当時には約5.5万店だった海外の日本料理店が、2023年には約18.7万店にまで増えるなど日々関心が高まっています。 京都府立大学、日本料理アカデミーでは京都から国内外を問わず和食のさらなる発展と和食文化を担う人材の育成を目指し、「日本料理大全 デジタルブック」を公開します。 ある料理を知るためには、まずその背景を知らないと始まりません。「日本料理大全」シリーズは手法のみを解説するのではなく、考え方の基礎を示していくことを目指しています。経験や勘に頼るのではなく、なぜこの味が生まれるのか、どうしてこの調理法になるのか、といった根拠や科学的な理由を示しています。それらをもとに料理する人が考え、取り入れ、オリジナルの料理を生み出す手助けとなることを目指しています。 このシリーズが日本料理の発展・普及の一助となり、多くの人々の健康と喜びを導くことにな

2024年9月10日、京都府立大学が、特定非営利法人日本料理アカデミーと共同で、『日本料理大全』のデジタル版を同大学のウェブサイト上で一般公開しました。 『日本料理大全』は、日本料理の技法を科学的に理解し、自分の料理に取り入れて実践できるよう、日本料理アカデミーが制作した料理教本です。日本語版と英文版があり、現在までに5巻が刊行されています。 国内外を問わず和食のさらなる発展と和食文化を担う人材の育成を目指し、一般公開を開始するとあります。 報道・広報（京都府立大学） https://www.kpu.ac.jp/ ※2024年9月10日付けで「日本料理大全 デジタルブックの一般公開について」とあります。 日本料理大全デジタル版 京都府立大学サイトにて公開！（日本料理アカデミー, 2024/9/10） https://culinary-academy.jp/taizen_digital_bo

貧しいからカップラーメンを食う？　惣菜パンばかり食う？　牛丼ばかり食う？　なにを言ってるんだ？　おれにはわからない。おれたちにはキムチ鍋があるじゃないか。 キムチ鍋。 pic.twitter.com/Y9p1hxKJUF— 黄金頭 (@goldhead) January 22, 2019 キムチ鍋。 pic.twitter.com/dhw3CJe3Pw— 黄金頭 (@goldhead) January 21, 2019 キムチ鍋。 pic.twitter.com/nnzaJD9CeC— 黄金頭 (@goldhead) January 20, 2019 キムチ鍋。 pic.twitter.com/3EUpJ2EXJc— 黄金頭 (@goldhead) January 19, 2019 キムチ鍋。 pic.twitter.com/V0XoiNWSfN— 黄金頭 (@goldhead) Janu

みなさまお元気ですか 暑さも少し落ち着いてきて、ようやく外に出てもいいかなという気になってきました。季節の変わり目体調には気をつけていきたいですね。 実は、一ヶ月くらい前に Linux PC を自作して Mac から移行しました。そのときの考え、その後の感想を残しておきます。 また、学んだことや作業のログを細かく残しておきたいと思います。（どこかの誰かが不安に思ったときに同じ失敗や疑問を経験した人がいて安心してもらえたら嬉しい） Ubuntu のインストール画面 (ベストオープンソースと開発しよう！) 目次 Mac をやめるきっかけ、経緯 Ubuntu に移行して一ヶ月の感想 おまけ1: どのような PC になったか おまけ2: 事前に学んだこと おまけ3: PC の組み立て おまけ4: Ubuntu のセットアップ 加筆/修正 指摘のあった誤字を修正 NVEnc について誤った内容があっ

モダンなブラウザは JS API として gzip や deflate が使えます。 昔から Chrome に搭載してるのは知ってたんですが、今見たらだいたい搭載してました。 わかってる人向けに言うと、バンドルサイズ大きめの JS実装の pako や zlib.js が不要になって、ブラウザネイティブの(たぶんHTTP上のgzip展開と同等の)高速な実装が使えます。 // impl const encoder = new TextEncoder(); const decoder = new TextDecoder(); export async function compress(str: string): Promise<ArrayBuffer> { const cs = new CompressionStream("gzip"); const buf = encoder.encode(

CTO 室の恩田(@takashi_onda)です。 一休レストランのフロントエンドアーキテクトを担当しています。 Intro 一休レストランでは、以前ご紹介したようにフロントエンドで React / Remix を利用しています。 user-first.ikyu.co.jp 一方、設計方針としては、React / Remix への依存が最小になるように心掛けています。 今日は、そんな一見矛盾するような設計方針について、ご紹介したいと思います。 この記事を読んでいただき Remix に興味をもたれたら、明後日 2024/8/7(水) 19:00〜 のオンラインイベント offers-jp.connpass.com にもご参加いただけると嬉しいです。 この記事でご紹介している疎結合なフロントエンドアーキテクチャを実現する Remix の魅力についてお話します。 なぜ依存を最小にするのか？ R

ファインディ株式会社でフロントエンドのリードをしております 新福(@puku0x)です。 この記事では、ファインディで導入しているモノレポ管理ツール「 Nx 」について紹介します。 モノレポとは Nxとは Nxワークスペースの作成 Nxの機能 コード生成 変更検知 依存関係の管理 キャッシュ機構 自動マイグレーション まとめ モノレポとは モノレポは全てのコードベースを単一のリポジトリで管理する手法です。 monorepo.tools コードの共通化や可視化、ツール・ライブラリの標準化、一貫性のあるCI/CDパイプラインを構築できるといったメリットがあります。また、マイクロサービスと相性が良いとも言われています。 circleci.com ファインディでは主にフロントエンド系のリポジトリをモノレポとして運用しています。 アプリケーションとそれに関連するフィーチャー、UIライブラリがひとつに

React has been around for 11 years, which seems hard to even grasp when you look at the current pace of web development. The reason why we're still talking about React today is that it's somehow been able to keep up, always evolving to meet the challenges thrown at it by its users. In fact, not content with merely keeping up, React is even leading the way on new innovative patterns such as Server

最近はお客さんとの勉強会でDockerのドキュメントをつまみ食いして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 本エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基本的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整

はじめに こんにちは。サーバーサイドエンジニアの mokuo です。 最近、ミニマムな React アプリを実装する機会がありました。 社内のメンバーにアドバイスをもらいながら、今（2024年前半） React アプリをミニマムに作るならこんな感じかな、という構成になった気がするので、ご紹介したいと思います。 実例の1つとして参考にしていただけますと、幸いです。 はじめに 本文 📝 機能要件 ⚒️ 採用したツール (npm モジュール) 📁 ディレクトリ構成 👨‍💻 プロトタイピングの実施 🍩 おまけ コンポーネント設計について フロントエンドに DDD のエッセンスを取り入れてみたい おわりに 本文 📝 機能要件 社内の限られた CS メンバーのみが利用する、管理画面を開発しました。 バックエンドは Golang で実装される API サーバーで、認証機能以外だと、2つの機能

javascripter です。ハローでは、初期メンバーとしてプロダクトのローンチ前からAutoReserve の開発に関わっています。 前回の記事に引き続き、筆者が社内で書いている技術ガイドラインについて紹介します。 はじめに ハローでは、高品質なコードを維持し、開発チームの技術レベル向上を図るため、チーム横断的に、有用な技術Tips、ベストプラクティス・コーディングガイドラインなど情報をNotion上に集約し、自由にエンジニアが閲覧・編集できるようになっています。 この取り組みの目的は以下の通りです： コード品質の向上と統一 開発チームメンバーの技術スキル向上 「どう」直すかでではなく「なぜ」そう修正すべきかまで理解してる人を増やす 効率的な開発プロセスの確立 前回の記事については、こちらを参照下さい。 Reactベストプラクティス: react-hooks/exhaustive-de

個人的に「Webサービスの公開前チェックリスト」を作っていたのですが、けっこう育ってきたので公開します。このリストは、過去に自分がミスしたときや、情報収集する中で「明日は我が身…」と思ったときなどに個人的にメモしてきたものをまとめた内容になります。 セキュリティ 認証に関わるCookieの属性 HttpOnly属性が設定されていること XSSの緩和策 SameSite属性がLaxもしくはStrictになっていること 主にCSRF対策のため。Laxの場合、GETリクエストで更新処理を行っているエンドポイントがないか合わせて確認 Secure属性が設定されていること HTTPS通信でのみCookieが送られるように Domain属性が適切に設定されていること サブドメインにもCookieが送られる設定の場合、他のサブドメインのサイトに脆弱性があるとそこからインシデントに繋がるリスクを理解してお

Yjsは、リアルタイム共同編集を実現するためのアルゴリズムとデータ構造を提供するフレームワークです。Notion や Figma のように、1 つのコンテンツを複数人で同時に更新する体験を提供することができます。 Y.Map, Y.Array, Y.Text といった共有データ型を提供し、それらは JavaScript の Map や Array のように利用できます。さらにそのデータに対する変更は他のクライアントに自動的に配布・同期されます。 Yjs は Conflict-free Replicated Data Types (CRDT) と呼ばれるアルゴリズムの実装であり、複数人が同時にデータを操作してもコンフリクトが発生せず、最終的に全てのクライアントが同じ状態に到達するように設計されています。 クイックスタート Y.Map がクライアント間で自動的に同期されるコード例を見てみましょ

javascripter です。ハローでは、プロダクトのローンチ前からAutoReserve の開発に関わっています。 今回は、筆者が社内で書いている技術ガイドラインについて紹介します。 はじめに ハローでは、高品質なコードを維持し、開発チームの技術レベル向上を図るため、社内で継続的に技術Tipsやガイドラインの整備・蓄積を行っています。 チーム横断的に、有用な技術Tips、ベストプラクティス・コーディングガイドラインなど情報をNotion上に集約し、自由にエンジニアが閲覧・編集できるようになっています。 この取り組みの目的は以下の通りです： コード品質の向上と統一 開発チームメンバーの技術スキル向上 「どう」直すかでではなく「なぜ」そう修正すべきかまで理解してる人を増やす 効率的な開発プロセスの確立 新メンバーのオンボーディング支援 今回紹介するドキュメント 今回は、その中から「reac