Node.js における設計ミス By Ryan Dahl - from scratch
Ryan Dahl は Node.js の original author ですが、彼の作ったプロダクト deno に関するトークが jsconf.eu 2018 でありました。 Node.js にずっと関わってきた僕が見て非常に興奮するような話だったので、しばらくぶりにブログに書き起こすことにしました。 背景 Ryan Dahl は2009年に Node.js の話を初めて公の場に公開しました。その時の「公の場」というのが「jsconf.eu 2009」です。 www.youtube.com Video: Node.js by Ryan Dahl - JSConf.eu - 2009 この発表から Node.js が広まり、今やサーバのみならず、IoTデバイス、デスクトップアプリなど、様々なところで動作しています。 で、今回はその発表から9年の歳月が経過し、Node.jsに対しての設計不
Node.js Performance 改善ガイド - from scratch
Node.js Performance 改善ガイド Memory の場合 メモリリークかどうかを特定する メモリリークではない場合 CPU の場合 どこの処理に時間がかかっているのかを確認する v8 simple profiler flame graph を取得する File の場合 大きなサイズのファイルをどうしても扱う時 Network の場合 keepalive を on にする その他: 全体的にパフォーマンスを改善するためにやること JIT が効いているかを確認する clusterが使えないか検討する C++ addons vs JavaScript libraries まとめ 参考資料 Node.js Performance 改善ガイド この記事は Node.js 2 Advent Calender の 5日目の記事です。 qiita.com Node.js のパフォーマンスに
npm v5 がリリースされた - from scratch
npm v5 The npm Blog — v5.0.0 npm に v5 がやっとリリースされました。この npm v5 は既に明日リリース予定の Node v8 にバンドルされる予定です。 かいつまんで、機能を紹介します。 Notable Changes package-lock.json!!! faster than npm v4 no more --save option Offline mode sha512 support package-lock.json!!! npm v4 まで問題だった npm-shrinkwrap の問題 を解消するための新しい lock ファイルが生まれました。 shrinkwrap は依存ライブラリを固定するための機能です。npm v4 までは shrinkwrap で固定していましたが、新しく npm v5 になってからはshrinkwrap は
socket.io が提供してくれているものは何か - from scratch
現在開発中のシステムにリアルタイムな処理があり、そこで socket.io を使おうかなと思ってて、そういう折にタイムリーにもこの辺りの記事がタイムラインで出てきたのでメモ代わりに自分の意見を残しておく。 blog.jxck.io qiita.com socket.io が提供してくれているもの 「ブラウザとサーバ間のプロトコル」という観点で見ると socket.io は WebSocket を基本として繋がらなかった時に XHR Long Polling や polling といった形式の代替手段を提供してくれるもの、という位置づけ。 一方で「ライブラリ」という観点で見ると socket.io はリアルタイムアプリケーションを作る際に必要になる処理をまとめて実装し、クライアントとサーバ間での EventEmitter として抽象化してくれているもの、という風になる。 もう少し噛み砕いて言
Node.js における Promise を使った例外処理 - from scratch
さて、 Node.js のエラーハンドリングは難しいと言われてますが、 2016年現在、つまりNodeの v4 とか v6 が主流になり、 Promise が基本的な処理として採用されている状況ではどうでしょうか。ちょっと考えてみます。 一応これの補足です。 qiita.com TL;DR 未だに難しい。ただし、 Promise で改善されている。async-await や zone まで来たらかなり楽になる。 あと、 unhandledRejection が uncaughtException よりも酷いことにならないので、大分マシになっている。 Node.js のエラーハンドリングの難しさ まず JavaScript には同期と非同期のエラーハンドリングのやり方があります。前者は所謂 try-catch による方法、後者は callback を使って第一引数で実現する方法や emit(
ES Modules と Node.js について - from scratch
書こう書こうと思いながらこのタイミングまでのがしてしまいました。 今一番 Node.js の中で hot な discussion の一つと言えるでしょう、『ES Modules が Node.js の中でどうなるか』です。 ES Modules 現況 ES2015 が発刊されてそろそろ一年です。 ES2015 にある機能は Node.js v6でも 93% 程度カバーされています。モダンブラウザでも大体が90%を超えています。しかし、 ES Modules だけはまだどのブラウザも実装しきれていません(kangax compat table は ES Modules は省かれてます)。 そもそも ECMAScript 2015 自身で定義されたのは構文だけなので、構文はともかく、どうやってモジュールを取ってくるかという Loader の部分がまだ決まりきっていません。 https://w
from scratch
今年の漢字を一字上げるとしたら、筋トレの「筋」か受験の「験」かなと思います。 基本的に娘の受験勉強を見てあげるか、筋トレするかで過ごしてきました。 というのも今年が受験最終年で、筋トレは新しく趣味として始めてみたらハマってしまったというのが理由ですね。 一年前にやり始めた分割法で一年間続けた感じになります。筋トレはプログラミングとは違いますが、集中して何かに打ち込む事という意味では非常に良い趣味だなと思ってます。健康になりますし。 ただぶっちゃけ、受験勉強教えてから諸々やったあとに筋トレに行くと大体0時を過ぎており、筋トレのし過ぎで寝不足という健康なんだか不健康なんだか分けの分からない意味不明の状態になってるので、来年は睡眠をちゃんと確保しながらその辺りの事をできるように効率よくやっていきたいと思います。 それでは振り返ります。 yosuke-furukawa.hatenablog.com
DeNAを卒業します - from scratch
この週末にこの話を書こうと思っていたのですが、筆不精なもので土日を普通に過ごしてしまいました。 さて、表題の通りDeNAを卒業することになりました。 今回は技術的な話ではなく、単純にライフステージの変化の話なので気にならない人は読み飛ばしてください。 DeNAに入社したのは3年半前 yosuke-furukawa.hatenablog.com だいぶ昔の記事ですね。この時は同年代や年下の若いエンジニア達がメキメキと力をつけていく中で「なんとかしなければ」という焦燥感で常に何かしらをウォッチしつつ、新しい技術があれば飛びついて調べ、アウトプットする、というようなことをやってました。（今でもアンテナは張っているつもりです） そんな折に DeNA に誘われて入社できたのは非常にラッキーだったと思っています。新しい技術を積極的に採用しつつも、ある程度冷静かつ成熟した判断をしている部分があり、しかも
Node.js と io.js の統合は最終局面へ - from scratch
いくつかこの何日間でニュースが出ているので紹介します。 ちなみに、 io.js と Node.js のニュースに関してはこれまで２つ書いたので、まだ良く知らない人はそれをまずはご一読ください。 yosuke-furukawa.hatenablog.com yosuke-furukawa.hatenablog.com さて、次の展開へ、という事でいくつか話があります。 「Join the Node Foundation?」 というissueが mikeal から提案される github.com issue 本文を翻訳したものを貼っておきます。 Node Foundationのためのすべての文書が揃った。 TSC Charter (技術委員会の目的) Development Policy(開発ポリシー) Convergence Plan(移行プラン) Project Lifecyle (Wor
io.js と Node.js の和解への道 - from scratch
io.jsがリリースされてから早二ヶ月が経過しました。 io.js Evangelistの一人になりました。 @yosuke_furukawa です。 Node.js側との和解の状況へある程度話が進んできたようなので、ここらへんで一回振り返りましょう。 また、io.jsの最新情報は io.jsブログ にもまとまっております。そちらもご一読ください。よろしくお願いいたします。 io.js リリースからここまでの話 リリースから少しして、結局どうなっているかわからない人達もいると思います。一旦復習を兼ねてリリースから今まで何が起きているのかを解説します。 Node Foundation が設立 io.js がリリースされた後にちょうど NodeSummit と呼ばれる大きめのNode.jsカンファレンスがありました。 このカンファレンスでは、 Joyent の CEO である Scott Ha
io.js がリリースされました - from scratch
さてさて、io.js ver.1.0.0, 1.0.1 が無事アメリカ時間の1/13日に予告通りリリースされました。 リリースから数日経過して、現在はv1.0.3が出ています。 ある程度v1.0が安定してきた今、実際にNode.jsとどう違うのかを解説したいと思います。 Node.jsと機能的に違う所はどこか 前回の記事のio.jsについて知っていること - from scratchでも触れたんですが、一番大きな違いはv8が新しくなり、ES6の機能が増えました。 詳しくは公式のES6に関するページを読んでもらうとして、かいつまんで書いていきます。 ES6の機能に"shipping", "staged", "in_progress"の3段階のラベルがつくようになりました。 これはES6の機能の安定度合いを示していて、 "shipping" > "staged" > "in_progress"
io.jsについて知っていること - from scratch
今、Node.jsに起きてることを語る上で、io.jsは避けて通れない話題でしょう。 今回のNode.js アドベントカレンダー 2014の締めを飾るために、このio.jsについて僕が知っている限りの事をまとめて書くことにします。 io.jsを知り、今後"Node"がどうなっていくのかを皆で一緒に考えていきましょう。 またこの一連のio.jsのfork騒動はOSSという特殊なプロジェクトをどう進めていくのがハッピーなのかを知る一つの教材だと思います。 OSSに関わっている皆さん、今回も長いですが、最後まで読んでもらえると幸いです。 io.js とは何か Node.jsのForkです。次のNode.jsの安定版になる、v0.12をForkしています。「アイ・オー ジェイエス」と読みます。名前の由来は木星にある四番目に大きな衛星の名前から取られました。*1 Nodeを使っている人のことをnod
Stream今昔物語 - from scratch
この記事は Node.js Advent Calendar 2014 の 1日目の記事です。 こんにちは、代表です。 Stream大好きなみんなのためにStreamの過去と現在、そして未来についてお話するよ！！ Streamを何故使うのかっていう話と歴史的な話をします！！ Streamとは データの流れを扱うための抽象化されたモジュールです。もうみんな耳にタコかもしれませんが、Streamを使うとデータの流れを綺麗に書くことができます。ちなみに今に始まった概念ではなくて、C++にもC#にもStreamがありますし、Java8の新機能にもStreamがあります。「データを扱うときの抽象化された流れ」を指す広義のStreamという意味では今日の言語ではだいたい実装されています。 Node.jsでは、以下のリンクが参考になるでしょう。 Node.js の Stream API で「データの流れ」
atomのpackageの作り方 - from scratch
先日、atomというgithub製のIDEが公開されて話題になってます。 これ、広める戦略がうまくて、昔のgmailと同じく、inviteを受けた人が3人だけinvite ticketを持ってて、その人からまた3人inviteできるって仕組みになってます。こうすることでSNSでのinvite ticket要求が盛んになり、流行ってるように見えるというのが上手い。 ちなみにDLされるファイルだけ他人に送っても内部的にチェックしててpackage managerとかが使えない仕組みになってるので、inviteを持ってない人はおとなしく誰かから回ってくるのを待ちましょう。 本題 atom自身はSublime Textっぽい外観で、apmっていうパッケージマネージャが付属されてます。 んで、早速apmに自作のpackageを作って公開してみました。 実行している所： yosuke-furukawa
EventEmitterの代わりにEventEmitter2を使う - from scratch
このエントリをNode.js Advent Calendarにするか迷いましたが、Advent Calendarとしてはちょっとマニアックだったので、没になった方もアップします。ブログエントリの大掃除中です。 Node.jsを使うならEventEmitterを知っとくべし、という記事とかありますが、EventEmitter使ってるといくつか疑問に当たりますよね。 EventEmitterおさらい EventEmitterの基本的な機能をおさらいしておくと、EventEmitterというのは、イベントという単位で処理を行えるようにするためのモジュールで、イベントの受発信を行うことで非同期プログラミングを行いやすくするもの。 emitでイベントを発行 onで発行したイベントを受信 removeListenerでイベントを消すことができる onceで一回だけイベントを受信することができる で、こ
Node.jsのコミュニティに変化を与えるnode-forwardについて - from scratch
ちょっとここ最近node.jsを騒がせてるnode-forwardについてまとめました。 node-forwardとは Node.jsを専門とするTechnical Committee(技術委員会)です。 nodeforward.org というサイトができており、簡単にそこに書かれている事を翻訳しておきました。 [翻訳] nodeforward.org Node Forwardとはオープンなコラボレーションを通してNode, JavaScript, それらのエコシステムを改善するために努力をするコミュニティです。 Nodeは驚くべき速さで成長しています。この成長はコミュニティが一定以上の規模になるまでに起きたいくつかの問題を先頭を切って解決してきました。 いくつかの問題は単純にアサインされるようなものだけじゃなく、リーダーシップとコントリビューターの自主性を要求するような問題でした。一方で
traceur-compiler 入門 - from scratch
最近ちょっとはまってるtraceur-compilerについて紹介していきます。 前書き 今回、書いてたら非常に長くなってしまって、ちょっとした薄い本の記事くらいの文量があります。 その代わり、公式ドキュメント + コードの中を読みこんで書いているので、今のところ多分日本では一番詳しい記事かと思います。 すごく長いので章分けしました。興味が有るところだけ読み飛ばしてもらってもいいかと思います。 第一章 traceur-compiler概要 第二章 ES6言語仕様概要 第三章 traceur compilerの使いどころと類似ツール 第一章 traceur-compiler概要 traceur-compilerとは Googleが作っている EcmaScript6 形式で書かれた JavaScript を EcmaScript5 の形式に変換してくれるツールです。"トレーサーコンパイラー"と
nodeconf.eu 3日目 (mad science, leveldb, strongloop) - from scratch
「英語すごいできるんですね。」みたいなコメントが有ったんですが、できないです。 相手が伝えている情報のうち、分かる単語から情報を拾って、確認するっていう、3 way handshake みたいな確認を逐一しながら補完しているだけです。要は気合です気合。 向こうの人は優しくて、こっちがネイティブじゃないんだってわかるとゆっくり喋ってくれたり簡単な言葉に直してくれるので楽ですね。 さてさて最終日も濃かったnodeconf.euの話をしていきます。 mad science act track このtrackでは、今までの「node.jsの運用」とか「microservicesで今後のnode.jsがどうこう」というよりもnode.jsのcutting edgeを走るsubstack, feross, dominic tarr, mikolaの話を聞いて彼らが普段何を考えてるのか、どんなものを作っ
nodeconf.eu 1日目 (Future Node.js, microservices, hapi) - from scratch
さて、 nodeconf.eu に来ています。 当たり前なんだけど、nodeconf.eu ではnode.jsを使っているユーザーが多くて、外人ばっかり。 会う人会う人に「お前の国ではNode.jsは流行ってるのか?」って聞いてるんだけど、とりあえずの理解では、「サンフランシスコ、シアトルとかアメリカでは流行ってる。Dublin、ロンドンとかのアイルランド、イギリスでもまぁまぁ流行ってる。スウェーデンでは全く流行っていない。」っていう感じ。 日本ではどうなんだ?って聞かれたから「MatzのおかげでRubyがめっちゃ流行ってるよ、Node.jsも一時期流行ったけどRubyほどじゃない、最近だとGoとScalaが流行ってるよ」って応えてる。 ちなみにサンフランシスコだと、Node.jsめっちゃ流行ってて、Goがちょっと前のNode.jsみたくぼちぼち流行ってる、エッジな人たちがRust使い始め
LLDiver で「それでもNode.jsをやる」というタイトルで発表してきた - from scratch
発表資料 LLDiverで発表してきました。最近僕もgolangとか触ってるので色々と言われるんですが、「一時期Node.jsやってた人ってみんなGoに行っちゃったよね」って言われることすごく多くて、これについて色々と思うことがあるので話してきました。 ちょっとした補足とか この前のRebuild.fmでのmicroserviceの話とかでもあったんですが、モノリシックな一枚岩のアーキテクチャではなく、"一つのことを上手くやる"複数のコンポーネントとしてのサービスを作りそれの集合体で全体のサービスを提供する構成が流行ってきています。 これ自体は今に始まった話じゃなくてTwitterがRuby on Railsで作られたサービスをscalaでSOA化した話はあまりにも有名ですし、大体どの企業でもモノリシックなサービスで未来永劫続けるのは大規模になると難しくなるので、正しい姿といえるでしょう。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
