はてなブックマーク

はじめに 皆さんはaタグにaタグを入れ子にしたいと思ったことはありませんか？もしかしたら意外とないかもしれないですね笑🤓 例えばQiitaの記事カードのUIなどは複数のリンク先を内包するカードになっていますが、カード全体もaタグとして機能しています。 （出典: https://qiita.com/ ） こういった場合に単純に下記のようにマークアップすることはできません。 <a href="/article/1"> <a href="/user/1">@UserName</a> <a href="/article/1">記事のタイトル</a> </a> Next.jsの場合、開発環境では下記のようにエラーになります。 In HTML, <a> cannot be a descendant of <a>. This will cause a hydration error. 理由は、aタグは

概要 LLMを使った業務効率化を目的とした社内ツールとして「人事評価の目標作成壁打ちチャットボット」を作成し、社内に公開することができました この記事では、LLMを使ったチャットボットの作成方法や社内への公開方法について紹介します。 人事評価の作業は皆さん苦労されていると思うので、この記事が少しでも参考になれば幸いです。 チャットボットの紹介 どのようなチャットボットなのか利用方法についてまず紹介します Step1. 前提情報を入力 自分の等級（ランク）やチームの目標、半期や通期で取り組む案件やタスクなどの情報を事前に入力が求められます。 入力が求められる項目は以下の通りです 壁打ちしたいランク（必須） 例：G1やG2などのランク 職務（必須） 例：〇〇営業、〇〇人事、〇〇エンジニアなど チーム目標（オプション） チームとして半期や通期の目標が掲げられていれば入力 チームとして目標達成のた

はじめに 実装したいのはこんなパララックスです。 各セクション間に背景画像が見えていて、セクションごとに異なる画像に切り替わります。 これを2通りの方法で実装してみます。 background-attachment: fixed で実装 position: fixed + clip-path で実装 先に書いておくと、background-attachment: fixed を使う方法はiOS Safariでうまく動かなかった（2024年9月時点）ため、実際のプロダクトでは後者の方法で実装しました。 必要に応じて前者は読み飛ばしてください。 1. background-attachment: fixed で実装 特筆ポイントは、background-imageを指定している要素にbackground-attachment: fixed;を指定している点です。 背景画像を固定してくれます。

はじめに フロントエンドエンジニア組織の部署内[1]で毎週読み合わせ会を開催している。開始してから1年半が経ち、執筆時点では開催回数は70回を超えた[2]。 きっかけ 毎週、それまでは個人でJSer.infoを読んでいたのだが、ほかのメンバーとの実務に関する会話の中で「（この話題は）JSer.infoでも取り上げられていたなー」などと思う場面もあり、いっそのこと「皆でパブリックに読む機会を作るのが良いでは…」と考え、読み合わせ会を開始することにした[3]。 読み合わせ会とは 大まかには以下のような形式で実施している。 開催方法： Slackのハドルを利用 所属部署のrandomチャンネルで実施 開催頻度と時間： 毎週1回、1時間程度 ファシリテーター： 筆者（主催者） 参加者： 任意参加（出欠報告不要）・聞き専OK・発言自由 部署外や業務委託のメンバーが参加することもある 形式： 画面共有

概要 Dify v0.6.11で利用可能になったFirecrawlでWebサイトのナレッジ登録が可能に SaaS版のFirecrawlは無料だと500回のリクエスト制限がある OSS版のFirecrawlは無制限でリクエストが可能 この記事ではローカルでOSS版のFirecrawlを立ち上げDifyと繋げる方法を紹介 前提 DockerやGitコマンドが使える ローカル上にDifyが既に起動している OSS版Firecrawlをローカル起動 クローン OSS版Firecrawlは下記で活発に開発が行われています。 このリポジトリをローカルにクローンします

はじめに 私の所属するチームではPRレビューが滞る問題を抱えていました。 チームメンバーがそれぞれ小さなプロジェクトを複数抱えている場合には、要件の把握などでレビューの難易度が上がるため特に顕著でした。 そのため、PRレビューを早めることに関心がありチームで色々試していたのですが、その中でも重要だと感じた2つの要素があります。 それぞれ重要でよく耳にする指標ですが、2つ揃った時にこそ大きな効果を発揮したと感じているので紹介させていただきます。 基本的にはgoogleのコードレビューガイド(日本語版)を参考にしているところが大きいです。 1つ目の鍵: PRの粒度(≒タスクの粒度)を小さくする PRで重要なことは？と言えばこれってくらいによく耳にしますがやはりこれです！ 適切なPRの変更行数は200から400行程度である(※参考)なんて言われていたりもしますね。 私はPRの粒度≒タスクの粒度と

:has()の登場以前 :has()が利用できるようになり、CSSでの表現力は飛躍的に上がっている（:has()は最近のモダンブラウザならどれでも利用できるような状態である）。 Chrome Edge Safari Firefox Safari on iOS

本稿は、 ZOZOTOWN 開発本部のフロントエンドエンジニア有志で開催されている、スタイル分科会にて挙がったテーマを記事にしたものです。 この記事で分かること isolation: isolate; がどのような場面で有用かを解説します。 複数のコンポーネントを配置したとき、それぞれの z-index が競合したケースを例に用います。 前提 それぞれ position: absolute; の要素を内包する、 2 つのコンポーネントを横並びで配置します。 デモ メニューに hover してみてください。デフォルトでは、表示される子メニューが他のコンポーネントの z-index に負け、表示が崩れてしまいます。 「z-index の競合を解決する」ボタンを押下すると、子メニューが正しく表示されるようになります。 解説 実装コード 2 つのコンポーネントを、 マウスオーバーメニュー と カー

この記事は 2023 年 11 月 6 日に行われた ZOZO Tech Meetup - Web フロントエンドで発表した資料を記事にリライトしたものです。 資料だけでは伝わらない部分や、もっと詳細に触れたい部分もあったので記事にしました。 当時の発表資料は以下です。多くの部分では同様のことが記載されていますが、細部や扱う内容を若干変えています。 はじめに 3 年前にコンポーネントではなく Hook 自体をテストしたいというモチベーションから「React Hooks でテストをゴリゴリ書きたい」という記事を書きました。 この記事を書いた当時は Hook やコンポーネントで使われる関数がそれぞれ正しく動いていることが確認できれば、それらを組み合わせて作るコンポーネントもある程度正しいことが担保されるではないかと考えていました。 また、コンポーネントは JSX が書かれていて DOM 構造と

プロローグ 私は新規のプロジェクトを立ち上げるときにVanilla-Extractを採用しました。 型安全なCSSがかけることやスコープをもたせることができ、管理画面のような肥大化しやすいプロジェクトでの導入が望ましいと考えたためです。 しかし、この考えは現在打ち砕かれてしまいました。 泣く泣くVanilla-Extractの導入を諦めSASSでの開発をしていたときStyleXのリリースのニュースが飛び込んで来たのです。 Type-Safeで再利用可能であり、静的なCSSのパフォーマンスとスケーラビリティを手に入れられるとのこと。 これを逃すわけにはいきません。早速詳細を確かめ、次回新規プロジェクトが立ち上げるときに候補にできるのかを確かめましょう。 概要 この記事ではVanilla-Extractで問題だったことを振り返りつつ、StyleXではどのような構文が採用されVanilla-Ex

はじめに この記事は　ZOZO #2 Advent Calendar 2022 1日目の記事になります。 Elasticsearchに大量のデータを投入して、様々な検索処理を実験したいと思いました。 このような場合、よくWikipediaのデータが利用されますが、巷のWikipediaのデータをインデクシングする記事が古くて、最新の環境だと難航したので、今回まとめることにしました。 やること３行 Dockerで環境構築 Wikipediaのデータをダウンロード＆整形 整形したデータをElasticsearchにインデクシング 環境 M1 Mac Docker & Compose v2 イメージ：Python 3.10 準備 Elasticsearchにインデクシングするためのデータを用意したり整形したりといった準備について以下では説明しています。 最終的なファイル構成 最終的なファイル構成

GitHub Pages に新しいデプロイ方法が来た まだ Beta ですが、 ついに公式から Pages にデプロイする方法が提供されました。 いままで いままで GitHub Pages へデプロイする際は、ブランチを指定する方法や、デフォルトブランチの特定のディレクトリを指定していました。 また、これを GitHub Actions で行うために、日本人作者の peaceiris/actions-gh-pages を利用したことがある人も多いと思います。 （記事のアイコンは畏敬の念を込めて作者のアイコンっぽい絵文字にしました） これから これからは、gh-pages ブランチなどリポジトリを汚染せずに GitHub Pages へのデプロイが可能になります。 peaceiris/actions-gh-pages からの乗り換え 以下の 2 つを用いることで対応できます。 action

概要 各コンポーネントに指定するz-indexの値を定義する。 モチベーション z-indexの衝突を避けたい z-indexの指定を理由を明確にしたい コンポーネントが増えるたびにz-indexの定義を増やしたくない 前提知識 重ね合わせコンテキスト（スタッキングコンテキスト）という概念があることを前提に話を進めるため、以下のページを合わせて読むと理解がしやすい。 重ね合わせコンテキスト - CSS: カスケーディングスタイルシート | MDN （スタッキングコンテキスト） isolation - CSS: カスケーディングスタイルシート | MDN z-indexのルール 複雑さを避けるため以下のルールを設ける。 各コンポーネント内のz-index指定を極力少なくする z-indexは0から4までの値を使用する（後述のLayer Stackに基づく指定をする） -1などの負数は使用しな