はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

2018-04-24(日本時間2018-04-25)にNode.js v10.0.0がリリース そのクラス図（event付き）を（たぶん）世界最速で公開 https://github.com/darai0512/node-class-diagram core moduleの一部のみ net, tls, udp, http, httpsとそれらの親クラスに当たるevents, stream WIP 公式ドキュメント記載分のみ Deprecated APIはDocumentation-only1も含め除外 図でhttp.IncomingMessageに'close'イベントがないのは、streamのものを継承していることを表す（ただしoverwriteして別物になっていることもあるので注意） 赤字はv9以降で追加されたもの、うちv10.0.0で追加されたのは下記2 EventEmitter o

背景・動機 IntelliJで開発するとき、依存ライブラリ(External Libraries)を手元に用意しておかないとジャンプとか補完とか便利機能が効かなくなる。 ただnpmならProject（intellijのProjectのこと。大体Gitのリポジトリ単位）のディレクトリ以下にしか影響を及ぼさないので問題ないのだが、 pythonのpipのデフォだと、全Projectから参照可能なinstallをする。書いたコードが手元で動いた理由が、実は別Projectの依存関係のおかげだったりしたらまずい。というか汚れるのがちょっと......（潔癖症） venvも悪くないけど（AI周りはvenv流行ってるし）、docker開発が現場ではメジャーだと思う。 IntelliJのinterpreterをDockerに繋ぐことで、コンテナ内のExternal Libraryを参照させる1。 方法

A. 何秒待っても出力されない 同期処理の言語に慣れていると、すぐにokの出力を期待してしまうが... Node.jsでのsetTimeout() Node.jsはJavaScriptエンジン(v8)を持っている 基本的にはJSのAPIを利用できる ただし一部はNode.jsのランタイムではNode core APIが実行される setTimeout(),setInterval(),setImmediate()はJSのTimerではなくNode core APIのTimerが実行される これらはNode.js Eventloop内で処理される JS/Node.jsの主な非同期処理 JS Promise(ここではObject.observe()として扱う1) Node.js I/O setImmediate setTimeout/setInterval process.nextTick Ev

動機 professional SSL/TLSを読んで、今後はなるべくECDSA鍵を使っていこうと思った。 先行記事のGitHubでEd25519鍵をつかうも非常に面白いのでぜひ。 ECDSAとは？ ECDSA(Elliptic Curve Digital Signature Algorithm)は楕円曲線暗号を使った公開鍵のアルゴリズムで、RSAよりも短い鍵長で安全性を担保できる。 短いということは、TLSなどで利用する場合は高速に鍵交換が行えるということである。 （後で示すが、256bitのECDSA鍵は、2,048bitのRSA鍵より安全かつ2倍早い） ただし古いブラウザでは対応していない場合があることに注意。 参考（ちょっと古め）: ウェブブラウザにおけるTLS/SSLの対応状況の変化 とはいえNISTによると、2031年以降、RSA 2,048bitをはじめ強度の低いアルゴリズム

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

「Node.jsはシングルスレッドだから、プロダクションで使うのはリスクだ」みたいな発言に対するアンサー（今更感） Node.jsは戦略的にシングルスレッド・シングルプロセスを採用しているわけで、 しかも任意にマルチプロセス化が可能だし、重いデータを扱う際は内部(libuv)で勝手にマルチスレッド化して処理される。 今のシリコンバレーではNode.js経験者の需要が高い、なんて話も聞く。 開発効率の良いNode.jsでプロトタイプを作り、リリースを繰り返すことがベンチャーにとって重要だからだ。 TwitterやGoogleレベルならともかく、ベンチャーレベルのtrafficで、パフォーマンス的な問題が出たという話は聞いたことがない。 なお、プロダクションで使うことを勧める記事ではありません。 またECMAScriptのSharedArrayBufferなどの話は無視します。 前段 Node

$brew-file init Do you want to set a repository (y)? ((n) for local Brewfile). [y/n]: y Set repository, "non" for local Brewfile,<user>/<repo> for github repository, or full path for the repository: non initではGithubリポジトリと連携する場合に"non"以外の文字列を入れるが、 一度リポジトリを設定してしまうと、変更は$brew-file set_repoでできるものの、削除はできない様子。 自分は間違えてlocal pathを入れてしまい、$brew-file set_repoで"non"と答え直してBrewfileを生成できたが、 再度$brew-file initをしても最初

React v16リリースと共にMITライセンスへ https://facebook.github.io/react/blog/2017/09/26/react-v16.0.html#mit-licensed 16系だけでなく、すぐに移行できない人向けに、15系の主要バージョンもMITライセンスに変更されました。 2017/09/24追記 近日リリース予定のReact v16にて、ライセンスをBSD + PatentsからMITに変更予定とのPOSTがありました。 We're relicensing React, Jest, Flow, and Immutable.js under the MIT license. https://t.co/3XD0z49UsS — React (@reactjs) 2017年9月22日 但しまだGitHubでLICENSE*ファイルの変更やPATENTS