node --inspect=0.0.0.0:9229 app Docker コンテナ内で利用するには 0.0.0.0 が味噌
node --inspect=0.0.0.0:9229 app Docker コンテナ内で利用するには 0.0.0.0 が味噌
フロントエンドのパフォーマンス計測は得意なのだが、サーバーサイド node.js のメトリクスの取り方はあまり知らなくて、いつも勘でやりがちだった。最近は業務でこの周辺で困ることが増えたので、勉強しなおした。 また、最近使ってみたかった cloudflare workers の制限で、メモリ 128MB、CPU 時間 50ms という制約があり、このためにも Node.js の CPU のメトリクスを計測できるようになっておく必要があった。 という目的を踏まえて、今回は OS やデータベースの最適化は扱わず、ネットワークとアプリケーション層だけに絞って学習した。あと仕事の Docker イメージのサイズにも悩んでたので、ここも。 (あと ISUCON 参加者が楽しそうだったのもある。 ISUCON のチューニング対象にフロントエンドは含まれないので…) 計測対象 今回実験したリポジトリはこ
Warning: This blog post is outdated. It may contain incorrect information. Update 2019-11-22: ESM support in Node.js is not experimental, anymore. This post was updated to reflect that. Conditional exports are now explained. In this blog post, we look at npm packages that contain both ES modules and CommonJS modules. Required knowledge: How ES modules are supported natively on Node.js. You can rea
Node.js のコアに util.promisify が追加された。 github.com 今回は util.promisify が持つ役割を中心に Node.js における Promise の立場についても話していけるといいと思う。 util.promisify とは 読んで字のごとく関数を Promise に変換してくれるユーティリティメソッド。 下記のような要領で変換できる。 const util = require('util'); const fs = require('fs'); const stat = util.promisify(fs.stat); stat('.').then((stats) => { console.log(stats); }).catch((error) => { console.error(error); }); async-awaitを使いたい
経緯 ドワンゴ様から恵贈頂いた。 高校生からはじめる プログラミング 作者: 吉村総一郎出版社/メーカー: KADOKAWA発売日: 2017/04/14メディア: 単行本この商品を含むブログを見る …読んでみたけど、HTML/CSS/JS の初歩的な部分を、初学者にやらせるとこうなる、という素朴な世界観で、CSSフレームワークもJSライブラリも出てこない。いや、出せと言ってるわけじゃない。理解せずにフレームワークを使う習慣がつくと、スクリプトキディ的な振る舞いによっていくし、教える側としても、変数が大きくなってコントロールできないのが問題だろう。 じゃあ基礎を抑えたとして、この先どう教えるといいんだろうな、というのは、たしかに自分も前から考えてはいて、それを書いてみる。 この文章のターゲット JavaScriptを教える人、またはポインタがあれば自学できる中級者以上 追記: すべての初学
だいたいこの記事のまんまですが大雑把な訳記事だと思ってください。 こんなファイル(app.js)があったとする。 //app.js exports.testableMethod = function () { complicatedMethod(untestableMethod); }; var untestableMethod = function (a, b) { return (a + b); }; testableMethodはexportsされてるのでテストできますね(まぁ参照エラーでるけど) こういう時untestableMethodのテストって結構至難の業でexportsされてるメソッド経由でテストしてたり、テスト用に var local ; exports.test = local = {}; local.privateMethodA = fucntion () {}; と
さて、 Node.js のエラーハンドリングは難しいと言われてますが、 2016年現在、つまりNodeの v4 とか v6 が主流になり、 Promise が基本的な処理として採用されている状況ではどうでしょうか。ちょっと考えてみます。 一応これの補足です。 qiita.com TL;DR 未だに難しい。ただし、 Promise で改善されている。async-await や zone まで来たらかなり楽になる。 あと、 unhandledRejection が uncaughtException よりも酷いことにならないので、大分マシになっている。 Node.js のエラーハンドリングの難しさ まず JavaScript には同期と非同期のエラーハンドリングのやり方があります。前者は所謂 try-catch による方法、後者は callback を使って第一引数で実現する方法や emit(
概要 AWS ECS でマルチプレイゲーム用インスタンスの管理すると限りなく最強。 はじめに リアルタイム・マルチプレイゲームを作る時、まず考えられることは、あるプレイヤーの行動や状態が他のプレイヤーに伝わることではないかと思われます。しかし、スマートフォンアプリは不安定であったり、複数端末同士で(基地局やバックボーンを介さずに)物理的に直接接続することは出来ませんし、理論的にできたとしても、だいたい開発が進んでいくうちに排他制御の問題などで炎上、もしくはとん挫してしまいます。軽い気持ちでマルチスレッド処理をおこない事故る現象と全くおなじです。 もっとも簡単な解決方法としてはマルチスレッド処理のときようにクリティカルセクションを設けることです。ようはサーバを用意してそこで処理すれば、比較的容易に一意な結果が得られますし、接続に関する問題も起こりにくくなります。 長くなるので → http:
7 principles for rich web apps And how next.js achieves these principles
Share: Node.js debugging best practices Debugging Performance Issues Performance problems are best resolved with a methodical approach. Except in cases of clear regressions and other simple situations, resolving poor performance starts as a system-wide debugging affair. It’s important to be able to narrow scope quickly and definitively. So while strictly not a specific Node.js practice, the Utiliz
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く