JavaScriptよ。文明を捨て、自然に還れ。
Web ナチュラリスト フィードを眺めていたら Alex Russell 氏の新作が投稿されていた。 The "Developer Experience" Bait-and-Switch | Infrequently Noted 本来の趣旨については原文を読んでもらえばいいし、下記はこれを読んだ上で普段の考えを踏まえて脳裏をよぎったポエムである。 我々は複雑性で仕事をしている 仕事をしている、もしくはそれでお金を稼いでいる。誰もが。 私は 2012 年頃から Web の、特に Web フロントエンドの複雑性に加担している自覚がある。 Web の専門性が高まることはその技術領域に深淵な価値があることを示唆し、それに携わることの価値を相対的に向上させることができる。 私の活動そのものは些細なものだが、かくして 2018 年現在の Web はかくも複雑になることに成功し、エンジニアリングの名の下
Web クライアントサイドのパフォーマンスメトリクス — Speed Index、Paint Timing、TTI etc...
色々なパフォーマンス指標のこと 何かを評価するときには何らかの指標（メトリクス）を定めますが、何を指標として設定してどのように測るかというのは重要です。 いわゆる KPI もそうですが、扱っている商材やビジネスのステージ（フェーズ）によっても適切な指標は変わるかもしれません。色々な指標をよく理解して引き出しを広げておくことは、状況に合わせて適切な指標を選んで改善していく過程で役立ちます。 これまでのパフォーマンス指標 過去の Web パフォーマンス界隈はバックエンドから HTML ドキュメントを返却する際の所要時間や、Web ページロード時の各イベントの発火時間を計測する方法が多く見られました。 Backend Time Browser Event Based DOMContentLoaded Page load ( onload ) 近年は特に後者の、既定のイベント発火に依存していたクラ
リモートワークの勘所と限界について1年くらいの感想、組織にとっての選択肢作りの話
1年くらいリモートワークを続けてみた感想 まず当然ながら「リモートワークは生産性が高い！これこそ未来のワークスタイル！」のような感想はありません。 生産性やコミュニケーションに関連するメリット、デメリットをうまく相殺しきれれば、生活の自由度だけ向上してハッピー、と考えています。 今は自宅かレンタルオフィスのいずれかを作業場として開発などを行いつつ、本社がある渋谷には1泊2日の出張を月2回するようなペースで仕事をしています。基本は Slack でテキストチャットによるコミュニケーションをメインとしつつ、必要があれば MTG に Hangout でビデオチャットで参加します。 生産性は大して上がらない 期待していた生産性は、それほど向上することはありませんでした。 東京にさえいなければ気軽に MTG に呼び出されることもありませんし、開発に充てることが可能な時間は若干増えています。通勤時間が長
開発や業務におけるチャットを使った情報共有の民度、潜伏あるいは揮発してしまう情報のリスクについて
テキストチャット中心の開発コミュニケーションと課題感 ご飯ブログを書いてばかりで、老害活動できていないからたまには真っ当なブログ。 最近、テキストチャットを使ったコミュニケーションが円滑になるためには？という課題についてよく考えるのでチャットユーザの民度を上げるための覚え書きをまとめます。 Slackなどを使ったチャットコミニュケーションの民度、運用の成熟に思いを馳せてる。 — あほむ (@ahomu) June 28, 2016 オフィスワーカーにとってのチャット オフィスワーカーであっても、メールと同じで記録が残りメールよりも即時性が高い、チャットによるコミュニケーションは少なくありません。物理的に移動する手間を省き、送信側の任意のタイミングでメッセージを送れることなどが魅力です。 口頭コミュニケーションは即時性が高い代わりに揮発性も高く、その場に居合わせないと得られない情報です。口頭
RAIL という Web パフォーマンスモデルの概要
RAIL を簡単に紹介する 主に Googler が、という趣ですが今年に入ってから RAIL というパフォーマンスモデルが紹介される機会が増えてきました。 RAIL は Response / Animation / Idle / Load の頭文字をとった命名で「アプリケーションのライフサイクルの観点から、それぞれのフェーズの基準時間（限界時間）を示したもの」です。 手前味噌ながら Webパフォーマンスにおけるイニシャライズとランタイム で紹介したうちの「ランタイム」部分が細分化されて、それぞれに基準時間を割り当てたようなイメージです。 Idle や Animation あたりの時間は紹介する人・タイミングによって多少ブレている印象ですが、大まかに以下のような感じです。 Response : 100ms 「UI が操作されたときユーザーにレスポンスするまでの応答時間は 100ms 以内」
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 に入れてダウンロードさせると
2014年のWebパフォーマンスふりかえり - 来年以降の期待etc
ひさびさにWebフロントエンドパフォーマンス系の話題をつらつらと書いてみます。例によってモバイル系開発者寄りの視点かもしれません。文中の参照リンク多め。 ファクタ まずはパフォーマンスに影響を与えるファクタについての所感。Webパフォーマンスにおけるイニシャライズとランタイム ::ハブろぐ で示した分類に基づきます。 イニシャライズ（いわゆるページロード） 4GやLTEが普及してもコンテンツの肥大化には追いついていない concat と CSS Sprites の呪いが解けない HTTP/2 の Streams and Multiplexing に期待 HTTP/2 の Server Push にも期待 画像周りだと <picture> 関連仕様も使いたい（srcsetだけならいける？） WebRTC とか WebSocket とかストリーミングとかは？ （やや疎い、てかイニシャライズじゃ
フロントエンドチューニングの箇条殴り書き
普段気をつけてるよリスト "モバイルで、WebViewとブラウザのコンパチで、特にセオリー化されていないデザインモジュールのなか、装飾画像もふんだんに使うぞ系サービス開発" の文脈における、パフォーマンス確保のため気をつけてるよリスト。 よく、パフォーマンス「向上」とか「確保」とか申しますが、メンテナンスコストなどと天秤にかけて、「必要十分」のラインを狙うのが重要だと思う次第。 画像リソース 画像リソースを揃えるときのセオリ。圧縮率とか最適化とか細かいチューニングはあれど、大雑把に下記を守る。そしてImage Optim（or 相当の処理）。 JPEGはプログレッシブで画質60くらい（オレ目安） PNGは差し支えない範囲で色数をきちんと削る 50px未満のサムネイルは@2.0xなリソースにしない 案外、Androidあわせの@1.5xや@1.0xでも大丈夫なことすらある GIFアニメを入れ
ScalaでAndroidアプリな修行をはじめています
Android！ 自称フロントエンドエンジニアということで、普段はHTML/CSS/JavaScriptが守備範囲ですが、Android/iOSでネイティブアプリも作ることができたら、クライアントサイド実装の幅を拡げられるな〜、ということでレッツトライ。 前回Railsで俺専用RSSリーダーを用意したので、それのControllerに.jsonのレスポンスを追加してAPIらしくしました。 それを取得してAndroidでリスト表示＋選択した記事のWebView表示くらいまでを目標に挑戦中。 今の時点でも、リスト表示とカテゴリー切り替え、WebViewでの記事表示までは出来てます(∩´∀｀)∩ ﾜｰｲ 解説記事を見ながら環境構築 前提としてScala + IntelliJ IDEAでAndroidしたかったので、 ちょうど同じ条件で手順を解説されている[Mac] Android アプリを Sc
続々・PhantomJSで遊びながらHARをYSlowする
今回は元ネタあり 今回はWeb Performance Power Tool: HTTP Archive (HAR) - igvita.comを元に、HARします。はー。 HTTP Archive 1.2 (frozen) format that can be used by HTTP monitoring tools to export collected data. HAR 1.2 Spec | Software is hard HARというのはHTTPのモニタリングデータの収集結果を表すファイルです。中身は所定のフォーマットに従って書かれた、ただのJSONファイルですね。Request・Responseなどなどが記録されています。 HARの生成 YSlowに.harを渡す パフォーマンス解析の結果を得る のような順序で進めます。 HARの生成 HARの生成については、phantomj
Rails + Heroku で俺専用RSSリーダー作った
Webアプリのリハビリ ということで、Official Blog: A second spring of cleaningで告知された、Google Reader閉鎖に備え、俺専用RSSリーダーをRuby on Railsで軽めに作ってみた。 read.aho.mu 目的としてはRuby + Railsの学習と、サーバーサイドのリハビリのつもりだったのだけど、簡単すぎて実作業1日分くらいで終わってしまった..(´・ω・`) 自分で登録したフィードを、自分でなんとなく流し読みして、良いと思った記事に♡を付けられるだけなのですが、それがついでにオープンになっているだけ。 色々もにょもにょ 触ってみた箇所について所感など。 前からScalaなりNodeなりでHello Worldまでは試してましたが、素直にRailsをデプロイして動くところまで手を入れたのは初。 無料で使えるアドオンを幾つか入れ
Gruntによる継続的なビルド環境を求めて 〜 package.jsonと0.4.0のこと
安定したビルド環境 gruntの広まりを感じる...。みんな...package.jsonをつかうのです...そしてバージョンにも気を遣ってstableな環境を目指すのです....安定して使えないビルド環境はいくらナウくてもゴミです....。 — aho.mu (@ahomu) December 11, 2012 夏前に、nodeでビルドってなんかナウい(∩´∀｀)∩ワーイって使い始めて、秋から現職のプロジェクトで実践してみた結果、そんな当たり前な視点を忘れないようにしなければ、と強く思った次第。 今回は下記の2点を紹介します。 Gruntと永く付き合うためのノウハウとして、package.jsonを使った管理について 賞味期限の短いノウハウとして、Grunt 0.4.0への移行に関して Gruntイイヨーの続きとして、今後付き合っていくために必要なことを改めておさらい。 1. packa
Backbone.js コメント付きソースコード日本語訳
Annotated Sourceのコメントを訳しました 地味に道のりが長い作業でしたが、何とか先々週末にやっつけて、例によって@cssradar氏に確認していただいたりとかして今に至りご紹介する次第。 日本語訳コメントがついたソースコード· enja-oss/Backbone · GitHub なんだかんだで全域を網羅する必要があったたので、非常に勉強になりました。ソースコード自体は短く簡潔なので、Backboneをこれから使い始める/もう使ってるを問わず、まだ読んでない方は一度読んでみると良いです。 監訳謝辞 Revert original text for supervise by ahomu · Pull Request #12 · enja-oss/Backbone 上記Pull Request＆監訳依頼につきまして、多大なるレビューをしてくださった@cssradar 氏に感謝を。
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
