並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 63件

新着順 人気順

frontendの検索結果1 - 40 件 / 63件

  • 大公開!バッチアプリケーションの品質を高めるZOZOの『バッチ開発ガイドライン』 - ZOZO TECH BLOG

    こんにちは。MA部の田島です。 弊社では開発ガイドラインというものを用いて、システムの品質を担保しています。今回私がテックリードを務めているということもあり、バッチアプリケーションを開発するためのガイドラインを作成しました。本記事では「開発ガイドライン」と「バッチ開発ガイドライン」を紹介します。 バッチアプリケーション開発に限定したTipsはまとまっているものが多くないため参考にしていただければと思います。 開発ガイドラインについての紹介 冒頭でも紹介した通り弊社では、開発ガイドラインというものを用いてシステムの品質を担保しています。バッチ開発ガイドラインを紹介する前に、まず開発ガイドラインを紹介します。 開発ガイドラインの種類 開発ガイドラインは現在、以下の種類が存在します。 共通 Android iOS Frontend Backend Infra API Batch DB(Datab

      大公開!バッチアプリケーションの品質を高めるZOZOの『バッチ開発ガイドライン』 - ZOZO TECH BLOG
    • 設計ドキュメント腐る問題、Git管理で運用してみた結果 | フューチャー技術ブログ

      はじめにTIG真野です。 秋のブログ週間2023 の3本目は、設計ドキュメントをGit管理して腐らせないようにがんばってみた話をします。 前段として6年前、「我々はいかにシステム開発におけるドキュメント腐る問題と戦えば良いのか」という記事を書いたのですが、その後の試行錯誤はどこにも残していないことに気づきました。普段のフューチャー技術ブログですとちょっと引け目を感じるテーマですが、秋の夜長を楽しむため読み物成分を多めに書くというテーマのこのブログリレーにピッタリな気がするため、この機会をお借りします。 ドキュメントも色々な種別があるかと思いますが、この記事では設計ドキュメントを指すことにします。設計ドキュメントは開発メンバーが参照するもので、ステークホルダーへの説明資料に引用して使うことはあれど、主目的は異なるという前提です。Design Docの場合もありますし、システム構成図、ERD、

        設計ドキュメント腐る問題、Git管理で運用してみた結果 | フューチャー技術ブログ
      • 私のJavaScriptの情報収集法 2024年版

        個人的なJavaScriptの情報収集の方法についてまとめてみます。 JSer.infoなどをやっているので、JavaScriptの情報については色々な情報源を見るようにしています。 JSer.infoの範囲の中での情報源については、次の記事でまとめています。 JSer.info 13周年: JavaScriptの情報源を整理する - JSer.info この記事では、少しスコープを広げてJavaScriptの情報収集についてまとめてみます。 かなりスコープが広がってしまうので、万人向けの方法ではなく、個人的な情報収集方法としてまとめています。 この記事では、膨大な情報の中から見つけるというアプローチをとっているので、人によって向き不向きがあると思います。 情報収集の方法 情報の元となる情報源はさまざまなサイトや人になると思います。 しかし、そのサイトや人ごとに見ていくというのはかなり大変

          私のJavaScriptの情報収集法 2024年版
        • webフロントエンドテストと自動化

          Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything

            webフロントエンドテストと自動化
          • サーバーレスの次はなんなんだ

            はじめに この記事は、同人誌サークル「めもおきば」から不定期刊行している技術解説本「めもおきばTecReport」に書いたものを公開用に再編集したものです。 ⇒ めもおきばTecReport 2023.12 この記事のほかにも「私もSecHack365に参加したい!」や、「2023年振り返りと2024年技術予想」としてこんなキーワードを取り上げているので、気になったらぽちっとしてください! メガクラウドと特化型クラウド/ハイパーバイザーのSoC化/ライセンスとクラウドベンダー/イベント駆動型API/LLM時代のAIペアプロ力/生活必需品としてのGPU・NPU/Passkey/ウェブアクセシビリティ/リアルイベントの再開 サーバーレスの次はなんなんだ サーバーレスと呼ばれる技術ムーブメントが盛り上がり始めて8年近くが経ちました。各クラウドベンダーのFaaS(Function-as-a-Ser

              サーバーレスの次はなんなんだ
            • GitHub Projects を利用したタスク管理 - 一休.com Developers Blog

              宿泊開発チームでエンジニアをしている @itinao です。 昨年の10月に入社しました。 今回は GitHub Projects を利用したタスク管理について記載します。 なんとなーく GitHub Projects 使うと、KANBANにしてみたり リストにして使ってみたり で終わってしまいます。 もっと色々できるんだよってことが伝えられればと思います。 背景 どんな機能があるか Custom Fields Views Group by Slice by Workflows ISSUEと Pull requestの紐づけ Insights タスクの進め方 タスクの洗い出し 見積もり 現状の課題と今後の展望 まとめ さいごに 背景 一休ではチームごとにタスクの管理方法が違い、 Google Spreadsheet・GitHub Projects・Jiraなど、チームごとにタスク管理の方法

                GitHub Projects を利用したタスク管理 - 一休.com Developers Blog
              • Webサービスを作るときのテンプレートを作った - hiroppy's site

                週末に自分がよく使っている技術をまとめたら反応が良かったので、テンプレートを作りました。 なにかWebサービスを作るときに、自分はこれらのライブラリを基本的には入れます。 ベースはcreate-next-appとなりますが、そこで生成された状態だと認証もDBも何もありません。 しかし、サービスを作るにあたって必要なケースがほとんどです。 このテンプレートには特定のライブラリを入れると毎回書かないといけない項目等を事前に作っておき、 開発に集中できる仕組みを作るのがゴールとなります。また、例を示しつつ削除するコード量を最小限に抑えます。 主にNext.js固有のハマるポイントや環境構築などめんどくさいけど毎回書いている点をカバーします。 linterと関連があるVSCode, pre-commit等の設定NextAuthに指定されたDB Schemaの作成やAPI routeの設置開発、テス

                  Webサービスを作るときのテンプレートを作った - hiroppy's site
                • フロントエンドの新規開発でNext.jsの採用を見送った話 - バイセル Tech Blog

                  ※こちらはバイセルテクノロジーズ Advent Calendar 2023の10日目の記事です。 前回の記事は、金澤さんのAuth0とEntra IDを扱うプロダクト同士を繋げるためのIstio設定あれこれでした。 はじめに こんにちは、開発3部の神保です。 バイセルでは、お客様宅への出張訪問による買取が買取チャネルの主力となっています。現在開発3部の弊チームでは、この出張訪問買取で使用されるWebアプリケーション「Visit」の新規開発を進めています。 VisitのフロントエンドにはReactを採用しましたが、Next.js等のフレームワークは使用せず、Vite + ReactによるSPA (Single Page Application)構成を選択しました。 技術選定の過程では、社内での採用事例などからNext.jsも検討の対象となりましたが、最終的にはその採用を見送る結論に至りました

                    フロントエンドの新規開発でNext.jsの採用を見送った話 - バイセル Tech Blog
                  • DB に JSON を保存したいときに Protobuf を使うと便利 #LayerXテックアドカレ - LayerX エンジニアブログ

                    こんにちは。バクラク事業部 Enabling チームの @izumin5210 です。最近「HUNTER×HUNTER」の既刊を全部読みました。 この記事はLayerXテックアドカレ2023の9日目の記事です。 前回「1人目データアナリストとしてデータチームに異動しました 」 次回「Slack × Zapier × MiroでKPTでの振り返りをラクにする」 RDB や KVS などのデータ保存先において、データを正規化せずにそのまま保存したいと思うことはありませんか? 8月にリリースされた「バクラク請求書発行」というプロダクトには「柔軟なレイアウトカスタマイズ」機能が搭載されています。リンク先の画面操作イメージを見ていただくと、この機能の雰囲気を理解していただけると思います。この機能が扱うレイアウトデータはまさに「関係の正規化をせずに保存したいデータ」でした。 bakuraku.jp こ

                      DB に JSON を保存したいときに Protobuf を使うと便利 #LayerXテックアドカレ - LayerX エンジニアブログ
                    • GitHub - ByteByteGoHq/system-design-101: Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.

                      Architecture styles define how different components of an application programming interface (API) interact with one another. As a result, they ensure efficiency, reliability, and ease of integration with other systems by providing a standard approach to designing and building APIs. Here are the most used styles: SOAP: Mature, comprehensive, XML-based Best for enterprise applications RESTful: Popul

                        GitHub - ByteByteGoHq/system-design-101: Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.
                      • テストピラミッド万歳 | POSTD

                        クイックサマリー:「テストピラミッド」は、自動テストをUI、サービス、ユニット単位に整理することで、開発に自動テストを組み込む方法を示すために作成されました。2012年に定義されて以降、このモデルは次第に使われなくなってきたように思いますが、本当に廃れてしまったのでしょうか。この記事では、最新のテスト戦略を紹介するとともに、今日のソフトウェア開発におけるテストピラミッドの関連性を検討します。 筆者の同僚であるジャン・フィリップ・ピエトルチェクが、かつてコードを書く開発者の責任について、次のように述べました。 none「我々の仕事の成果を最終的に使用する人々は、(中略)我々がただ最善を尽くすだけでなく、実際に機能するものを作ることを期待しているのです。」 — ジャン・フィリップ・ピエトルチェク 彼の言葉は、私たちが書くコードをそれに依存する人々の観点からとらえている点で非常に印象に残りました

                          テストピラミッド万歳 | POSTD
                        • JavaScriptビルドツールの整理 各ツールの機能と依存関係

                          フロントエンドのビルドツールが色々ありすぎて、何がどうなっているのかがわかりづらいため、 各ツールができること、特徴 ツール間がどのように依存しあっているか を一気に調べて整理した。(情報は2023/10時点) 概要 ツールの依存関係整理 上層: dev server付きのバンドラ/ビルドツール。アプリ開発者が直接configなどを書いて取り扱うのはここが多いと思われる。(Next.jsに関しては、ビルド機能に着目した場合) 下層: やや基盤的なdev serverなしのツール群。 矢印は、明示的な依存関係を表す。実際には、明示的な依存関係がなくても、下層のツール群は上層のバンドラ(やRollup)に対してプラグインを提供していることが多い。 各ツールのできること整理 ツールごとに、大まかな機能区分で、できることとできないことをまとめた。 各機能区分の定義は次セクションを参照。 ツールごと

                            JavaScriptビルドツールの整理 各ツールの機能と依存関係
                          • PlaywrightのVSCode拡張を使って効率的にテストを書く

                            この記事では、Playwright の VSCode 拡張を使って GUI 操作のみでテストの記録や実行する方法について紹介します。 Playwright の VSCode 拡張とは? Playwright の VSCode 拡張は、Playwright の作成元である Microsoft が公式に提供している拡張機能で、VSCode 内で直接ブラウザテストの記録や実行を支援するための便利なツールです。 GUI 操作を中心に、テストの記録や実行を手軽に行うことが可能となります。 VSCode 拡張のインストールは、以下のリンクから行うことができます。 VSCode 拡張を活用してテストを書く 本記事では、シンプルな ToDo アプリを例にテストの作成方法を説明します。Playwright のインストール方法は、公式ドキュメントをご参照ください。その後、VSCode に Playwright

                              PlaywrightのVSCode拡張を使って効率的にテストを書く
                            • アーキテクチャの進化はドメインイベントが起点になる - KAKEHASHI Tech Blog

                              こちらの記事はカケハシ Advent Calendar 2023 Part2の24日目の記事になります。 adventar.org はじめに 反復的な開発は、変更容易性の高いソフトウェアが不可欠です。ソフトウェア開発の経験がある方なら、デリバリ後の洞察や市場環境の変化から、新しい機能の追加やアーキテクチャの進化の必要性に直面したことが一度はあるでしょう。 私自身、要求分析手法やSOLID原則等の技法を取り入れ、変更容易性に対応する多くのプロジェクトに参加しました。しかし、どれだけ優れた手法や技法を持っていても、変更が難しい要求が出てくることは避けられません。その際、「過去の出来事」を正確に記録していれば、後から見返して問題解決が容易だったと感じることがよくあります。 ドメイン駆動設計(DDD)では、「過去に起こった出来事」を表現するドメインモデルを「ドメインイベント」と呼びます。変更容易性

                                アーキテクチャの進化はドメインイベントが起点になる - KAKEHASHI Tech Blog
                              • 業務システム SPA のフロントエンド技術選定(2023年版) - KAKEHASHI Tech Blog

                                本エントリはカケハシ Part 2 Advent Calendar 2023の13日目の記事です。 (Part 1もおもしろい記事がいっぱいあるので、ぜひご覧ください。) はじめに こんにちは。カケハシでソフトウェアエンジニアをしている平松です。 今年、新規プロダクト立ち上げの機会があり、その際に行ったフロントエンドの技術選定について紹介したいと思います。 フロントエンドの領域は選択肢が豊富で、変化のスピードも速いため、プロダクトの要件に適した技術を選ぶことはひとつの挑戦です。 実際、フロントエンド技術選定のヒント 【令和五年度版】のアドベントカレンダー記事を読んで、その難しさを改めて感じました。 今回の新規プロダクトは、ユーザがログインして利用するtoBの業務システムです。 私はカケハシでは2度目の新規プロダクト立ち上げですが、前回の経験を活かしつつ、新しいアプローチにも挑戦しています。

                                  業務システム SPA のフロントエンド技術選定(2023年版) - KAKEHASHI Tech Blog
                                • 誰でも簡単⁉️👀 絵文字ができるまで😃👍

                                  現在の私たちが何気なく使っている絵文字たち(😀🥺💦💕🏠💻🌊😈🐱💢…)って、実は誰でも提案📝📮することができて、「この絵文字はワシが作った👴」と言えるチャンス💪があることをご存知ですか❓🤔 このスライド📄では、普段あまり知ることのないUnicode Emoji😀(絵文字の代表格)の仕様策定の流れ💨や、Emojiを提案する方法🙆‍♀️を簡単にご紹介👩‍🏫します! ✅ Zennに本スライド以外の内容(📊通過率・🗑️Emoijのボツ案など)を含めて載せてます↓ https://zenn.dev/cybozu_frontend/articles/how_to_propose_a_new_emoji ※本資料は、2023年6月30日にサイボウズで開催された社内イベント「フロントエンドデー」における登壇資料に一部編集を加えたものです。 ※ここに掲載の内容は2

                                    誰でも簡単⁉️👀 絵文字ができるまで😃👍
                                  • 「推測されやすい」パスワードを入力させないためにフロントエンドエンジニアができること

                                    2023/08/26(土)に開催された Frontend Nagoya #11
のセッションで使用したスライド資料です。

                                      「推測されやすい」パスワードを入力させないためにフロントエンドエンジニアができること
                                    • 巷の「ReactとNext.jsの比較」はここがおかしい、というか比較すること自体が微妙 - honey32

                                      (WIP まとまったら Qiita とかに上げるかも) TLDR; 「React と Next.js を比較」という記事で、 Next.js と比較できるのは「フレームワークなしで React を使うという選択肢」であって、「React そのもの」ではない。 ✅️ React を使うのに 「フレームワークあり」 vs 「フレームワークなし」 ❌️「React」 vs 「Next.js」 それはそうと、「create-react-app の機能・特徴」のことを、「React の機能・特徴」であるかのように書いてしまっている記事が多い create-react-app 自体が擬似的なフレームワーク(といえそう) そもそも、create-react-app は今は更新されてないので create-vite-app を使うべき フレームワークあり or フレームワークなし 【フレームワークあり】

                                        巷の「ReactとNext.jsの比較」はここがおかしい、というか比較すること自体が微妙 - honey32
                                      • 個人で開発していた上場企業の情報サイトをOSSにした

                                        結論 個人で開発していたWEBサービスをOSSとして公開しました。 この背景や技術環境について書いていきます。 すべてのソースコードをGitHubに公開しています。 スターやレビューをしてくださると嬉しいです! 公開したサービス: 上場企業ランキング 先日、オープンソースでWEBサービスを公開しました。 「上場企業ランキング」というサービスです。 その名の通り日本の上場企業を業界ごとに「給与」や「売上」順で閲覧することができるサービスです。 URL: https://company-ranking.net/ GitHub: https://github.com/yuki0920/company-ranking 私は2度の転職活動経験がありますが、企業を選ぶ際に知っておきたいことはいくつもありますよね。 「給与はどのくらいだろう」 「売上や利益はどの程度なのかな」 こういった情報は、求人ペー

                                          個人で開発していた上場企業の情報サイトをOSSにした
                                        • Backend エンジニア視点からの GraphQL / GraphQL from a perspective of backend engineer

                                          "LayerX、スタディサプリ、SHEと考える GraphQLが向いている現場とは?運用実践LT" で登壇した資料です。 引用した資料 [Rails アプリに RESTful API のレールを敷いて生産性が大きく上がった話 | Wantedly Engineer Blog](https://www.wantedly.com/companies/wantedly/post_articles/85098) [React Server Components と GraphQL のアナロジー | by Yosuke Kurami | Dec, 2023 | Medium](https://quramy.medium.com/89b3f5f41a01) [実質無料で GraphQL Gateway を手に入れる / low-cost GraphQL Gateway - Speaker Deck](

                                            Backend エンジニア視点からの GraphQL / GraphQL from a perspective of backend engineer
                                          • フロントエンドパフォーマンスの変遷とNext.jsに見る次の時代

                                            こちらのイベントのLT登壇資料です。 https://ochacafe.connpass.com/event/308830/ 登壇後、資料内の論理展開を登壇者の判断で改善しております。以下は登壇時からの主な修正点です。 ・レガシーMPAについて、FCPのみに着目して初回表示が遅いとしていた記述を削除 ・レガシーMPA + Ajaxについて、初回表示に関する言及を削除。SPAで行われる初回表示に関する変化の説明と重複するため ・SPAの初回表示について、FCPが速くなったとポジティブな書き方を、逆にLCPが遅くなったとのネガティブな記述に修正 ・SPA+SSRのページを削除。サーバーサイドフェッチを伴うSSRについてはNext.js側のページで解説 ・サーバーサイドフェッチを伴うSSRについてのネガティブな記述を削除し、SPA的なクライアントサイドフェッチのアーキテクチャとフラットに取り扱う

                                              フロントエンドパフォーマンスの変遷とNext.jsに見る次の時代
                                            • Why, after 6 years, I’m over GraphQL

                                              GraphQL is an incredible piece of technology that has captured a lot of mindshare since I first started slinging it in production in 2018. You won’t have to look far back on this (rather inactive) blog to see I have previously championed this technology. After building many a React SPA on top of a hodge podge of untyped JSON REST APIs, I found GraphQL a breath of fresh air. I was truly a GraphQL h

                                              • モノレポの開発環境でDocker ComposeをやめてTaskfileを導入した話

                                                こんにちは、Sally社 CTO の @aitaro です。 マーダーミステリーアプリ「ウズ」とマダミス制作ツール「ウズスタジオ」、マダミス情報サイト「マダミス.jp」を開発しています。 はじめに この記事ではウズの開発当初から利用していた Docker Compose をやめることにした背景についてご紹介します。 Docker Compose は各マシンの開発環境での差異を吸収するというメリットがあり、多くの開発現場で導入されていますが、Docker Composeの抱えているデメリットを勘案して、最終的に一部を残して辞める決断をしました。 Docker Composeの特徴 Docker Composeは、複数のコンテナを定義し、管理するためのツールです。ウズの開発環境では、バックエンド、フロントエンド、データベースなどをそれぞれコンテナ化して、Composeで一括管理していました。こ

                                                  モノレポの開発環境でDocker ComposeをやめてTaskfileを導入した話
                                                • TypeScriptのモノレポ構成を考える

                                                  はじめにlink あまりモノレポの構成について語られている記事が多くないなと感じたので、現時点で自分が考えている設計をまとめてみる。 以前にTwitterでディレクトリ構成と内容については言及したが、実際に利用する技術についてはあまり触れなかったので改めて検証してみた。 https://twitter.com/koh110/status/1617510034266808322 クライアントサイドとサーバーサイドのコード共有については下記の記事がよくまとまっていた。 https://capelski.medium.com/effective-code-sharing-in-typescript-monorepos-475f9600f6b4 上記の記事の構成も参考にしつつ、自分の考えも加えて検証していく。 相対パスを利用する方法 npmのローカルパス指定(file:xx)を利用する方法 シンボ

                                                    TypeScriptのモノレポ構成を考える
                                                  • Secrets from the Algorithm: Google Search’s Internal Engineering Documentation Has Leaked

                                                    Google, if you’re reading this, it’s too late. Ok. Cracks knuckles. Let’s get right to it. Internal documentation for Google Search’s Content Warehouse API has leaked. Google’s internal microservices appear to mirror what Google Cloud Platform offers and the internal version of documentation for the deprecated Document AI Warehouse was accidentally published publicly to a code repository for the c

                                                      Secrets from the Algorithm: Google Search’s Internal Engineering Documentation Has Leaked
                                                    • GitHub - webui-dev/webui: Use any web browser as GUI, with your preferred language in the backend and HTML5 in the frontend, all in a lightweight portable lib.

                                                      You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                                        GitHub - webui-dev/webui: Use any web browser as GUI, with your preferred language in the backend and HTML5 in the frontend, all in a lightweight portable lib.
                                                      • 今年の書初めコーディングはAITuberを創る!

                                                        はじめに あけましておめでとうございます。去年は何といってもAIの年でした。ChatGPTやStableDiffusionが2022年末に登場してから、想像を超えてAI周りが進化しましたね。今回は年の初めという事もあり、前から興味のあったAITuberを作ってみる事にしました。 「AITuberを作ってみたら生成AIプログラミングがよくわかった件」 って本も買ったし。LLM部分だけでは無く、OBSやYouTubeのコメント取得などAITuberに必要な内容が一式揃っていて非常に参考になりました。 また、私はプログラミングは多少できますが、イラストや音楽に関しては全くスキルの無い人間です。そのためそのあたりに関してはStable DiffusionやSunoAIの力を借りて作っているので、結果的にオール生成AIという感じですね。そのあたりも含めて記事にまとめたいと思います。 TL;DR 素の

                                                          今年の書初めコーディングはAITuberを創る!
                                                        • フロントエンド監視の全体像と実現方法

                                                          必要性 フロントエンドの監視はバックエンドやインフラのそれらと比べ、優先度が低くなりがちです。 バックエンドやインフラでの障害はサービス継続に直結するため、これは当然と言えば当然なのですが、別の理由もあると考えています。 それは計算リソースをサービス提供側が管理していないことです。 例えばアプリケーションがインフラとして AWS を利用しているなら、AWS のリソースを管理するのはサービス提供側です。 これは AWS 以外のクラウドサービスプロバイダやオンプレであっても同様です。 一方でフロントエンドはエンドユーザのブラウザ上で動作し、これを管理しているのはエンドユーザです。 フロントエンドはその性質上、監視の「盲点」になりがちです。 しかしフロントエンドはエンドユーザが直接触れるものであるため、そこで何が起きているかサービス提供側は正確に把握する必要があります。 マイルストーン フロント

                                                            フロントエンド監視の全体像と実現方法
                                                          • 「理論上は最強」の Qwik/QwikCity を、フロントエンドの共通基盤にできないか

                                                            Qwik をマイクロフロントエンド基盤として使えないか検討していて思いついた色々。副産物で色々作った。 tl;dr Qwik は理論上は最強。だが難しい qwik-react を使えば選択的に Qwik/React を切り替えられるので、 Astro と同じメタフレームワークとして使えそう React 以外もその気になれば対応できるはず => qwik-svelte と qwik-vue を実装した 最終的な問題は Qwik が流行るかどうか Qwik/QwikCity とは何か Qwik は SSR First なUIライブラリで、 .tsx の React 方言からコンポーネントを生成する。 import { component$, useSignal } from '@builder.io/qwik'; export default component$(() => { return

                                                              「理論上は最強」の Qwik/QwikCity を、フロントエンドの共通基盤にできないか
                                                            • 【React / useHooks】開発不要で使える便利なカスタムフックス20選

                                                              フロントエンドで処理をカスタムフックス化する際、windowの高さを取得するなど、どのプロジェクトでもある程度決まったコードがありますよね。 useHooksはそういったカスタムフックスのライブラリとなっています。カスタムフックは自前で作ってしまうことが多いものの部分的に任せられるかなと思い、useHooksに登録されている便利そうなカスタムフックスをピックアップしてみました。 useHooksを使うにあたって カスタムフックスは自前で用意する方がカスタマイズ性高く安心して使える 調べれば同じ機能を持つカスタムフックのコードが出てくるので必ずしもuseHooksを使う必要はない プロトタイプ開発とかで速度が求められるなら導入するのはありかも 最初からこういうのに慣れすぎると開発理解があやふやになるのではといった議論はありそう こういうカスタムフック置くと便利だなという確認にも良さそう 結論

                                                                【React / useHooks】開発不要で使える便利なカスタムフックス20選
                                                              • Vike

                                                                Like Next.js/Nuxt but as do-one-thing-do-it-well Vite plugin. 🔧 ControlUse any UI framework (React, Vue, Svelte, Solid, ...) and any tool you want (any frontend library, web technology, deploy environment, Vite plugin, ...). With Vike, you integrate tools manually and keep architectural control. 📦 Zero-configVike gives you control only where it matters. Everything else just works without the nee

                                                                  Vike
                                                                • フロントエンドで収集するべきテレメトリは何か

                                                                  先日『フロントエンド監視の全体像と実現方法』という記事を投稿しましたが、その中でテレメトリについては触れませんでした(※本記事は上記記事の内容を知らなくても読み進められるようになっています)。 というのは、テレメトリは可観測性を実現するための重要な概念ではあるものの、テレメトリを軸に監視を考えるのは手段の目的化になってしまうと考えているからです。 重要なのはサービスにとって何を観測するべきかを考えることであり、テレメトリはそれを設計や実装に落とし込む際に現れるものです。 一方で監視に対する理解を深める上では、テレメトリを軸に考えることも重要でしょう。 そこで本記事ではフロントエンド監視においてどのようなテレメトリを収集するべきか述べていきます。 監視 SaaS と OpenTelemetry (OTel) Datadog, New Relic, Sentry のいずれかを利用することを考え

                                                                    フロントエンドで収集するべきテレメトリは何か
                                                                  • ソースコードのハッシュ値を利用したCIの高速化 - Cybozu Inside Out | サイボウズエンジニアのブログ

                                                                    こんにちは、kintoneチームの川向です。 ソースコードハッシュ値計算ツールであるsverを導入してCIの高速化を行ったので、その紹介をさせてください。 この仕組みにより、通常は1時間かかるCIの実行時間が最善のケースでは20分程度に短縮可能になりました。 導入前の課題 解決方法の検討 sverを使ったテストのスキップによるCI高速化 kintoneでのsverの利用方法 sver設定ファイルの書き方 キャシュの保存先(GitHub Actions Cache、Amazon S3) sverを使ったジョブの書き方 sver情報生成ジョブ: ハッシュ生成とキャッシュの存在確認 ビルドジョブ: 依存ファイル以外に依存しないことの確認 テストジョブ: ジョブ成功後にキャッシュ保存 下流ジョブのifの書き方 結果 課題と今後の展開 まとめ 導入前の課題 kintoneのCIの大まかな構成は以下の

                                                                      ソースコードのハッシュ値を利用したCIの高速化 - Cybozu Inside Out | サイボウズエンジニアのブログ
                                                                    • Next.jsを4年間使用してたどりついた、エンタープライズアプリケーションのフロントエンド開発・構築手法 | POSTD

                                                                      はじめに 目まぐるしく進化するフロントエンド開発の世界では、常に最新の知識や技術をいち早く取り入れることが、エンタープライズアプリケーションの開発を成功させる上で欠かせません。Tailwind CSS、TypeScript、Turborepo、ESLint、React Queryなどを含む強力なツールキットとNext.jsを4年間使用してきた結果、開発に役立つさまざまな知見やベストプラクティスが得られました。この記事では、大企業向けフロントエンドアプリケーションのパフォーマンス、保守性、拡張性を最大限に高める設計・構築手法を紹介したいと思います。 注記:ここに記載する内容はあくまでも個人的な見解であり、筆者が推奨する手法が必ずしも適さない場合もあります。 効果的なエンタープライズ向けフロントエンドアーキテクチャの基本原則 エンタープライズ規模のアプリケーション向けにフロントエンドソリューシ

                                                                        Next.jsを4年間使用してたどりついた、エンタープライズアプリケーションのフロントエンド開発・構築手法 | POSTD
                                                                      • HTML First

                                                                        HTML First is a set of principles that aims to make building web software easier, faster, more inclusive, and more maintainable by... Leveraging the default capabilities of modern web browsers. Leveraging the extreme simplicity of HTML's attribute syntax. Leveraging the web's ViewSource affordance. Goals The main goal of HTML First is to substantially widen the pool of people who can work on web s

                                                                          HTML First
                                                                        • The Front End Developer/Engineer Handbook 2024

                                                                          This guide is open source, please go ⭐️ it on GitHub and make suggestions/edits there! https://github.com/FrontendMasters/front-end-handbook-2024 1. Overview of Field of Work This section provides an overview of the field of front-end development/engineering. 1.1 — What is a (Frontend||UI||UX) Developer/Engineer? A front-end developer/engineer uses Web Platform Technologies —namely HTML, CSS, and

                                                                            The Front End Developer/Engineer Handbook 2024
                                                                          • GraphQL Gatewayはフロントエンド開発を幸せにする

                                                                            はじめに マイクロサービスの開発では、サービスが増え続けるバックエンドに対して、フロントエンドは接続先が増えるため、開発効率を下げてしまいます。その対策として、さまざまな設計パターンが存在します。 弊社の開発ではGraphQL Gatewayを用いていますが、そこに至るまでや周辺の技術/アーキテクチャを解説します。 マイクロサービスとフロントエンド マイクロサービスを採用する場合、フロントエンド(ウェブアプリケーション、モバイルアプリケーションなど)は複数のサービスとの連携が必要になることが多いです。各マイクロサービスは通常、API(REST、gRPCなど)を提供し、フロントエンドはこれらのAPIを通じてデータの取得や操作を行います。 API Gateway API Gatewayは、フロントエンドとマイクロサービス間の中間に位置するコンポーネントとして機能し、マイクロサービスアーキテクチ

                                                                              GraphQL Gatewayはフロントエンド開発を幸せにする
                                                                            • Next.js に対する Kent C. Dodds の批判と、Lee Robinson のアンサーの要約

                                                                              Next.js に対する Kent C. Dodds の批判と、Lee Robinson のアンサーの要約 はじめに 10 月 26 日に Next.js Conf が開催されましたが、それと前後して Kent C. Dodds (以下 kentcdodds と呼びます) と Lee Robinson (以下 leerob と呼びます) がそれぞれ という記事を公開しました。前者はタイトルの通り、Testing Library の作者であり、Remix の共同創業者の一人でもある開発者兼教育者 kentcdodds が、Next.js を使わない理由について述べたものです。そして後者は、Vercel の VP of Developer Experience である leerob が、主に前者に対する反論を述べたものです。筆者は両方の記事を公開後すぐに面白く読み、そしてどちらにも頷けるところ

                                                                                Next.js に対する Kent C. Dodds の批判と、Lee Robinson のアンサーの要約
                                                                              • Structured Logging with slog - The Go Programming Language

                                                                                Jonathan Amsterdam 22 August 2023 The new log/slog package in Go 1.21 brings structured logging to the standard library. Structured logs use key-value pairs so they can be parsed, filtered, searched, and analyzed quickly and reliably. For servers, logging is an important way for developers to observe the detailed behavior of the system, and often the first place they go to debug it. Logs therefore

                                                                                  Structured Logging with slog - The Go Programming Language
                                                                                • モバイルとの相性最強と言われるgRPCをFlutter x NestJSで実装し、Stream通信や認証、複数言語実装に使えるか試す

                                                                                  まとめ 相性バツグンといわれる、モバイル x gRPCは思ったよりずっと簡単に実装可能 複数言語間でもProtocol Buffersの恩恵により型変換を意識することなくスムーズに開発が進められる。 メソッド、引数の型、引数の返り値の型が自動生成されるのでとても良い RESTful APIにおけるheaderを、表現力の高いMetaDataとして利用し、認証認可等にも使えそう Streamをうまく使いこなせば、ユーザー体験をめっちゃ高くできそう。チャットやゲームなどの双方向通信が比較的楽に実装できるかも どんな人向きでない記事? NestJSの詳しい実装を知りたい方 Bidirectional streaming, Client streamの詳細実装を知りたい方 モバイル向け通信技術の本格的な選択肢、gRPCを実際に試してみたい 現在、私の働いているMinediaで開発しているサービス群

                                                                                    モバイルとの相性最強と言われるgRPCをFlutter x NestJSで実装し、Stream通信や認証、複数言語実装に使えるか試す