web over layered apis (LAPIs) at #tng30
WebアプリにしろWebサイトにしろパフォーマンスはとても重要です。どんなに高機能であっても、どんなにデザインが良くても、パフォーマンスが悪ければユーザーは離れてしまいます。 とは言え現場はキツキツのスケジュールで、パフォーマンスにまでこだわる余裕がないよ!パフォーマンスはひとまずできる限りのところまで頑張るよ!となってしまうこともあるかと…。 この問題の解決の糸口はパフォーマンスを良くする手段をどれだけ知っているかです。仕様を決めるとき、デザインを決めるとき、実装するとき、それぞれのフェーズでパフォーマンスを常に意識していると自ずとハイパフォーマンスに近づきます。 というわけで今回はフロントエンドの観点から、イマドキのパフォーマンス改善手法をまとめてみました。イマドキと謳っておきながら2年前くらいの技術が出てきたりして最新の話題でもないのですが。 ちなみに、本題に入る前にWebパフォーマ
gulp なしの Web フロントエンド開発から 1 年あまり。その間、特に問題もなく npm-scripts で Web フロントエンド開発を管理できているので、この間に得られた運用知見や所感などをまとめてみる。 npm-scrips とは? 最近の Web フロントエンド開発では AltJS/AltCSSのビルドやリリース用イメージ作成などに Node.js + npm を利用することが一般化してきた。そのためプロジェクトは package.json で管理することになる。package.json の提供する代表的な機能として プロジェクト情報の定義 プロジェクトの成果物を npm として配布するための情報 プロジェクト名、バージョン、作者などのメタデータを定義する 依存モジュール管理 プロジェクトが依存する npm とバージョンを管理する この情報へ基づき npm install コ
結城です。 最近、AngularJSを使ったWebアプリ開発のプロジェクトに参加する事になり、とりあえず一通りの事は把握しておかなければと思って公式のチュートリアル(英語)を実践してみたのですが、JavaScriptの経験が浅い人だとハマらなさそうだけれども、中途半端に経験があったせいでドハマり、という場面に遭遇してしまいました。 恥ずかしい話ですが、せっかくなので同じように躓いている人(もしいれば)のために、分かった事や理解のポイントを書き記しておこうと思います。 この記事の対象読者は、以下のような状況にある人です。 フレームワークを使わないJavaScript(例えば、jQueryを使ったJavaScript程度)は書いた事がある。 自動テスト(特に、ユニットテスト)は書いた事がある。 AngularJSを始めたばかりである。 依存性注入という概念は理解できるが、実際にどう使うかはあま
JavaScriptを中心としたWebアプリ開発の栄枯盛衰まとめ――LiveScriptからAngularJS/React.jsまで:15周年記念特別企画 @ITが誕生した2000年頃はJavaScriptが不遇だった時代。そこから現在のような人気のプログラミング言語になるまでには、どのような歴史があったのか。15周年を迎えた@ITの豊富なWeb開発関連記事とともに振り返る。 2015年6月17日に、JavaScriptの最新標準仕様となる、ECMAScript 6(ES6、ECMAScript 2015)が正式に承認されました(参考)。1997年にECMAScriptのバージョン1がリリースされてから6度目のアップデートとなり、これまでの中で一番大きな変更が加えられたことになります。 本稿では、ECMAScript 6が正式に承認されたということもあり、2000年頃の第一次ブラウザー戦争
4 ヶ月あまり続いた新規開発案件がようやく落ち着きを見せたので、ここらで振り返りをしてみたいとします1)リリースまでに巻き取れなかった不具合や未実装箇所が幾つか残っているので、まだ気持ち的には終われていないのですが…。 サービスのおおまかなアウトライン コンシューマ ( 一般ユーザー ) 向けサービス ブラウザで動く Web アプリケーション ワンソースによるレスポンシブレイアウト サポートするブラウザは IE9 以降や Android4.x 以降のモダンブラウザのみ Ruby on Rails 多言語対応あり SEO 対策はそれなりに必要 わりとフワッとしか要件が決まっていないままスタートしたので、TRY & ERROR を繰り返しながらの開発 すごく大雑把ですが、だいたいこんな感じの Web アプリケーションです。これを踏まえてフロントエンドをどのように開発していくかを設計していきまし
やんなくちゃなー、と思っていたので 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-
世界のJavaScriptを読もう @ 2014 ^目的: ウェブの世界は絶対変化するもの 変化する前提の行動が求める それをどうやって見ていくか、それを知ってどうするか ^ JavaScriptやブラウザ周りのリリースの状況はウェブの変化にあわせるように変化してきている。 どのように変化してきたか知り、どうやって変化を見ていくのか、そしてわたしたちはどう変化していくのかを考えよう。 アジェンダ 世界のJavaScriptを読もう @ 2012 の続編的なものです ブラウザやJavaScriptのリリースは変化してきている 私たちはどのように変化を知り見ていくのか そして私たちはどのように変化していくのか [fit] 世界のJavaScriptを見る話 [fit] JSer.info 開始 2011年〜 ^ JSer.infoを始めた2011年を一つの基準として考えて、 そこからブラウザや
1. ServiceWorker が拓く Mobile Web の新しいかたち HTML5とか勉強会 02/25/2015 Kinuko Yasuda (@kinu) kinuko@chromium.org HTML5とか勉強会 02/25/2015 Kinuko Yasuda (@kinu) kinuko@chromium.org ServiceWorker が拓く Mobile Web の新しいかたち 2. 自己紹介: Kinuko Yasuda @kinu / kinuko@chromium.org Chrome エンジニア 5年目くらい ■ ストレージ、ネットワーク、Worker系など裏方っぽい API をよくいじっています ■ File/Blob, FileSystem, Quota, XHR, Web Workers, ServiceWorker などなど ■ 2013年秋頃か
最近あまり使ってない、ちょっと前の流行りもの なんとなく書いてみます。Web アプリケーション開発屋さんなので、Web サイト制作屋さんとはかなり文脈ズレると思います。 jQuery ファミリー 個人的には jQuery って、協業用のツールという位置づけでした。jQuery でさえ書かれていれば、jQuery 書ける人材のほうが外からも調達しやすいため、人員の流動にも有効と考えられる頃が確かにありました。 DOM に触れてくれるな勢の台頭 ところが昨今では AngularJS や React、その他ライブラリでも DOM 操作が大いに抽象化されていることが多く、jQuery で直接 DOM を操作すること自体が相性良くないケースが散見されます。今思えば Backbone.js くらいのころが jQuery 需要の最終ピークだったように思います。 jQuery プラグイン の需要減 jQu
Intro 最近 Extensible Web の話がたまに出るようになりましたが、なんというかレイヤの高い概念(ポエム)的な話が多い気がしてます。 もう少し具体的な API とか、「それコード書く上で何が変わるの?」って話があまりないので、今日はそこにフォーカスして、 Extensible Web 的な流れの中で整理された API の話をします。 しかし、実際には API が 「Extensible Web という理念で生まれたかどうか」は自明ではないので、 今標準化されている低レベルな API を拾い、それを整理するというエントリだと思ってもらと良いかもしれません。 あまり知られてない API もあると思うので、これを期に「これがあれば、今までできなかったアレが、標準化や実装を待たなくても、できるようになるな」と思ったら是非書いてみると良いと思います。 実際はそれこそが Extensi
業務で携わっている案件なのですが、アクセス数の急増が見込まれるイベントがありまして。準備期間も少なく、バックエンド側でできることがほぼないという状況でサイトを落とさないようにがんばる!というお仕事でした。レガシーソースてんこ盛り。CSSプリプロセッサとか何それ状態。 そこで実施した対策のまとめです。サーバー・アプリケーション・サイトの構成によって、効果の大小はありますが、比較的効果があったと思われるものをつらつらと。 リクエストの削減とファイルサイズの最適化 まず一番最初に考えなければいけないのがリクエスト数です。すごいおおざっぱに言うと、WEBサーバー(ApacheとかNginxとか)への負荷は、PV数×リクエスト数です。PVがそんなに無くてもそのページのリクエストがめちゃくちゃ多いとそれだけでかなりの負荷になります。リクエストを半分にできれば2倍の人数がさばけるってことに、すげーおおざ
11:10~ 課題ページの確認&PageSpeed Insightsの実行目的:チューニング対象のウェブサイトの改善の余地を調査 上記のgruntプラグインをインストールする npm install コマンドを実行しながら、ブラウザやIDEでチューニング対象のウェブサイトを確認し始めました。 少し見ただけでもCSSの構文エラーがあったり、使っていないJavaScriptライブラリがインポートされていたり…。 まるで無茶な運用を数ヶ月続けたかのような、カオスなファイル群でした。 ここで実行した PageSpeed Insights に画像サイズの最適化をオススメされたので、まずはそこから行うことにしました。 11:20~ 画像ファイルの最適化目的:画像ファイルサイズの削減 30 x 30pxで表示している画像ファイルが実際には150 x 150pxで保存されていたりする画像がそこそこあったの
2014年9月6日に、@h_doxas さん主催の「夏のJavaScriptシューティングゲーム祭り2014」というゲームプログラミングの勉強会を Stocker.jp / Space にて開催していただきました。 「JavaScriptシューティングゲーム祭り」では、その名の通り JavaScript を使ったシューティングゲーム開発についていろいろな方が登壇されるイベントです。 WebGL を使った表現や高速化、ESMAScript 6 などの話題もあり、非常に興味深い内容でした。 iPhone で講演内容を録画していたので、そちらの内容を公開します。 三脚の設置に失敗しており、斜めになっているものや音量が不安定な箇所があり、申し訳ありません。 全体的に音声は小さめですので、音量を大きくしてお聴きください。 弾幕記述用ライブラリbulletml.jsについて だいしさん @daish
ぼくの連絡ミスによってUstreamが準備出来てなかったり、直前の台風によって寿司が提供できなかったりと色々と不備がありました。申し訳ありませんでした。 んで、その代わりに完璧なレポートを書こうと思ってたんですが、既にazuさんが完璧なレポートを書いてくれてるので、そちらを見ると雰囲気が分かるかと。僕はそこに対して感想を加える形で書いていきます。 ハイライト 個人的に一番面白かったLTはAngularJS x デザインの話、一番興味惹かれたフレームワークはOm、学びが多かったのはchaplin (marionetteと近くて違いが分かってよかった) IsomorphicなWAFはNode.jsの生きる道であり、夢。 WebComponentsはCSSにとっての銀の弾丸、JavaScriptの問題を解決するものではない。 AMD (require.js) はオワコン、CommonJSかES6
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く