Whenever there is bad press about Node.js it is about performance issues it's about performance issues in production systems.
I am currently researching ways to instrument Node.js to get proper memory and CPU metrics that may help to detect bottlenecks in applications.

In this workshop we'll briefly go over some top performance problems and use an example project to apply instrumentation to it. Then we'll try to do somethings useful with the huge amount of data we get ... like creating cool sunburst charts using d3.

We're still setting up lines of communication, but you can watch this issue to get info about next year's NodeConf when it becomes available.

We should update the CoC. I'm pretty sure it's years old, and the tl;dr is a big red flag at this point.

Here's the current CoC: http://nodeconf.com/code-of-conduct.html

Here's the Node CoC: https://github.com/nodejs/node/blob/master/CODE_OF_CONDUCT.md - it's not really designed for a conference so can't be used as-is. I'd normally be concerned about the "anti-profanity" thing but with so many small children about maybe that's not so bad.

And here's the Alterconf CoC, which is probably about as close to the state of the art on these things that you can get: http://www.alterconf.com/code-of-conduct#coc

We have the pond from 2pm-5pm Thursday, Friday and Saturday.

If someone lets me know what they'd like to do naturalist hikes for the kids and significant others let me know.

We need someone to lead the sponsorship outreach team.

We're going to need to update the sponsorship page on the website with more levels and updated info http://nodeconf.com/sponsors.html

We should be open to having a bunch of sponsors, but we don't want to give up control of the event, and we won't have any talks they can take over. But if someone like Tessel wanted to throw a workshop, that would be pretty cool.

I think @dshaw expressed interest in helping out with this sort of thing.

Coding workshop on new ES6 features in io.js: https://iojs.org/en/es6.html

I'm not entirely sure who is coming, but I figure there might be a bunch of us there and if people are interested / willing we could do some sort of panel / tsc meeting / etc.

It has also been suggested to me that it would be really cool if people from the TSC could do a panel like Confessions of a jQuery Committer (i.e. How did we become TSC members / core people). I don't feel like any of this requires lots of prep, so...

cc @chrisdickinson / @mikeal Any idea who else from the TSC might be coming? Unfortunately I can't mention the group from here.

What you need for 0.10 streams - highWaterMark

Mafintosh's Stream Modules To Fix Node.js Streams

• pump - https://www.npmjs.com/package/pump
• Duplexify - https://www.npmjs.com/package/duplexify
• end-of-stream - https://www.npmjs.com/package/end-of-stream
• pumpify - https://www.npmjs.com/package/pumpify

There was some talk of getting involved with GatherScript (I think that was the name) for handling the financial stuff. Anyone know how to contact them, or have different ideas?

notes

bootstrapping
- how to install node
- run tuts w/o installing, e.g. docker (download app / hosted online?)

new workshoppers
- workshop workshopper?
- css
- unix tools
    - terminal intro (ls, touch, cd)
    - bash
- regex
- synthesis (dont care about DBs, want to make a thing)
    - e.g. make a video game, make a blog
    - could be made from a couple workshops
    - look at this neat thing, I want to try to make it

etc
- workshop roulette
- hacking websites people already use? (e.g. css in tumblr, favorite all posts in twitter)
- how to balance removing complexity and not using a real dev environment

For the last several months, me and my team at Nilas have been working on an email client built on top of Atom Shell. Atom Shell is a project from Github that bundles io.js and Chromium. It allows you to deliver cross-platform desktop applications written entirely in Javascript, with native menus, windows, integration with notification center, etc.

We've really enjoyed using it, and I think it'd be great to walk folks through the basics of creating a new Atom Shell app, opening windows and creating a quick UI with React.

Atom Shell is also being used for Slack's Windows app, Mapbox Studio, Github's Atom text editor, and more!

If enough other folks are using Atom Shell (or NW.js), we could also turn this into a discussion.

I am currently researching ways to measure performance and detect bottlenecks in Node.js applications.

Although I've already accomplished to create simple realtime metrics using V8 profiler I am still not sure which measures are really providing value to developers and operation folks.
E.g. what do event loop timings really tell us (and is my way of measuring them valid)?

I will briefly share what I found out and I am hoping for an open discussion about which metrics are desirable, how to measure them and what could be added in future versions of Node.js.
I would also be happy to hear the voice of some core developers on this.

We need someone to head up the volunteer team.

Pre-conference: handling stuff like acquiring awesome non-alcoholic beverages and renting the van.

During the conference: keeping people organized, answering questions, packing and unpacking stuff, fire safety.

Are there any constraints around next year's date? Things we don't want to conflict with: Maker Faire, Burning Man.

The second weekend of June is the 8th through the 12th next year.

We don't have any talks to curate, but we need folks to organize the nodeschool workshops.

I might remember @maxogden saying he wanted to help in some capacity with that?

cc/ @Fishrock123 @Trott @Qard @whyisjake @julianduque @dshaw @bryan-m-hughes @chrisdickinson @devinivy @dtex

Pulled out the action items:

• Add explicit call to action at the top of the main io.js repo for "get involved!"
• Make a quick start/start here section in the contribution guide: basic notes, link to "good for newbies" issue label, tell you to sign up for a mentor (and how to do this)
• Accessible communication channels. I think this ended up as: get Slack, hook up automatic cross-posting for IRC and/or Gitter if that's appropriate
• Review contributing documentation & fix so there's not as much assumed knowledge. (This would be a great place to bring in people from the diversity discussion & have them help identify barriers to entry)
• Set up mentoring/make it better. See the notes, there was a lot of discussion here.

Full notes:

• Contributing.md - add explicit call to action at the top "Get involved!"
• Contributors guide is verbose, hard to get started with. Can there be a "start here" section with just the basics, try a bug from the newbies label, here's where to get help
• IRC/Gitter/Slack? IRC hard to get into, Gitter not great either. Connect IRC to slack – ask github.com/tcr
• Wordpress has a good manual/book
• Documentation should not have as much assumed knowledge
• Find Slack channels associated with the topic you want to contribute to
• This is the barrier to entry – foster communication with the Diversity discussion to improve the onboarding process accordingly
• Mentors assigned to newbies – would you want one, would you volunteer for it?
  • Yes, would do it for someone else
    • but would I be valuable? Core people would be more useful.
      • Does that mean you're just not onboarded enough?
      • Mentorship useful even if you just know who to tell them to talk to
    • Rockstars are great & friendly people & people are still intimidating
  • Mentor would learn a lot by mentoring
  • Doesn't have to be centrally blessed; rogue mentoring is cool, might not get everyone
  • The more we have mentoring, the better our bus factor – spread the knowledge
  • It's already documented who owns parts of the system, but you might not know what you don't know and that's what a mentor is for - get you some context
  • The act of setting up as a mentor means you are likely to improve the quality of information sharing we do overall.
  • Could have just read the onboarding docs in person, but wouldn't have learned nearly as much as sitting down with the mentor
  • Implementation needs thought: how do you get a mentor?
    • "Ask if you have questions" isn't good enough. Feels like asking a favor, intimidating. Mentor instead needs to schedule a 1:1 in the future "we'll talk, and see if I can help you with anything"
  • Precedent for mentorship with Hapi - talk to Eran Hammer
    • You could be a mentor + a mentee simultaneously in that program based on your different areas of expertise – topic-based mentorship
      • Inter-working group communication is currently not good, this could help
• Useful to have multiple formats. Video work for some, not others
  • Jeremiah has some plans for this

In past nodeconfs we drank through almost all the cases of beer. One option we could explore is getting kegs of beer. We could potentially have our beer catered by a brewery. Lagunitas is down the road and has an event contact form.

However we would need to check with Walter Creek Ranch if they allow kegs and if they allow outside catering of alcohol.

Let's hack on NodeBots. Enough of us are here with enough hardware that we can throw something together.

The website claims that Nodeconf is a 3-day event. I guess that's kind of true, since there are some activities on Friday, but nothing except food and leaving on Sunday. Still, it seems counterintuitive at least to say the event is 3 days and is July 6-9 (a 4-day span). Any thoughts?

We were hoping to make Nodeschool a significant presence at NodeConf Adventure 2017, so it would be great if we could find a co-organizer for the unconf who has some experience running Nodeschool events. @maxogden might have some thoughts on who we should ask, particularly someone from an underrepresented group?

Proposal

I propose we have a discussion on steps and best practices everyone is using to make it easier for devs to install and use our modules that use native libraries, and what we can do to make the process better.

node-ffi an node-pre-gyp are two mechanisms that I am aware of that make it easier to use native libraries, but, as with all software, they each have their pros and cons.

What solutions are other people using? What has worked best for you? Let's swap stories and brainstorm ways to make it even easier!

Background

In the Node.js Hardware Working Group, we have been discussing all of the pain points for developers using Johnny-Five and similar NodeBots platforms.

We have identified our reliance on native modules as the biggest barrier to entry currently, and are focusing our efforts around making the installation process easier.

Ideally we would use node-pre-gyp to ship pre-compiled binaries down for everything, which we currently attempt to do, but this has grown problematic as the support matrix has ballooned recently, especially given that we are, by definition, supporting more esoteric platforms. See serialport/node-serialport#519 for brief discussion on the support matrix issue.

I'd like to see Node's documentation get better. While we currently have fairly complete and well-written API reference docs, we're missing a lot of other docs: tutorials, topic guides, internal documentation, navigation, policies, etc. One clear sign that things could be better is that we're running out of places to put this info – some of it's going into project wikis, some of it is being shoved into ALLCAPS.md files at project root. Often the topics these docs touch on cross over – CONTRIBUTING.md + COLLABORATORS.md comes to mind! We need good docs, and the first step in that is having a good structure – one that can address our information storage needs for the future.

I've been a part of several documentation efforts over the years – there's a lot of enthusiasm for writing good documentation, but that enthusiasm is often hard to direct. I'd like to propose some specific goals for this meeting:

1. At the end of the meeting, we should have a proposed documentation structure. This will be in the form of directories (with assumed index landing pages.)
2. We should agree on a brief set of editorial standards to hold new documentation to for all new docs.

We want to have just enough agreement on direction that we can get ourselves out of the way and let everyone pitch in. If we reach these goals, we can propose the new structure on the Node issue tracker, and start dividing up the work of creating this documentation at that point.

Before the meeting:

• Please have read @jacobian's excellent series of posts on technical documentation and editing.
• Post on this issue any topics that you would like to have documented – ones that you feel are missing!
• Also suggest other talks/posts you'd like everyone to review before meeting up.
• Other talks and posts might be added to this list before the conf – check back in!

/cc @Qard @Fishrock123 @mikeal

hiring/training

Beginners tutorial how to build a very simple application using io.js, hapi, handlebars, bootstrap, and mongoose

Hello! 😸

Me and a friend @wanderer are working with a project called Ethereum.
Ethereum is based on bitcoin technology, but adds a turing complete language on top, turning the blockchain into a simple VM.
Ethereum is being implemented in a few different languages and @wanderer is writing the node client.
I am writing a front-end via browserify.

We're curious if we could talk about our work at nodeconf adventure. I think the project is an example of some of the audacious things you can do that people don't expect from javascript.

So lets address the primary reason one might say no: we don't want peeps coming in and just advertising their startup. fair enough. for full disclosure, here's some relevant facts, for and against:

• @wanderer is paid by the ethereum org to work on ethereum
• I work with ethereum independently
• we both have some financial investment in ethereum and stand to benefit from its adoption
• the Ethereum Foundation is a non-profit organization ( https://ethereum.org/foundation )
• ethereum is a crypto-asset that has not yet launched so we must assume its a scamcoin™
• this will be my third year at node-conf!

Let us know what you think. If a focus on a single project with financial contexts doesn't seem appropriate, we could additionally cover a few things (crypto, bitcoin, ipfs).

This could be a talk or a workshopper, though I would lean towards a talk. A workshopper could be successful depending on internet connectivity, as its a decentralized network.

I have had quite some discussions recently if and how JavaScript would benefit from a static type system and what would be the downsides. Based on TypeScript as the de-facto type system I would like to discuss the pros and cons.

How about a Workshop on Hapijs Firebase ReactJS.

I've heard a few people wrestling w/ Docker and all this fun DevOps type stuff, and I've heard a couple people who sounded fit to run such a workshop (not me, just throwing it up here for discussion).

Let's all build some completely zany peer to peer experiments.

It might also be helpful to jot out what currently exists and what needs to exist on a whiteboard.

Ask questions! There will be a lot of us here just hacking. If you want tips on how to build a distributed system, we can set you up with some quality npm packages.

• Include a Contributing.md file
  • action: create a template
  • PR: update create-module to include a Contributing.md scaffolding
• Standard as example of useful utility
  • Module by Feross that encapsulated linting and made it easier to include in tooling
• Coding style
  • Explicit style guide helps improve participation by removing
• Coverage tools
      - Istanbul
      - NYC
      - Lab
      - Coveralls
• Changelog
      - github-changes
      - collaborator (Facilitates "Open Open Source")
      - pullmetender
• SLAs for project maintainers
      - hapijs/contrib
• Versioning
      - semver
      - Angular commit log conventions
      - semantic-release
• Definition of done
      - Tests
      - Documentation
      - Should not fail
• Documentation
      - documentation module
      - Value internal
• Value examples in modules
      - Active users that understand the module, the more likely to become contributors
• Issues
      - "help wanted" is supposed to elevated to a feature inside of github
      - Suggestions from others that you don't have to do
      - Invite new contributors in contributor.md to submit an issue before writing code
• Folks are scared to put code out on open source
      - Disable issues is an option
      - Let folks know that it's experimental or not available
      - Publishing does not automatically mean that it's being looked at
      - Tip: Text can be interpreted as negative. Use emoji!
• node-modules.com
      - CLI node-modules
      - star your own modules
      - Write good npm description
      - npm search
• Outcome: module web ring [max]

The website could probably use an update. Some of the style looks a little wonky, and it flashes when the page loads.

Both io.js and Node core have a desire for deeper insight into how core APIs are being used across the ecosystem. Given that, I set out to build a tool to answer some questions:

1. What external APIs does a given package use?
2. How does it use those APIs?
   1. What types are sent?
   2. How are return values used?
   3. Are calls wrapped in try/catch blocks?

The result of that work is a package called estoc. It uses a stack machine + spies to statically analyze individual packages. As a package, it exposes a readable stream of "Usage" data, where that usage (currently) contains:

1. Type of usage (load: x, lookup, x.y, and call x()).
2. Path of usage (x = require('url'); x.y.z yields a path like so ['url (as x)', 'y', 'z'])
   1. return value segments will contain <return value (from $funcname $filename:$line)>
   2. "inversion of control" segments will contain <ioc-arg #$argpos>
3. args, if a call.
4. exception destination, if any

estoc evaluates full packages – it accepts directories or gzipped tarballs as arguments. It can successfully analyze the contents of my local npm cache. An average package takes about 500-600ms to analyze. I'm at a point now where I need input from others on how to make this as useful as possible, and especially from folks involved with npm to see if there are any high-value ways of exposing this to the community.

Here is the result of running estoc against request 2.53.0. Of note: these lines are being generated by these calls to this function.

Tickets are on sale for NodeConf Adventure 2018! July 20-22 at Walker Creek Ranch

http://nodeconf.com/

We need someone to lead up the diversity/inclusion/outreach team.

We need to update the CoC (#26)

Some useful blog posts:

• http://www.ashedryden.com/blog/increasing-diversity-at-your-conference
• http://www.ashedryden.com/blog/so-you-want-to-put-on-a-diverse-inclusive-conference

Not sure how much we can afford to spend on this, but eventually we'll want to manage some diversity scholarships, and maybe give some to bootcamps like Hackbright.