PygmentsでSyntax Highlightされたcatとlessを手に入れる
Paul Irishは云った First: `sudo easy_install Pygments` Then `alias c='pygmentize -O style=monokai -f console256 -g'` Yay, colorized cat!paulirish.com/i/colorized-ca… — Paul Irish (@paul_irish) October 14, 2012 謹んで引用。 真似しよう！ Pygments — Python syntax highlighter Pygmentsを入れます。easy_installは、たぶんMacなら標準で入ってますよね？（pythonよくわからない） % sudo easy_install Pygments シェルの設定ファイル（.zshrc・.bash_profile等）にaliasを設定します。 alia
Web サイトっぽい SPA に必要なブラウザナビゲーションのエミュレートなど
Web サイトっぽい SPA に立ち向かう 大分前の話ですが、Node学園 20時限目 今回もdots!!!!! - connpass で Client Side of なんちゃらfresh.tv としてお話した内容のうち、Web サイトっぽい SPA に関してだけこだわりを再抽出して書き留めます。 本件は、ページ全体のスクロールや頻繁なナビゲーションを伴わず、1画面におさまるレスポンシブな Web アプリを作っている場合はあんまり関係がありません。画面内の局所的な状態更新は、コンポーネントの責務分割やら何やらの設計なので実は別の話です。 総じて、Web サイトっぽいくせに大人の事情で Web ブラウザのネイティブなナビゲーションを積極的に破壊しにいくときの心構えです。 URL が変わっても最低限レンダリングできるまで画面更新を遅延させる 画面遷移に必要なのは、 URL が更新されても次の
Web クライアントサイドのパフォーマンスメトリクス — Speed Index、Paint Timing、TTI etc...
色々なパフォーマンス指標のこと 何かを評価するときには何らかの指標（メトリクス）を定めますが、何を指標として設定してどのように測るかというのは重要です。 いわゆる KPI もそうですが、扱っている商材やビジネスのステージ（フェーズ）によっても適切な指標は変わるかもしれません。色々な指標をよく理解して引き出しを広げておくことは、状況に合わせて適切な指標を選んで改善していく過程で役立ちます。 これまでのパフォーマンス指標 過去の Web パフォーマンス界隈はバックエンドから HTML ドキュメントを返却する際の所要時間や、Web ページロード時の各イベントの発火時間を計測する方法が多く見られました。 Backend Time Browser Event Based DOMContentLoaded Page load ( onload ) 近年は特に後者の、既定のイベント発火に依存していたクラ
App Shell モデルの素振り（後編）SSR なき世界観を模索してみた
3. その他 SPA にありがちな懸念点の検討 書き終わって読み直すに、いくつかの方法論は浮かぶが思った以上にやってみねぇと分からんという感じです。 ここでは SPA + SSR における完全な HTML を生成するサーバーサイドと、SPA + BFF (Backend For Frontend) くらいのゆるやかなサーバーサイドを別のアプローチとします。どのみち完全に静的な HTML と API サーバだけで複雑な SPA を成り立たせるのは無理があるので BFF の支援は前提に入ります。 また、SPA + SSR のダルさの根源は node の CPU ぶん回し対策や、キャッシュサーバーの管理などを伴うキャッシュストラテジーの煩雑性と定義します。単純に SPA + SSR を実現するだけなら道具も成熟してきているので、さほど難しくはなくなってきているという扱いにしておきます。 3-1.
App Shell モデルの素振り（前編）webpack と Workbox を利用した構築
App Shell モデルという設計パターン App Shell モデルは、共通のガワ部分を構成する HTML、CSS、JavaScript をシェルと定義し、その中に入る動的なコンテンツ部分と構造的に分離して扱えるように設計されます。 アプリケーション シェル（App Shell）アーキテクチャは、ネイティブ アプリのように瞬時に、そして確実にユーザーの画面に読み込める Progressive Web App を構築する方法の 1 つです。 アプリの「シェル」とは、ユーザー インターフェースが機能するために必要な最小限の HTML、CSS、JavaScript です。これらをオフラインで使用できるようにキャッシュしておくことで、ユーザーが同じページに再アクセスした際に、瞬時に高いパフォーマンス が発揮されます。つまり App Shell は、ユーザーがアクセスするたびにネットワークからす
React v0.14.x から v15.2.x へのアップデート録
react v15.2.x アップデートに関連した記録 FRESH! by AbemaTV と AbemaTV の React を v0.14.x から v15.2.x にアップデートしたので、遭遇した WARN などについてメモ。 基本的には React v15.0 | React を読めばマイグレーションガイドがありますが、今回の作業で実際に遭遇したものだけ対応を記録します。 不明な prop を渡すなエラー … Unknown props foo, bar... on <***> tag. Remove these props from the element. <div {...props} /> のように、下位コンポーネントに対する props の雑な継承で WARN が発生します。DOMAttribute として正しくない prop が要素に渡ると警告の対象です。詳細は Unk
リモートワークの勘所と限界について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 で作られているものがあります。 各ブラウザの状況 まだま
yahoo/fluxible による SPA + Server Rendering の概観
Single Page Application + Server Rendering yahoo/fluxible を使って、Single Page Application と Server Rendering の良いとこ取りのアーキテクチャを目指す。ある程度の複雑性と引き換えに、双方の利点で双方の欠点を打ち消し合うことができるため、全体的には良好なユーザーインタラクションを期待できる構成。 なぜ Single Page Application なのか 画面遷移時するたびにJavaScript/CSS のパースと評価をしなくて良くなる 画面遷移時のトランジションを柔軟に適用できる 画面遷移をまたがった実装が可能になる（あくまで可能になるだけ） なぜ Server Rendering するのか 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰
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 だけ使うということで内部モジュール禁止です。不便ないですね。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
