1年くらいリモートワークを続けてみた感想 まず当然ながら「リモートワークは生産性が高い！これこそ未来のワークスタイル！」のような感想はありません。 生産性やコミュニケーションに関連するメリット、デメリットをうまく相殺しきれれば、生活の自由度だけ向上してハッピー、と考えています。 今は自宅かレンタルオフィスのいずれかを作業場として開発などを行いつつ、本社がある渋谷には1泊2日の出張を月2回するようなペースで仕事をしています。基本は Slack でテキストチャットによるコミュニケーションをメインとしつつ、必要があれば MTG に Hangout でビデオチャットで参加します。 生産性は大して上がらない 期待していた生産性は、それほど向上することはありませんでした。 東京にさえいなければ気軽に MTG に呼び出されることもありませんし、開発に充てることが可能な時間は若干増えています。通勤時間が長

コンポーネント管理できそうなライブラリの選定 ここでいうコンポーネントは HTML 要素をコンポーネントに見立てるような、近代 Web フロントエンドにおける狭義のコンポーネントです。大まかな条件は次の3点。 コンポーネント中心の開発ができること >= IE9 をサポートすること（切っても良さそうなんだけど...） 既製品・スクラッチは問わないが極端なリスクは踏めない（納期がシビア） あとは期待度や API のセンスなど、個人的な審美眼判定に依ります。 angular/angular : 2.0 が正式リリースしたらまた会いましょう jashkenas/backbone : 最近のコンポーネント管理には及ばない Custom Elements ( Polymer ) : polyfill が >= IE10サポート segmentio/deku : 振る舞いは十分だったけど、>= IE10

インタラクションのモックアップ ネイティブアプリを作っていて、いわゆるインタラクション・アニメーションの部分をモックアップできるツールの必要性を感じたので @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 結果、一番

ひさびさにWebフロントエンドパフォーマンス系の話題をつらつらと書いてみます。例によってモバイル系開発者寄りの視点かもしれません。文中の参照リンク多め。 ファクタ まずはパフォーマンスに影響を与えるファクタについての所感。Webパフォーマンスにおけるイニシャライズとランタイム ::ハブろぐ で示した分類に基づきます。 イニシャライズ（いわゆるページロード） 4GやLTEが普及してもコンテンツの肥大化には追いついていない concat と CSS Sprites の呪いが解けない HTTP/2 の Streams and Multiplexing に期待 HTTP/2 の Server Push にも期待 画像周りだと <picture> 関連仕様も使いたい（srcsetだけならいける？） WebRTC とか WebSocket とかストリーミングとかは？ （やや疎い、てかイニシャライズじゃ

この記事は ラーメン Advent Calendar 2014 - Adventar への寄稿（フライング）です。中本 以外で今年行った渋谷近辺のラーメン屋（の一部）のふりかえり。 蒼龍山 道玄坂にある職場近...いようなそうでもないような場所にあるラーメン屋。青山椒担々麺がものすごいしびれる味。辛さはそれほどでもないので、ムシャクシャしたときも中本よりは胃腸にやさしい。

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

ひさびさの金沢でFrontrendでした FRONTREND IN KANAZAWA 今回はDMM.comラボさまのご協力で、金沢での講演となりました。2年以上前にKanazawa.jsで訪れて以来でしたが、色々見覚えのある光景やらに懐かしく感じた次第。（故郷ではない） 懇親会でもお久しぶりな方とチラホラ楽しいお話ができたり、新しい出会いもあったりでとっても愉快な感じでした。(∩´∀｀)∩ 10年先生きのこるには スライドはしばらく後の公開になりますが、スライドだけ見てもあまり価値がないです。フロントエンドの広い範囲において、ライブラリスタックやらツールセットやらの比較やポイントをサマリーでお伝えした感じです。 『10年先のため、今身につけたいこと』 今回の共通テーマと向き合うにあたって、どういう伝え方をしようかなーとうんうん考えた結果、、、 フロントエンドはなぜ流行り廃りが速いのか 流行

JavaScript 系パッケージマネージャの重複問題 npm は言わずもがな Node.js のパッケージマネージャだが、フロントエンド開発においては Bower も利用するのが一般的になっている。この現状の問題点は、package.jon と bower.json という似たような管理ファイルを二重で管理しなければならないということだ。 現状の使い分けをおさらいをしておくと、次のような感じになる。 タスクランナー（Grunt/gulp）・モジュールシステム（browserify/webpack）・テストスイート（karma/testem）などの開発環境系の管理が npm の主なお仕事。インストールされたパッケージは node_modules 内に展開されて、CommonJS スタイルのモジュール管理から利用する。 本題につながる話としては、ブラウザで動くライブラリの一部は npm にも

Concept 『Web Components with Virtual DOM』 ahomu/Claylump Motivation Web Components ラッパーを書いてみたいなーと思った React の JSX がイマイチ気にくわない（JSとHTMLを一緒にするなオジサン） <template> に書いた内容を Virtual DOM 生成器に変換すればいいんじゃね というような所から人様のライブラリを借りてツギハギして習作してみた次第。借りてきたライブラリ（HTML String パーサと Virtual DOM）は独自実装しても楽しそうなので、やる気があればやる。 もちろん実験品なので、実用には耐えない Files claylump.polyfill.js（webcomponents.js + window.fetch + es6promise） claylump.run

AgularJS に対する気持ち 所感といいつつ、主に自分がつらさとして感じていることを書く。所感シリーズとしては jQueryについての所感 も併せて読みたい。 この学習曲線の中でいうと、たぶん今の自分は Very Cool! の頂点から降りている最中くらいだと思う。そして、マサカリをふりかぶった諸兄にひとつだけ言いたいのは、共感脳を養った方がモテるということだ。 チキンハート的弁解: 以下はAngularJSに関するつらさを述べることに専念するために、美点を挙げていないだけであってAngularJSを全方位的に貶めたり、何かと比べて明確にクソだというような意図はない。 画像は AngularJS: The Best Parts · Anand Mani Sankar からの引用。X軸にある www.bennadel.com は AngularJS 大好きさん。 辛1. $scope が

オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ

まさかのデザインに関するトーク 先日の 第49回 HTML5とか勉強会 で、Material Design と、それをWebで実践するための Polymer (Paper Elements) まわりについてお話させていただきました。 去年とか、Googler が紹介するパフォーマンス関係のわりとマニアックなトコだとかケーススタディの共有に努めたり、さらにその前もJavaScript関係のライブラリ・ツールの話をしておりました。 という流れで、エンジニア的なブランディングに終始しておりました為、今回Google I/O 現地で話を聞いてきたとはいえ、デザインに関するセッションのお話をいただいて緊張しきりでございました。 YouTube（追記） いつの間にか動画があがってました。 第49回HTML5とか勉強会「HTML5最新情報 @Google I/O」 - YouTube 小並感 なんでgr

Concatでどこまで戦えるのか @jxck_ browserify使ってるんだけどあんま意味ない感じになっててつらいんだよねーっていうのを昨日 @ahomu に話したら、concatで全然いけますよって言われたからさっき乗り換えた。 — Kazuhito Hokamura (@hokaccha) August 6, 2014 (＾ω＾) 全然いけますよ 依存管理をサボってconcat 以下、「依存管理に労力を割きたくない」という理由で依存管理を省略した場合に、concatだけで破綻無くビルドするためにやっていたパターンの紹介。いけますと言った手前はあるが、最終的には現場によってケースバイケースということで、どうかひとつご容赦願いたい。 Case 1: Backbone.js Backbone.jsの場合、extends に代表されるクラスベースのオブジェクト指向モデルに多少の制約が必要に

Sitespeed.io - Analyze your website speed and performance 大分前に見かけた気がするんですが今更ためしてみた。普通に使う分には以下のような感じでインストール＆実行できます。 # インストール brew tap sitespeedio/sitespeedio brew tap tobli/browsertime brew install sitespeed.io # 普通にたたく sitespeed.io -u http://havelog.ayumusato.com # モバイル用ルールセットで、depth=3までクローリングする sitespeed.io -u http://havelog.ayumusato.com -l sitespeed.io-mobile -d 3 これでしばらく待つと、sitespeed-result とい

直近で、新規案件に関わることになりそうなので、ライブラリ選定やタスクランナー、そして今回の依存管理のようにベーシックな話が続いてます。次第に、具体的な実装やコード設計のポストが多くなる･･･はず。 今回はVue.jsでも触れましたが、改めてcomponent - modular javascript frameworkについて。 概要 Componentはパッケージマネージャー兼、依存解決込みのビルドツールです。クライアントサイドについて、JSのパッケージマネージャーやビルダーは既にありますが、Componentは HTML/CSS/JSをセットにして扱うことができます。 npmでいうpackage.jsonと同様に、component.jsonという定義ファイルによって、パッケージの依存関係やリポジトリなどの各種情報を示します。 component/component コア部分のリポジト

Webフロントエンド・パフォーマンス 思考整理系。 Webフロントエンドにおける3要素として、過去のセッションでは下記の3つを中心に紹介していました。 通信コスト - Networking 描画コスト - Rendering 計算コスト - Computing これらの問題は複雑に絡み合い、時として相反する関係をとります。例えば、通信コストを減らすために、視覚表現を画像からCSS3に置き換えたら、描画コストが高くなってしまいスクロールが重くなった、なんてケースは頻繁にあるでしょう。 理解の問題 この3つのコストは確かにパフォーマンスに影響を与える要因であります。しかし、その要因がWebフロントエンドのページライフサイクルにおいて、どこで影響を与えているかは表してくれません。 要因がどのような影響を及ぼしうるかという基礎的な理解と、パフォーマンスの問題に取り組むための切り口としての理解は、そ

Angularとサーバーサイドテンプレートの混在 先日リリースされた某サービス(他社)がAngularを使っていて、XSSがボロボロ出てくるだとか、{{var}} な形式で値を入力するとng-template側でテンプレーティングされるだとかの話がありました。 詳しくは見ていないので、今回の話とまったく同じかは把握していませんが、サーバーサイドテンプレートを混在させると、次のようなことが起こりえます。 例えばejsとAngular サンプルとしてスカスカなControllerを用意します。 angular.module('app', []).controller('AcmeCtrl', function($scope) { $scope.foo = 'bar'; }); ejsは次のようなテンプレートになっているとします。

当時の思い違い たとえば、一般的なエンジニアが何かを作ろうとすると、その個人の「技術的な限界＝発想の限界」となりがちです。 ではデザイナーと呼ばれるような職能を持っているひとが、果たしてプロダクトを実装として理解すべきか、というと、それは分業上の実装サイドによるエゴ（こっちの都合もちゃんと考えて欲しい！的な）でしかないと思っていました。 多少、吹っ飛んだ話であっても、意図を失わずに現実的な実装に落とし込むのはコミュニケーションの問題であって、デザイナー職能の理解不足ではない、と。 コミュニケーションでも解決できる問題として、これは今も間違ってはいないはずですが。 しかし、これは適切なタイミングで、大きな青写真を描くための能力であり、デザイナー職能を全うする話とは違ったのです。 優秀とは 身の回りで優秀なデザイナーと呼ばれる諸氏は、ビジュアルを作るだけでなくステートの管理までよく考え、利用コ

ここで自分が思いを馳せることができるのは、下記のようなトピックです。 チーム構成・人材配置 アーキテクチャやライブラリの標準化 開発効率の向上・環境整備 チーム構成・人材配置 ちょっと夢見すぎかなと感じている事案のひとつに「複数職能の人間（≒ゼネラリスト）を複数人組み合わせれば少数精鋭が成り立つ」があります。 少数精鋭がなぜ少数精鋭たるかといえば、単に「精鋭だから」ということに尽きると思っています。正味な話、平均的な能力の人間を浅く広くゼネラリスト化して少数集めたところで、生産力が高まるどころか品質が低下する恐れがあります。 組織であればこそ、環境と仕組みによって品質担保を行うことはできます。よって、品質担保の仕組みと合わせて議論すべきであることを前提としつつも、昨今のフルスタックエンジニア論に踊らされる過ぎるのはそれでも危うくないでしょうか。 一方、完全なスペシャリスト集団による分業も夢