タグ

ブックマーク / havelog.aho.mu (14)

  • SSR と CDN ( Fastly ) とユーザー依存情報、その後

    正式リリースに向けての開発で表面化した不都合 以前、アーキテクチャ編: SSR と CDN ( Fastly ) とユーザー依存情報の分離(新規開発のメモ書きシリーズ4)で紹介したように、SSR で生成した HTML を CDN ( Fastly ) でキャッシュできるように「ユーザー依存情報はクライアントサイドで非同期に取り扱うというアプローチ」をとっていました。それによって発生していた不都合と解決に関する追加情報です。 ユーザー依存情報が非同期でレイアウトされる問題 ユーザー依存情報が非同期で解決されるということは、そのような情報を扱うコンポーネントの矩形は Web ページが一度レンダリングされたあとにレイアウトされます。つまりこの記事でも紹介されたところの「ガタンッ」的なユーザー体験が生じます。 ログインと非ログインが、全く同じサイズの矩形を確保するようなビジュアルデザインになってい

    SSR と CDN ( Fastly ) とユーザー依存情報、その後
  • アーキテクチャ編: SSR と CDN ( Fastly ) とユーザー依存情報の分離(新規開発のメモ書きシリーズ4)

    新規開発のメモ書きのラスト シリーズだったはずなのに、色々あって前回のエントリから1ヶ月あきました。_:(´ཀ`」 ∠): 今回の話の中心は結果的に「Server Side Rendering との折り合いの付け方」と「Fastly を利用した動的コンテンツのキャッシュ戦略」です。 このシリーズの他の記事はこちら。 技術要素編: web アプリが新陳代謝を続けるための依存関係の厳選 ビルド設定編: UA に応じた最適な JS バンドルの配信と webpack との距離感 コード設計編: context による縦軸分類とレイヤードアーキテクチャ まずは全体的なアーキテクチャ像 次の図はアーキテクチャの全体像です。クライアントサイド寄りの範囲を中心に書いているため、バックエンドな Microservice 群以降がおざなりな図ではありますがご容赦ください。 主要リソースは Fastly を通じ

    アーキテクチャ編: SSR と CDN ( Fastly ) とユーザー依存情報の分離(新規開発のメモ書きシリーズ4)
  • コード設計編: context による縦軸分類とレイヤードアーキテクチャ(新規開発のメモ書きシリーズ3)

    流行りの monorepo 風味と DDD 風味? 今回はコードの設計について書き残します。主に JavaScript 界の話です。Web アプリケーション全体の設計は次回で、今回はコード面の設計に限定して書き留めています。プロダクト全体のアーキテクチャは次の記事で述べる予定ですが大雑把には、メディアっぽいサービスでありつつも SPA + SSR が許容される程度には要件定義の時点でコードの行数がかさむことが約束されたプロダクトです。 今回は大きく分けて下記について述べています ディレクトリ構造 オブジェクトの種類と責務 Flux 的なデータフロー あくまで風味なので今回、専門用語の意味ズレなどは優しくお願いします... このシリーズの他の記事はこちら。 技術要素編: web アプリが新陳代謝を続けるための依存関係の厳選 ビルド設定編: UA に応じた最適な JS バンドルの配信と web

    コード設計編: context による縦軸分類とレイヤードアーキテクチャ(新規開発のメモ書きシリーズ3)
  • SPA + サーバーサイドレンダリング、そのダルさに関する私見

    いわゆる SPA + サーバーサイドレンダリングがダルい 唐突ですがおさらいです。 なぜサーバーサイドレンダリング(SSR)が嬉しいかと言えば 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰にやさしい() 古いブラウザ・低性能マシンにやさしい yahoo/fluxible による SPA + Server Rendering の概観 ::ハブろぐ であり、特に SPA + SSR の文脈においては Universal Architecture による SPA + SSR は、技術的には過渡期の歪なキメラっぽさが拭いきれませんが、昨今の Web フロントエンドにしては珍しくビジネス的な説得力があります。 SSR なのでSNSや検索からの流入による初期表示が速い SPA なので回遊時のページ遷移も速い SSR なので古いブラウザでも CSS

    SPA + サーバーサイドレンダリング、そのダルさに関する私見
  • Reactive Programming in JavaScript - Frontrend Final Conference 資料

    Reactive Programming in JavaScript ( 今回のスライド: HTML版 ) このスライド自体が Bacon.js で書かれた ahomu/Talkie で作られています。Rx系のライブラリに興味を持たれた方は、ぜひコードのほうもご覧いただければ。 アジェンダ What is Reactive Programming ? Reactive in Frontend JavaScript FRP with Reactive Extensions Reactive Programming について紹介しました。今回も懲りずに新ネタでしゃべった次第。Reactive も Functional も若干こわいひとたちが生息しているイメージ(個人の感想です)があるので、遅延評価で飛んでくる斧だけがこわい :P ノイズ避け 率直な感想として、RP/FRP を学ぼうとすると情報

    Reactive Programming in JavaScript - Frontrend Final Conference 資料
  • Polymer v0.8.0 Preview 所感

    Improvement Polymer の Twitter アカウントが気になる発言をしていたので、Polymer のアップデート内容を確認した。 Next major version of Polymer: 5 x faster in Chrome, 8 x faster in Safari. Up to 87% smaller (15KB, 6KB gzipped) pic.twitter.com/SBJhuxIxXd — Polymer (@polymer) November 19, 2014 Chrome と Safari における実行速度の高速化はもちろんわかるが、ファイルサイズが 87% 減というのはかなり大きい。v0.5.1 の polymer.min.js が 123KB なのに対して、新しい v0.8.0 では 15KB になっているということだ。 それなりに大きい取捨選

    Polymer v0.8.0 Preview 所感
  • Polymer と Web Components の違い9選(もとい Polymer の便利機能)

    違い、または付加機能 色々な周辺事情で、勢力を広げつつある Polymer さん。(つい最近、それに加担したような気もする) 「どこまでが Web Components で、どこからが Polymer なのか」を理解するためにもPolymerの機能をメモる。Polymer は色々なことを便利にしてくれるライブラリであり、差分を言い出すとキリがないので主要なポイントだけ。 <template> が自動で Shadow DOM に放り込まれる Shadow DOM内の <link> をインラインの <style> に展開 repeat のサポート {{interpolate}} のサポート <element> のかわりを <polymer-element> としてサポート on-click とかイベントハンドラの宣言 this.$ による idが付加された要素のコレクション observe に

    Polymer と Web Components の違い9選(もとい Polymer の便利機能)
  • Docker を Mac で使ってみた(Nodeアプリ例)

    色々あってDockerした。さっくりとアプリ作るならHerokuも便利なのだけど、Dockerをサポートする他のPaaSも使えた方が便利そうな風潮を感じたので。 1. インストール&導入 Mac OS X - Docker Documentation Releases · boot2docker/osx-installer からpkgインストーラをダウンロードして実行。適当にはいる。 boot2docker Mac OS X上で、Dockerを走らせるためのLinuxなVMを boot2docker で立ち上げられる。(boot2docker/boot2docker はpkgインストーラに含まれている) boot2docker init boot2docker up boot2docker init で初期化 boot2docker up で起動。dockerコマンドにホストを教えるための

    Docker を Mac で使ってみた(Nodeアプリ例)
  • Webパフォーマンスにおけるイニシャライズとランタイム

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

    Webパフォーマンスにおけるイニシャライズとランタイム
  • 技術は発想やデザインの限界にならない

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

    技術は発想やデザインの限界にならない
    komlow
    komlow 2014/01/07
  • jasmine-jqueryというかloadFixturesが便利

    beforeEach内でDOMをちまちまやるのが面倒 なんですよ.例えばですが乱暴にゴチャゴチャと書くと... describe('Some test case....', function() { var testDiv, testList, attrTest, insertTest; beforeEach(function() { testDiv = document.createElement('div'); testDiv.innerHTML = '<a id="attrTest" data-test="hogehoge" target="_blank" href="#">test</a>'; document.body.appendChild(testDiv); testList = document.createElement('div'); testList.innerHTM

    jasmine-jqueryというかloadFixturesが便利
  • 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を使うときに参考になるリソース 2012年末版 (Backbone Advent Calendar 2012 25th day)
  • 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 氏に感謝を。

    Backbone.js コメント付きソースコード日本語訳
  • ぼくが実際に運用していたGitブランチモデルについて

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

    ぼくが実際に運用していたGitブランチモデルについて
    komlow
    komlow 2012/09/02
  • 1