From ddf52bd3473edd2d017e2eaeb2a95cd8611bfe3f Mon Sep 17 00:00:00 2001 From: isaacs Date: Tue, 19 Jun 2012 22:13:22 -0700 Subject: [PATCH] Initial blog source Exported from WP and cleaned up a bit. --- doc/blog/README.md | 28 ++ ...-way-to-build-scalable-network-programs.md | 16 + .../Uncategorized/development-environment.md | 25 ++ .../evolving-the-node-js-brand.md | 34 ++ doc/blog/Uncategorized/growing-up.md | 12 + doc/blog/Uncategorized/jobs-nodejs-org.md | 14 + .../Uncategorized/ldapjs-a-reprise-of-ldap.md | 88 +++++ doc/blog/Uncategorized/libuv-status-report.md | 45 +++ .../node-meetup-this-thursday.md | 11 + .../node-office-hours-cut-short.md | 12 + doc/blog/Uncategorized/office-hours.md | 12 + ...o-windows-with-microsoft%e2%80%99s-help.md | 12 + doc/blog/Uncategorized/profiling-node-js.md | 60 ++++ .../Uncategorized/some-new-node-projects.md | 13 + .../the-videos-from-node-meetup.md | 10 + doc/blog/Uncategorized/trademark.md | 17 + doc/blog/Uncategorized/version-0-6.md | 12 + .../Uncategorized/welcome-to-the-node-blog.md | 13 + ...server-continuous-deployment-with-fleet.md | 89 +++++ .../service-logging-in-json-with-bunyan.md | 337 ++++++++++++++++++ ...ng-node-js-dependencies-with-shrinkwrap.md | 165 +++++++++ .../npm-1-0-global-vs-local-installation.md | 64 ++++ doc/blog/npm/npm-1-0-link.md | 114 ++++++ doc/blog/npm/npm-1-0-released.md | 36 ++ doc/blog/npm/npm-1-0-the-new-ls.md | 144 ++++++++ ...antrill-instrumenting-the-real-time-web.md | 19 + doc/blog/video/welcome-to-the-node-blog.md | 13 + ...-vulnerability-please-upgrade-to-0-6-17.md | 45 +++ 28 files changed, 1460 insertions(+) create mode 100644 doc/blog/README.md create mode 100644 doc/blog/Uncategorized/an-easy-way-to-build-scalable-network-programs.md create mode 100644 doc/blog/Uncategorized/development-environment.md create mode 100644 doc/blog/Uncategorized/evolving-the-node-js-brand.md create mode 100644 doc/blog/Uncategorized/growing-up.md create mode 100644 doc/blog/Uncategorized/jobs-nodejs-org.md create mode 100644 doc/blog/Uncategorized/ldapjs-a-reprise-of-ldap.md create mode 100644 doc/blog/Uncategorized/libuv-status-report.md create mode 100644 doc/blog/Uncategorized/node-meetup-this-thursday.md create mode 100644 doc/blog/Uncategorized/node-office-hours-cut-short.md create mode 100644 doc/blog/Uncategorized/office-hours.md create mode 100644 doc/blog/Uncategorized/porting-node-to-windows-with-microsoft%e2%80%99s-help.md create mode 100644 doc/blog/Uncategorized/profiling-node-js.md create mode 100644 doc/blog/Uncategorized/some-new-node-projects.md create mode 100644 doc/blog/Uncategorized/the-videos-from-node-meetup.md create mode 100644 doc/blog/Uncategorized/trademark.md create mode 100644 doc/blog/Uncategorized/version-0-6.md create mode 100644 doc/blog/Uncategorized/welcome-to-the-node-blog.md create mode 100644 doc/blog/module/multi-server-continuous-deployment-with-fleet.md create mode 100644 doc/blog/module/service-logging-in-json-with-bunyan.md create mode 100644 doc/blog/npm/managing-node-js-dependencies-with-shrinkwrap.md create mode 100644 doc/blog/npm/npm-1-0-global-vs-local-installation.md create mode 100644 doc/blog/npm/npm-1-0-link.md create mode 100644 doc/blog/npm/npm-1-0-released.md create mode 100644 doc/blog/npm/npm-1-0-the-new-ls.md create mode 100644 doc/blog/video/bryan-cantrill-instrumenting-the-real-time-web.md create mode 100644 doc/blog/video/welcome-to-the-node-blog.md create mode 100644 doc/blog/vulnerability/http-server-security-vulnerability-please-upgrade-to-0-6-17.md diff --git a/doc/blog/README.md b/doc/blog/README.md new file mode 100644 index 00000000000..7d37706470a --- /dev/null +++ b/doc/blog/README.md @@ -0,0 +1,28 @@ +title: README.md +status: private + +# How This Blog Works + +Each `.md` file in this folder structure is a blog post. It has a +few headers and a markdown body. (HTML is allowed in the body as well.) + +The relevant headers are: + +1. title +2. author +3. status: Only posts with a status of "publish" are published. +4. category: The "release" category is treated a bit specially. +5. version: Only relevant for "release" category. +6. date +7. slug: The bit that goes on the url. Must be unique, will be + generated from the title and date if missing. + +Posts in the "release" category are only shown in the main lists when +they are the most recent release for that version family. The stable +branch supercedes its unstable counterpart, so the presence of a `0.8.2` +release notice will cause `0.7.10` to be hidden, but `0.6.19` would +be unaffected. + +The folder structure in the blog source does not matter. Organize files +here however makes sense. The metadata will be sorted out in the build +later. diff --git a/doc/blog/Uncategorized/an-easy-way-to-build-scalable-network-programs.md b/doc/blog/Uncategorized/an-easy-way-to-build-scalable-network-programs.md new file mode 100644 index 00000000000..e1a509ecd78 --- /dev/null +++ b/doc/blog/Uncategorized/an-easy-way-to-build-scalable-network-programs.md @@ -0,0 +1,16 @@ +title: An Easy Way to Build Scalable Network Programs +author: ryandahl +date: Tue Oct 04 2011 15:39:56 GMT-0700 (PDT) +status: publish +category: Uncategorized +slug: an-easy-way-to-build-scalable-network-programs + +Suppose you're writing a web server which does video encoding on each file upload. Video encoding is very much compute bound. Some recent blog posts suggest that Node.js would fail miserably at this. + +Using Node does not mean that you have to write a video encoding algorithm in JavaScript (a language without even 64 bit integers) and crunch away in the main server event loop. The suggested approach is to separate the I/O bound task of receiving uploads and serving downloads from the compute bound task of video encoding. In the case of video encoding this is accomplished by forking out to ffmpeg. Node provides advanced means of asynchronously controlling subprocesses for work like this. + +It has also been suggested that Node does not take advantage of multicore machines. Node has long supported load-balancing connections over multiple processes in just a few lines of code - in this way a Node server will use the available cores. In coming releases we'll make it even easier: just pass --balance on the command line and Node will manage the cluster of processes. + +Node has a clear purpose: provide an easy way to build scalable network programs. It is not a tool for every problem. Do not write a ray tracer with Node. Do not write a web browser with Node. Do however reach for Node if tasked with writing a DNS server, DHCP server, or even a video encoding server. + +By relying on the kernel to schedule and preempt computationally expensive tasks and to load balance incoming connections, Node appears less magical than server platforms that employ userland scheduling. So far, our focus on simplicity and transparency has paid off: the number of success stories from developers and corporations who are adopting the technology continues to grow. diff --git a/doc/blog/Uncategorized/development-environment.md b/doc/blog/Uncategorized/development-environment.md new file mode 100644 index 00000000000..f7141815890 --- /dev/null +++ b/doc/blog/Uncategorized/development-environment.md @@ -0,0 +1,25 @@ +title: Development Environment +author: ryandahl +date: Mon Apr 04 2011 20:16:27 GMT-0700 (PDT) +status: publish +category: Uncategorized +slug: development-environment + +If you're compiling a software package because you need a particular version (e.g. the latest), then it requires a little bit more maintenance than using a package manager like dpkg. Software that you compile yourself should *not* go into /usr, it should go into your home directory. This is part of being a software developer. + +One way of doing this is to install everything into $HOME/local/$PACKAGE. Here is how I install node on my machine:
./configure --prefix=$HOME/local/node-v0.4.5 && make install
+ +To have my paths automatically set I put this inside my $HOME/.zshrc:
PATH="$HOME/local/bin:/opt/local/bin:/usr/bin:/sbin:/bin"
+LD_LIBRARY_PATH="/opt/local/lib:/usr/local/lib:/usr/lib"
+for i in $HOME/local/*; do
+  [ -d $i/bin ] && PATH="${i}/bin:${PATH}"
+  [ -d $i/sbin ] && PATH="${i}/sbin:${PATH}"
+  [ -d $i/include ] && CPATH="${i}/include:${CPATH}"
+  [ -d $i/lib ] && LD_LIBRARY_PATH="${i}/lib:${LD_LIBRARY_PATH}"
+  [ -d $i/lib/pkgconfig ] && PKG_CONFIG_PATH="${i}/lib/pkgconfig:${PKG_CONFIG_PATH}"
+  [ -d $i/share/man ] && MANPATH="${i}/share/man:${MANPATH}"
+done
+ +Node is under sufficiently rapid development that everyone should be compiling it themselves. A corollary of this is that npm (which should be installed alongside Node) does not require root to install packages. + +CPAN and RubyGems have blurred the lines between development tools and system package managers. With npm we wish to draw a clear line: it is not a system package manager. It is not for installing firefox or ffmpeg or OpenSSL; it is for rapidly downloading, building, and setting up Node packages. npm is a development tool. When a program written in Node becomes sufficiently mature it should be distributed as a tarball, .deb, .rpm, or other package system. It should not be distributed to end users with npm. diff --git a/doc/blog/Uncategorized/evolving-the-node-js-brand.md b/doc/blog/Uncategorized/evolving-the-node-js-brand.md new file mode 100644 index 00000000000..dbb7f852f15 --- /dev/null +++ b/doc/blog/Uncategorized/evolving-the-node-js-brand.md @@ -0,0 +1,34 @@ +title: Evolving the Node.js Brand +author: Emily Tanaka-Delgado +date: Mon Jul 11 2011 12:02:45 GMT-0700 (PDT) +status: publish +category: Uncategorized +slug: evolving-the-node-js-brand + +To echo Node’s evolutionary nature, we have refreshed the identity to help mark an exciting time for developers, businesses and users who benefit from the pioneering technology. + +Building a brand + +We began exploring elements to express Node.js and jettisoned preconceived notions about what we thought Node should look like, and focused on what Node is: kinetic,connected, scalable, modular, mechanical and organic. Working with designer Chris Glass, our explorations emphasized Node's dynamism and formed a visual language based on structure, relationships and interconnectedness. + + + +Inspired by process visualization, we discovered pattern, form, and by relief, the hex shape. The angled infrastructure encourages energy to move through the letterforms. + + + +This language can expand into the organic network topography of Node or distill down into a single hex connection point. + +This scaling represents the dynamic nature of Node in a simple, distinct manner. + + + +We look forward to exploring this visual language as the technology charges into a very promising future. + + + +We hope you'll have fun using it. + +To download the new logo, visit nodejs.org/logos. + + diff --git a/doc/blog/Uncategorized/growing-up.md b/doc/blog/Uncategorized/growing-up.md new file mode 100644 index 00000000000..6faff59cec7 --- /dev/null +++ b/doc/blog/Uncategorized/growing-up.md @@ -0,0 +1,12 @@ +title: Growing up +author: ryandahl +date: Thu Dec 15 2011 11:59:15 GMT-0800 (PST) +status: publish +category: Uncategorized +slug: growing-up + +This week Microsoft announced support for Node in Windows Azure, their cloud computing platform. For the Node core team and the community, this is an important milestone. We've worked hard over the past six months reworking Node's machinery to support IO completion ports and Visual Studio to provide a good native port to Windows. The overarching goal of the port was to expand our user base to the largest number of developers. Happily, this has paid off in the form of being a first class citizen on Azure. Many users who would have never used Node as a pure unix tool are now up and running on the Windows platform. More users translates into a deeper and better ecosystem of modules, which makes for a better experience for everyone. + +We also redesigned our website - something that we've put off for a long time because we felt that Node was too nascent to dedicate marketing to it. But now that we have binary distributions for Macintosh and Windows, have bundled npm, and are serving millions of users at various companies, we felt ready to indulge in a new website and share of a few of our success stories on the home page. + +Work is on-going. We continue to improve the software, making performance improvements and adding isolate support, but Node is growing up. diff --git a/doc/blog/Uncategorized/jobs-nodejs-org.md b/doc/blog/Uncategorized/jobs-nodejs-org.md new file mode 100644 index 00000000000..bf8278b816c --- /dev/null +++ b/doc/blog/Uncategorized/jobs-nodejs-org.md @@ -0,0 +1,14 @@ +title: jobs.nodejs.org +author: ryandahl +date: Thu Mar 24 2011 23:05:22 GMT-0700 (PDT) +status: publish +category: Uncategorized +slug: jobs-nodejs-org + +We are starting an official jobs board for Node. There are two goals for this + +1. Promote the small emerging economy around this platform by having a central space for employers to find Node programmers. + +2. Make some money. We work hard to build this platform and taking a small tax for job posts seems a like reasonable "tip jar". + +jobs.nodejs.org diff --git a/doc/blog/Uncategorized/ldapjs-a-reprise-of-ldap.md b/doc/blog/Uncategorized/ldapjs-a-reprise-of-ldap.md new file mode 100644 index 00000000000..3507b61e19f --- /dev/null +++ b/doc/blog/Uncategorized/ldapjs-a-reprise-of-ldap.md @@ -0,0 +1,88 @@ +title: ldapjs: A reprise of LDAP +author: mcavage +date: Thu Sep 08 2011 14:25:43 GMT-0700 (PDT) +status: publish +category: Uncategorized +slug: ldapjs-a-reprise-of-ldap + +This post has been about 10 years in the making. My first job out of college was at IBM working on the Tivoli Directory Server, and at the time I had a preconceived notion that working on anything related to Internet RFCs was about as hot as you could get. I spent a lot of time back then getting "down and dirty" with everything about LDAP: the protocol, performance, storage engines, indexing and querying, caching, customer use cases and patterns, general network server patterns, etc. Basically, I soaked up as much as I possibly could while I was there. On top of that, I listened to all the "gray beards" tell me about the history of LDAP, which was a bizarre marriage of telecommunications conglomerates and graduate students. The point of this blog post is to give you a crash course in LDAP, and explain what makes ldapjs different. Allow me to be the gray beard for a bit... +

What is LDAP and where did it come from?

+Directory services were largely pioneered by the telecommunications companies (e.g., AT&T) to allow fast information retrieval of all the crap you'd expect would be in a telephone book and directory. That is, given a name, or an address, or an area code, or a number, or a foo support looking up customer records, billing information, routing information, etc. The efforts of several telcos came to exist in the X.500 standard(s). An X.500 directory is one of the most complicated beasts you can possibly imagine, but on a high note, there's +probably not a thing you can imagine in a directory service that wasn't thought of in there. It is literally the kitchen sink. Oh, and it doesn't run over IP (it's actually on the OSI model). + +Several years after X.500 had been deployed (at telcos, academic institutions, etc.), it became clear that the Internet was "for real." LDAP, the "Lightweight Directory Access Protocol," was invented to act purely as an IP-accessible gateway to an X.500 directory. + +At some point in the early 90's, a graduate student at the University of Michigan (with some help) cooked up the "grandfather" implementation of the LDAP protocol, which wasn't actually a "gateway," but rather a stand-alone implementation of LDAP. Said implementation, like many things at the time, was a process-per-connection concurrency model, and had "backends" (aka storage engine) for the file system and the Unix DB API. At some point the Berkeley Database (BDB) was put in, and still remains the de facto storage engine for most LDAP directories. + +Ok, so some a graduate student at UM wrote an LDAP server that wasn't a gateway. So what? Well, that UM code base turns out to be the thing that pretty much every vendor did a source license for. Those graduate students went off to Netscape later in the 90's, and largely dominated the market of LDAP middleware until Active Directory came along many years later (as far as I know, Active Directory is "from scratch", since while it's "almost" LDAP, it's different in a lot of ways). That Netscape code base was further bought and sold over the years to iPlanet, Sun Microsystems, and Red Hat (I'm probably missing somebody in that chain). It now lives in the Fedora umbrella as '389 Directory Server.' Probably the most popular fork of that code base now is OpenLDAP. + +IBM did the same thing, and the Directory Server I worked on was a fork of the UM code too, but it heavily diverged from the Netscape branches. The divergence was primarily due to: (1) backing to DB2 as opposed to BDB, and (2) needing to run on IBM's big iron like OS/400 and Z series mainframes. + +Macro point is that there have actually been very few "fresh" implementations of LDAP, and it gets a pretty bad reputation because at the end of the day you've got 20 years of "bolt-ons" to grad student code. Oh, and it was born out of ginormous telcos, so of course the protocol is overly complex. + +That said, while there certainly is some wacky stuff in the LDAP protocol itself, it really suffered from poor and buggy implementations more than the fact that LDAP itself was fundamentally flawed. As engine yard pointed out a few years back, you can think of LDAP as the original NoSQL store. +

LDAP: The Good Parts

+So what's awesome about LDAP? Since it's a directory system it maintains a hierarchy of your data, which as an information management pattern aligns +with _a lot_ of use case (the quintessential example is white pages for people in your company, but subscriptions to SaaS applications, "host groups" +for tracking machines/instances, physical goods tracking, etc., all have use cases that fit that organization scheme). For example, presumably at your job +you have a "reporting chain." Let's say a given record in LDAP (I'll use myself as a guinea pig here) looks like: +
    firstName: Mark
+    lastName: Cavage
+    city: Seattle
+    uid: markc
+    state: Washington
+    mail: mcavagegmailcom
+    phone: (206) 555-1212
+    title: Software Engineer
+    department: 123456
+    objectclass: joyentPerson
+The record for me would live under the tree of engineers I report to (and as an example some other popular engineers under said vice president) would look like: +
                   uid=david
+                    /
+               uid=bryan
+            /      |      \
+      uid=markc  uid=ryah  uid=isaacs
+Ok, so we've got a tree. It's not tremendously different from your filesystem, but how do we find people? LDAP has a rich search filter syntax that makes a lot of sense for key/value data (far more than tacking Map Reduce jobs on does, imo), and all search queries take a "start point" in the tree. Here's an example: let's say I wanted to find all "Software Engineers" in the entire company, a filter would look like: +
     (title="Software Engineer")
+And I'd just start my search from 'uid=david' in the example above. Let's say I wanted to find all software engineers who worked in Seattle: +
     (&(title="Software Engineer")(city=Seattle))
+I could keep going, but the gist is that LDAP has "full" boolean predicate logic, wildcard filters, etc. It's really rich. + +Oh, and on top of the technical merits, better or worse, it's an established standard for both administrators and applications (i.e., most "shipped" intranet software has either a local user repository or the ability to leverage an LDAP server somewhere). So there's a lot of compelling reasons to look at leveraging LDAP. +

ldapjs: Why do I care?

+As I said earlier, I spent a lot of time at IBM observing how customers used LDAP, and the real items I took away from that experience were: + +
+ +For all the good parts of LDAP, those are really damned big failing points, and even I eventually abandoned LDAP for the greener pastures of NoSQL somewhere +along the way. But it always nagged at me that LDAP didn't get it's due because of a lot of implementation problems (to be clear, if I could, I'd change some +aspects of the protocol itself too, but that's a lot harder). + +Well, in the last year, I went to work for Joyent, and like everyone else, we have several use problems that are classic directory service problems. If you break down the list I outlined above: + +
+ +So that's the crux of ldapjs right there. Giving you the ability to put LDAP back into your application while nailing those 4 fundamental problems that plague most existing LDAP deployments. + +The obvious question is how it turned out, and the answer is, honestly, better than I thought it would. When I set out to do this, I actually assumed I'd be shipping a much smaller percentage of the RFC than is there. There's actually about 95% of the core RFC implemented. I wasn't sure if the marriage of this protocol to node/JavaScript would work out, but if you've used express ever, this should be _really_ familiar. And I tried to make it as natural as possible to use "pure" JavaScript objects, rather than requiring the developer to understand ASN.1 (the binary wire protocol) or the LDAP RFC in detail (this one mostly worked out; ldap_modify is still kind of a PITA). + +Within 24 hours of releasing ldapjs on Twitter, there was an implementation of an address book that works with Thunderbird/Evolution, by the end of that weekend there was some slick integration with CouchDB, and ldapjs even got used in one of the node knockout apps. Off to a pretty good start! + +
+
+

The Road Ahead

+
+ +Hopefully you've been motivated to learn a little bit more about LDAP and try out ldapjs. The best place to start is probably the guide. After that you'll probably need to pick up a book from back in the day. ldapjs itself is still in its infancy; there's quite a bit of room to add some slick client-side logic (e.g., connection pools, automatic reconnects), easy to use schema validation, backends, etc. By the time this post is live, there will be experimental dtrace support if you're running on Mac OS X or preferably Joyent's SmartOS (shameless plug). And that nagging percentage of the protocol I didn't do will get filled in over time I suspect. If you've got an interest in any of this, send me some pull requests, but most importantly, I just want to see LDAP not just be a skeleton in the closet and get used in places where you should be using it. So get out there and write you some LDAP. + +
diff --git a/doc/blog/Uncategorized/libuv-status-report.md b/doc/blog/Uncategorized/libuv-status-report.md new file mode 100644 index 00000000000..68637a43b92 --- /dev/null +++ b/doc/blog/Uncategorized/libuv-status-report.md @@ -0,0 +1,45 @@ +title: libuv status report +author: ryandahl +date: Fri Sep 23 2011 12:45:50 GMT-0700 (PDT) +status: publish +category: Uncategorized +slug: libuv-status-report + +We announced back in July that with Microsoft's support Joyent would be porting Node to Windows. This effort is ongoing but I thought it would be nice to make a status report post about the new platform library libuv which has resulted from porting Node to Windows. + +libuv's purpose is to abstract platform-dependent code in Node into one place where it can be tested for correctness and performance before bindings to V8 are added. Since Node is totally non-blocking, libuv turns out to be a rather useful library itself: a BSD-licensed, minimal, high-performance, cross-platform networking library. + +We attempt to not reinvent the wheel where possible. The entire Unix backend sits heavily on Marc Lehmann's beautiful libraries libev and libeio. For DNS we integrated with Daniel Stenberg's C-Ares. For cross-platform build-system support we're relying on Chrome's GYP meta-build system. + +The current implmented features are: + +The features we are working on still are + +For complete documentation see the header file: include/uv.h. There are a number of tests in the test directory which demonstrate the API. + +libuv supports Microsoft Windows operating systems since Windows XP SP2. It can be built with either Visual Studio or MinGW. Solaris 121 and later using GCC toolchain. Linux 2.6 or better using the GCC toolchain. Macinotsh Darwin using the GCC or XCode toolchain. It is known to work on the BSDs but we do not check the build regularly. + +In addition to Node v0.5, a number of projects have begun to use libuv: + +We hope to see more people contributing and using libuv in the future! diff --git a/doc/blog/Uncategorized/node-meetup-this-thursday.md b/doc/blog/Uncategorized/node-meetup-this-thursday.md new file mode 100644 index 00000000000..0dfb98dae50 --- /dev/null +++ b/doc/blog/Uncategorized/node-meetup-this-thursday.md @@ -0,0 +1,11 @@ +title: Node Meetup this Thursday +author: ryandahl +date: Tue Aug 02 2011 21:37:02 GMT-0700 (PDT) +status: publish +category: Uncategorized +slug: node-meetup-this-thursday + +http://nodejs.org/meetup/ +http://nodemeetup.eventbrite.com/ + +Three companies will describe their distributed Node applications. Sign up soon, space is limited! diff --git a/doc/blog/Uncategorized/node-office-hours-cut-short.md b/doc/blog/Uncategorized/node-office-hours-cut-short.md new file mode 100644 index 00000000000..48d0344057a --- /dev/null +++ b/doc/blog/Uncategorized/node-office-hours-cut-short.md @@ -0,0 +1,12 @@ +title: Node Office Hours Cut Short +author: ryandahl +date: Thu Apr 28 2011 09:04:35 GMT-0700 (PDT) +status: publish +category: Uncategorized +slug: node-office-hours-cut-short + +This week office hours are only from 4pm to 6pm. Isaac will be in the Joyent office in SF - everyone else is out of town. Sign up at http://nodeworkup.eventbrite.com/ if you would like to come. + +The week after, Thursday May 5th, we will all be at NodeConf in Portland. + +Normal office hours resume Thursday May 12th. diff --git a/doc/blog/Uncategorized/office-hours.md b/doc/blog/Uncategorized/office-hours.md new file mode 100644 index 00000000000..e4c94992ce7 --- /dev/null +++ b/doc/blog/Uncategorized/office-hours.md @@ -0,0 +1,12 @@ +title: Office Hours +author: ryandahl +date: Wed Mar 23 2011 21:42:47 GMT-0700 (PDT) +status: publish +category: Uncategorized +slug: office-hours + +Starting next Thursday Isaac, Tom, and I will be holding weekly office hours at Joyent HQ in San Francisco. Office hours are meant to be subdued working time - there are no talks and no alcohol. Bring your bugs or just come and hack with us. + +Our building requires that everyone attending be on a list so you must sign up at Event Brite. + +We start at 4p and end promptly at 8p. diff --git a/doc/blog/Uncategorized/porting-node-to-windows-with-microsoft%e2%80%99s-help.md b/doc/blog/Uncategorized/porting-node-to-windows-with-microsoft%e2%80%99s-help.md new file mode 100644 index 00000000000..d2be3e3ba2a --- /dev/null +++ b/doc/blog/Uncategorized/porting-node-to-windows-with-microsoft%e2%80%99s-help.md @@ -0,0 +1,12 @@ +title: Porting Node to Windows With Microsoft’s Help +author: ryandahl +date: Thu Jun 23 2011 15:22:58 GMT-0700 (PDT) +status: publish +category: Uncategorized +slug: porting-node-to-windows-with-microsoft%e2%80%99s-help + +I'm pleased to announce that Microsoft is partnering with Joyent in formally contributing resources towards porting Node to Windows. As you may have heard in a talk we gave earlier this year, we have started the undertaking of a native port to Windows - targeting the high-performance IOCP API. + +This requires a rather large modification of the core structure, and we're very happy to have official guidance and engineering resources from Microsoft. Rackspace is also contributing Bert Belder's time to this undertaking. + +The result will be an official binary node.exe releases on nodejs.org, which will work on Windows Azure and other Windows versions as far back as Server 2003. diff --git a/doc/blog/Uncategorized/profiling-node-js.md b/doc/blog/Uncategorized/profiling-node-js.md new file mode 100644 index 00000000000..ff259c3c42c --- /dev/null +++ b/doc/blog/Uncategorized/profiling-node-js.md @@ -0,0 +1,60 @@ +title: Profiling Node.js +author: Dave Pacheco +date: Wed Apr 25 2012 13:48:58 GMT-0700 (PDT) +status: publish +category: Uncategorized +slug: profiling-node-js + +It's incredibly easy to visualize where your Node program spends its time using DTrace and node-stackvis (a Node port of Brendan Gregg's FlameGraph tool): + +
    +
  1. Run your Node.js program as usual.
    2. +
  2. In another terminal, run: + 
    +$ dtrace -o stacks.out -n 'profile-97/execname == "node" && arg1/{
+    @[jstack(100, 8000)] = count(); } tick-60s { exit(0); }'
    + This will sample about 100 times per second for 60 seconds and emit results to stacks.out. Note that this will sample all running programs called "node". If you want a specific process, replace execname == "node" with pid == 12345 (the process id). +
    3. +
  3. Use the "stackvis" tool to transform this directly into a flame graph. First, install it: + 
    $ npm install -g stackvis
    + then use stackvis to convert the DTrace output to a flamegraph: + 
    $ stackvis dtrace flamegraph-svg < stacks.out > stacks.svg
    +
    4. +
  4. Open stacks.svg in your favorite browser.
    5. +
+ +You'll be looking at something like this: + + + +This is a visualization of all of the profiled call stacks. This example is from the "hello world" HTTP server on the Node.js home page under load. Start at the bottom, where you have "main", which is present in most Node stacks because Node spends most on-CPU time in the main thread. Above each row, you have the functions called by the frame beneath it. As you move up, you'll see actual JavaScript function names. The boxes in each row are not in chronological order, but their width indicates how much time was spent there. When you hover over each box, you can see exactly what percentage of time is spent in each function. This lets you see at a glance where your program spends its time. + +That's the summary. There are a few prerequisites: + + + +There are a few other notes: + + + +For more on the underlying pieces, see my previous post on Node.js profiling and Brendan's post on Flame Graphs. + +
+ +Dave Pacheco blogs at dtrace.org diff --git a/doc/blog/Uncategorized/some-new-node-projects.md b/doc/blog/Uncategorized/some-new-node-projects.md new file mode 100644 index 00000000000..77515af7364 --- /dev/null +++ b/doc/blog/Uncategorized/some-new-node-projects.md @@ -0,0 +1,13 @@ +title: Some New Node Projects +author: ryandahl +date: Mon Aug 29 2011 08:30:41 GMT-0700 (PDT) +status: publish +category: Uncategorized +slug: some-new-node-projects + +