FileReader利用時のメモリ増減パターンをちょっと調べてみた
FileReaderを通してローカル画像ファイルのプレビュー jsFiddleを使ってみたかったので，デモ的に貼ってみます． HTML5 Rocks - Reading local files in JavaScript Utilizing the HTML5 File API to choose, upload, preview and see progress for multiple files - Robert's talk このあたりを参考に，FileReaderでローカルの画像ファイルを読み込み＆ファイルプレビューをしてみました．大体動くんですが，どうもブラウザがメモリとってもおいしいです☆をしていたので，ちょっと調べてみました． メモリリークするケース？ で，どうもFileReaderのインスタンスを作ったらしっかり使い回さないと，狭い確認範囲ですがメモリリークすることがある
リモートワークの勘所と限界について1年くらいの感想、組織にとっての選択肢作りの話
1年くらいリモートワークを続けてみた感想 まず当然ながら「リモートワークは生産性が高い！これこそ未来のワークスタイル！」のような感想はありません。 生産性やコミュニケーションに関連するメリット、デメリットをうまく相殺しきれれば、生活の自由度だけ向上してハッピー、と考えています。 今は自宅かレンタルオフィスのいずれかを作業場として開発などを行いつつ、本社がある渋谷には1泊2日の出張を月2回するようなペースで仕事をしています。基本は Slack でテキストチャットによるコミュニケーションをメインとしつつ、必要があれば MTG に Hangout でビデオチャットで参加します。 生産性は大して上がらない 期待していた生産性は、それほど向上することはありませんでした。 東京にさえいなければ気軽に MTG に呼び出されることもありませんし、開発に充てることが可能な時間は若干増えています。通勤時間が長
Web ページを高速化して ユーザーに価値を届けたい 制作者のための セミナー＆ワークショップ資料公開
Web ページの高速化セミナー WCAN 2018/09/15「Web ページを高速化してユーザーに価値を届けたい制作者のためのセミナー＆ワークショップ」 - WCAN | Doorkeeper 先日、2018年9月15日にひっさびさに WCAN に登壇させていただいて Web パフォーマンスチューニング....のなかでもページロード速度の高速化を中心にセミナーとワークショップを行わせていただきました。 下記はそのときの資料です。今回は Web サイト制作者向けのセミナーとして企画したので、Web アプリ開発勢が好きそうなテクニカルな話はすべて割愛しています。 ウケが良かったような気がするネタ なにがウケるか読みがつかなかったので、とりあえず色々盛り込んでみました。会場では下記のあたりがウケが良かったような....気が...する。 格安 SIM の回線は、大手キャリアのプロパー回線と比べる
JavaScriptよ。文明を捨て、自然に還れ。
Web ナチュラリスト フィードを眺めていたら Alex Russell 氏の新作が投稿されていた。 The "Developer Experience" Bait-and-Switch | Infrequently Noted 本来の趣旨については原文を読んでもらえばいいし、下記はこれを読んだ上で普段の考えを踏まえて脳裏をよぎったポエムである。 我々は複雑性で仕事をしている 仕事をしている、もしくはそれでお金を稼いでいる。誰もが。 私は 2012 年頃から Web の、特に Web フロントエンドの複雑性に加担している自覚がある。 Web の専門性が高まることはその技術領域に深淵な価値があることを示唆し、それに携わることの価値を相対的に向上させることができる。 私の活動そのものは些細なものだが、かくして 2018 年現在の Web はかくも複雑になることに成功し、エンジニアリングの名の下
SSR と CDN ( Fastly ) とユーザー依存情報、その後
正式リリースに向けての開発で表面化した不都合 以前、アーキテクチャ編: SSR と CDN ( Fastly ) とユーザー依存情報の分離（新規開発のメモ書きシリーズ4）で紹介したように、SSR で生成した HTML を CDN ( Fastly ) でキャッシュできるように「ユーザー依存情報はクライアントサイドで非同期に取り扱うというアプローチ」をとっていました。それによって発生していた不都合と解決に関する追加情報です。 ユーザー依存情報が非同期でレイアウトされる問題 ユーザー依存情報が非同期で解決されるということは、そのような情報を扱うコンポーネントの矩形は Web ページが一度レンダリングされたあとにレイアウトされます。つまりこの記事でも紹介されたところの「ガタンッ」的なユーザー体験が生じます。 ログインと非ログインが、全く同じサイズの矩形を確保するようなビジュアルデザインになってい
コード設計編: context による縦軸分類とレイヤードアーキテクチャ（新規開発のメモ書きシリーズ3）
流行りの monorepo 風味と DDD 風味？ 今回はコードの設計について書き残します。主に JavaScript 界の話です。Web アプリケーション全体の設計は次回で、今回はコード面の設計に限定して書き留めています。プロダクト全体のアーキテクチャは次の記事で述べる予定ですが大雑把には、メディアっぽいサービスでありつつも SPA + SSR が許容される程度には要件定義の時点でコードの行数がかさむことが約束されたプロダクトです。 今回は大きく分けて下記について述べています ディレクトリ構造 オブジェクトの種類と責務 Flux 的なデータフロー あくまで風味なので今回、専門用語の意味ズレなどは優しくお願いします... このシリーズの他の記事はこちら。 技術要素編: web アプリが新陳代謝を続けるための依存関係の厳選 ビルド設定編: UA に応じた最適な JS バンドルの配信と web
Web クライアントサイドのパフォーマンスメトリクス — Speed Index、Paint Timing、TTI etc...
色々なパフォーマンス指標のこと 何かを評価するときには何らかの指標（メトリクス）を定めますが、何を指標として設定してどのように測るかというのは重要です。 いわゆる KPI もそうですが、扱っている商材やビジネスのステージ（フェーズ）によっても適切な指標は変わるかもしれません。色々な指標をよく理解して引き出しを広げておくことは、状況に合わせて適切な指標を選んで改善していく過程で役立ちます。 これまでのパフォーマンス指標 過去の Web パフォーマンス界隈はバックエンドから HTML ドキュメントを返却する際の所要時間や、Web ページロード時の各イベントの発火時間を計測する方法が多く見られました。 Backend Time Browser Event Based DOMContentLoaded Page load ( onload ) 近年は特に後者の、既定のイベント発火に依存していたクラ
時間依存メディアについて（カッコカリ）
時間依存メディアの概要と対応方針の草稿 本記事は WCAG 2.0 A (シングルエー) に準拠する場合を想定して、時間依存メディアに関する内容の要約と対応方針の力加減をまとめたものです。 ようは時間依存メディアの項を読むのが苦しいのでマイルドにしてみた結果です。対応方針ほか諸々の内容はツッコミを受けて逐次修正される可能性があります。 対象 「時間依存メディア = 音声または映像」 であり、同時に 「同期したメディア = 音声付きの映像（動画）」 と読み替えて概ね問題ない。 「時間依存メディア」は、時間の経過に従って再生中の内容が連続的に変化する「音声、映像または両方を含むメディア全般」を指す。また、仕様書の中に登場する「同期したメディア」は、特に「音声と映像の両方を含むメディア（音声と動画が同期して変化するメディア）」を指す。 分類と必要な対応 音声しか含まないメディア → 書き起こしテ
App Shell モデルの素振り（前編）webpack と Workbox を利用した構築
App Shell モデルという設計パターン App Shell モデルは、共通のガワ部分を構成する HTML、CSS、JavaScript をシェルと定義し、その中に入る動的なコンテンツ部分と構造的に分離して扱えるように設計されます。 アプリケーション シェル（App Shell）アーキテクチャは、ネイティブ アプリのように瞬時に、そして確実にユーザーの画面に読み込める Progressive Web App を構築する方法の 1 つです。 アプリの「シェル」とは、ユーザー インターフェースが機能するために必要な最小限の HTML、CSS、JavaScript です。これらをオフラインで使用できるようにキャッシュしておくことで、ユーザーが同じページに再アクセスした際に、瞬時に高いパフォーマンス が発揮されます。つまり App Shell は、ユーザーがアクセスするたびにネットワークからす
SPA + サーバーサイドレンダリング、そのダルさに関する私見
いわゆる SPA + サーバーサイドレンダリングがダルい 唐突ですがおさらいです。 なぜサーバーサイドレンダリング（SSR）が嬉しいかと言えば 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰にやさしい（） 古いブラウザ・低性能マシンにやさしい yahoo/fluxible による SPA + Server Rendering の概観 ::ハブろぐ であり、特に SPA + SSR の文脈においては Universal Architecture による SPA + SSR は、技術的には過渡期の歪なキメラっぽさが拭いきれませんが、昨今の Web フロントエンドにしては珍しくビジネス的な説得力があります。 SSR なのでSNSや検索からの流入による初期表示が速い SPA なので回遊時のページ遷移も速い SSR なので古いブラウザでも CSS
近況とリハビリ
半年近く間を空けたブログです こんにちは！ リハビリといってもブログを書くことのリハビリで、身体的には元気です！ なぜブログを書いていなかったか 「直接的な技術以外の経験値を溜めていた → 曲がりなりにも技術中心のブログとしてはアウトプットしづらさがある → ていうかブログ書く暇あったら原稿やれよ的な被害妄想 → ああー(‘A`)」という流れです。うんうん…。 技術以外の経験とは 最近の仕事は、組織であったり制度であったり人事であったり…自分でコードを書いて価値を生み出すというよりも、コードを書いて価値を生み出しているひとたちの成果を最大化することに移っています。最近の仕事を棚卸しするとこんな感じ。 Web Initiative Center の運営 パフォーマンス、アクセシビリティの社内外啓蒙と推進 技術的なチャレンジの促進 社内コミュニケーションの強化 CyberAgent 的なブラン
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 アプリケーションのアクセシビリティを向上させるときによくあるヤツと対応方針
アクセシビリティ向上メモ 最初から考慮されているのが一番ですが、そうでもなかったプロダクトに手を入れるときのあるあるを記録します。既存プロダクトはモノが出来上がってしまっているため根治的なリファクタリングよりも基本的には省力で済ませたいので、今回書いた対応方法も完璧よりは省力路線です。 HTML やらセマンティクスに関する知識はそれなりにあるつもりでしたが、AT やマシンリーダビリティを念頭に勉強し直すと自分で作ったものも至らなかったなと振り返らざるを得ない今日この頃。初期設計のときの考慮範囲が拡がったように思うので善きかなです。 各項目について、もっと良い解法や誤り等あれば twitter とかでご指摘ください。 1. 画像に alt 属性がない場合 付けましょう。付けます。はい。 昔から基本とも言うべき、HTML/CSS 書きとしては耳にたこができるほど言われてきたことなので今更感もあ
Webデザイン学科の特別講義として、フロントエンドについて演説しました
Web フロントエンドで仕事をしてご飯をおいしく食べる話 画像の引用がめんどうになったので、自分の写真ライブラリから適当なご飯画像を入れることにしました。 学校法人河合塾学園トライデントコンピュータ専門学校の Web デザイン学科に在籍する1, 2年生を対象に、業界研究という授業で演説を繰り広げさせていただきました。ほんと、そこまで喋るつもりなかったのですが、なんだかすごく熱心に聞いてくれているので、ついつい喋りたいこと喋りすぎました(; 'A`) 各位には当日申し上げましたが、分かることは「分かる〜」って感じで、分からないことは「分からん！」って感じのリアクションを正しくとることは、喋ってる人のテンションを左右するので非常に重要です。聞き手のスキルです。調子にのりましたすみません。 なんとなくのアウトライン Web フロントエンドという職能に関する夢のはなしと、社会は厳しいという話を少し
開発や業務におけるチャットを使った情報共有の民度、潜伏あるいは揮発してしまう情報のリスクについて
テキストチャット中心の開発コミュニケーションと課題感 ご飯ブログを書いてばかりで、老害活動できていないからたまには真っ当なブログ。 最近、テキストチャットを使ったコミュニケーションが円滑になるためには？という課題についてよく考えるのでチャットユーザの民度を上げるための覚え書きをまとめます。 Slackなどを使ったチャットコミニュケーションの民度、運用の成熟に思いを馳せてる。 — あほむ (@ahomu) June 28, 2016 オフィスワーカーにとってのチャット オフィスワーカーであっても、メールと同じで記録が残りメールよりも即時性が高い、チャットによるコミュニケーションは少なくありません。物理的に移動する手間を省き、送信側の任意のタイミングでメッセージを送れることなどが魅力です。 口頭コミュニケーションは即時性が高い代わりに揮発性も高く、その場に居合わせないと得られない情報です。口頭
小さい広告的な Flash を Chrome で自動再生させちゃうアレ
重要でない Flash を Chrome は遮断する Googleは、ChromeでFlashをあからさまに遮断するわけではないが、動画などの「中心的コンテンツ」の再生のみを許可し、Flashアニメーションなどの周辺コンテンツは一時停止させる。 「Chrome」、Flash広告をデフォルトで停止に--9月1日から - CNET Japan Chrome のデフォルト設定では重要でないとされる広告的なサイズの Flash は自動再生が行われないようになっています。 業務でこの仕様について調べたところ、Flash がある一定以上のサイズで表示されていれば自動再生されますが、ある一定のサイズを下回ると自動再生されなくなることが分かりました。 Width 基準なのか Height 基準なのか、はたまた面積なのか画面サイズやウインドウサイズに対する相対値なのか、他にも条件があるかもしれません。詳細は
HTML6 でも CSS4 でもない Web 技術のゆくえ - WCAN 2015 Winter に登壇してきました
@kazumich さんにお声がけいただき、WCAN 2015 Winter でおよそ 60 分ほどのセッションを登壇してきました。32:9 のスクリーンがあるという、TED でもやるんかオイという特殊な環境でした。普段はプロジェクター的な投影なので、スクリーンの前に立つのが微妙なんですが、ここはディスプレイが壁面に大量に並んでいて自ら発光するので、部屋を暗くしなくてもテレビのように十分に見えますし前に立っても平気です。 一緒に登壇したのが @yhassy さんと @Hidehisa さんということもあり、近年まれに見る胃痛を伴う緊張を味わいながらお話させていだきました。（リアルにセッション終了後、1時間くらい胃痛がズキズキしてました） 技術的なお話でした 参加されたみなさま、メインセッションや LT に登壇された各位、ならびに運営されたスタッフの方々、ひとまずお疲れさまでございました。貴
RAIL という Web パフォーマンスモデルの概要
RAIL を簡単に紹介する 主に Googler が、という趣ですが今年に入ってから RAIL というパフォーマンスモデルが紹介される機会が増えてきました。 RAIL は Response / Animation / Idle / Load の頭文字をとった命名で「アプリケーションのライフサイクルの観点から、それぞれのフェーズの基準時間（限界時間）を示したもの」です。 手前味噌ながら Webパフォーマンスにおけるイニシャライズとランタイム で紹介したうちの「ランタイム」部分が細分化されて、それぞれに基準時間を割り当てたようなイメージです。 Idle や Animation あたりの時間は紹介する人・タイミングによって多少ブレている印象ですが、大まかに以下のような感じです。 Response : 100ms 「UI が操作されたときユーザーにレスポンスするまでの応答時間は 100ms 以内」
【AD】名古屋に戻ってリモートワーカーになりました
なっごや〜 周囲の方々へのご報告を兼ねまして、家庭の事情と思う所があり名古屋に引っ越しました。半年に及ぶ相談と調整を経て、幸いにも諸々の条件つきで現職のままでございます。 名古屋で粛々とした勉強会をやったりとか色々検討中なので、よしなにお願い致します。 リモート業務との向き合い方 リモートとイモートって似てない？ イモート業務したくない？？ — あほむ (@ahomu) June 22, 2015 などとバカなことを言っていたら、本当にリモート業務を始めることになりました。当面は今のプロジェクトのチーム（開発系だけで20人近くいる!!）で仕事をするのでチームプレイがんばります。 遠隔地とコミットメント 在宅勤務というと自由気ままなイメージがありますが、実は人一倍他人に対して気遣いができる、コミュニケーション能力の高い人間でないと、務まらないです。 また、人並み以上にチームや組織全体の目標に
Isomorphic Architecture を実装してるときの細かいアレコレ
Isomorphic あらため Universal ？ 一時期火がついていた Isomorphic について。各自がプロダクションの事例を作り上げる潜伏期に入ったのか、はたまた本当に一過性で火が消えたのか、コモディティ化を遂げたのか分かりませんが、あまり耳にすることがなくなった印象です。 そんな中ですが先日、Universal JavaScript — Medium が公開され、なるほど Universal ってキモチになったので、タイトルに反して以下は Universal と呼称します。 今回の話題にするのは module レベルではなく Universal な JavaScript architecture のほうです。アーキテクチャのレベルで Universal なコードが役立つ代表的ケースは SPA (Single Page Application) と SSR (Server S
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
