リモートワークの勘所と限界について1年くらいの感想、組織にとっての選択肢作りの話
1年くらいリモートワークを続けてみた感想 まず当然ながら「リモートワークは生産性が高い！これこそ未来のワークスタイル！」のような感想はありません。 生産性やコミュニケーションに関連するメリット、デメリットをうまく相殺しきれれば、生活の自由度だけ向上してハッピー、と考えています。 今は自宅かレンタルオフィスのいずれかを作業場として開発などを行いつつ、本社がある渋谷には1泊2日の出張を月2回するようなペースで仕事をしています。基本は Slack でテキストチャットによるコミュニケーションをメインとしつつ、必要があれば MTG に Hangout でビデオチャットで参加します。 生産性は大して上がらない 期待していた生産性は、それほど向上することはありませんでした。 東京にさえいなければ気軽に MTG に呼び出されることもありませんし、開発に充てることが可能な時間は若干増えています。通勤時間が長
ブラウザベンダによる Flash 包囲網の現状メモ ( 2016年12月20日アップデート )
Flash の息の根がいよいよ止まりそう ※ ( 2016年7月21日 ) Firefox について動きがあったので追記しました ※ ( 2016年10月10日 ) Chrome について 8/9 付けの動きを追記しました ※ ( 2016年10月10日 ) Safari 10 の挙動について追記しました ※ ( 2016年12月20日 ) Chrome のについて 12/9 付けの動きを追記しました ※ ( 2016年12月20日 ) Edge について 12/14 付けの動きを追記しました 脱 Flash、祝 HTML5 という機運が高まったのはだいぶ前の話ですが、実際には Flash コンテンツは今もなお数多くが生き続けています。たとえばニコニコ動画のプレイヤーであったり、アメーバピグや艦これのような人気ゲームにも Flash で作られているものがあります。 各ブラウザの状況 まだま
babel な ESLint の設定をがんばった
やんなくちゃなー、と思っていたので Lint Like It’s 2015 — Medium を眺めながら、ahomu/es6-Kameita の JavaScript Linter を ESLint に乗り換えました。 Lint の設定つくるのがダルイ問題 本当にだるい。この投稿を書いている時点では .eslintrc を以下のようにしました。 スペースの入れ方については、強い意志をもって堅めの設定になっているはず。 max-params はちょい甘めです。consistent-this を全力で否定しているので、流用したい方は気をつけた方がよろしいかと。 { "parser": "babel-eslint", "env": { "browser": true, "node": true }, "rules": { "strict": 2, "default-case": 2, "no-
TypeScript における ES6 との兼ね合いで避けているパーツ
ES6 フレンドリな TypeScript のために 先日書いた JSX と TypeScript の混合 Flux または悪魔合体 の経緯から TypeScript と JSX を併用しているため、コードの記述に大きな差ができないよういくつかのパーツ（主に TypeScript のもの）を避けることにしています。 NGなパーツ 独断と偏見です。 Private/Public modifiers ジャングル ニ プライベート ナイ！ class Acme { private himitsu = ''; public tellme() {} } みたいなのですね。バイオ JS にプライベートなんて必要なかったんや。protected も使えるっぽいけどアンドキュメント？ Modules ES6 ライクな import/export だけ使うということで内部モジュール禁止です。不便ないですね。
もうES6 (ES2015) でいいんじゃないか
個人プロジェクトは ES6 で書いている ブログの頻度が落ちているので、継続のための雑さな記事を醸し出す時期。 以前に es6-Kameita を紹介したときの繰り返しですが、Babel (旧名 6to5) の登場から個人プロジェクトは ECMAScript 6 で書くようにしています。仕事でも新しい開発がある予定なので、そこでもきっと ES6 を使うことでしょう。 ahomu/Talkie ahomu/Urler ahomu/Claylump ということで「もう ES6 でいいんじゃないか」という気持ちを書きます。 厳密には、ES6トランスパイラを使っていけばいいんじゃないか、という話 仕様周りは（きっと）安定してきている 世間的の大多数的には、ES6とES7の境界すらハッキリしていないであろう状況ではありますが、ES6自体は2015年中の勧告を目標に進んでいることから、それなりに安定し
最近あまり使ってない、流行っていた時期もあるフロントエンドもの
最近あまり使ってない、ちょっと前の流行りもの なんとなく書いてみます。Web アプリケーション開発屋さんなので、Web サイト制作屋さんとはかなり文脈ズレると思います。 jQuery ファミリー 個人的には jQuery って、協業用のツールという位置づけでした。jQuery でさえ書かれていれば、jQuery 書ける人材のほうが外からも調達しやすいため、人員の流動にも有効と考えられる頃が確かにありました。 DOM に触れてくれるな勢の台頭 ところが昨今では AngularJS や React、その他ライブラリでも DOM 操作が大いに抽象化されていることが多く、jQuery で直接 DOM を操作すること自体が相性良くないケースが散見されます。今思えば Backbone.js くらいのころが jQuery 需要の最終ピークだったように思います。 jQuery プラグイン の需要減 jQu
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アニメを入れ
iOS6 スクロール中のタイマー発火絡みのバグ備忘
Fxck iOS6!!! と思っている方々も少なからずいらっしゃるのではないでしょうか。ぼくは今わりとそう思っています。 だって、Androidでposition: fixedとか、z-indexとか、怪しげなモノって使わずに避ける、慎重に触れるとかまだ何とかなるじゃないですか。伝家の宝刀「Androidですから…」って言い訳も少なからず使えますし。けれども、AjaxとかTimer周りって、必須すぎて避けようがないんですよ。任意のタイミングで再描画起こすためにsetTimeoutとか使いますよね。遅延描画的な溜め込みとか、ほら、いろいろ。しかもそれ、iOSの最新版ですよ。 そんなわけで、ぼくはiOS6があまり好きではありません。（前置き） でまぁ、Ajaxについては下記によくまとまっていますし、9月ごろの情報ですね。 Understanding the iOS6 AJAX bugs | G
モバイルブラウザのキャッシュとデータストレージについて
表題の件について情報を漁った 現時点で裏取り検証をまったくしていないので、議論対象の参考程度でお願いします。 これから実際に手元のプロダクトで検証していく予定ですが、誤読や内容などの疑わしきはTwitterとかでマサカリ投げてください。 ここでは海外のイカしたgeekらが調べてくれた、貴重な情報を信じて話を進めて参ります。素直が一番って、ばーちゃんが言ってました。 Browser Cache キャッシュと言っても無限の領域ではなく、むしろ現実的に出回っているモバイルデバイスのリソースは、ごくごく有限です。その上でブラウザの振る舞いを理解できていないことを反省して、ちょっと調べてみた次第。 まずはブラウザキャッシュに依存したストラテジを支える、キャッシュコントロール + ユーザー操作に関するブラウザの基本的な振る舞いについて。 Early findings: Mobile browser c
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
