containプロパティにstyleやsizeを指定した場合に、どうレンダリングされるかをご紹介します。 CSS Containmentの概要については「CSS Containmentの仕組みを理解してレンダリングパフォーマンスをアップする1 概要」をご確認ください。 タイトルを「レンダリングパフォーマンスをアップする」としていますが、今回ご紹介するstyleとsizeはパフォーマンスを向上するものというよりは、包含ブロックの内外でスタイルの計算やサイズの計算を分けることを目的としています。 styleの検証 contain: style;の設定の有無によるcounter()のカウントの違いからStyleの封じ込めを検証します。 containプロパティの設定がない場合 containプロパティの設定がないブロックを2つ用意します。 ブロックをまたいでそれぞれのブロック内の要素をカウントす
知らない景色を見に行こう チャンスを掴んだら道が開けたマネジメントの旅 / Into the unknown~My management journey~
前回は、「UIデザインってそもそも何なの？」という概論的な説明と、UIデザイン未導入の組織の中でみんなでデザインを始めてみるための施策（プロトタイピングとユーザビリティ評価）を話しました。 今回はサービス、プロダクト開発において、デザイナーではない人でも知っていて損はないUIデザインの重要ポイントについて説明します。主に以下の３つのテーマについて順番に議論をしていきます。 デバイスやソフトによるUIの違い ユーザーにかかる身体的・認知的負荷を理解する UIの重要概念（ナビゲーション、インタラクションなど）を知る 「ちょっと」と銘打っておきながらめちゃくちゃ長いnoteになってしまったので、気になる項目だけ読むか、何回かに分けて読んでいただくことをおすすめします、。 ※どこか内容に間違ってる部分やご意見ありましたらコメントいただけたら嬉しいです。 なお、こちらの記事の内容は順次YouTube
プロジェクト全体のテストを組み立てる際に重要な課題になるのが、テストレベル設計です。テストレベル設計は、ユニットテスト、結合テスト、システムテストといったテストレベルを、どのような責務・段取りで行うか分析・設計する活動です。 このテストレベル設計ですが、ここ10年程度の間に望ましいアプローチが変わってきたと感じています。今回はこの変化と、変化後のモダンなテストレベル設計の原則について、考えていることを書き出したいと思います。 旧来のテストレベル設計のアプローチ 旧来、このテストレベル設計では、Vモデルをベースしたアプローチや、自工程完結・品質積み上げをベースとしたアプローチがよく見られました。 このうち一つ目のVモデルをベースとしたアプローチは、要求定義から設計までの上流工程への対応を観点に、テストレベルを設計するものです。 （Vモデルが必須と明言しているわけではなく、極端な例ですが）例え
・Windowsのセットアップを自動化する おつかれさまです。長崎のあいつです。 皆様も、週末になるとハードオフに行ってジャンクPCを拾ってきては修理し、使いもしないのにセットアップと環境構築の苦行に勤しんでいるかと思い……拾ってこない？セットアップもしない？そうですか。そうでしたか。この話は終わりだ！解散だ、散れ！散れ！！！！！ 気を取り直して。 テストや検証、再構築やご奉仕メンテナンスなどでWindowsを新規セットアップ→環境構築することが多いので、ある程度までの環境構築を自動化しています。何かの役に立つ人もいるかもしれないので、備忘録を兼ねてバッチファイルなどを公開します。 【追記】 「何でもいいからさっさと試したい！！！という人は、セットアップ用USBメモリを作って(Windows10 / Windows11)、ここからファイルをダウンロードしてUSBメモリに展開してください。
これは はてなエンジニアアドベントカレンダー2023 2日目の記事です。 はてなエンジニア Advent Calendar 2023 - Hatena Developer Blog はてなエンジニアのカレンダー | Advent Calendar 2023 - Qiita トップバッターは緊張するけど、順番が回ってくるまで長い間ソワソワするのも嫌、という理由で例年2日目を狙うようにしている id:pokutuna です。今年も成功しました。 観光名所とは 目を閉じれば思い出す、あのコード... あの Issue... あなたが Web 系のエンジニアであれ、趣味で開発している方であれ、必要に応じてライブラリやフレームワークのコードを読むのはよくあることでしょう。公開の場で開発されているソフトウェアは、ソースコードだけでなく、開発コミュニティでの議論やバグ報告なども見ることができます。 リポ
https://offers.connpass.com/event/299909/ 登壇資料
意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す
去年の夏ごろ、いつものように会議をしていると、元キーエンスのメンバーがこんな話をしてくれました。 「僕、前職の営業でいろんな町工場を回ってたんすけど、図面がめちゃくちゃバラバラに、紙とかPDFで管理されてて。一回探しに行ったら20分、30分も戻ってこないことがけっこうあったんです」 「なんとかできないのかなって、ずっと思ってたんですよね」 そんな言葉から今回の事業はスタートしました。 それから半年ほどでサービスを開発・法人化し、導入社数はすでに200社近く。新規事業としてはかなりのスピードで成長できていると思います。 このnoteでは、僕らの開発した「町工場向けSaaS」が売れるまでの半年間を振り返ってみます。営業やPMなど事業開発に関わる方や、レガシー的な業界で働く方にとって、少しでもお役に立てばうれしいです！ 町工場をまわってユーザーヒアリング町工場向けに、図面の管理が楽になるサービス
Intro SPA の隆盛で進化したフロントエンドライブラリによって生み出された「コンポーネント」という資産は、それを View 層の最小単位として扱うエコシステムにその重心をずらした。 近年の Web 開発は、虫食いのテンプレートエンジンにデータをはめ込む方式から、デザインシステムにカタログされたコンポーネント群に、API から取得したステートを流し込み、それらを「いつ、どこで、どう」レンダリングするかという課題への最適解を、各位が模索するフェーズとなっている。 コンポーネントを敷き詰めるコンテナ側の設計は、Flexbox および Grid の登場によるレイアウトの進化が手助けしたところも多いにある。しかし、「ページ」を前提に設計された CSS は、「コンポーネント」を前提にした設計に移行するうえで、ミッシングピースが多かった。 現在、提案/実装が進んでいる CSS の新機能群には、この
TypeScript (4.7 時点) において, 文字列に付けられる型には以下の 3 つ (とそのユニオン型) があります. 文字列型 string 文字列リテラル型 ("foo" など) テンプレートリテラル型 (`data-${string}` など) これらのうち, 実行時の入力, 特に事前にパターンが想定されていないような任意の入力が含まれるような文字列に対しては, string や string を含むテンプレートリテラル型を付けることはできても, 文字列リテラル型を付けることはできません. 文字列リテラル型を付けるためには型検査時 (実行の前) に入力文字列の内容がわかっている必要があるので, まあそれはそうですね. このことを利用して, 実行時の入力を含む文字列を与えようとすると型検査に失敗するような関数を作ることができそうです. まずは与えられた型が文字列リテラル型, ま
┌────────────────────────────────┬─────────────────────────────┬────────────────────────────────┐ │ TypeBox │ TypeScript │ Json Schema │ │ │ │ │ ├────────────────────────────────┼─────────────────────────────┼────────────────────────────────┤ │ const T = Type.Any() │ type T = any │ const T = { } │ │ │ │ │ ├────────────────────────────────┼─────────────────────────────┼─────────────────────────────
at #ワインと鍋js なぜフロントエンドに Edge Worker が必要なのか、Cloudflare Workers をどう使っていくかみたいな話をしました
はじめに こんにちは、株式会社 Flatt Security セキュリティエンジニアのぴざきゃっと (@pizzacat83) です。 認証機構を自作せずに導入できる Firebase Authentication は様々なアプリケーションにて利用されていますが、その特性を十分に理解せずに導入すると、実は不具合や脆弱性が生じることがあります。そこで本稿では Firebase Authentication を利用するうえで、注意しなければ不具合や脆弱性に繋がりうる 7 個の「落とし穴」について解説します。 はじめに IDaaS の利点と欠点 落とし穴 1. 自己サインアップ リスク 対策 落とし穴 2. ユーザーが自身を削除できる 対策 落とし穴 3. 他人のメールアドレスを用いたユーザー登録 リスク リスク 3-1. メールアドレス誤入力によるユーザー乗っ取り リスク 3-2. 他人にメー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
