JavaScriptよ。文明を捨て、自然に還れ。
Web ナチュラリスト フィードを眺めていたら Alex Russell 氏の新作が投稿されていた。 The "Developer Experience" Bait-and-Switch | Infrequently Noted 本来の趣旨については原文を読んでもらえばいいし、下記はこれを読んだ上で普段の考えを踏まえて脳裏をよぎったポエムである。 我々は複雑性で仕事をしている 仕事をしている、もしくはそれでお金を稼いでいる。誰もが。 私は 2012 年頃から Web の、特に Web フロントエンドの複雑性に加担している自覚がある。 Web の専門性が高まることはその技術領域に深淵な価値があることを示唆し、それに携わることの価値を相対的に向上させることができる。 私の活動そのものは些細なものだが、かくして 2018 年現在の Web はかくも複雑になることに成功し、エンジニアリングの名の下
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
SPA + サーバーサイドレンダリング、そのダルさに関する私見
いわゆる SPA + サーバーサイドレンダリングがダルい 唐突ですがおさらいです。 なぜサーバーサイドレンダリング（SSR）が嬉しいかと言えば 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰にやさしい（） 古いブラウザ・低性能マシンにやさしい yahoo/fluxible による SPA + Server Rendering の概観 ::ハブろぐ であり、特に SPA + SSR の文脈においては Universal Architecture による SPA + SSR は、技術的には過渡期の歪なキメラっぽさが拭いきれませんが、昨今の Web フロントエンドにしては珍しくビジネス的な説得力があります。 SSR なのでSNSや検索からの流入による初期表示が速い SPA なので回遊時のページ遷移も速い SSR なので古いブラウザでも CSS
リモートワークの勘所と限界について1年くらいの感想、組織にとっての選択肢作りの話
1年くらいリモートワークを続けてみた感想 まず当然ながら「リモートワークは生産性が高い！これこそ未来のワークスタイル！」のような感想はありません。 生産性やコミュニケーションに関連するメリット、デメリットをうまく相殺しきれれば、生活の自由度だけ向上してハッピー、と考えています。 今は自宅かレンタルオフィスのいずれかを作業場として開発などを行いつつ、本社がある渋谷には1泊2日の出張を月2回するようなペースで仕事をしています。基本は Slack でテキストチャットによるコミュニケーションをメインとしつつ、必要があれば MTG に Hangout でビデオチャットで参加します。 生産性は大して上がらない 期待していた生産性は、それほど向上することはありませんでした。 東京にさえいなければ気軽に MTG に呼び出されることもありませんし、開発に充てることが可能な時間は若干増えています。通勤時間が長
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
AngularJS についての所感
AgularJS に対する気持ち 所感といいつつ、主に自分がつらさとして感じていることを書く。所感シリーズとしては jQueryについての所感 も併せて読みたい。 この学習曲線の中でいうと、たぶん今の自分は Very Cool! の頂点から降りている最中くらいだと思う。そして、マサカリをふりかぶった諸兄にひとつだけ言いたいのは、共感脳を養った方がモテるということだ。 チキンハート的弁解: 以下はAngularJSに関するつらさを述べることに専念するために、美点を挙げていないだけであってAngularJSを全方位的に貶めたり、何かと比べて明確にクソだというような意図はない。 画像は AngularJS: The Best Parts · Anand Mani Sankar からの引用。X軸にある www.bennadel.com は AngularJS 大好きさん。 辛1. $scope が
WCAN 2013 Summer で「ハイパフォーマンスWebフロントエンド」を話してきました
スライド 振り返り 50分という限られた時間の中で、Network・Render・Computeという3本柱についてご紹介するという構成に挑ませていただきました。 恐らくフロントエンドが専門でない方も多くいらした中で、どこまでニュアンスだけでも届けられるように、という面の調整が多かったです。 結果的には目に見えるRenderについて多めに盛り込んで着地しています。 WebKit依存の内容が多めの所から、Canaryに載っている開発者ツールの使い方を通して、パフォーマンス問題の検証と対策について肉付けしている構成です。 参考にした資料のURLリスト 導入のあたり 開発者のための WebKit (“WebKit for Developers” 日本語訳) Performance Checklist for the Mobile Web - YouTube Strangeloop - Impac
技術は発想やデザインの限界にならない
当時の思い違い たとえば、一般的なエンジニアが何かを作ろうとすると、その個人の「技術的な限界＝発想の限界」となりがちです。 ではデザイナーと呼ばれるような職能を持っているひとが、果たしてプロダクトを実装として理解すべきか、というと、それは分業上の実装サイドによるエゴ（こっちの都合もちゃんと考えて欲しい！的な）でしかないと思っていました。 多少、吹っ飛んだ話であっても、意図を失わずに現実的な実装に落とし込むのはコミュニケーションの問題であって、デザイナー職能の理解不足ではない、と。 コミュニケーションでも解決できる問題として、これは今も間違ってはいないはずですが。 しかし、これは適切なタイミングで、大きな青写真を描くための能力であり、デザイナー職能を全うする話とは違ったのです。 優秀とは 身の回りで優秀なデザイナーと呼ばれる諸氏は、ビジュアルを作るだけでなくステートの管理までよく考え、利用コ
さくらのVPSにGoogleのmod_pagespeed入れてみた ハブろぐ - havelog.ayumusato.com
原理的に、2倍も速くなったら元が酷いんじゃないか疑惑を感じつつ あなたのサイトも最高2倍速に？！Google純正のサイト高速化モジュール『mod_pagespeed』だと・・・ - IDEA*IDEA ～ 百式管理人のライフハックブログ 速くなるのはいいことなのでレッツトライ。 さくらのVPS 標準 CentOS5.5 x86-64 にmod_pagespeedをインストールしてみたところあっさり行かなかったので、メモ貼りエントリーします。ここでは、mod_pagespeedの概要は、すっ飛ばしてインストールを進める次第。 サクっとインストールするつもりが公開鍵でつまづいた % wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_x86_64.rpm % sudo yum localinstal
俺流BackboneラーメンとPhalanxのはなし
前置き この記事は Frontrend Advent Calendar 2013 の7日目です。 意見表明を避けてたジャンルだけど、俺流Backbone.jsとの付き合い方と、それを反映したライブラリについて書いてみる。大半が夏前に書かれていたけど、イマイチで放置してた系を掘り起こした！ 職場近くに俺流塩らーめんというお店があって、そこの熟成塩ラーメン(¥680)が、スガキヤのラーメン(¥280)に近い味してる気がする。¥400余分に払っても価値がある。 巷ではdata bindingsだとかMV*の在り方に関心が集まっている昨今、マイペースにAOP風（記述言語がないので実装はmixin...）とか、Viewの領域管理の表現に腐心していた。 今の時点ではこれがベストとは思っておらず、つまるところ Marionette.js あたりを上手に使うことに注力すれば良さそうというのが結論だ。そこに
フロントエンドチューニングの箇条殴り書き
普段気をつけてるよリスト "モバイルで、WebViewとブラウザのコンパチで、特にセオリー化されていないデザインモジュールのなか、装飾画像もふんだんに使うぞ系サービス開発" の文脈における、パフォーマンス確保のため気をつけてるよリスト。 よく、パフォーマンス「向上」とか「確保」とか申しますが、メンテナンスコストなどと天秤にかけて、「必要十分」のラインを狙うのが重要だと思う次第。 画像リソース 画像リソースを揃えるときのセオリ。圧縮率とか最適化とか細かいチューニングはあれど、大雑把に下記を守る。そしてImage Optim（or 相当の処理）。 JPEGはプログレッシブで画質60くらい（オレ目安） PNGは差し支えない範囲で色数をきちんと削る 50px未満のサムネイルは@2.0xなリソースにしない 案外、Androidあわせの@1.5xや@1.0xでも大丈夫なことすらある GIFアニメを入れ
モバイルブラウザでの画像アップロードについて覚え書き
前置き スマートフォンブラウザで画像アップロードしたいという要件があったので、あんまり無理しないで実装できるとこまでやったら、どうなるのかやってみた。 やりたいことは、アップロードに加えて、画像データにリサイズ処理を適用すること。さすがに3G回線で2MB近い画像データを、input[type="file"]でそのまま送りつけるのは無理がある。 某所で書いたブツの要約版なので、某所のほうを見た諸氏はアレでソレして解釈してください : ) サンプルコード 基本方針としては、以下のようなコードで処理することになる。 var elFileInput = document.getElementById('js-select-photo'), elPreview = document.getElementById('js-preview-photo'), createObjectURL = windo
モバイルブラウザのキャッシュとデータストレージについて
表題の件について情報を漁った 現時点で裏取り検証をまったくしていないので、議論対象の参考程度でお願いします。 これから実際に手元のプロダクトで検証していく予定ですが、誤読や内容などの疑わしきはTwitterとかでマサカリ投げてください。 ここでは海外のイカしたgeekらが調べてくれた、貴重な情報を信じて話を進めて参ります。素直が一番って、ばーちゃんが言ってました。 Browser Cache キャッシュと言っても無限の領域ではなく、むしろ現実的に出回っているモバイルデバイスのリソースは、ごくごく有限です。その上でブラウザの振る舞いを理解できていないことを反省して、ちょっと調べてみた次第。 まずはブラウザキャッシュに依存したストラテジを支える、キャッシュコントロール + ユーザー操作に関するブラウザの基本的な振る舞いについて。 Early findings: Mobile browser c
Backbone.jsを使うときに参考になるリソース 2012年末版 (Backbone Advent Calendar 2012 25th day)
Backboneを使うときの参考情報たち Advent Calendarがネタ切れの折、最終日が冴えない小ネタで終わるよりはマシかということでリストアップしてみた。 日本語リソース では早速、日本語のリソースから。古い情報はリストから外しているので、いくらか偏りがあるかも。悪しからず。 ビギナー向けにまとまったの CodeGrid - フロントエンドに関わる人々のガイド Backbone.js Advent Calendar 2011 - Qiita CodeGridで連載中のBackbone入門が、ちょうどリアルタイムに更新されているビギナー向け情報でおすすめ。ただし有料。去年のAdvent Calendarも丁寧でおすすめ。 enja-oss/Backbone · GitHub JavaScript MVCフレームワーク Backbone.jsのコメント付きソースコード日本語訳が公開
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 氏に感謝を。
最強のJavaScript IDE「WebStorm」の姉妹品「PhpStorm」はPHP IDEとして最高だった ::ハブろぐ
先に「WebStorm」について軽く言及 【コラム】イマドキのIDE事情 (94) 最強のJavaScript IDE「WebStorm」を試してみる | エンタープライズ | マイコミジャーナル 最強のJavaScript IDE 「WebStorm」を使ってみた | Web scratch 最強と称したのは自分じゃないのですが、「WebStorm」は最強らしいです。最強な割に、AptanaとかKomodo等と比べるとマイナー感が溢れているのですが、気のせいでしょうか。 WebStorm自身、いつの間にかJavaScript向けのIDEということになっていますが、実際はWebフロントエンド全般に適したIDEです。そのため、HTMLやCSSについても、優秀な機能を備えています。とはいえ、HTMLやCSSだけを取り扱う場合はIDEが縁遠い気もするので、実質JavaScriptでゴリゴリ開発す
jQuery Mobileをマジメに使うならやっておくべきローカライズとかの設定
jQuery Mobileつかってますか？ jQueryでキャラを立てたいわけじゃないんですが...，たびたびのjQueryネタです．なんだかんだで需要が高く，最近は実案件で触る機会があったので情報を残します． いくらお手軽でも，まじめに使うならこれぐらいはやっておかないとダメじゃないかと思う設定のポイントを軽く紹介．Loading...とかデフォルト英語なラベルの変更とかです． 設定の初期化 デフォルトの文字表示やクラス名等の設定を変更するときは，Configuring Defaultsによると，jQuery本体とjQuery Mobileの間に初期化スクリプトを挿入します． <script src="http://code.jquery.com/jquery-1.5.2.min.js"></script> <script type="text/javascript"> $(docume
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
