浮かない顔をしておるな。ワケを話してみよ。 npmの依存パッケージが増えた ふむ。npmで依存パッケージを増やしたと。それで？ なに、他の開発者から 動かない と言われたのか。で、毎回 npm ciをしてくれ と頼んでいるわけか。 …その問題、半世紀ほど前に解決されておるぞ。 何かの縁じゃ。お主に開発環境を自動更新する古来の術式を教えてやろう。 詠唱準備 手始めに適当なパッケージを作るかの。今からの操作は空ディレクトリの中で作業していくぞ。 お主がNode.jsをインストール済であれば、
※本記事は筆者styprが英語で執筆した記事を株式会社Flatt Security社内で日本語に翻訳したものになります。 TL;DR Node.jsのエコシステムで最も人気のあるMySQLパッケージの一つである mysqljs/mysql (https://github.com/mysqljs/mysql)において、クエリのエスケープ関数の予期せぬ動作がSQLインジェクションを引き起こす可能性があることが判明しました。 通常、クエリのエスケープ関数やプレースホルダはSQLインジェクションを防ぐことが知られています。しかし、mysqljs/mysql は、値の種類によってエスケープ方法が異なることが知られており、攻撃者が異なる値の種類でパラメータを渡すと、最終的に予期せぬ動作を引き起こす可能性があります。予期せぬ動作とは、バグのような動作やSQLインジェクションなどです。 ほぼすべてのオンラ
npm、一見無意味なパッケージを消したら1000件ものパッケージが依存するパッケージであったことが判明 npmが一見無意味に思えるfsというパッケージをSPAMとみなして削除したところ、1000件ほどのパッケージが依存するパッケージだったので、削除を取り消した。 npm, Inc. Status - "fs" unpublished and restored 今日、数分ほど、"fs"というパッケージが、ユーザーからSPAMであるという報告を受けて、レジストリから非公開にされた。これは現在復旧されている。これは私(@seldo)による人為的なミスである。私は非公開が安全であるかを確認する内部のガイドラインに従っていなかった。ビルドが阻害されたユーザーに謝罪する。 詳細："fs"というパッケージは、無意味なパッケージである。これは単に"I am fs"をログに残して終了する。このパッケージが何
This package does not have a README. Add a README to your package so that users know how to get started.
NAME node-win32ole - Asynchronous, non-blocking win32ole bindings for node.js powered by v8 engine . win32ole makes accessibility from node.js to Excel, Word, Access, Outlook, InternetExplorer, WSH ( ActiveXObject / COM ) and so on. It does not need TypeLibrary. USAGE Install with npm install win32ole. It works as... (version 0.1.x)
windows-cpu CPU monitoring utilities for Node.js apps on Windows. NOTE: Version 1.0.0+ only supports Node v8+. If you need to support an older version of Node, install windows-cpu@0.1.6 - See version 0.1.6. About A small API that provides load information about any process or the system on Windows platforms. Node.js does have os.loadavg() although it does not work correctly in Windows. Windows-CPU
1./etc/init.d/nodeを作る vi /etc/init.d/node #!/bin/sh # # chkconfig: 35 99 99 # description: Node.js /MyDirectory/app.js # . /etc/rc.d/init.d/functions user="root" # 実行するユーザー nodejs="/root/.nvm/v0.6.12/bin/node" # Node.jsのパス rootdir="/MyDirectory/" #app.jsがあるパス server="$rootdir/app.js" # サーバへのパス logfile="/var/log/node/app.log" # ログファイルのパス lockfile="/var/lock/subsys/node" # ロックファイルへのパス start() { if [
There are a wide range of methods to set up a Node.js process as a service on Linux, with little consensus on a standard at this point. That's fine - Node.js is still a long way away from staid maturity and the era in a technology's development in which people settle on the two or three standard ways of solving a given problem. Here, I'll outline one of my presently preferred ways of setting up a
この記事は東京Node学園祭2012 アドベントカレンダーの8日目の記事です。 この記事を書こうと思った理由 Node.jsに関するWeb上の記事を読んでいると、「Node.jsは静的コンテンツに弱い」とだけ書いてある記事をよく見かけます。有名なところだと、LinkedInのNode.jsのパフォーマンスに関する10個のTipsの3番目のTipsに"Don't use Node.js for static assets"とばっちり書いてあります。 確かにCDNやNginxに比べれば、Node.jsは静的コンテンツの扱いが遅いとは思います。しかし、それは LinkedIn くらいの超大規模なトラフィックがある場合には問題になるとは思いますが、小〜中規模なサイトでもNginxは必須なほど遅いのでしょうか？512MBしかメモリのないVPSにNginxとNode.jsを入れてやりくりすることがホン
はじめに ちょっと前の nodejs のメーリングリストで 「Odd behavior of nested Domaons」 https://groups.google.com/d/topic/nodejs/i8NjWjVvk2I/discussion という質問が投げかけられていました。 私も内容が気になり、動作結果が非常に奇妙に思えたので調べてみました。(ML宛には解答を返事してますのでネタバレ注意です） 問題の奇妙な振る舞い 質問で提示されたコードは下記のものでした。 var domain = require('domain'); var topDomain = domain.create(); //親ドメインの作成 var subDomain = domain.create(); //子ドメインの作成 topDomain.add(subDomain); //親ドメインに子ドメインを
node.js のような非同期APIを使ったプログラミングに拒絶反応を示すエンジニアが多い理由の一つが、非同期APIと例外処理の相性の悪さだ。 Javascript の場合、例外処理はこんな感じに記述する。 function f(i) { try { throw new Error('an error #'+ i); } catch(e) { console.log('Error caught:', e.message); } } ところが、これに非同期APIが絡むと、とたんに分かりにくくなる。例えば下の例。 function f(i) { try { setTimeout(function() { throw new Error('an error #'+ i); }, 1000); } catch(e) { console.log('Error caught:', e.message)
以下の文章は Targeter App Blog の記事を翻訳したものです。原文は 2012年5月12日 に書かれました。 Why we moved from NodeJS to RoR http://blog.targeterapp.com/post/22984987832/why-we-moved-from-nodejs-to-ror 免責事項：この記事は NodeJS や Ruby on Rails について騒ぎ立てるものではありません。ただ私たちの決定とその理由について振り返るものです。両フレームワークはそれぞれが作られた目的において素晴らしいものであり、そのことは、私たちのスタックの一部がいまだ NodeJS で動いている理由でもあります。 私は NodeJS のすごいファンで、これは非常にエキサイティングな技術だと信じていて、これらの人気が出る様を目にするだろうと思う。私はとて
Node.jsでWebアプリを書いてるんだけど別に大量のリクエストをさばくわけでもないしWebSocketも使ってないし、じゃあなんでそんなことしてんの、という話。 まず結論だけ書くと、 並列度が低くてよいが長時間かかることが確定的な処理を非同期的に走らせる必要がある場合、普通はそのような用途でもJobQueue/Workerを使って構成するがそういうのは管理も面倒だしインストールも面倒くさくなるのであんまりやりたくない。Node.jsなら普通のWebアプリケーションフレームワークだけでラクに書けていいんじゃね？ というひとつの提案です。 同期実行のケース 普通Webアプリケーションフレームワークというのは、一連の処理はクライアントにレスポンスを返すことで完了する。そしてひとつのプロセス/スレッドはリクエストをディスパッチされてからレスポンスを返すまでがそのリクエストに占有される。 ここで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く