Elastic Beanstalk with Docker と OpsWorks で Node + MongoDB する
Node + MongoDB のアプリを立ち上げたい ある文脈で「HerokuはアカンけどAWSならええで」って言われたので、AWS使ってみた。 AWSでは、EC2やS3などを使ってアプリケーションの実行環境を編成するわけだが、その管理ツールとして以下のサービスが用意されている。EC2やS3がリソースなのに対して、これらはあくまでツールまたはサービスといえる。 Elastic Beanstalk OpsWorks Cloud Formation できあがった構成 いじくってみた結果、最終的には App と Batch を Elastic Beanstalk with Docker でデプロイし、MongoDB を OpsWorks で編成できた感じなので、なんとなくメモにして残す。 AZ1 - App - Batch - MongoDB Primary AZ2 - MognoDB Seco
ビルド設定編: UA に応じた最適な JS バンドルの配信と webpack との距離感（新規開発のメモ書きシリーズ2）
たくさんある道具をどのように組み合わせるか 今回はコード設計編のつもりでしたが、ビルド周りを先にまとめることにしました。主にパフォーマンス上の都合ですが、心がけたポイントは次の点です。 画一的なバンドルではなく、適切なバンドルを選択的に配信できるようにする 適当な粒度で Code Splitting できるようにする ひとつのツールに何でもかんでもやらせない（ webpack、お前のことだよ！） ビルドのパイプラインを短く、シンプルに済ませる（できることを全てやろうとしない） タスクランナーは前回述べた通り make を利用しています。同僚が使っているのを見てパクりましたが Self-Documented Makefile の手法が、タスク名忘れに優しくてよかったです。 npm run したら npm scripts が一覧で出てくるのと似たようなやつです。 このシリーズの他の記事はこちら
App Shell モデルの素振り（前編）webpack と Workbox を利用した構築
App Shell モデルという設計パターン App Shell モデルは、共通のガワ部分を構成する HTML、CSS、JavaScript をシェルと定義し、その中に入る動的なコンテンツ部分と構造的に分離して扱えるように設計されます。 アプリケーション シェル（App Shell）アーキテクチャは、ネイティブ アプリのように瞬時に、そして確実にユーザーの画面に読み込める Progressive Web App を構築する方法の 1 つです。 アプリの「シェル」とは、ユーザー インターフェースが機能するために必要な最小限の HTML、CSS、JavaScript です。これらをオフラインで使用できるようにキャッシュしておくことで、ユーザーが同じページに再アクセスした際に、瞬時に高いパフォーマンス が発揮されます。つまり App Shell は、ユーザーがアクセスするたびにネットワークからす
SPA + サーバーサイドレンダリング、そのダルさに関する私見
いわゆる SPA + サーバーサイドレンダリングがダルい 唐突ですがおさらいです。 なぜサーバーサイドレンダリング（SSR）が嬉しいかと言えば 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰にやさしい（） 古いブラウザ・低性能マシンにやさしい yahoo/fluxible による SPA + Server Rendering の概観 ::ハブろぐ であり、特に SPA + SSR の文脈においては Universal Architecture による SPA + SSR は、技術的には過渡期の歪なキメラっぽさが拭いきれませんが、昨今の Web フロントエンドにしては珍しくビジネス的な説得力があります。 SSR なのでSNSや検索からの流入による初期表示が速い SPA なので回遊時のページ遷移も速い SSR なので古いブラウザでも CSS
node.jsとsocket.ioを使って接続する実装サンプルと，ポートの設定周りをごく基本的に
インスパイアされて試してみた node.js+socket.ioを使ったライブコーディングwebアプリを作ってる - すぎゃーんメモに影響されて，ちょうどnode.jsを触っていたので，自分もnode.js+socket.ioを試してみました． コードや設定は別途調べて自分なりに書いてみたり．なかなか勉強になりまして，ちょっと分かってきました．試してみたらワクワクしてきますね！ リアルタイムな実装が，こんな簡単にできるなんてすごい， 今回は，それらのごくごく基本的な実装と設定周りをまとめました．サンプルコードは，socket.ioを動かすところまでを最小限に記述しています． node.jsを動作させ始めるまでの道のりはnode.js用の環境作り - ディレクトリ構成とnginxの設定から起動テストまでとか，node.jsとnpmのインストールをしたメモとかを． サーバーサイドの実装と設定
Web アクセシビリティ向け Node.js 製の自動チェックツールや DevTools 用の拡張機能など
アクセシビリティを担保するプロセス作り この記事は Web Accessibility Advent Calendar 2016 - Adventar の 12 日目の記事です。 UI 実装の再考と a11y - Frontrend Vol.8 LT でも述べましたが、Accessibility is a Process, Not a Project ということでアクセシビリティ対応するプロジェクトではなく、アクセシビリティを担保するプロセスを作りましょうということで、チェックツールをいくつか並べて俯瞰してみます。対象読者は自分と同じようなクライアントサイドの Web アプリケーション屋さんということにしておきます。 ちなみにアクセシビリティ評価ツールについては 3 日目のアクセシビリティ方針、報告書、試験支援ツールa11ycのご紹介 (Web Accessibility Advent C
リモートワークの勘所と限界について1年くらいの感想、組織にとっての選択肢作りの話
1年くらいリモートワークを続けてみた感想 まず当然ながら「リモートワークは生産性が高い！これこそ未来のワークスタイル！」のような感想はありません。 生産性やコミュニケーションに関連するメリット、デメリットをうまく相殺しきれれば、生活の自由度だけ向上してハッピー、と考えています。 今は自宅かレンタルオフィスのいずれかを作業場として開発などを行いつつ、本社がある渋谷には1泊2日の出張を月2回するようなペースで仕事をしています。基本は Slack でテキストチャットによるコミュニケーションをメインとしつつ、必要があれば MTG に Hangout でビデオチャットで参加します。 生産性は大して上がらない 期待していた生産性は、それほど向上することはありませんでした。 東京にさえいなければ気軽に MTG に呼び出されることもありませんし、開発に充てることが可能な時間は若干増えています。通勤時間が長
AngularJSでng-repeat時の生成内容を分岐させたい
つまり var items = [ {type : 'A'}, {type : 'B'}, {type : 'A'}, {type : 'A'}, {type : 'A'}, {type : 'B'}, {type : 'B'} ]; を ng-repeat 越しに <ul> <li ng-repeat="item in items">Aな感じの内容物</li> <li ng-repeat="item in items">Bな感じの内容物</li> <li ng-repeat="item in items">Aな感じの内容物</li> <li ng-repeat="item in items">Aな感じの内容物</li> <li ng-repeat="item in items">Aな感じの内容物</li> <li ng-repeat="item in items">Bな感じの内容物</l
AngularJS についての所感
AgularJS に対する気持ち 所感といいつつ、主に自分がつらさとして感じていることを書く。所感シリーズとしては jQueryについての所感 も併せて読みたい。 この学習曲線の中でいうと、たぶん今の自分は Very Cool! の頂点から降りている最中くらいだと思う。そして、マサカリをふりかぶった諸兄にひとつだけ言いたいのは、共感脳を養った方がモテるということだ。 チキンハート的弁解: 以下はAngularJSに関するつらさを述べることに専念するために、美点を挙げていないだけであってAngularJSを全方位的に貶めたり、何かと比べて明確にクソだというような意図はない。 画像は AngularJS: The Best Parts · Anand Mani Sankar からの引用。X軸にある www.bennadel.com は AngularJS 大好きさん。 辛1. $scope が
HTML6 でも CSS4 でもない Web 技術のゆくえ - WCAN 2015 Winter に登壇してきました
@kazumich さんにお声がけいただき、WCAN 2015 Winter でおよそ 60 分ほどのセッションを登壇してきました。32:9 のスクリーンがあるという、TED でもやるんかオイという特殊な環境でした。普段はプロジェクター的な投影なので、スクリーンの前に立つのが微妙なんですが、ここはディスプレイが壁面に大量に並んでいて自ら発光するので、部屋を暗くしなくてもテレビのように十分に見えますし前に立っても平気です。 一緒に登壇したのが @yhassy さんと @Hidehisa さんということもあり、近年まれに見る胃痛を伴う緊張を味わいながらお話させていだきました。（リアルにセッション終了後、1時間くらい胃痛がズキズキしてました） 技術的なお話でした 参加されたみなさま、メインセッションや LT に登壇された各位、ならびに運営されたスタッフの方々、ひとまずお疲れさまでございました。貴
node.js用の環境作り - ディレクトリ構成とnginxの設定から起動テストまで
開発環境を設定してみる 前回の，node.jsとnpmのインストールをしたメモ（CentOS さくらのVPS）でnode.jsとnpmをインストールしましたが，まだ環境設定ができてなかったので今回も引き続き下準備． (仮に) /hogehoge/public/dev/ で開発することに．環境のディレクトリ構成とか，サーバー設定についてあまり参考になる記事を見つけられなかったので，以下適当に設定をしてみた．サーバーは，nginxを使います． ディレクトリ構成の予定 /hogehoge/public/dev/server.js : 8124をlistenするHTTPサーバー的なJSファイル．． /hogehoge/public/dev/app/ : その他lib的に，nodeで実行するJSを設置する． /hogehoge/public/dev/www/ : 公開ディレクトリとして，CSSやクラ
npm とフロントエンドのパッケージ管理の未来
JavaScript 系パッケージマネージャの重複問題 npm は言わずもがな Node.js のパッケージマネージャだが、フロントエンド開発においては Bower も利用するのが一般的になっている。この現状の問題点は、package.jon と bower.json という似たような管理ファイルを二重で管理しなければならないということだ。 現状の使い分けをおさらいをしておくと、次のような感じになる。 タスクランナー（Grunt/gulp）・モジュールシステム（browserify/webpack）・テストスイート（karma/testem）などの開発環境系の管理が npm の主なお仕事。インストールされたパッケージは node_modules 内に展開されて、CommonJS スタイルのモジュール管理から利用する。 本題につながる話としては、ブラウザで動くライブラリの一部は npm にも
テストを考慮した singleton の ES6 export
テスト時の singleton を避けたい export facebook/flux のサンプル準拠だと、Store や Dispatcher が singleton でテストを書きづらいことがあるので、普段使う singleton インスタンスと、テストで使う class オブジェクトを両方 export した。 import AppDispatcher, {Action, Payload} from '../dispatcher/AppDispatcher'; import * as Events from 'events'; const CHANGE_EVENT = 'change'; // 生クラスの export export class AcmeStore extends Events.EventEmitter { dispatchToken: string; construc
Yeoman ヨーマン
Yoeman Yeoman - Modern workflows for modern webapps yeoman/yeoman - GitHub Yeoman is a robust and opinionated client-side stack, comprised of tools and frameworks that can help developers quickly build beautiful web applications. We take care of providing everything needed to get started without any of the normal headaches associated with a manual setup. "Yeomanは、開発者が迅速にWebアプリケーションの立ち上げを行えるように、クライ
YeomanとBrunchをさわさわした
Yeoman - Modern workflows for modern webapps Brunch | HTML5 application assembler 今回はニュートラルな気持ちで、並べて触ってみるのが目的なので、どっちが良い・悪い、という評価的な主張は重きを置いてない。（感想としては混じってるけど）淡々と記録しているだけなので、流し読んでいただければ幸い。 CompareTable Install Skeletons/BoilerPlate Scaffolding (generate/destroy) Build Server & Watch Test PackageManager Conclusion Compare Table とりあえず比較表。オリジナルから行列加えてる。 Original: Compare Table - Brunch | HTML5 applicat
JSX と TypeScript の混合 Flux または悪魔合体
JSX + TypeScript の悪魔合体 ギョーム的に気持ちになったので JSX + TypeScript をはじめました。 導入にあたってチーム内への説明を兼ねたブログ。AltJSに対して ES でいいじゃん派ですが、自分の型需要に対して 現状の Flowtype が辛みしかないのでやむをえず。 動機 紆余曲折あって結局 React を使うことにした React Component には JSX with Babel を使いたい（手書きは無理だ） UI 以外のロジックを持ったモジュールは型の恩恵に預かりたい Flowtype つらい TypeScript かー UI 周りは JSX で、その他の堅いロジックは TypeScript で書けばいいのでは？ 共存だ！！ メリットがあるのかも不明瞭ですが、分からないからこそ試してみようという感じです。JSX と TypeScript の境界
プロジェクトの Dockernize と肥えた node_modules
node アプリ + HTML/CSS/JavaScript のリポジトリを Dockernize したときの話。最近 Docker の機運が高まっているのはたまたまです。 同じプロジェクトのバックエンドのリポジトリ（ただし別言語）が Dockerfile 内で依存解決をしていたので、おもむろに RUN cd /src && npm i && npm run build 的な処理を記述したら時間がかかりすぎて爆死しました。 予想はしてましたが node_modules 以下の依存ツリーが肥大化しているのが原因です。 $ du -k -d 1 node_modules | sort -nr 466792 node_modules 85224 node_modules/sc5-styleguide 60400 node_modules/gulp-svg-sprite 32844 node_mo
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 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 0.5 → 1.0 変更点ナナメ読みメモ
変更点のナナメ読み Polymer 1.0 が Google I/O 2015 のキーノート（？）で公開されたようなので、ドキュメントから変更点について気になるところだけ拾い読みしました。 ハイライト Introducing Polymer 1.0 - Polymer の Highlight より。 0.5 と比べて Web Components をネイティブサポートする Chrome で起動速度と実行時性能が劇的に高速化（したしい） 0.5 と比べて ペイロードサイズ（ファイルサイズ）を減らした 実装の全体的なリファクタリング（たぶんゼロベース） 新しく シンプル化＆高速化されたデータバインディングを実装 新しく shady DOM という Shadow DOM の Polyfill を実装 ネイティブの Shadow DOM なしで要素のスタイルを保護する境界を作った 前々からアピール
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
