jsconf.eu 2019 に行ってきました。 特に npm や yarn の今後の話とそもそも Registry をどうしていくか、の話があったのでお知らせします。 そもそも Registry をどうしていくかについては次のエントリで話します。 tink: A Next Generation Package Manager npm の次のコマンドラインツールである tink が紹介されていました。 github.com presentation: github.com video: www.youtube.com そもそも npm の仕組み ローカル依存ファイルを読む (package.json, package-lock.json, shrinkwrap.json) 存在しないパッケージのメタデータをfetchする 木構造を計算して、実行する（npm v3 以降だとflattenする

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 のパフォーマンスに

さて、とうとう皆さん待望の Node.js v6.0 がリリースされました！次のLTS候補です。LTSになるのは2016年の10月からの予定です。v6 の LTS 期間は明示化されてないですが、ルールに照らし合わせれば、LTSになってから 2年半がサポート期間なので、おそらく 2019年4月まではサポートされます。 Node v6.0.0 (Current) | Node.js Node.js v6.0 の主な変更点 ES2015 support の改善 module load性能の改善 Buffer API の new Buffer() コンストラクタの廃止 (セキュリティ上の理由から) ES2015 support の改善 やっぱりこれが一番大きな変化ですね。 node.green を見てもらえればわかるかもしれませんが、 ES2015 のサポートがこれまでは 58% だったのが 96

無駄にラノベみたいに長いタイトル書いちゃったんですが、まぁやっぱり一言くらいは残しておくかと思ったので書きます。長いのでまとめだけでも見てもらえると良いかもしれません。 leftpadの話はかなり大事になっていて、Node.js界隈を中心としてその他のOSSをやっている全体的に話が波及しています。幾つかの記事を読みました。今回はJSの文化と歴史についてちょっとずつ書いていこうかなと思います。 本の虫: npmからkikとその他諸々が消されたまとめ 江添さんの話はすごくよくまとまっていて、ネタも含めた上で一番面白い話になっていました、ここで言われている下記の疑問に答えていこうと思います。 もっと憂うべきパッケージがある。isArrayだ。このパッケージは一日88万回もダウンロードされていて、2016年2月だけの一ヶ月間に1800万回もダウンロードされていて、72個ものNPMパッケージが依存し

いくつかこの何日間でニュースが出ているので紹介します。 ちなみに、 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 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"

今、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

はじめに この話はGuillermo Rauch氏が書いたhttp://rauchg.com/2014/7-principles-of-rich-web-applications/ という記事の翻訳です。許可を得て翻訳しています。 ここ最近Web業界を賑わしているSingle Page Applicationの必要性、HTTP2/SPDYといった技術、リアクティブプログラミングやIsomorphicデザインという考え方について包括的にまとめたすごく良い記事になっております。 最初に断っておきますが、ものすごく長いです。各セクションがわかれているので時間がない方はセクションごとに書かれたtl;DRとまとめを読むだけでも参考になるかと思います。 ちなみに明日のNode学園祭には、本記事を記述したGuillermo Rauch氏が見えるので、そこで詳しく聞いてみるのもいいのではないでしょうか。

ずっと興味はあったし、追っていたんですが手は出せていなかったWebRTCについてやっと学ぶことが出来ました。 ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 作者: Ilya Grigorik,和田祐一郎,株式会社プログラミングシステム社出版社/メーカー: オライリージャパン発売日: 2014/05/16メディア: 大型本この商品を含むブログ (2件) を見る ハイパフォーマンスブラウザネットワーキングという本(以下、HPBN)がありまして、会社の中で輪読会していました。みんなで一つの章を担当しながら話すというスタイルでやっていました。 そこで僕が紹介したWebRTCの話です。 基本的にWebRTCの中でやっていることを深く説明した資料になっています。 HPBNの資料だけで分からなかったところはWebRTCミートアップの資料や先人た

「visionmedia、Node.js辞めるってよ」って事で、今回はこの話の翻訳ですね。 Farewell Node.js — Code adventures — Medium 最近のnode.jsはホントTJ Fontaine のリーダー就任から始まってNode.jsでできたエディタであるAtomがreleaseされたり、gemのモジュール数をnpmのモジュール数が抜いたり、socket.io v1.0が出たりと色々あるんですが、今回の話は飛び抜けて衝撃的だったなぁと思ってます。 一応知らない方のためにvisionmediaについて説明しておくと、以下のモジュールは全てvisionmedia製です。 express (Web Applicaiton Framework) mocha (Testing Framework) jade (hamlライクなtemplate engine) s

さてさて、前回の続きです。 オレはgruntのエコシステムに乗って楽をしたい、でもGruntfile.jsが長くなりすぎて辛い、grunt taskが時間がかかりすぎて辛い、という話は話で分かります。また、それに対する色んな解決策もあります。 最近出た、HTML5Rocksで紹介されてたやり方もあるし、いくつか先人の知恵もあるので、解決していきましょう。 Gruntfile.jsが長くなりすぎて辛い時 https://github.com/firstandthird/load-grunt-configを使いましょう。 いろんなtipsを見てきましたが、このライブラリが一番分かりやすく、かつGruntfile.jsをメンテナブルに保つことができます。 load-grunt-configには3つの機能があります。 grunt pluginの自動ロード機能 grunt configのファイル分割

Gruntについて最新の気持ち ::ハブろぐ 上記のブログエントリを読んで非常に今自分が感じていることと共通点を感じました。 Gruntに対する最新の気持ちでは2つの問題提起がされてました。 1. Gruntfile.jsが長すぎる(700行とか) 2. そもそも全部gruntでやらなきゃいけないのか 1.に関しては色んな解決手段があります、ブログの筆者も解決されているようですし、この件に関しては次回のMaintainable Gruntfile.jsで触れます。 最初は2.に関しての、全部gruntでやらなきゃいけないんだっけ、という疑問に関してです。 僕も同じ思いをしてたので、同調してブログを書きます。 gruntについて 言わずと知れたタスクランナーですね、gruntを使うとjavascriptのminifyやmeta cssのコンパイルといったフロントエンドにありがちな作業を自動化

Bower入門 これから Bower について書いてきます。Bowerの使い方から実際に使う上で考慮することまで含めて書きます。 長くなりそうなので単に使うだけの基礎編とモジュールを作る上で気をつけることをまとめた応用編に分けて書きます。 Bower とは Twitter社が作ったフロントエンド用のパッケージマネージャです。 Java で言う Maven、 Ruby で言う gem、 Perl で言う cpan のようなものです。 Node.jsには npm と呼ばれるパッケージマネージャがありますが、それに強く影響を受けています。 パッケージマネージャを利用することでライブラリを自分で管理する必要がなくなり、管理するファイルの数を減らすことができます。 また、パッケージマネージャを利用することでライブラリのバージョン管理をしやすくなります。 さらに自分のライブラリを Bower comp

自分が退職エントリを書くことになる、というのは一年前、このブログを初めた時には考えもしなかった。この数ヶ月間、いくつか考えることがあったので、自分のためにも残しておく。 今回のエントリは多分めちゃくちゃ長いです。 最後にまとめがあるので、そこを見るだけでもいいと思います。 バックグラウンド的な まず、今の会社、富士ゼロックスに入社が決まった時から「この会社に一生勤めよう」とか、「安定したメーカーに就職できたからこれで安泰だ」とかは全く思っていなかった。 せっかくエンジニアになったのだから、「ユーザーの生活・働き方が変わるようなイノベーティブな製品を作りたい」という思いを持ち、それを叶えようと思っていた。 富士ゼロックスに勤めると、プリンター、コピー機だけじゃなくて、ソフトウェア含めて色んなモノを開発しているから自分の視野の拡大できるだろうし、富士ゼロックスにはFXPALっていうソフトウェア