SSR と CDN ( Fastly ) とユーザー依存情報、その後
正式リリースに向けての開発で表面化した不都合 以前、アーキテクチャ編: SSR と CDN ( Fastly ) とユーザー依存情報の分離（新規開発のメモ書きシリーズ4）で紹介したように、SSR で生成した HTML を CDN ( Fastly ) でキャッシュできるように「ユーザー依存情報はクライアントサイドで非同期に取り扱うというアプローチ」をとっていました。それによって発生していた不都合と解決に関する追加情報です。 ユーザー依存情報が非同期でレイアウトされる問題 ユーザー依存情報が非同期で解決されるということは、そのような情報を扱うコンポーネントの矩形は Web ページが一度レンダリングされたあとにレイアウトされます。つまりこの記事でも紹介されたところの「ガタンッ」的なユーザー体験が生じます。 ログインと非ログインが、全く同じサイズの矩形を確保するようなビジュアルデザインになってい
SPA + サーバーサイドレンダリング、そのダルさに関する私見
いわゆる SPA + サーバーサイドレンダリングがダルい 唐突ですがおさらいです。 なぜサーバーサイドレンダリング（SSR）が嬉しいかと言えば 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰にやさしい（） 古いブラウザ・低性能マシンにやさしい yahoo/fluxible による SPA + Server Rendering の概観 ::ハブろぐ であり、特に SPA + SSR の文脈においては Universal Architecture による SPA + SSR は、技術的には過渡期の歪なキメラっぽさが拭いきれませんが、昨今の Web フロントエンドにしては珍しくビジネス的な説得力があります。 SSR なのでSNSや検索からの流入による初期表示が速い SPA なので回遊時のページ遷移も速い SSR なので古いブラウザでも CSS
Web サイトっぽい SPA に必要なブラウザナビゲーションのエミュレートなど
Web サイトっぽい SPA に立ち向かう 大分前の話ですが、Node学園 20時限目 今回もdots!!!!! - connpass で Client Side of なんちゃらfresh.tv としてお話した内容のうち、Web サイトっぽい SPA に関してだけこだわりを再抽出して書き留めます。 本件は、ページ全体のスクロールや頻繁なナビゲーションを伴わず、1画面におさまるレスポンシブな Web アプリを作っている場合はあんまり関係がありません。画面内の局所的な状態更新は、コンポーネントの責務分割やら何やらの設計なので実は別の話です。 総じて、Web サイトっぽいくせに大人の事情で Web ブラウザのネイティブなナビゲーションを積極的に破壊しにいくときの心構えです。 URL が変わっても最低限レンダリングできるまで画面更新を遅延させる 画面遷移に必要なのは、 URL が更新されても次の
リモートワークの勘所と限界について1年くらいの感想、組織にとっての選択肢作りの話
1年くらいリモートワークを続けてみた感想 まず当然ながら「リモートワークは生産性が高い！これこそ未来のワークスタイル！」のような感想はありません。 生産性やコミュニケーションに関連するメリット、デメリットをうまく相殺しきれれば、生活の自由度だけ向上してハッピー、と考えています。 今は自宅かレンタルオフィスのいずれかを作業場として開発などを行いつつ、本社がある渋谷には1泊2日の出張を月2回するようなペースで仕事をしています。基本は Slack でテキストチャットによるコミュニケーションをメインとしつつ、必要があれば MTG に Hangout でビデオチャットで参加します。 生産性は大して上がらない 期待していた生産性は、それほど向上することはありませんでした。 東京にさえいなければ気軽に MTG に呼び出されることもありませんし、開発に充てることが可能な時間は若干増えています。通勤時間が長
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 における保守信仰
Web Components を支えるPolyfillライブラリ
Hello 生成されるJSそのものはピュアな感じなので、たしかにbosonicを捨ててもWeb Componentsとして成り立ちそうではある。 瑣末だが、この記事を書いてる時点で試したらWeb Platform featuresのフラグをEnableにしたCanaryで、bosonic-pollyfillsがエラー吐いてる... 余談、実はえらいかも Polymerコンポーネントって、結局Polymer入れないと使えないなら、BackboneJSで使えないAngularディレクティブみたいなもんな気がしてきた。Bosonicのコンセプト、実は偉いかも。（出来る範囲は制限されるかもしれないけど） — あほむバーガー (@ahomu) June 30, 2014 結論 個人的にはふつうのPolyfillとして動いてくれるものを精査したかったのだけど、結果的に Polymer/platform
VagrantとChef-soloについて初歩の備忘
開発環境を管理する 遅まきながら触ってみたら、予想以上に簡単だったのでちゃっちゃと備忘する次第。 Vagrant Chef | Opscode ということで、開発環境をどうにかしたかったので、VagrantとChefによる管理を試してみました。ついでに、Amazon S3のようなインスタンスを対象にもセットアップできるようにすることも想定してます。 本記事は、ほんとに備忘録ノリなので、「Chefとは」「Chef soloとは」「Vagrantとは」などについては各自ググってください。 前提 現状は、開発環境のVMが秘伝のタレと化している 新しくVMをセットアップする際の作業にも秘伝のスクリプトが点在する phpやnginxのconfigが、複数のリポジトリに偏在していて集めるの大変 それぞれが個別に設定しなくても、開発環境を一斉に更新できるようにしたい 新しい人がジョインしたときも同じ水準
URLスキームからのスマフォアプリ起動のフォールバック
前段 ブログリハビリ..._:(´ཀ`」 ∠): URLスキームで任意のアプリ（今回はLINE）を起動したい フォールバックとして、アプリのURLに誘導するなりアラートするなりしたい Android Galaxy S3 (4.0.3) と Xperia SX (4.1.2) のAndroidブラウザで確認する限りは、下記のようなコードで実現できた。 var iframe = document.createElement('iframe'); iframe.className = 'is-hidden'; iframe.onload= function() { alert('LINEアプリ、インストールしてなくない？'); iframe.parentNode.removeChild(iframe); }; iframe.src = 'line://msg/text/loremipsum...
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
