メディアクエリに依存した要素の表示切り替えを `display: contents` でユーティリティコンポーネント化
画面幅、メディアクエリに依存した要素の表示切り替え React + CSS Modules を使っている前提イメージ JSX 上で表示・非表示の分岐が明示されてほしい CSS を掘らないと分からないのは見通しが悪く感じる matchMedia() ベースの Hooks にすると SSR で難儀する 一貫性のためにサーバーサイドコードで頑張るのも億劫である 表示・非表示だけなら純粋な CSS で実現したい display: contents を使ってみた メディアクエリで display: none と block を切り替えれば良いという単純な話ではなく、親要素が Flexbox や Grid だった場合を想定する必要があるので、表示されている状態ではボックスモデル的に虚無になってほしい。 contents これらの要素は自身のために特定のボックスを生成しません。擬似ボックスやその子ボック
見積もりも約束もしたくない開発
慎重な見積もりは苦しい 本来、どんぶり勘定の見積もりでも 6-7 割の精度はあるはず（きっと） ドメイン知識やコードベースをそれなりに掌握している必要はある 慎重に見積もりの精度を高めるのは責任を伴う約束のせい じゃあ最初から約束しなければいい 慎重に見積もってもどうせ事故るときは事故る とはいえステークホルダー向けに「いつまでに終わらせる」意志の表明は必要 意志を尊重し、目論見が外れても咎められないことが求められる 見積もりの心理的安全性ともいえる 正確な見積もりと約束に時間をかけるよりも、いつまでに終わらせるという意志力と、想定より伸びても咎めない寛大な心でいきたい — あほむ｜副業転職 Offers の overflow (@ahomu) September 8, 2023 見積もりと計画を捨て、約束を破れ 一般的に理性的な見積もりは遠大な計画になりやすい 責任と約束のために不明なバ
アーキテクチャ編: SSR と CDN ( Fastly ) とユーザー依存情報の分離（新規開発のメモ書きシリーズ4）
新規開発のメモ書きのラスト シリーズだったはずなのに、色々あって前回のエントリから1ヶ月あきました。_:(´ཀ`」 ∠): 今回の話の中心は結果的に「Server Side Rendering との折り合いの付け方」と「Fastly を利用した動的コンテンツのキャッシュ戦略」です。 このシリーズの他の記事はこちら。 技術要素編: web アプリが新陳代謝を続けるための依存関係の厳選 ビルド設定編: UA に応じた最適な JS バンドルの配信と webpack との距離感 コード設計編: context による縦軸分類とレイヤードアーキテクチャ まずは全体的なアーキテクチャ像 次の図はアーキテクチャの全体像です。クライアントサイド寄りの範囲を中心に書いているため、バックエンドな Microservice 群以降がおざなりな図ではありますがご容赦ください。 主要リソースは Fastly を通じ
ビルド設定編: UA に応じた最適な JS バンドルの配信と webpack との距離感（新規開発のメモ書きシリーズ2）
たくさんある道具をどのように組み合わせるか 今回はコード設計編のつもりでしたが、ビルド周りを先にまとめることにしました。主にパフォーマンス上の都合ですが、心がけたポイントは次の点です。 画一的なバンドルではなく、適切なバンドルを選択的に配信できるようにする 適当な粒度で Code Splitting できるようにする ひとつのツールに何でもかんでもやらせない（ webpack、お前のことだよ！） ビルドのパイプラインを短く、シンプルに済ませる（できることを全てやろうとしない） タスクランナーは前回述べた通り make を利用しています。同僚が使っているのを見てパクりましたが Self-Documented Makefile の手法が、タスク名忘れに優しくてよかったです。 npm run したら npm scripts が一覧で出てくるのと似たようなやつです。 このシリーズの他の記事はこちら
CSS Containment の制約と効能について覚え書き
ある要素内の状態による外界への影響を封じ込めて最適化を促す CSS Containment Module で定義される contain プロパティは will-change と同じようにブラウザが処理を最適化するために開発者から提供できるユーザーエージェント向けヒントとして機能します。 ヒントの目的はcontain の対象要素が親兄弟に影響を及ばさない独立した部分木であることを宣言し、各種の影響を contain の対象要素の中に封じ込めることです。 使うときは contain プロパティに既定の値として用意された size | layout | style | paint | content | strict のいずれかを指定します。content と strict は複合指定のエイリアスなので、本文では size layout style paint の4つについて個々の説明をします。
既存 Web アプリケーションのアクセシビリティを向上させるときによくあるヤツと対応方針
アクセシビリティ向上メモ 最初から考慮されているのが一番ですが、そうでもなかったプロダクトに手を入れるときのあるあるを記録します。既存プロダクトはモノが出来上がってしまっているため根治的なリファクタリングよりも基本的には省力で済ませたいので、今回書いた対応方法も完璧よりは省力路線です。 HTML やらセマンティクスに関する知識はそれなりにあるつもりでしたが、AT やマシンリーダビリティを念頭に勉強し直すと自分で作ったものも至らなかったなと振り返らざるを得ない今日この頃。初期設計のときの考慮範囲が拡がったように思うので善きかなです。 各項目について、もっと良い解法や誤り等あれば twitter とかでご指摘ください。 1. 画像に alt 属性がない場合 付けましょう。付けます。はい。 昔から基本とも言うべき、HTML/CSS 書きとしては耳にたこができるほど言われてきたことなので今更感もあ
Web サイトっぽい SPA に必要なブラウザナビゲーションのエミュレートなど
Web サイトっぽい SPA に立ち向かう 大分前の話ですが、Node学園 20時限目 今回もdots!!!!! - connpass で Client Side of なんちゃらfresh.tv としてお話した内容のうち、Web サイトっぽい SPA に関してだけこだわりを再抽出して書き留めます。 本件は、ページ全体のスクロールや頻繁なナビゲーションを伴わず、1画面におさまるレスポンシブな Web アプリを作っている場合はあんまり関係がありません。画面内の局所的な状態更新は、コンポーネントの責務分割やら何やらの設計なので実は別の話です。 総じて、Web サイトっぽいくせに大人の事情で Web ブラウザのネイティブなナビゲーションを積極的に破壊しにいくときの心構えです。 URL が変わっても最低限レンダリングできるまで画面更新を遅延させる 画面遷移に必要なのは、 URL が更新されても次の
開発や業務におけるチャットを使った情報共有の民度、潜伏あるいは揮発してしまう情報のリスクについて
テキストチャット中心の開発コミュニケーションと課題感 ご飯ブログを書いてばかりで、老害活動できていないからたまには真っ当なブログ。 最近、テキストチャットを使ったコミュニケーションが円滑になるためには？という課題についてよく考えるのでチャットユーザの民度を上げるための覚え書きをまとめます。 Slackなどを使ったチャットコミニュケーションの民度、運用の成熟に思いを馳せてる。 — あほむ (@ahomu) June 28, 2016 オフィスワーカーにとってのチャット オフィスワーカーであっても、メールと同じで記録が残りメールよりも即時性が高い、チャットによるコミュニケーションは少なくありません。物理的に移動する手間を省き、送信側の任意のタイミングでメッセージを送れることなどが魅力です。 口頭コミュニケーションは即時性が高い代わりに揮発性も高く、その場に居合わせないと得られない情報です。口頭
Web Initiative Center と社内的な所信表明
4月から社内の Web Initiative Center ( 以下 WIC ) というグループで、新しい業務に取り組み始めました。社内メールに放流することを前提として書いているので、社内向けの内容です。すみません。 2016/11/03 追記: 開局6か月／900万DL突破の「AbemaTV」、急成長するウェブサービスを支えるフロントエンドエンジニアの舞台裏：CodeZine（コードジン） の取材の中でも Web Initiative Center について話をしました。 活動 Web のプロダクト品質を横断的に向上させる Web 技術を使ったチャレンジがしやすい環境をつくる この2つが活動の主旨であり、これらを通して Web によるユーザー体験を向上させることが目的です。 活動は CyberAgent 全社ではなくメディア系の部門内にひとまず限られますが、この中にはアメブロや Ameb
HTML6 でも CSS4 でもない Web 技術のゆくえ - WCAN 2015 Winter に登壇してきました
@kazumich さんにお声がけいただき、WCAN 2015 Winter でおよそ 60 分ほどのセッションを登壇してきました。32:9 のスクリーンがあるという、TED でもやるんかオイという特殊な環境でした。普段はプロジェクター的な投影なので、スクリーンの前に立つのが微妙なんですが、ここはディスプレイが壁面に大量に並んでいて自ら発光するので、部屋を暗くしなくてもテレビのように十分に見えますし前に立っても平気です。 一緒に登壇したのが @yhassy さんと @Hidehisa さんということもあり、近年まれに見る胃痛を伴う緊張を味わいながらお話させていだきました。（リアルにセッション終了後、1時間くらい胃痛がズキズキしてました） 技術的なお話でした 参加されたみなさま、メインセッションや LT に登壇された各位、ならびに運営されたスタッフの方々、ひとまずお疲れさまでございました。貴
WAI-ARIA 対応のアクセシブルなタブ UI を React で実装する
タブ UI のアクセシビリティ対応 この記事は、下記の点に留意してご覧いただきたい。 タブ UI におけるアクセシビリティ対応（主に WAI-ARIA）の参考実装であること React コンポーネントとしての機能性は二の次のサンプルであること アクセシビリティ実装についてのツッコミは歓迎であること ひさびさにPCキーボード的なアクセシビリティ対応が必要そうな性質のサービスを開発することになったので、コンポーネント単位でのアクセシビリティ関連実装を進めている。 React 実装 今回はタブ UI を題材に、React コンポーネントを実装した。 行うべき操作を見通しよくするために、タブ UI を <Tabs> コンポーネント1つで実装した。厳密には <TabList> や <TabPanel> などの要素を分解してコンポーネント化したほうが良いだろうが、今回は簡易実装としている。 キーボード
RAIL という Web パフォーマンスモデルの概要
RAIL を簡単に紹介する 主に Googler が、という趣ですが今年に入ってから RAIL というパフォーマンスモデルが紹介される機会が増えてきました。 RAIL は Response / Animation / Idle / Load の頭文字をとった命名で「アプリケーションのライフサイクルの観点から、それぞれのフェーズの基準時間（限界時間）を示したもの」です。 手前味噌ながら Webパフォーマンスにおけるイニシャライズとランタイム で紹介したうちの「ランタイム」部分が細分化されて、それぞれに基準時間を割り当てたようなイメージです。 Idle や Animation あたりの時間は紹介する人・タイミングによって多少ブレている印象ですが、大まかに以下のような感じです。 Response : 100ms 「UI が操作されたときユーザーにレスポンスするまでの応答時間は 100ms 以内」
最近あまり使ってない、流行っていた時期もあるフロントエンドもの
最近あまり使ってない、ちょっと前の流行りもの なんとなく書いてみます。Web アプリケーション開発屋さんなので、Web サイト制作屋さんとはかなり文脈ズレると思います。 jQuery ファミリー 個人的には jQuery って、協業用のツールという位置づけでした。jQuery でさえ書かれていれば、jQuery 書ける人材のほうが外からも調達しやすいため、人員の流動にも有効と考えられる頃が確かにありました。 DOM に触れてくれるな勢の台頭 ところが昨今では AngularJS や React、その他ライブラリでも DOM 操作が大いに抽象化されていることが多く、jQuery で直接 DOM を操作すること自体が相性良くないケースが散見されます。今思えば Backbone.js くらいのころが jQuery 需要の最終ピークだったように思います。 jQuery プラグイン の需要減 jQu
Android4.0.3（エミュレーター）の標準ブラウザで:checkedと間接＆隣接セレクタが挙動あやしい
:checkedの状態変化に、続く間接セレクタが追いついていない 前置き。あいにく手元に、4.0.3のAndroidエミュレーター（Mac）しか無いため、実機での挙動がどうなのかは未検証です。話半分ぐらいでお願いできると(；´Д`人 で、現象としてはチェックボックスやラジオボタンでcheckedを付けたり外したりしたときに、:checkedと間接＆隣接セレクタによるスタイルの適用がおかしい感じ。 サンプルコード <!doctype html> <html lang="ja"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <style type="text/css"> :checked + #first { color: blue; } :
Pixateでアプリのインタラクションモックアップが捗りそう
インタラクションのモックアップ ネイティブアプリを作っていて、いわゆるインタラクション・アニメーションの部分をモックアップできるツールの必要性を感じたので @hiloki さんに聞いたツールをいくつか試してみました。 The Next Generation of Mobile Interaction Design | Pixate Justinmind: Interactive wireframes for web and mobile Briefs 昔ながらに Flash を使うという選択肢もあった気はしますがせっかくなので、そういう用途に特化したツールを探したかった次第。（メンバーに Flash 使えるひとがいなかったという事情もある） Pixateがよかった The Next Generation of Mobile Interaction Design | Pixate 結果、一番
jit-grunt で grunt をキビキビ動作の高速化
Take Grunt to the Next Level — Jonathan Suh この記事を見て知ったのだが、jit-grunt というプラグインが中々よい。Just In Time ということで、タスクのロードを loadNpmTasks でまとめて最初にやる代わりに、各タスクの実行時までロードを遅延させるというもの。 npm の jit-grunt ページを見ると相当数がダウンロードされて利用者がいるようだが、検索するとあまり紹介されてないようだったので書いてみる。 効能 17個のタスクをロードしていた手元の環境に導入したところ、単純なタスクを実行した限りでは次のような実行時間の短縮が見られた。計測は例によって time-grunt だ。 Before loading tasks で 625ms かかっていて、全体では 651ms を要した。 % grunt concat:lib
picture要素の関連仕様って今どうなってるんだっけ？を調べたメモ
<picture> どうなった 勤め先がモバイルに注力していたこともあり、レスポンシブもへったくれもない世界を生きてきた。そのせいで、その類の情報にかなり疎くなっていたので、現状を軽く調査してみた次第。 HTMLでの画像リソース読み込み分岐の必要性 CSS には Media Queries があるので、Viewport の width であったりデバイスのピクセル密度であったりを条件にして background プロパティの指定をすれば対応できる。 反面、<img> 要素と src 属性にはそのような仕組みがないため、Media Queries で可能な条件で同じようにやろうと思うと、JavaScript で DOMContentLoaded のあとに"頑張って"操作するか、バックエンドで UserAgent に応じて"賢く"返す仕組みを用意しなければならない。 WebP のような画像形式
Material Design と Polymer - HTML5とか勉強会に登壇してきた
まさかのデザインに関するトーク 先日の 第49回 HTML5とか勉強会 で、Material Design と、それをWebで実践するための Polymer (Paper Elements) まわりについてお話させていただきました。 去年とか、Googler が紹介するパフォーマンス関係のわりとマニアックなトコだとかケーススタディの共有に努めたり、さらにその前もJavaScript関係のライブラリ・ツールの話をしておりました。 という流れで、エンジニア的なブランディングに終始しておりました為、今回Google I/O 現地で話を聞いてきたとはいえ、デザインに関するセッションのお話をいただいて緊張しきりでございました。 YouTube（追記） いつの間にか動画があがってました。 第49回HTML5とか勉強会「HTML5最新情報 @Google I/O」 - YouTube 小並感 なんでgr
Gruntについて最新の気持ち
思いつき だいぶ前からGrunt周りというかGruntそのものへの関心が薄れゆくなか、タスク周りがやたらと充実してきたエコシステムの恩恵を、ただただ享受するにとどまっている。 業務で700行のGruntfile.jsを見かけて、SAN値をもっていかれた折に前々から感じていた疑念が表に出た。 「これ、Gruntに仕事させすぎじゃないの」 分担してもよいのでは 前述の700行のなかには、ファイルのビルドをはじめとして、ユニットテスト、E2Eテスト、ドキュメント生成、ローカルサーバー、LiveReload etc etc etc ...すべてひとつのファイルに入っていた。 (; ⁰⊖⁰) Oh... いまいち感覚的なトコロなので表現しづらいのだが、役割としてあまりにGruntfileで表現している内容がごった煮すぎるように思う。 自分の場合、テスト周りはtestemにしていて、ドキュメント生成系
技術は発想やデザインの限界にならない
当時の思い違い たとえば、一般的なエンジニアが何かを作ろうとすると、その個人の「技術的な限界＝発想の限界」となりがちです。 ではデザイナーと呼ばれるような職能を持っているひとが、果たしてプロダクトを実装として理解すべきか、というと、それは分業上の実装サイドによるエゴ（こっちの都合もちゃんと考えて欲しい！的な）でしかないと思っていました。 多少、吹っ飛んだ話であっても、意図を失わずに現実的な実装に落とし込むのはコミュニケーションの問題であって、デザイナー職能の理解不足ではない、と。 コミュニケーションでも解決できる問題として、これは今も間違ってはいないはずですが。 しかし、これは適切なタイミングで、大きな青写真を描くための能力であり、デザイナー職能を全うする話とは違ったのです。 優秀とは 身の回りで優秀なデザイナーと呼ばれる諸氏は、ビジュアルを作るだけでなくステートの管理までよく考え、利用コ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
