レイアウトシフトとは、Webページがロードされる時に画像のスペースが確保されず、画像が表示された時にその分レイアウトがずれてしまうことです。 このレイアウトシフトを回避するために10年以上もの間、アスペクト比を手動で適用する必要がありました。しかし、現在ではそんな馬鹿げたハックは必要ありません。最近登場した2つの優れた解決方法を紹介します。 Avoiding <img> layout shifts by Jake Archibald (@jaffathecake) 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 レイアウトシフトとは aspect-ratioプロパティによるレイアウトシフトの回避方法 widthとheightによるレイアウトシフトの回避方法 どちらの方法を使用すべきか レイアウトシフトとは デフォルトでは、<im

資金調達に成功し、スタートアップとして飛躍的に成長を遂げる「最もエキサイティングな時期」こそ、経営者として一番つらかった。今回は私にとってのハードシングスについて話します。

jQuery <=> JavaScript全書き換え一覧ではありません jQueryで書いていたコードをvanilla(素のJavaScript)に書き換えたいけど書き方がわからなくて調べ方もピンとこない状態の自分がこれを見ることができたらきっと嬉しいと思ったのでここに供養します。 脳の記憶容量が8バイトくらいしかないので今でもシンプルにJavaScriptの書き方をページ内検索して使ったりしています。 /*----------------------------------- セレクター ------------------------------------*/ //html $("html") document.documentElement; //body $("body") document.body; //id $("#hoge"); document.getElementBy

子要素を親要素からはみ出して画面いっぱいにするは、今までであれば親要素から出してコーディングし直すというのが一般的でした。 ただし、今ではcalcとvwとい新たなCSSの概念があるので、子要素を親要素からはみ出して画面いっぱいにするということが簡単にできるようになっています。 この記事は、その具体的なCSSの実装方法について紹介していきます！（結論から言うと、以下のとおりですが…） 📝 inner幅からはみ出して横幅いっぱいにするCSS わざわざコンテナーを作り直す必要がなくて、自然なHTMLのままでコーディングできます！ — .hoge { margin: 0 calc(50% – 50vw); width: 100vw; } — ピンクのエリアがインナーで、そこからはみ出して画面いっぱいになる pic.twitter.com/8wBUiw7Nzd — はにわまん (@haniwa00

みなさん、こんにちは。 ユーザベースという会社でSaaS事業のCTOを務める林 尚之です。 本日、新しいWebメディア『Agile Journey』がローンチされました。私はこのメディアに編集長として関わりますが、本稿では『Agile Journey』がどんなメディアで、なぜアジャイルをテーマとしたメディアを立ち上げたのかをお伝えしたいと思います。 『Agile Journey』はできるかぎり「実践」にフォーカスしていきたいと考えています。すでに世の中には、アジャイルに関する事柄を解説する本や資料がたくさんあり、「ペアプロってなに？」「TDDってなに？」という問いに対する基本的な解は容易に見つかるでしょう。しかし、「やり方を知る・理解する」と、「それをいかに実践するか」には別の難しさがあります。実際、私も「アジャイルをいかにして、実践するか」に関して日々、頭を悩ませていますし、試行錯誤を繰

こんにちは、プロダクトマネージャー（以下PM）の adachi です。（ToDo: ここになにか面白い文章を入れる） 先日、プロダクトの目的・目標・指標をまとめた図をTwitterに投稿したところ、わりと反響があったのでこちらで解説したいと思います。 開発メンバーから「会社の戦略とプロダクトの目標がどう紐付いてるかわからない」という声をもらって作った図。 改めて整理する中で自分のなかでも気付きがあり、もっと早くやっておけばよかったなと思いました。 pic.twitter.com/tuedZhaZG2— Takashi Adachi (@asanebo_) 2022年6月1日 この記事でお伝えしたいこと 会社のミッションや戦略とプロダクトの目的・目標・指標は、構造的に整合していることが重要である PMにとって自明に思えることでも、アウトプットしなければチームで共有できない 目的・目標・指標の

今回は、プロダクトバックログの優先順位付けに関する記事になります。 皆さんのプロダクトオーナーは、プロダクトバックログを”フェア”に管理していますか。発言力のあるステークホルダーから言われるがままにリリースしていたり、不要な項目でバックログが溢れかえっていませんか。 プロダクトバックログは、発言力などに影響されず、”フェア”に価値を見極めて決める必要があります。 今回は、スクラムを前提に優先順位の決め方や重要性について解説していきたいと思います。 プロダクトバックログとはバックログというのは、優先順位付けされた作業リストです。つまり、プロダクトバックログとは、プロダクトに関する作業に優先順位付けされたリストになります。 この”作業”とは、改善に必要な新機能、バグ、技術的負債などを意味します。Todoタスクのような細かい作業を意味するものではありません。 各スプリントで取り組む作業は、プロダ

概要 こんにちは、Offers を運営している株式会社 overflow の Software Engineer（主戦場はフロントエンド）の Kazuya です。今回は、UI コンポーネントの Props 設計について紹介します。 コンポーネントを初めて作る方や作り慣れていない方は、どのような Props 設計にすれば、汎用的にできるのか、どこまで Props に持たせるべきか悩んだことがあるのではないでしょうか。本記事では、具体的な実装例を元に解説していきますので、ぜひ参考にしてもらえればと思います。 おすすめの記事 はじめに 本記事では、UI コンポーネントの Props 設計と具体的な作り方を紹介します。基本的に他のフレームワークや言語でも活用できますが、チームメンバーのスキルアセット、要件定義など様々な要因で本記事で紹介する内容とマッチしない場合があります。今回は設計の一例であるこ

【2022/07/04追記】 この記事の結果に至るまでを示した補足記事を書きましたので、良ければ見て頂けると嬉しいです。 tech.commmune.jp はじめに これは何？ 誰向けの記事？ 自己紹介 前提：「ベロシティの安定」とは 取り組み導入の背景 属人性を減らす取り組みの一覧 ① WIP制限 どうやったか 得られた成果 補足 ② タスクサイズの制限 どうやったか 得られた成果 ③ 死亡前死因分析（プレモーテム） 死亡前死因分析とは？ どうやったか 得られた成果 全ての取り組みの結果 得られた成果 何故この成果を得られたか？ 注意点 まとめ 最後に はじめに これは何？ スプリントの属人性を回避しようと取り組んだらベロシティが安定したので、実際に行った以下の取り組みを紹介する記事 WIP制限 タスクサイズの制限 死亡前死因分析 誰向けの記事？ スクラム最初の壁であるベロシティの安定化

Atomic Design は難しい Webフロントエンド開発をしている人で Atomic Design を用いた経験がある方に会った時は、必ず 『Atomic Designどうですか？』と聞くようにしています。 大体の方はちょっと苦笑いをしながら『やっぱり難しいですねぇ』とか『試行錯誤しながらで...』みたいなことを教えてくれます。 私もメインの開発をする際に Atomic Design という枠組みを用いています。そして、同様に色々と悩んだのですが、このあたりについて納得がいく解釈ができたと思っています。 そこで、私の思う Atomic Design の難しさや、そう思う原因、どうやってそれを解消するかという点について、https://atomicdesign.bradfrost.com/ を適宜参照しながら共有したいなと思います。 そもそも Atomic Design 何やねん。な方

2019年1月30日、株式会社Re:Buildが主催するイベント「【Nuxt.js/Vue.js】スタートアップ企業導入事例」が開催されました。近年注目を集めるNuxt.jsやVue.jsを実際の開発現場でどのように活用しているのか、スタートアップ4社が集い、自社の取り組みを語ります。プレゼンテーション「SPA開発未経験者によるNuxt.jsを使った自社サービス開発」に登壇したのは、株式会社リビルドの嘉数侑起氏。講演資料はこちら SPA開発未経験者によるNuxt.jsを使った自社サービス開発 嘉数侑起氏（以下、嘉数）：みなさん、こんばんは。「SPA開発未経験者によるNuxt.jsを使った自社サービス開発」というタイトルで、プレゼンさせていただきます。株式会社Re:Buildの嘉数と申します。よろしくお願いします。 こちらがアジェンダです。 今回、Nuxt.jsをこれから導入しようと検討し

概要 内容に応じてサイズが可変する textarea を、できるだけ手間をかけず、スマートな実装を試みます。 しかも、ネイティブのフォームが持っている利点をそのまま活かして、堅牢でアクセシブルな設計を目指します。 標準 textarea の難点 HTML の textarea 要素は基本的に高さが固定されていて使い勝手が悪いです。３行分くらいしか領域がなくて、長い文章を打つのがとにかく苦痛なんていうこともザラです。 最近のブラウザ実装では、多少気を利かせてくれているのか、テキストエリアの領域をドラッグで拡大・縮小できます。 ただ私は思うのです。めんどくさいし、最初っから、入力するテキスト量に応じて自動的に伸び縮みしてくれればいいのに……と。スクロールバーなんて、１ページにひとつあればじゅうぶんなんですよ。 実装方法 難しいことはありませんが、HTML と CSS、JS が協調して動作します

概要 こんにちは、Offers を運営している株式会社 overflow の Software Engineer（主戦場はフロントエンド）の Kazuya です。今回は、React や Vue.js などの SPA フレームワークにおけるコンポーネント設計について紹介します。 昨今のフロントエンド開発では、コンポーネント指向での開発がスタンダート化しつつありますが、コンポーネント設計には厳格なルールが無く、どのように設計すればいいか悩む方も多いのではないでしょうか？（筆者は沼にはまりました） コンポーネントの単位はどの程度に分割すべきなのか、状態管理はどうすればいいのか、API 通信はどこですべきなのかなど、一言にコンポーネント設計と言っても考えるべき項目が多いです。チーム開発では、認識があっていないとコードが魔境になることもしばしばあると思います。（筆者の経験談より） そこで今回は、数々

Offers を運営している株式会社 overflow の あほむ です。「〜を支える技術」的な技術評論社さまの伝統的パンチラインに感化されてしまう世代です。 文書校正の自動化でおなじみの textlint textlint は JSer.info や JavaScript Primer でおなじみの azuさん が開発されている OSS です。 ESLint に代表される各種 Lint ツールの自然言語バージョンです。プレーンテキストや Markdown テキストを対象にいわゆる文章校正を自動的に走らせて、ルールによっては自動修正も適用できます。 弊社のテックブログは GitHub リポジトリで zenn のコンテンツを管理 しており、そのリポジトリ上で textlint を使ってルールに従った文章校正の自動化を試みています。 GitHub Actions の設定 設定はシンプルで Pu

広木です。 いろいろ、時が流れるとそのときどきの時代背景のようなものやコンテクストが失われてしまうことがよくあります。すると、手段が目的化するとか主客の転倒などが起きてしまい物事がうまくいかないなんてことになります。 たとえば、採用支援をしているとエンジニア採用をするために、エンジニアブログをやろうとするがあまりうまくいかないという話をよく聞きます。 なかなか書いてくれるエンジニアがいなかったり、いても他のエンジニアブログみたいにバズったりするわけじゃないしなどなどです。 これも主客の転倒が起きているんだと思います。 実際は別にどの会社もエンジニアを採用するためにエンジニアブログを書いているわけじゃないのです。書きたいから書いているし、役に立つから書いているし、そういう発信があるから良さそうな文化を感じ取ってたまたま採用につながることもあるだけなんです。これは結構当たり前のことではあるんで

先に結論書いてしまいますと、全部公式ドキュメントに書いてあります。 でも、書いてある箇所がバラバラなので 先に公式ドキュメントをちゃんと目を通していれば混乱しないのでしょうが、 ちゃんと読まずにいきなり現場のソースコード読んで、まぁどうにかなんだろうと思ったら ん？この <template> と <template> はなんか違うの？？ と混乱してしまった人（私です）向けにまとめました。 <template> タグには以下の役割があります。 条件付きレンダリングで複数要素を対象とする場合（v-if） リストレンダリングで複数要素を対象とする場合（v-for） 名前付きスロット（v-slot） 単一ファイルコンポーネント 条件付きレンダリングで複数要素を対象とする場合（v-if） 公式ドキュメントはこちら https://jp.vuejs.org/v2/guide/conditional.h

今年も書きます。 kths.hatenablog.com kths.hatenablog.com 能力主義のパラドックス 自分が客観的で公正な人だと信じてしまうことで、偏向した行動をとってしまう現象を「能力主義のパラドックス」というそうです。 韓国で16万部超のベストセラーとなった『差別はたいてい悪意のない人がする』では、全員に同一の基準を適用することが、だれかを不利にさせてしまう間接差別の例について紹介されています。 だれに対しても同じ基準を適用することのほうが公正だと思われるかもしれないが、実際は、結果的に差別になる。司法書士試験で、問題用紙・答案用紙と試験時間をすべての人に同一に設定すれば、視覚障害者には不利になる。製菓・製パンの実技試験において、すべての参加者に同じように手話通訳を提供しない場合、聴覚障害者に不利である。公務員試験の筆記試験で、他の受験生と同様、代筆を許可しない場合

こんにちは。株式会社スタメンでFANTSのフロントエンドを担当している@0906kokiです。 今回の記事では、FANTS におけるフロントエンドのテスト戦略について書きたいと思います。 🙋🏻‍♂️ はじめに みなさんはフロントエンドのテストを書いていますでしょうか？ 私が所属しているチームでは、今まで全体的なテスト指針が明文化されていなかったので、機能によってテストが書かれたり書かれなかったり、テストを書くにしても個人によって書く粒度にバラツキがありました。 直近でフロントエンドを書く人が増えていく / プロダクトがスケールしていくにつれて、そうしたバラツキによって生まれるコミュニケーションコストが大きくなってきたり、システム的な安全性を継続的に担保していくことが難しくなっていくように感じました。そのため、今まで方針を定めていなかったテスト戦略を、これから事業やプロダクト、チームがス

Webエンジニアを始めて丸2年が経ちました。 複数プロジェクトを進める中で、CSSコーディングを行うときの「こうしておくと便利」「このほうが管理しやすい」といった知見が溜まってきたのでまとめます。 はじめに 長くなってしまった細かい説明はところどころ折りたたんでいます。概要だけで理解できたら飛ばしていただき、詳しい話が気になったら開いて読んでください。 これらは「自分がよく取り入れている手法」であって、必ずしもどのプロジェクトにも当てはまるものではないと思います。 各項目について、自分がその判断に至った 「理由」 を説明していますので、 理由を読んだ上で自分のプロジェクトに取り入れるか判断いただくと良いと思います。 この記事は、すでにCSSコーディングをしていてアイデアがほしい人に向けた記事で、 CSSをこれから学び始めるような 初学者向けではない ことご了承ください。 一般的と思われるキ