JavaScriptよ。文明を捨て、自然に還れ。
Web ナチュラリスト フィードを眺めていたら Alex Russell 氏の新作が投稿されていた。 The "Developer Experience" Bait-and-Switch | Infrequently Noted 本来の趣旨については原文を読んでもらえばいいし、下記はこれを読んだ上で普段の考えを踏まえて脳裏をよぎったポエムである。 我々は複雑性で仕事をしている 仕事をしている、もしくはそれでお金を稼いでいる。誰もが。 私は 2012 年頃から Web の、特に Web フロントエンドの複雑性に加担している自覚がある。 Web の専門性が高まることはその技術領域に深淵な価値があることを示唆し、それに携わることの価値を相対的に向上させることができる。 私の活動そのものは些細なものだが、かくして 2018 年現在の Web はかくも複雑になることに成功し、エンジニアリングの名の下
SPA + サーバーサイドレンダリング、そのダルさに関する私見
いわゆる SPA + サーバーサイドレンダリングがダルい 唐突ですがおさらいです。 なぜサーバーサイドレンダリング（SSR）が嬉しいかと言えば 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰にやさしい（） 古いブラウザ・低性能マシンにやさしい yahoo/fluxible による SPA + Server Rendering の概観 ::ハブろぐ であり、特に SPA + SSR の文脈においては Universal Architecture による SPA + SSR は、技術的には過渡期の歪なキメラっぽさが拭いきれませんが、昨今の Web フロントエンドにしては珍しくビジネス的な説得力があります。 SSR なのでSNSや検索からの流入による初期表示が速い SPA なので回遊時のページ遷移も速い SSR なので古いブラウザでも CSS
Web アクセシビリティ向け Node.js 製の自動チェックツールや DevTools 用の拡張機能など
アクセシビリティを担保するプロセス作り この記事は Web Accessibility Advent Calendar 2016 - Adventar の 12 日目の記事です。 UI 実装の再考と a11y - Frontrend Vol.8 LT でも述べましたが、Accessibility is a Process, Not a Project ということでアクセシビリティ対応するプロジェクトではなく、アクセシビリティを担保するプロセスを作りましょうということで、チェックツールをいくつか並べて俯瞰してみます。対象読者は自分と同じようなクライアントサイドの Web アプリケーション屋さんということにしておきます。 ちなみにアクセシビリティ評価ツールについては 3 日目のアクセシビリティ方針、報告書、試験支援ツールa11ycのご紹介 (Web Accessibility Advent C
Web アクセシビリティと呼ばれているものと Web アプリ開発現場に思いを寄せて
捉え方と考えの整理 Web アプリケーション開発屋として Web アクセシビリティをどのように捉え、どのように付き合っていくべきかの考えを書いてみます。昨今の Web サービスにおいてアクセシビリティは Web の領域だけで果たされるものではなくアプリとかも含めてだよね、という向きはありますが話が広がりすぎるので今回は Web の中に留めます。 自分が Web におけるアクセシビリティとは何なのか？と考えるときは「多様なクライアント環境に対する配慮」と「制限をもつユーザーに対する配慮」の2面で捉えています。前者はあくまで Web に関する技術的な配慮であり、後者は Web に限らず包括的なアクセシビリティとしての配慮またはその社会的要請です。 多様なクライアント環境や Web に対するニーズへの配慮 Web ページを参照できるユーザーエージェントやデバイスの数が多いのは言うまでもなく、これ
小さい広告的な Flash を Chrome で自動再生させちゃうアレ
重要でない Flash を Chrome は遮断する Googleは、ChromeでFlashをあからさまに遮断するわけではないが、動画などの「中心的コンテンツ」の再生のみを許可し、Flashアニメーションなどの周辺コンテンツは一時停止させる。 「Chrome」、Flash広告をデフォルトで停止に--9月1日から - CNET Japan Chrome のデフォルト設定では重要でないとされる広告的なサイズの Flash は自動再生が行われないようになっています。 業務でこの仕様について調べたところ、Flash がある一定以上のサイズで表示されていれば自動再生されますが、ある一定のサイズを下回ると自動再生されなくなることが分かりました。 Width 基準なのか Height 基準なのか、はたまた面積なのか画面サイズやウインドウサイズに対する相対値なのか、他にも条件があるかもしれません。詳細は
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 アクセシビリティ勉強会を開催した
アクセシビリティの社内啓蒙 8月9日、Web Initiative Center による社内啓蒙活動の一環として、社内勉強会を開催しました。個人的なレポートです。会社のブログは誰かが書いてくれると言っていた気がするんだが...だが...。 ゲストスピーカーとして @bakera さんと @magi1125 さんにお越しいただきました。みなさんもご存じなアクセシビリティのピンク本の著者でもあるお二人です。 このお二人に直接お話を伺えるのは、うちの社員にとって貴重な機会だったと思います。懇親会でもたっぷりとアクセシビリティに関する意見交換やら社内事情を踏まえた相談やらをさせていただきました。お二人とも本当にありがとうございました。 参加者としては大半が Web フロントエンド従事者でしたが、デザイナーやサーバーサイドエンジニア、ディレクターの参加もちらほらありました。ありがたいことです。 スピ
既存 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 が更新されても次の
フライパンで作るローストビーフのようなもの、または牛肉のタタキであるもの
安いモモ肉を買います 今回は 300g で 500 円くらいです。ジューシーな脂っぽい肉を食べたいなら金を出せば解決するのですが、安い肉で良い赤身というのは難しく感じます。オージービーフはおいしいです。火の入り方のムラをなくすために、なるべく直方体に近い獲物を狙います。 下ごしらえ 塩をモリモリ擦り込む 常温に戻す 水分をキッチンペーパーで拭き取る スパイスを振る なんとなくこの順序でやっています。安い肉を買うとローストビーフ用のタレとかスパイスがついてくるので、適宜使ったり使わなかったりします。 焼きを入れます 一面あたり 15〜20秒くらいずつ、フライパンから白煙が立ちのぼるくらいの強火で焼いていきます。なにげに煙がじゃんじゃん出るので、火災報知器に注意してください。メイラード反応を狙っていきます。 表面を焼いたらフライパンに蓋をして、3〜5分くらい極めて弱火で何となく蒸し焼きにします
リモートワークの勘所と限界について1年くらいの感想、組織にとっての選択肢作りの話
1年くらいリモートワークを続けてみた感想 まず当然ながら「リモートワークは生産性が高い！これこそ未来のワークスタイル！」のような感想はありません。 生産性やコミュニケーションに関連するメリット、デメリットをうまく相殺しきれれば、生活の自由度だけ向上してハッピー、と考えています。 今は自宅かレンタルオフィスのいずれかを作業場として開発などを行いつつ、本社がある渋谷には1泊2日の出張を月2回するようなペースで仕事をしています。基本は Slack でテキストチャットによるコミュニケーションをメインとしつつ、必要があれば MTG に Hangout でビデオチャットで参加します。 生産性は大して上がらない 期待していた生産性は、それほど向上することはありませんでした。 東京にさえいなければ気軽に MTG に呼び出されることもありませんし、開発に充てることが可能な時間は若干増えています。通勤時間が長
Webデザイン学科の特別講義として、フロントエンドについて演説しました
Web フロントエンドで仕事をしてご飯をおいしく食べる話 画像の引用がめんどうになったので、自分の写真ライブラリから適当なご飯画像を入れることにしました。 学校法人河合塾学園トライデントコンピュータ専門学校の Web デザイン学科に在籍する1, 2年生を対象に、業界研究という授業で演説を繰り広げさせていただきました。ほんと、そこまで喋るつもりなかったのですが、なんだかすごく熱心に聞いてくれているので、ついつい喋りたいこと喋りすぎました(; 'A`) 各位には当日申し上げましたが、分かることは「分かる〜」って感じで、分からないことは「分からん！」って感じのリアクションを正しくとることは、喋ってる人のテンションを左右するので非常に重要です。聞き手のスキルです。調子にのりましたすみません。 なんとなくのアウトライン Web フロントエンドという職能に関する夢のはなしと、社会は厳しいという話を少し
Android アプリのアクセシビリティガイドライン概観メモ
ネイティブアプリとアクセシビリティの関係 Web が専門ではありますが、アクセシビリティを通した品質向上を考え始めると、Web だけでは社内のプロダクトの半分あるいはそれ以下程度のカバレッジしかありません。 そこで今回はネイティブアプリ、特に Android のガイドラインについて目を通したメモ。 プラットフォームのガイドライン ネイティブアプリの筆頭たる iOS と Android においては、WCAG 2.0 ほどは詳細化されてこそいないものの、各プラットフォームでガイドラインが提供されています。 Implementing Accessibility | Android Developers Accessibility for Developers - Apple Developer とはいえ、この2つ見比べてみると iOS のドキュメントはそれほど充実していないような印象です。どうも
iOSアプリにおけるアクセシビリティの概観メモ
iOS のアクセシビリティ Android アプリのアクセシビリティガイドライン概観メモ ::ハブろぐ の続きです。前回、iOS のドキュメントをうまく見つけられなかったので Android だけ目を通しましたが iOS も読んでみます。 プログラミングガイド iOSアクセシビリティプログラミングガイド は、幸い日本語が用意されてるので読みやすくて安心です。英語版は PDF でありませんが Accessibility Programming Guide for iOS と About Accessibility Verification on iOS に相当するものと思われます。 なお、英語の情報は Accessibility on iOS - Apple Developer に動画なども合わせてまとまっています。 Apple いわくアクセシビリティは正義 最初に目についたのは「なぜアプリ
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
Isomorphic Architecture を実装してるときの細かいアレコレ
Isomorphic あらため Universal ？ 一時期火がついていた Isomorphic について。各自がプロダクションの事例を作り上げる潜伏期に入ったのか、はたまた本当に一過性で火が消えたのか、コモディティ化を遂げたのか分かりませんが、あまり耳にすることがなくなった印象です。 そんな中ですが先日、Universal JavaScript — Medium が公開され、なるほど Universal ってキモチになったので、タイトルに反して以下は Universal と呼称します。 今回の話題にするのは module レベルではなく Universal な JavaScript architecture のほうです。アーキテクチャのレベルで Universal なコードが役立つ代表的ケースは SPA (Single Page Application) と SSR (Server S
HTML6 でも CSS4 でもない Web 技術のゆくえ - WCAN 2015 Winter に登壇してきました
@kazumich さんにお声がけいただき、WCAN 2015 Winter でおよそ 60 分ほどのセッションを登壇してきました。32:9 のスクリーンがあるという、TED でもやるんかオイという特殊な環境でした。普段はプロジェクター的な投影なので、スクリーンの前に立つのが微妙なんですが、ここはディスプレイが壁面に大量に並んでいて自ら発光するので、部屋を暗くしなくてもテレビのように十分に見えますし前に立っても平気です。 一緒に登壇したのが @yhassy さんと @Hidehisa さんということもあり、近年まれに見る胃痛を伴う緊張を味わいながらお話させていだきました。（リアルにセッション終了後、1時間くらい胃痛がズキズキしてました） 技術的なお話でした 参加されたみなさま、メインセッションや LT に登壇された各位、ならびに運営されたスタッフの方々、ひとまずお疲れさまでございました。貴
【AD】名古屋に戻ってリモートワーカーになりました
なっごや〜 周囲の方々へのご報告を兼ねまして、家庭の事情と思う所があり名古屋に引っ越しました。半年に及ぶ相談と調整を経て、幸いにも諸々の条件つきで現職のままでございます。 名古屋で粛々とした勉強会をやったりとか色々検討中なので、よしなにお願い致します。 リモート業務との向き合い方 リモートとイモートって似てない？ イモート業務したくない？？ — あほむ (@ahomu) June 22, 2015 などとバカなことを言っていたら、本当にリモート業務を始めることになりました。当面は今のプロジェクトのチーム（開発系だけで20人近くいる!!）で仕事をするのでチームプレイがんばります。 遠隔地とコミットメント 在宅勤務というと自由気ままなイメージがありますが、実は人一倍他人に対して気遣いができる、コミュニケーション能力の高い人間でないと、務まらないです。 また、人並み以上にチームや組織全体の目標に
WAI-ARIA 対応のアクセシブルなタブ UI を React で実装する
タブ UI のアクセシビリティ対応 この記事は、下記の点に留意してご覧いただきたい。 タブ UI におけるアクセシビリティ対応（主に WAI-ARIA）の参考実装であること React コンポーネントとしての機能性は二の次のサンプルであること アクセシビリティ実装についてのツッコミは歓迎であること ひさびさにPCキーボード的なアクセシビリティ対応が必要そうな性質のサービスを開発することになったので、コンポーネント単位でのアクセシビリティ関連実装を進めている。 React 実装 今回はタブ UI を題材に、React コンポーネントを実装した。 行うべき操作を見通しよくするために、タブ UI を <Tabs> コンポーネント1つで実装した。厳密には <TabList> や <TabPanel> などの要素を分解してコンポーネント化したほうが良いだろうが、今回は簡易実装としている。 キーボード
Google I/O で v1.0 が発表された Polymer の Elements Catalog が面白い
Polymer Elements のカタログページ Site: Polymer Element Catalog Repo: Polymer/polymer-element-catalog Polymer は、これからの Web 標準の一角を占めるであろう Web Components のラッパーライブラリです。その Polymer で作られたコンポーネントのカタログサイトが公開されていました。 これまでも Core Elements や Paper Elements が Polymer のコンポーネントとして提供されていましたが、分類も新たにレパートリーが拡充されています。 Cart に入れて Download カタログには各コンポーネントのドキュメントやデモが載っていて、使いたいものをチェックして Cart に入れていきます。必要なコンポーネントを Cart に入れてダウンロードさせると
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
