この記事は LAPRAS アドベントカレンダー 2021 の 1 日目の記事です。 LAPRAS 入社後に行ってきたライブラリアップデート周りの取り組みについてまとめてみました。 経緯 プロダクトが成長して機能が豊富になると、必然的に依存ライブラリが増加し、各ライブラリのアップデートへの追従に苦労しがちですよね。 自分が入社した当時の LAPRAS でもその課題がありました。 当時のライブラリアップデートまわりの環境は、セキュリティアラートに関連する PR のみが定期的に作られ、その PR のレビューも気づいた者がベストエフォートで行うというもので特に何か明文化されたルールはありませんでした。 ライブラリアップデートが遅れると、以下のような問題があります。 セキュリティリスクの増加 新機能が使えないというモチベーションの低下 より大きなライブラリ・FW（例： Vue, Django 等）の

あるフロントエンドの悩み いざテストを書こうとして色々と調べはじめると、厄介な壁に色々とぶちあたります。 テストの種類多すぎてよくわからない問題。 何をどうテストすれば良いのかわからない問題。 テストのためのツールどれを選んだらいいか問題。 ...ｴﾄｾﾄﾗｴﾄｾﾄﾗ......の問題。 今回の記事は「最初はこんな感じで書き始めたらいいんじゃないか」という皮切りになれば幸いです。テストに関する複雑な問題を整理して、よしとりあえずこのルールで書いていこうっ、となるのを着地点とします。 1. テストの種類多すぎてよくわからない問題 テストに関する用語は数多く飛び交っていて非常に混乱させるので、整理します。 登場する用語の定義には、あまり厳密さを求めないでください。 エンドトゥーエンド(E2E)テストをブロードスタックテストと呼んでも、機能テストと呼んでも、あるいは単にUIテストと呼んでも、そこ

React公式ドキュメントのチュートリアルは古くなっているので、TypeScriptやReact Hooksで開発することも考えて参照するときにおすすめできるサイトを置いておく。 ほかにも有益な情報はあると思うが、あまり多すぎても大変なので、被りがなさそうかつ有益だと思っているリンクに絞っている。 2021年11月30日に編集 React公式ドキュメントのリニューアルが公開されるまでの繋ぎ。 New React Docs · Issue #3308 · reactjs/reactjs.org https://github.com/reactjs/reactjs.org/issues/3308 React公式ドキュメントがBeta版で公開されています。まずはこちらを参照するといいと思います！

今回は graphql-codegen を使い説明します。今回の例は、graphql-codegen 以外でも発生する可能性がありますが自動生成系が一番顕著に影響がわかりやすいです。 graphql-codegen はよく、graphql のスキーマから typescript の型定義/react の hooks 等を自動生成するのに使われますが、これは next.js と組み合わせた場合、少しトリッキーな部分があります。 graphql-codegen はデフォルトでは 1 ファイルにすべて出力されますが、それに対し next.js は各ページを chunks として吐くため何も考えずに実装すると、バンドルされるファイル量が膨大になる可能性があります。next.config.js から webpack の設定を上書きできますが、optimization はかなり上書きしづらくそもそも上書

どのようにコンポーネントを分類していくか 個々のコンポーネントがが単一の責任のみ負っている状態であれば、コードの見通しも良くなる上、後々のメンテナンスも容易です。 まずは「複数の関心ごとを１つにまとめない」という原則（単一責任の原則）から分類の指針を考えていきます。 フロントエンドにおける関心ごとですが、大別すると APIとの接続 View（表示とイベント実行） 状態管理 以上３つに集約されるのではないでしょうか。 では、これらの関心ごとをどの様に切り分けていけば良いのか考えていきます。 APIとの接続 まずはAPIとの通信ですが、こちらはコンポーネントの外で管理した方が良いと考えています。 各コンポーネントに通信に関わる処理がベタ書きされている状態だと、エンドポイントの変更等に弱くなり、通信処理の再利用も面倒です。 それに、「フロントの状態管理 / 表示」と「外部との接続」はそれぞれ別種

Pythonの「Prophet」ライブラリで株価予測をしてみよう：「Python」×「株価データ」で学ぶデータ分析のいろは（終）（1/3 ページ） 日々変動する株価データを題材にPythonにおけるデータ分析のいろはを学んでいく本連載。最終回はローソク足とともにこれまでに計算したオシレーターなど一式を1つのグラフで表示する方法や過去の株価データを基にした株価予測の方法を解説します。

Etsy has switched from using a RequireJS-based JavaScript build system to using Webpack. This has been a crucial cornerstone in the process of modernizing Etsy’s JavaScript ecosystem. We’ve learned a lot from addressing our multiple use-cases during the migration, and this post is the first of two parts documenting our learnings. Here, we specifically cover the production use-case -- how we set up

この記事では、標準出力、標準エラー出力を好き勝手に出力する。 ファイルに出力、画面に出力、両方出力などなどパターン化してみた。 出力用スクリプト作成 なんのコマンドを使うか悩む前に、両方をちゃんと出力するスクリプト作成から開始しよう。 今後の内容ではこれを使っていく。

こんにちは。株式会社スタメンでFANTSのフロントエンドを担当している@0906kokiです。 今回の記事では、皆さんおなじみの Chrome Devtools にある Performance タブで、フロントエンドのパフォーマンスを計測する方法について書きたいと思います。 はじめに フロントエンドのパフォーマンス・チューニングと言うとバックエンドと比べて後回しになりがちですが、フロントエンドにアプリケーションの複雑性が寄ってきている現在、フロントエンドがボトルネックでレスポンスのレイテンシーが発生することは往々にしてあると思います。 バックエンドではユーザー数の増加や大量の同時接続に耐えられる負荷対策やパフォーマンス・チューニングが中心となりますが、フロントエンドではプロジェクトサイズの増加による JavaScript ファイルのダウンロードやスクリプティング、レンダリング速度の低下等が

Today we’re excited to announce the release of TypeScript 4.5! If you’re not yet familiar with TypeScript, it’s a language that builds on JavaScript by adding statically checked types. When you use static types, you can run the TypeScript compiler to check for bugs like typos and mismatches in the shapes of your data, and get handy suggestions. These types don’t change your program, and you can re

当ブログではCSSの新機能をたくさん紹介してきましたが、今回紹介するのはこれまでのCSSの実装方法が大きく変わるものです。 カスケードレイヤー@layerを使用すると、CSSの詳細度とスタイルの順序をカスケード内で明示的にレイヤー化（階層化）できます。CSSのオーバーライド、リセットやサードパーティの外部CSSファイルの扱いが、今までよりはるかに楽になります。 できたてほやほやの新機能ですが、主要ブラウザがエバーグリーンブラウザ（最新版に自動アップデートするブラウザ）になった現在、いつの間にかすべてのブラウザにサポートされているかもしれません。 Cascade Layers? by Chris Coyier 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 【訳者注】最後の一文まで、必ず目を通してください。 【更新】2022/6:

Hamee様 開発合宿 2021年（前半戦）の資料です。 # 参考リンク - https://speakerdeck.com/soudai/engineer-life-hack - https://www.shinryo.com/special/contents01_3.html - htt…

概要 オニオンアーキテクチャはJeffrey Palermo氏により考案されたアーキテクチャパターンである。伝統的な階層化アーキテクチャとオブジェクト指向の考え方を踏襲しつつ、これまでよりも保守性、テスト容易性、依存性の点で優れたアプリケーションを構築することを目的としている。本記事ではこのオニオンアーキテクチャとは何かについてPalermo氏の記事を参考にして考察する。 前提となる知識 オニオンアーキテクチャを理解する上で前提となるいくつかの知識を挙げる。 オブジェクト指向 オニオンアーキテクチャはオブジェクト指向を前提としたアーキテクチャである。 階層化アーキテクチャ オニオンアーキテクチャは多層アーキテクチャを利用している。 依存性逆転の原則 オニオンアーキテクチャでは依存性逆転の原則がオブジェクトのモデリングに利用されている。 ドメイン駆動設計 Entity, Repository

TypeScriptの主要な入力ファイルは .ts, .tsx, .mts, .cts ですが、JavaScriptファイル (.js, .jsx, .mjs, .cjs) も読み込んで処理することができます。JSDocによる型アノテーションを認識するため、生のJavaScriptでもそれなりに型をつけることができます。 本稿ではタイトル通り、TypeScriptのJSDocサポートでできることとできないこと (.ts でしかできないこと) をまとめます。 おことわり 本記事はTypeScript 4.4時点での実装状況に基づいています。なるべくソースコード中の関係する箇所を参照するようにしたので、今後の変更はご自分で検証してください。 (TypeScript Playgroundで試すだけでも有用です JavaScriptモードで開始できるリンク) JSDocの機能一覧・TypeScri

JestでTypeScriptを高速化するJestでテストの高速化させる方法を紹介します。トランスフォーマーとしてesbuildやswcを紹介し、TypeScriptで遅くなりがちなトランスパイルを高速化させることで、テストを自体を高速化します。 はじめにesbuild の登場により、フロントエンドの世界は、開発環境により速度を求めるようになりました。vite の隆盛はその最たるものといってもいいでしょう。 esbuild や swc は高速な Go や Rust によって書かれ、更に多くの場合、Typescript の型チェックを省略しています。 tsc の型チェックは、大抵 IDE やワークフローで行われているので、これらを削ぎ落とすことで、純粋なコンパイラとして JavaScript への変換に特化しているということですね。 さて、Typescript コードをテストする際、多くの場

00:00 オープニング 09:25 DDDとは 24:25 モデリング手法 28:48 モデリングの題材 30:10 システム関連図 44:00 ユースケース図 54:25 ドメインモデル図&オブジェクト図 1:22:50 完成図 1:25:55 休憩 1:30:15 モデリングに関するQ&A 1:35:00 モデルをコードに落とす 2:15:50 書籍の紹介 2:18:24 モデルとコードのつながり 2:27:33 休憩 2:38:42 Q&A 新刊「ドメイン駆動設計 サンプルコード&FAQ」 DDDに関して頻出の質問に、多くのサンプルコードを交えて回答した解説書です。 モデリング、集約の実装、テストについても具体例を交えて解説しています。 https://little-hands.booth.pm/items/3363104 前作「ドメイン駆動設計 モデリング/実装ガイド」 はじ

はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な

はじめに Webアプリに限らず、ほとんどのサービスではユーザ名とパスワードを入力し、ログインをしてから サービスを使う OSのログインしかり、メールアプリ、Webサービスなど ユーザ名とパスワードの入力という基本部分はほぼ変わってないが 時代とともにより安全な仕組みへと進化しているので 私の知る限りの説明したいとおもう 認証、認可の違い まずややこしいのが、認証、認可（承認）のちがいである 認証(Authentication) は、ユーザーが正しいかどうかの確認（パスワード認証）で 認可、承認（Authorization）は、アクセス権の確認である 昔はこの認証、認可を同時に行っていたが、OAuth等の登場から厳密に分ける必要が出てきた ただ、いまだにHTTPヘッダでも混同して使われていたりする ただし順番に並んでいるともかぎらないし、抜けもある 平文ベーシック認証 いわゆるBasic認証