With the gracious support from Microsoft Windows Azure, Matt Podwysocki and I (Chris Williams) were able to create a great little “Intro to NodeCopter” lounge event over the two days of CascadiaJS. Set up just outside the main room of the event, we had two Parrot ARDrones available for individuals to run through some test flights. In total we were able to allow almost 45 people fly the drones over the course of the two days with almost everyone in attendance at least stopping by to see what was going on. We had several individuals sit down and start to dabble with the available hardware to extend or start new projects with the NodeCopters.

One of the more successful projects during the conference was to start the evolution of the previously built wii-drone from an arduino microcontroller system over to a more encapsulating Raspberry Pi based system. Another project that garnered a lot of interest, but is still in process was Rick Waldron’s efforts to get the Johnny-Five and node-serialport libraries to operate with the Arduino Leonardo boards. While not strictly a traditional NodeCopter event, the lounge provided a great place to discuss interesting and novel ways of using JavaScript to interact with the real world.

In summary, we are happy to report that the event overall was a huge success with many individuals primed and ready for their first, full-fledged NodeCopter event. The lounge style provided a nice, “walk-up”, and low-commitment variation of the NodeCopter event and afforded some amazing conversations in the process.

More pictures available from Matthew Bergman (link) and the CascadiaJS SkyDrive

Once again, a HUGE THANK YOU for supporting us to

• PhoneGap
• Cappuccino
• Node.js
• Appcelerator
• Yahoo! Mojito
• WaterBear
• Sashimi
• Gordon
• PDF.js
• Cloud9
• Firefox OS
• YepNope
• Fab
• Google Traceur
• Three.js Editor
• Jed Schmidt

The list continues further and makes all of us that help put JSConf on grin from ear to ear. Our aggressive self-dedication to spotlighting the next generation of ideas has been something fundamental to everything we do. It is specifically for this reason that we are going to break our golden rule.

Homecoming

Given that the theme of this year’s JSConf US is “5th Year Family Reunion”, we want to try out a different format for speaker selection. We are splitting JSConf US 2013 into two main speaking days split by a day of small group activities (more on that later). The first day will play host to presentations by community selected alumni JSConf US speakers. We have opened up voting for you to specify your preference on which of the alumni speakers from 2009 - 2012 should be invited back to speak again on the JSConf stage. The voting will remain open until Friday, November 30th at 12:00PM EST in order to allow time for everyone to participate. During the following week, we will tabulate the votes and send out invitations to the lucky alumni speakers.

A Blended Approach

We still want to retain the our traditional speaker selection process, continuing our trend of spotlighting new ideas. As such, we have opened up a more traditional Call for Speakers form that will remain open until Friday, November 30th at 12:00PM EST. As we have always done, we are seeking out new ideas and concepts that push the boundaries of JS and the JS community. We welcome strange and unusual presentations as long as they remain within the boundaries of our well established Code of Conduct. We are looking for talks focused on all parts of JS, including but not limited to:

• Data Management
• Web Security
• MVC Frameworks
• Server Side JS
• Compile to JS Languages/JSVM
• Mobile Web
• Future of JS
• Education and Outreach of Computer Programming

Last year we tried a new approach, what we called an “inverse call for speakers”. We are going to do that this year along with a traditional call for speakers. If you want to nominate a person and idea that you would like to see, you can submit that as well with the form above. If you are are the person submitting yourself, which is completely cool and encouraged, please mark your submission as “this is me”, so we can write you back if your submission is or is not accepted.

As we have done from the very start of JSConf, we cover full transportation costs (within reason, no first class all the way, unfortunately), admission to JSConf, and all of your lodging costs. We do this so you can provide an amazing presentation with a relaxed and refreshed outlook and attitude. There is zero risk in submitting yourself and people you admire to speak, so go ahead and throw in!

Training Included

We understand that people attend JSConf for a wide variety of reasons, whether it is to build deep relationships, be part of the next generation of JS, or to learn JS and all it has to offer. Historically, we have, admittedly, not focused on that last item and this has caused confusion and frustration with some attendees that arrive with a different expectation. This is probably the single biggest modification we are doing as part of JSConf US 2013. Training will be provided as an isolated, parallel track. Trainings will be provided for free in 1 or 2 hour blocks (allocation based on topic complexity) that align against the main track’s schedule. We will try to schedule this track as carefully as possible to avoid the “I want to be in two tracks at the same time” problem, but unfortunately that might happen. We are seeking individuals and/or organizations with a proven track record of providing best-of-breed training to conduct these segments. If you are ready to help educate JS developers at JSConf, please email us at training@jsconf.us.

Over the years that have followed, we have pushed the boundaries of what a conference should and could be. We always remained focused on presenting the conference as a personal expression of what we would want to share with our attendees. We selected cities where we had some of our most memorable experiences. We selected social activities that highlighted some of our favorite or most amazing nights, the kind that unless you had led our life you might never have had the opportunity to experience. 

Each year we would put in tireless nights, many heated discussions, and toiled over otherwise mundane details on ways we could share something even more amazing with you. We mention regularly that JSConf is an experiment and we deeply mean this, we have tried our best to never rest on our laurels and test out new possibilities, new ways of creating an event, and new concepts. 

We have always retained some core concepts, the most fundamental of which was to always focus on the human social development aspect of the event. The secondary was to always indulge every attendee well beyond that which they have paid. The third was to always treat attendees, staff, sponsors, and speakers with the utmost of respect and appreciation. These things make a huge difference in how the event runs, obviously, but also about how the experience evolves. Every event has always resulted in attendees, speakers, and sponsors coming up and showing a huge amount of appreciation for our efforts. What is even more striking is that venue staff and vendors we work with even go so far as to make it abundantly known that our group is one of the most kind, considerate, and easy to work with out there. We try to be humble, but this is one of our most proud acheivements in curating JSConf. It makes us even more proud that this respectful curation spirit has carried on in the events that have spawned from JSConf.

So after all of the years and the more than double-digit number of events we have been a part of organizing, we have learned a tremendous amount and have experienced a lifetime’s (or more) worth of joy and frustration in executing these events. At the end of this year’s JSConf US 2012, something happened that rocked our world and our immediate reaction was that all of the effort, complexity, and stress on our growing family wasn’t worth it. The determinal effects of negativity that are not only common, but rampant on the Internet had pretty much put an end to our desire to create anything further for the JS or any other technical community. 

You see, running these conferences isn’t our job, we each run our own successful business as our primary jobs. Also these conferences, while sometimes feeling like our baby, aren’t in fact our baby, we have one that is constantly growing into a wonderful engineer despite being only 2. Over time, we came to terms with what happened in different ways. At first, the terms were to take JSConf down the same path, but even bigger and bolder. We had a grand plan of hosting a JSConf in New York City and going full tilt, nothing held back, making a spectacle using the same core principles that had drawn so much focus over the last 4 years. Then something happened, we found out that we were having another child due right around the normal time we hold JSConf US. 

This changed something in both of us. For Chris it made him realize that the reason JSConf was such a target was its own success and also that the conference model we had helped established had taken root and become widely spread. If you look out at the conference landscape, the number of JS events that are inspired by or simply utilize the JSConf model is astounding, something we had never stepped back and looked at. An unforeseen result of giving everything away and helping others is that things start looking like your event, this is not necessarily a bad thing - just an observation. When we started JSConf, the landscape was tremendously different. We, a conference with a high focus on human social, were a rare breed. The only other conference we know of that did anything close was our inspiration, RubyFringe. There obviously have to be others, but to our knowledge and experience at that time it was a relatively short list. This started our wheels turning and we started thinking of a different concept for what a technical conference could be. Something different that would appeal to and include all interests and preferences. Something that would resolve some of the lingering issues we experience with our own events. A different event that would cure the last remaining complaints about JSConf, something that both took advantage of all the wonderful things we now know AND yet establishes something completely different. A fresh restart.

When looking for venues, we looked to keep the date close to previous years in order to maintain consistency and distance from other JSConf around the world. Since we were having the baby also during that time, it meant we had to do something back in the Washington DC area in order to reduce stress on our family. Unfortunately, all of the venues of size for a current JSConf in the DC area meant we would have to have a hotel room rate of in excess of $300 OR be within 3 weeks of the planned birth of our new baby. Neither of which was an acceptable solution for the event or us. As a chance, we requested a bid from the wonderful resort that Laura’s family spends Christmas and we occassionally spend our summer vacation at, Amelia Island, Florida. To our surprise, they were able to accomodate us at a room rate of $199/night for beach front hotel rooms AND host our event a full 3 months after the planned birth of our child AND provide enough space to pull of our new concept. Impossibly, we had found something that worked for our multivariable equation of a new conference model, while affording our family the space it requires.

We wanted to share all of this, because it is easy to forget when attending a conference that real people with real feelings and real families and friends are running these events. They are doing their hardest to produce something for the community out of good will. Technical conferences are not community events, they are events put on FOR the community by a handful of individuals at their own personal risk. If tickets don’t sell, as happened our first year, they have to put up the house (if they have one), their car (if they have one), and their savings (if they have any) as collateral to make this happen. At best, conferences are an individual or a group of individuals perspective on what they believe would be appreciated by the community at their own personal risk. 

As for what JSConf US 2013 will look like, stay tuned. This year, we are trying to share more about the process we go through in order to make JSConf happen. We hope this helps others in creating different events and allows those of you who don’t run events to see just what it takes to run an event. We are tremendously excited about our new concept for a conference and are pretty sure you will be just as excited as we roll out details. 

It was actually during this time that the JSConf EU team was soliciting topics for presentation and one from Nikolai Onken and Jörn Zaefferer of Uxebu popped up about Robotic JavaScript. In the proposal, they pitched that the thesis of their talk would be creating a world in which controlling devices could be as simple as:

$("livingroom").bind("motion", function() {
  $(this).find("lights").brightness("75%").dimAfter("120s");
});

Now, that struck a (good) nerve for me.

By modeling real world objects and actions as chainable, evented processes felt almost natural. For my specific use case, I was using the serial port as a response handler, the perfect example of this is “When the front door opens, toggle all lights”. The close similarity to jQuery had the added benefit that as we increased in size, we wouldn’t need a hardcore programmer that understood serial ports AND Python, but just JavaScript and a rough comprehension of jQuery. I felt like there was something worthwhile here and so I sat down to code.

While programming the first revision of node-serialport I realized a couple amazing things that I wanted to share. I see the same questions every single time someone posts a new project using node-serialport to the world and I would like to provide my perspective of the answers. I prefer to use node.js for programming arduinos, wireless stacks, printers, toasters, etc. (anything through the serial port), for some very definitive reasons the most direct reason is simplicity. The node module system and the very thin native bindings allows me to develop new low level functionality very swiftly without having to involve too much node specific code segments. This also affords me, the library maintainer, the ability to leverage the larger world of knowledge about how to program, debug, and test serial ports directly and not have to spend days working on getting it to work with node.js. The layer to connect straight C++ code with node.js is so thin, it is nearly trivial to implement (and implement properly) which is why I fell in love with it. I know people have a similar love (or strong hate) for Python and Ruby’s native binding, but, personally, am of the opinion that the syntax similarities between C and JavaScript make it a lot smoother of a process for mentally visualize the binding despite spanning two languages. If you look at the low level C++ of node-serialport you can probably fully understand it even if you have only ever programmed JavaScript. That can both be powerful and wrought for confusion, admittedly, but for me it just clicked and made writing the low level serial port code an absolute joy. Your mileage may vary, but at least it is worth investigating.

Once the low level code was written, one of the main reasons I have continued to develop on top of node.js for my serial port needs is that desire to programmatically describe my problem domain in a manner that fits it. As mentioned, my system, and most systems using node-serialport (arduino, etc), are inherently reactionary in that they wait for some event or data and then do some thing. This is arguably JavaScript’s bread and butter, it is how most people are trained already to think when they think in node and JavaScript. Can this be done in other languages, sure, but the simplicity of the implementation all the way up from the low-level C++ to the interfacing code to even the event handling makes for something very capable and very understandable with little effort. In the recent comments about the awesome node.js wifi-extending robot, an individual asked why not clojure or scala or python or ruby and my most direct answer is that the volume of code to create the reactionary system (including eventmachine/twisted/redis/pubsub/etc) quick grows beyond simple hobbyist experimentation. And lets be completely honest here, at least for now - arduino, x10, raspberry pi, etc are all at best in the hobbyist domain especially under the context of “software developers playing with hardware”. I would actually apply the theory of increasing developer happiness from Ruby as the reason to use node.js for building robot PROTOTYPES. It is lightweight, simple, and easy to make complex reactionary systems with little effort. Best of all it is JavaScript, so you have no risk of falling madly in love with your initial prototype and will eventually rewrite in something ‘more production-worthy’. Or not.

As an example of how lightweight node.js hardware development can be, I would offer up the amazing work done by Rick Waldron in Johnny-Five, take a look at the source code for processing events from an acceleromator it is easily readable, understandable and just over 10 lines of code. Controlling a servo, also just over 10 lines of code and just as readable and comprehensible. With node-serialport and firmata (which kicks butt, props to Julian Guatier) the physical world is an oyster for JS developers, if you don’t believe, three of the best presentations at NodeConf 2012 were ones using node.js to control physical devices. Also review his slides.

When I look at all the people working with node-serialport, the one thing I see across the board is that the “ease” of programming JavaScript, the evented model, and how real world devices exist and operate – all of that seems to blend nicely. Another fine example is the tmpad, a DIY MIDI pad from Elijah Insua. The source code is make a midi pad is almost nothing and that is a good thing. Elijah was able to create somethign amazing with little effort, which is why I believe we are on the cusp of the broader adoption of JS as a leading language for building and controlling hobbyist hardware systems.

I say this because every day I hear more people making newer, brighter, more robotic things with node-serialport. I recently came across BreakoutJS which is nobly attempting to make it even easier to interoperate with sensors and devices. This makes me happy and it should make you happy as well, if just to witness the energy and excitement. For me, the hobbyist hardware domain is more real than programming code, it is crossing of the boundary from abstract to real-life and has a massive potential to do a lot of good for a lot of people. Should it eventually be coupled with a strong AI system like a Clojure? Absolutely, but for now, play and experimentation are the key. If you must demand starting with a lisp, then just use ClojureScript and viola, best of both worlds!

An Announcement

One of the things that has been lacking from node-serialport was support for Windows. I recently found that Joe Ferner was working on a fork that would (among other things) add Windows support. In the full beauty of social, open source development, we synced up and are happy to present for your cross-platform robot creation plans of world domination:

node-serialport 1.0.0

We have tried to maintain the same API as the original node-serialport system, but add a couple of other accessible items. We have vetted this version with people that we had email addresses of and knew were building on top of node-serialport, if you were building something and run into an issue with this new version, please register a ticket. We will try to resolve it as quickly as possible. We are quite excited about this release and happy to say that after almost 2 years of watching the JS robotics community grow, I can officially say: “Welcome your robotic javascript overlords. Better yet, program them (even on Windows)!”

If you want to talk about things you are doing with node-serialport, arduino, anything robotics and beyond, please come join us in IRC on the freenode channel #robotjs.

npm i serialport

Happy Hacking,

@voodootikigod

Oh, and get off the Internet and go change the world!

And so the Regional JS Speaker Directory was born.

Initially this is targeting local JS meetup groups, but could very easily be used to help curate amazing local content for various regional JS conferences. For now, we are just gathering details about speakers, but we will be curating that list and providing them to regionally based meetup organizers as part of JSConf US 2012. This will hopefully get people talking with one another and allowing all these amazing talks happen across the USA and eventually the world. This is a pretty exciting initiative for us and for the JS community so anything you can do to help us would be greatly appreciated. At the very least, be sure to sign yourself up!

When I first saw that GitHub was producing their own conference series, I was quite stoked. GitHub has easily become a great asset for conference organizers both in terms of advertising visibility and their willingness to sponsor conferences of every ilk in almost every programming language. They support the community at a deep level both in their drive to turn coding into a social activity (through various GitHub meetups) and their funding of people with crazy ideas (aka conference organizers). I have always thought highly of the team at GitHub and so when I heard they were entering the conference space, I will admit I was both giddy and concerned.

The concern comes from the obvious overlap between the CodeConf events and JSConf events in terms of nature, style, and love of community. They are willing to showcase some arguably risky presentations and provide the critical social event backbone that makes conferences a success. In crafting JSConf, Laura and I stumbled into a lot of the decisions that made the conference what it became - CodeConf evolved from GitHub’s experience both as attendees, sponsors, and speakers at various events of all types. It is because of this that I actually turned my concern into a desire to help CodeConf grow by lending as much of a hand as I could. We need more events driven by passionate groups of people who have experienced all sides of the conference world. Speaking at most conferences sucks, sponsoring most conferences sucks, and attending most conferences – well that is hit or miss depending on your expectations.

I have helped GitHub organize their latest conference, focused on the Python community. Our experience of organizing a conference in a very well established community like Python has been quite interesting. The Python community is a very proud group and rightfully so, their community has been tended quite well by the Python Software Foundation (PSF) and a benevolent dictator. Our creation of a conference about Python is by no means an attempt to undo or insult these groups, but to add a new voice to the chorus. We have selected an amazing batch of speakers representing the aspects of Python that make it great; including, but not limited to, the PSF, PyLadies Advocacy, SciPy, Django, Microframeworks, and PyPy (and a little JS for good measure). We did this to bring together a nice cross cut of the broad Python community into a single event and allow you to get the full breadth in two jam packed days. To go along with this, we are putting together a line up of social events that will rival JSConf starting with an opening party on Wednesday night October 5th and ending the evening of Friday, October 7th.

I believe deeply in the benefit of organic conferences driven by love for the communities that they represent. I have to otherwise I wouldn’t continue doing what I do with JSConf. I would love for all communities to experience the magic of sharing drinks with “the best and brightest” on a completely level playing field. It is the anti-thesis of elitism, if anything it is a deliberate breakdown of such things. PyCon and other PSF events do this as well, PyCodeConf is just an attempt at a different take on the concept. Both can and should co-exist happily.  Part of the reason for choosing Python is that it seemed well suited for the type of environment we are working towards BECAUSE of PyCon, not in spite of it. That is why I am doing something that is absolutely crazy. I am, as a representative of JSConf, sponsoring PyCodeConf.

Most sponsorships mean that the organization gets money to create a better event and I have discussed this over with the GitHub team that the best way to do this is to get even more people there. So we are sponsoring to obtain a bigger space AND… Get ready for it…

OFFER TICKETS AT HALF THE REGULAR PRICE

This price reduction is only available as part of our sponsorship and as such there are only a few tickets available at the lower price (sorry I am not made of money). The offer is only open until September 9th or we reach the number of tickets covered by the sponsorship. If you already have a ticket, you rock, but unfortunately we cannot do a refund to the lower price (buy one for a friend/co-worker!). If you have been on the fence about attending PyCodeConf, consider this a big push. We want this conference series to grow and we want you to be a part of it, now is your chance. If you don’t program in Python, please pass this on to someone you know who does. If you are taking advantage of this, be sure to pick up your hotel rooms while the block is still open until September 9th.

Organic Technical Conferences FTW. Hooray!

Motive

First I want to start out by describing my intentions for JSConf. I believe any conference at the national or international level has a responsibility to its attendees and its following community at large to present the next generation of things. I believe that conferences are not a platform for repeating what has already been said, but a launchpad for announcing what is new, different, and amazing. When a conference costs more than $500 per attendee, I, as an attendee, demand to see stuff that I cannot see on the internet for free. This is in part why conference attendance is down for most events, but consistently (and crazily) sold out for JSConf and JSConf-like events - its new content that I can’t get elsewhere regardless of the cost. Think about it from a business perspective, would you pay $1200.00 (plus airfare and hotel) for your employees to go and see presentations that clearly blip.tv, vimeo, or youtube has for free? On top of that, most people attend these events for the “hallconf”, which is little more than job interviews by sponsors who are trying to pick up the talent, your talent that you just paid $1200 to $2000 to send. Of course you wouldn’t, but you would probably pay twice as much for your employees to WANT to be in the presentations BECAUSE it will make them ahead of the curve, thus not being “picked up” and even better coming back jazzed that they work at a company that is at the forefront of the world. That, that feeling, is what we target for JSConf.

This is one of the biggest driving forces for how I structured JSConf and specifically speaker selection. I have been both a company owner and an employee so I have seen both sides of the coin. When we pick speakers for each JSConf event, I am evaluating each one almost with a strong multiple personality disorder, where I am viewing it as:

• a business owner in that would I send my people in order to get a competitive advantage by having my employees at the lead of technology.
• an attendee and would I feel that I have to see this, like if I miss this talk would my life be over. 
• a sponsor from the perspective of will this bring out the best people, and thus make it the event to sponsor and more important, the event that we have to be a part of.

As you can see, the target for each one is creating something that is “have to see” and most importantly “can’t find elsewhere”. This means breaking the general expectation or model of how speakers are selected. Most conferences do selections based on sure-wins or safe bets, they pick presentations that they can see beforehand in order to ensure that it and the conference is good. Note, I said good - not great. Most conferences also pick speakers that they know personally and are friends with and perpetuates the previously described elitist society. Both of these suck and make for a par but rapid approaching sub-par speaker roster. Why do they suck, if you look at it the previously described contexts, you can clearly see that talks selected like this are clearly missing the mark.

The Process

It is easy to pick a part others, but it is harder and better to provide answers. So here you go. To select JSConf speakers, I first make a list of all titles, descriptions and UUIDs, but specifically excluding names and contact information. I go through each of these proposals and categorize them into one of a handful of pre-determined groups. For JSConf I use the following:

• Mobile - anything relating to small device (phone/tablet) development, design, testing, etc. If it moves, it goes in here.
• Nerdcore - anything that is complete and total mindsex in terms of philosophy, theory, coding practice, etc.
• WTF - anything that is complete insanity and most likely vaporware OR bullshit or some combination there of.
• Infrastructure - all things related to infrasctructure elements (networking, SCM, tools, etc). 
• Data - all things related to data transport, storage, and querying.
• Library - anything related to client side javascript libraries (jQuery, dojo, Moo, Prototype, etc.) 
• UX/UI - all items related to the visual side of life.
• Other - every year there is something insane that is not categorizable above.

Once all of the talks are categorized, I evaluate each group and rank them based on the merit of their title and description. I do this for many reasons. First, the topic needs to be compelling enough to steal my heart and mind if it isn’t no “celebrity power” will help that. I don’t care who the speaker is. Second, by doing it via groups and ranked within the group, I ensure balanced content at the conference because I am pulling the same number from each group and the top of each group. Finally, and this is my most important point, I AM SELECTING FAIRLY. I am not picking talks because they are friends or because I have to hit a minimum quota of gender or race, or any other hairbrained reason. I am picking talks solely and completely on their merit and importance OF THEIR TALK. The reason I am harping on this point is that many people believe that the way to increase gender and racial diversity at a conference is to tokenize the speakers. To have a token female speaker just to say “we have a female speaker”. Worse I see people blackmailing conferences about this point BEFORE A SINGLE SPEAKER IS ANNOUNCED. Hell, it happened to JSConf (US 2010). That is not gender and racial equality - it is bullshit. TALKS SHOULD BE SELECTED BASED ON THE TOPIC NOT THE SPEAKER. PERIOD. Increasing gender and racial diversity needs to start by increasing the number of speaking proposals coming from those groups, not by selection committees force-adding them. This is a very strong stand on a very touchy subject, but it has to be made and I will not budge on it. I have been very happy to see more and more gender and racially diverse submissions in JSConf and that shows up through our resulting selection. 

Once talks are categorized and ranked, I look at the names of the speakers. If they have spoken on the same or similar topic at any other conference they are docked half a point. If they have been making the rounds of pimping their topic (podcasts, interviews, etc) they are docked half a point. If they are friends or colleagues of mine, they are docked half a point. If they are a “celebrity” they are docked half a point. As you can see from this ranking, it actually hurts you to be closer to JSConf if you want to speak. Doesn’t mean its impossible, but makes it very hard. Brian Leroux is one of the greatest people I have had the pleasure of meeting through JSConf, he is also one of the most unfortunate. I invited him to speak at the first JSConf based off these exact same metrics. His talk was absolutely epic, it was the perfect balance of professional unprofessionalism. He went on to present at almost every conference there after even to this day his line up of conferences rivals that of Doug Crockford. At JSConf 2009, he and phonegap were known to a small set of people and his presentation was killer because of that fact. The unfortunate side is that because his talk was so awesome, it became a hinderance from having him speak again. Honestly I would love to have Brian present, he is the right type of crazy for JSConf, but for reasons listed above, it is very hard to do so. Hopefully Brian doesn’t hate me too much for this, but I think he understands because (luckily for the conference) he keeps coming back each year.

The Downside of Being a JSConf Speaker

One thing I do want to note, I will add a full point to the ranking of a talk if the item is something that is completely and totally insane. If there is realistically no chance in hell that this talk’s topic is actually accomplishable - I will add (positive) a full point. I do this because I want that kind of crazy (Brian’s kind) at the conference. I purposefully push myself to take the high-risk, high-reward topics that make people go “holy crap, my mind was just blown”. You can easily pick out the talks that have this point because they are generally the most memorable ones from the JSConf archives (Ryan Dahl, Brian Leroux, Tobias Schnneider, The Robotic JavaScript talk, etc.) They are high risk at the time we make selections (5-6 months prior to the conference), but they serve two sides, they strongly force the presenter to accomplish what they have laid out AND they give attendees a view of tomorrow, not of yesterday. This is a major difference between JSConf and JSConf-like events AND all other conferences. Conference organizers should take risks, safe bets are good for this year, horrible for next year.

“My Talk”

Once the rankings are settled, I take the top two from each category for my first round of selection. Nearly all first round options say yes, and we have our speakers for that year. Well almost complete. I always challenge myself to find one insane talk. Something that has no right being presented at JSConf, but yet for that reason becomes the most critical to have. I call this “my talk” because I get to pick it with wild abandonment. Last year, this was Aaron Quint’s amazing bacon talk, which resulted in one of the best talks I have ever seen, anywhere. It set the tone for JSConf and gave people a lot to think about on many topics. To this day, when I pitch sponsorships, I lead with the bacon talk. I say this is the kind of talks we have at JSConf and this is why you must be part of this event. Most organizers wouldn’t do that, arguably it is suicide to have a talk like this at a “professional” conference. However, that is what brings people back year over year and also what causes the energy of JSConf to continually expand and accelerate.

Conclusion

There you have it, that is how I pick the speakers for JSConf, that is how we make it “OMGzAWESOME” each year. It is also why when speakers are announced a lot of the “established leaders” look at the list and scratch their heads. It really doesn’t and wouldn’t make sense, not before the talks. After the conference though it is very obvious especially as time goes on and the excitement and energy of the talk and how it “changed my life/view/world” spreads. I would ask that we stop blackmailing conferences into diversity and instead do our best to solve the problem where the problem lies. Hint, organizers aren’t saying “oh crap that’s a woman I can’t have her speak” when they review proposals and to even think like that, let alone tweet about it, that is just insane. If you want a more diverse speaking population, encourage what you want to see speak to put in proposals. It is that easy. Most people don’t even know they can, worse most people don’t even know that they should. You look at how we pick speakers and it is unfair for established speakers at the benefit of new speakers, perfect for making a more diverse speaking population. Finally, I would love to see others use this technique for speaker selection - we need crazier speakers but more importantly we need conferences that are showing us the future, not the past.

P.S.

A quick note about first time conferences, this article isn’t targeted to them. I actually encourage you in the first year to invite a “name” in order to essentially bootstrap your event with their “social capital”. We did it for JSConf (in full disclosure). This article is more targeted for established second, third, fourth year conferences. 

Through pirate techniques and guerrilla SEO we can change how search engines present answers to common queries about our language. By driving traffic to the proper documentation, we can change search rankings and ensure that people interested in JS are connected with the proper educational resources. First target for promotejs, unseat w3schools.com for standard new JS developer queries with proper MDN documentation.

Also please note that this was in the context of improving the experience for new entrants and those continuing their education of the JavaScript language. When you boil down the mission statement of promotejs and the talk in general was this very simple point:

It is up to the experienced developers to point out the proper documentation for the inexperienced. 

Of course the first group to get excited by this, and properly so, where the developers who followed developers that were in attendance of JSConf.EU. Unfortunately by the time we had reached the afterparty the other side of the conversation had arrived. The so-called SEO Experts who, without full context, go off and explain how this is stupid and will not work. Awesome, there is nothing like hitting the hornets nest of a bunch of people that doubt everything. So lets put some facts around this discussion before we start selling FUD in metric tons ;) (note, when the JSConf EU video is released, that joke will make a lot more sense).

1. It has already worked

The goal of PromoteJS is first and foremost to better the documentation visibility and by the sheer viral nature of PromoteJS with a backplane of Twitter and Facebook, it wasn’t long before most of the development community knew a couple things.

1. JavaScript documentation visibility is surprisingly horrible
2. There are proper documentation elements out there like the Mozilla Developer Network and such
3. A lot of people believe in better visibility

When I say “a lot” I am being humble, let me put it this way, immediately after the initial launch of promotejs.com, not more than three (3) days time total - the site had over 4.5 million unique visitors and according to Google already had over 20,000 backlinks from people writing about promotejs.com on their site. So what does that mean? Well in simplest terms, this is obviously an issue that needed discussion and a rallying call mind you that even if no one put the badge on their site and backlinked the hell out of PromoteJS, thus giving a substantial amount of authority, we still win. Why? Well the first and highest quality link on the site not going back to google is to the top level Mozilla Developer Network site for JavaScript, as well as the second link, oh and the third link. So any discussion about the success or failure has to account for this before continuing anywhere else, a major factor that all the so called “SEO Experts” have not yet addressed.

2. Haters gonna hate

This is no more certain than the backlash against PromoteJS where as best I can see a total of 2 blog posts were generated by “experts”. Posts which mind you are providing highly organic back links to both PromoteJS AND the MDN site, links without the rel=”nofollow” or rel=”noindex” attributes. So let me start by saying thank you! Most of what I have read in these articles skips the main thrust of the #promotejs and that is getting people to link to proper documentation, to start discussing it, and to build better community awareness about the problem. In essence, the gist of their arguments are similar to mine - link in your articles it has greater weight than any single link or button ever will. That was a core fundamental of the educational component of the talk, #promotejs is just a way of getting people talking about it.

As for the “keyword stuffing” claims, I would contend that they just don’t get it. People do not search of “JavaScript”, but for specific items like “JavaScript Array Length” or “JS array.length” in order to find the specific target, the alt tag and name tag were crafted based on the actual searches done by actual people actually learning and using the language. Also bear in mind that the whole page and its context, its content, and its backlinkage are taken into account to determine the likelihood of a link being a link farm. So yes, if we had put it on a thousand one of sites each of which with little to no google page rank, I would agree, BUT THATS NOT THE POINT. These are going on high page rank, high value, high content sites that have lengthy histories. If anything this working with google’s algorithm, not against. It is people saying I believe this is the best documentation (for now) and if you want to know about JavaScript, like I write about it then go here. 

3. I repeat, it is working!

We built a site to track our progress within the google page ranking across all key terms called Are We First Yet. The site stopped working on March 1, 2011 due to API changes that google made (deprecated the API we were using). What it does show us is that from launch to March 1, we took almost all terms and got them two the first two page results - most above the fold on the first page. We can do even better and we are doing better. I actually wrote this article 3 days after launch, we all the SEO experts were clammering about how this is a flawed or failed effort and how its essentially going to do more damage than good. I ask you now, 5 months later, where are these “experts” with the big bowls of claim chowder? I can promise you this they aren’t on the first page of a common Google search, like umm… Learn JS which went from position 54 to link 3 or JS which went from 254 to link 68.

The thing I love most about SEO is that expertise is complete BS. Google changes their algorithm regularly in order to actually teardown the SEO experts and ensure that community determined proper content is placed above otherwise content. The goal of PromoteJS is, agreeably not to create a link farm, but to get us, JS developers, to start linking and start fixing the problems within our community. To take a stand and do instead of sitting and complaining. 

#jsconfeu ftw

There are many reasons to organize and run a conference, most of the “upfront reasons” are unfortunately bunk. I have experienced this on my own and corroborated with many conference and event organizers that I try to help out, here are a list of things that initially go through your head, depending on what else is going on in your life:

If I can pull this off, …

• I will have a lot higher visibility in the community!
• I can use the connections and marketing to help drive business to my consulting/product company!
• I will make a name for myself!
• I will be somebody important!
• I will make bring together people and all will be happy and right with the world!
• I can change the (world, community, or mindshare) for the better!
• I can do something amazing that will be self fulfilling.

I can tell you that pretty much everyone of those ends up not happening or quite to the contrary the opposite happens. I will admit that when I started JSConf and NoSQL East I firmly believed every single one of those at some point in the journey. Worse still, I EVEN believed some of these during JSConf 2010, as if the first time around had not taught me anything. So I would like to share with you some of my experiences and thoughts on this matter, especially because going into an event planning with the right foresight is probably the best thing you can do have to prepare you for the “revisionist” hindsight you will undoubtable experience after your event.

Let’s start with the obvious issue, the desire or feeling of wanting to do something that someone else thinks is amazing. Beyond basic instincts (food, water, sex, etc.), human psyche is driven by a burning desire for recognition - it is an annoying facet of life we all deal with and the more you might possibly have, the more you desire it. That just sucks. Worse for the conference organizer is that you are pulling together huge names, massive fame, and organizing amazing things - so your inclination is for that fame limelight to be shed on you. It is nature, there is little you can do about it. Most technical people will attempt to rationalize this desire into a convincing argument that “If I can bring people together for this event, I can figure out a way to benefit”. Right, it is obvious, it is how advertising works.

Step 1. Draw the audience.

Step 2. …

Step 3. Unicorns and Rainbows

But rounding the corner of organizing an event and receiving any degree of fulfillment from said event is, at least in my experience, one of the hardest accomplishments. Ever. Why is it so hard? Well simply put, it is because you are afraid of failing, of essentially throwing a party no one shows up to and so you make it the best damn party. In part it is due to the premature adoption that a conference organizer has with their event, in part it is the desire to make the best damn event ever - either way you are inclined to invest (time, effort, energy, hopes, dreams) way above and beyond what the event itself can ever return. In part, thats the passion of the event that shines through to attendees and makes them happy to have attendeed, but it has a dark side.

After every single conference I have thrown I tell myself “I will never ever do this again, fuck that.” It is a large amount of work from gathering (and herding) speakers, gathering (and also herding) sponsors, and finally herding attendees - it’s insane. Add to the mix vendors who drastically overcharge and then still proceed to nickel and dime you and it is enough to put anyone into an early grave. But this article is not about complaining it is about outcome. There is an inherent problem with conference organizers, they start the journey without knowing the end. Some (/me raises hand) become addicted to the adrenaline rush of actually pulling it off, some forgo the risk and take the profits, still others leverage the conference as a means to catapult themselves into the limelight. I personally have thrashed internally as to why I do JSConf. I hold back and even downplay my own personal efforts with the conference because I think it is what the community needs/deserves, which generally speaking goes according to plan - BUT that means no one notices. Ask any JS person who the top movers and shakers are and I highly doubt I would even be thought of let alone mentioned. Reason why? Simple I make it a point to be more behind the scenes and thus even though I am basically spotlighting the next year of JS (And other language conferences talks) the speakers take the “limelight”, deservedly. My personal ego thrashes constantly about this. I am human after all. My reason tells me it is pretty pointless, we spend all the money making an event memorable and yet I am purposefully circumventing that. WTF. It is just eventuallity and I do tell myself it is for the best in the long term.

What has becoming increasingly worse is the haters who jump all over “risky” items. We make JSConf a place for experimentation and while it is good to see conferences leverage those experiements (I love txjs) it is also tough to see others plunder it out right. Whether it be groups of people looking at JSConf saying.. there is something there, lets figure out how we can “extend” it, all without even emailing me OR bigger more established conferences taking our speakers, event ideas, or even themes and repurposing them. I get that this is a competitive market - I really do - and that I don’t have a trademark on awesome (I tried) but seriously it sucks goat testicles and it is just an eventual outcome of doing something different. You incur the risk, others take it to market cheaper after you’ve proven it. What was very nice the first year of JSConf, which most people completely gloss over is the “OMG THIS WAS THE BEST EVER” articles. I have watched year after year and event after event as those amazingly long and beautiful articles have disappeared. Replaced by “jsconf was great” tweets, which as you can probably guess are nice, but in no way fulfilling. You want to make a conference organizer happy? WRITE A LONG ASS BLOG POST ABOUT HOW THE EVENT WAS EVEN BETTER THAN SEX. That, as best I can tell, is the best and only gold of conference organization. Trust me, you have no idea how awesome it was the three weeks following JSConf 2009 reading those, it is what inspired me to do 2010. 

In the end, I have resolved myself to the outcome for JSConf being a couple great parties I get to attend (at the cost of organizing) and a couple nights in an awesome hotel room. Thats why we pick swanky hotels for JSConf and throw awesome parties. JSConf (or any conference of substance) can’t sustain its organizers and thus they have to return to their 9-to-9s in order to pay the bills. And thus you have it, conferences like JSConf, FunConf, ShnitzelConf, TXJS, etc. are labors of love remember that next conference you attend and hug the hell out of the people organizing it. Especially if you can do it at the most awkward moment (closing speech is best).

Sorry for the dark look on the other side, but hell thats what this series is about. This isn’t meant as a “cry for me”, but more just a peek at the other side, please take it as such.

We are an interesting lot when you look at the community as a whole. We are a rag tag group of designers, developers, noobs, and elites. We have a sordid history as one of the greatest technological wars played out across our land and left us in a wasteland of stagnation. The big vendors have looted and plundered our community and we survived it, only to come out stronger and better. Many of our original heroes have been lost to legend, or worse they have been scorned by the dragons they sought to slay. We have seen new leaders rise with vigor and innovation not often seen in other programming communities.  We are a community of rejuvenation, of rebuilding, of finding problems and fixing them. We are a community of developers who prefer JS, but use a variety of other languages and tools to accomplish tasks. We are at the point of a renaissance of interest, excitement, and energy and yet I worry. I fear as the drums of war start pounding between browser vendors and the rising tide of interest moves back to JS, what will it do to our community. Will we have built something sustainable or merely yet another flash in the pan technology cult? The new generation of JS, you, me, all of us here, will we learn from our past or are we destined to repeat it in all the wrong ways? Let us not just begin a discussion today, let us trigger action and inspire change! Sustainability should be the most important goal for the technology community at large, and yet no one discusses it. Tonight, we will do more than discuss.

Chapter 1: Education

JS is not a toy language, we believe that otherwise we would not be here. That reality is just now reaching the masses and their first impression of JS is absolutely abysmal. How many of you know what shows up when you search for ”JavaScript”? Look at the links that show up, wikipedia? w3schools? Download Java? Maybe you are saying to yourself that “JavaScript” is too broad a topic and no one in their right mind would search by name for the language that they are trying to learn. Well, lets see, ”JavaScript Array”. The first “quality” link on this page was the MDC documents, link 8 - non-existent. If you want me to take it a step further let’s use an actual query for a first time person, google ”Learn JavaScript”. The first link that actually presents proper JS is John Resig’s at position 8 AND its designed for advanced techniques - the stuff in there would blow the minds right out of anyone just starting out. 

This is the first impression of JS by the general masses who are coming to this language and once you see this, you can see why people consider it a “toy language” and understand how so much bad code and disdain can exist for JS. We have hidden the better tutorials, learnings, and documentations away from ourselves AND more to the point, those trying to join the party.  New entrants struggle to learn JS, but eventually just adopt what they know from PHP, Java, Perl, Python and Ruby to a close approximation of runnable code that suffices. Then they publish it back out, proud of what they have done, and continue to perpetuate this plague of improper JS coding. 

We have failed our fellow designers AND developers in this sense. We have made it almost impossible to learn proper JS, a language with both beauty and warts. Some will say it is not our fault, that browser vendors should provide the API documentation for the implementation or that the standards committee should publish and market it. I am calling bullshit on that. I say that it is up to us to invite, welcome, and most importantly properly educate people looking to learn JS. We, the best and brightest of the field, have an obligation to help those who are trying to learn and understand the complexities of the language. We are the ones that benefit from it most, since those now entering the language will be either extending, morphing, or taking over the very projects we are just now starting. Regardless of library, framework, and even language – if everyone knows how to program proper JS a little better, we all win. Period. 

So I challenge you to put down your library or framework preferences and write about some interesting facet about the JS language. Describe how you find the attributes on an object, what the difference between an object and an array is (and how to tell the two a part), anything and everything. If you seek fame and click traffic, write about the entry level stuff. If you seek respect and deep dialogs, write about the difference between implementations and convey the wisdom of when to favor one method over the other. If writing is too time consuming or your muse escapes you, I am announcing today a new campaign, promotejs.com. The goal of PromoteJS is this, through pirate techniques and guerrilla SEO we can change how search engines present answers to common queries about our language. By driving traffic to the proper documentation, we can change search rankings and ensure that people interested in JS are connected with the proper educational resources. First target for promotejs, unseat w3schools.com for standard new JS developer queries with proper MDN documentation. Yes I am saying that we crowd hack google.

We need to be the voice of education for our community. We need to promote the proper way of doing things, instead of just ignoring those that don’t “get it” or watering things down. We need to commit to educating our fellow developers on JS, the language, and in doing so it helps ALL of our frameworks, libraries, meetups, and conferences. promotejs.com is a step in that direction, but by no means the end of the story. The morale of this chapter is, ”The more people that learn proper JS, the better the community will be”. 

Chapter 2: Love The Pirate! Damn The Privateers!

The technology field has changed tremendously over the last 20 years and unfortunately it has become focused almost entirely on profiteering and fame. We see companies running technology conferences for profit, selling FUD in metric fuck tons, and making zealots out of noobs. Conmen jump from one “hot tech” to the next in order to be the first to sell this week’s “new deal”. It started with Java and the marketing engine that pushed it into the limelight, shadowing all else, thrived in the .NET ecosphere, and came full circle to the “hackers” with the rise of Rails. The world of software development has seemed to shift from developing to better mankind to a slow, but strong bleeding of developers. This is not the way of sustainable craftsmanship within Computer Science. We must turn this trend back. We, the crowd gathered here and those watching from home, we, the interested, we… JSConf… have a responsibility to ourselves to turn this tide. We are the people who can identify the conmen, the bad actors, the manipulators and we are the ones that have to call them out. Yes, it won’t be pretty and yes they will fight, but fuck it - we are pirates. 

From the beginning of JSConf, doing what matters versus doing what makes money has been a core fundamental to all of us involved. We are pirates, we believe deeply in the code that all ships rise with the rising tide and that equality for all makes for a proper ship. We have no problems addressing the issues in our community openly and calling for a change, we must rattle the sabers and shake out those that aren’t committed, and we need to do it now. because I fear to tell you - the establishment is at the door again, ready to make money off our work. 

And thus I say, love the pirate, damn the privateers. Privateers for those who don’t know, were people that posed as pirates and would pillage other countries or pirate ships at the behest of a monarchy or government. They were little more than hired guns paid to discredit pirates and break up colonies. Pirates have a code, though it may differ from ship to ship, the general principles of honesty and good faith amongst one another was ever present - this was untrue for the privateers. We need to root out those amongst us who are not here for love and challenge, those that present themselves as great, but provide little to no example or reasoning as to how. Show what you have done and let others determine your value, anything else is privateering. Many people think I am someone important in JavaScript, but they have never once  seen or used my code - trust me if they have, they certainly wouldn’t think that. We need to pull down the cult of personality that now permeates our world, it is only a device of the privateer. This is true for not just this band of pirates, but for all software developers out there. We must band together and bring sustainability and sanity back to our profession.

In this, I want to openly applaud Rebecca Murphey for challenging those who champion enterprise jQuery without offering solutions or a frank discussioon of the issues. I want to applaud Zed Shaw for speaking out quite vocally on this very issue in both small and large forums. Our profession needs more champions of character and less bullshit.

And so, I make this call to arms, “Love the Pirates, Damn the Privateers!” with the deepest of sincerity. Luckily, we are starting almost a new at this point. There is no more Ajax Experience, there are few, if any publisher-run conferences in JS. Right now, we have a developer driven development community. Think about that for a second, we have the power. We have a shipful of pirates and a wide open sea before us. Adhere to the code! ARRRRR!!

Chapter 3. Sex, Lies, and Comparing Sizes

JS is not the greatest programming language. No programming language is and none can ever be. They are all a close approximation to something the computer can understand. Every programming language has its benefits and its downfalls, we need to get to the point where we realize this and openly admit the negatives along with the positive. We need to stop presenting each new language or framework with zealotous “THIS IS THE BEST EVER” or coming out with rediculous metrics that “benchmark” two things that are not the same or aren’t actually benchmarking appropriate use. The world is big enough for all programming languages and frameworks, and to be honest -  the world needs every programming language. Not more than a year ago, if you told someone that JS would be a serious contender in the server market you would have been laughed at, much like if you had said Ruby 10 years. Times change, needs shift, holding a single weapon makes you easy to combat and a horrible pirate. We are not “JavaScripter”s, not pythonistas, not rubyists - we are programmers. We need to improve ourselves in as many programming languages as we can get our minds around, because every language forces you to view the world in a slightly different way. We need to remove the trolls from our world. We need to stop comparing cocksizes - lets be blatantly honest here, we are all geeks. We are not rockstars, we are not ninjas, luckily though, we are all friends.

Confession time: I am not Mr. JSConf. I am not a leader nor all that good of a programmer. On a good night, I can pull together something but it won’t win any awards or medals. Before I started JSConf, I was completely unknown, like many speakers at JSConf US and EU. After this, I am going to return back to DC sit at my cubicle and work as hard as I can on my full time job. After that I am going to go home and enjoy the company of my family. I bring this up to make one thing very clear. I am nothing special. I am just like everyone of you, and honestly I don’t want to be anything special. This is not false modesty nor self deprecating, this is honesty. And honesty is what we need to be to ourselves and our fellow programmers. I am most worried about this issue above all others I have since discussed. It is pride and selfishness that have turned programming from an art into a cesspool. It has to stop now and we have to be the ones to do it. Why us? Well simply put because we are interesting lot, we come from all different programming languages and educational backgrounds. We have a rare opportunity and the perfect mix of curiousity, intelligence, and experience. We are sitting at an amazing time and we are amazing people - that is why it is up to us to do this.

So let this be the start of something great. We are going to improve our community, we are not going to let it become a ghetto. We are going to do this not for some misguided blind love of a single programming language but because we embrace all programming languages. We have the power and the knowledge to make these changes, to make the programming world a better place and in turn the entire world a better place. We are pirates. We are JSConf!

Thank you. 

Map:

Ben Galbraith and Dion Almaer of Ajaxian recently posted that they are stepping down as formal editors of the blog Ajaxian.

I just wanted to write a short ode to Ajaxian. Ben and Dion both literally created the Ajax community, founding a central watering hole for everyone to come around. Of any tech community I’ve been a part of, the Ajax/Ajaxian community has been the absolute best one. While Jesse James Garrett might have coined the term Ajax, Ben and Dion made it real and gave it heart.

Ben and Dion both helped me launch my JavaScript career, supporting me with mentions when I put out some new Ajax hack or toolkit. Without Ajaxian there wouldn’t have been a place to post new updates; it’s the Techmeme of the JavaScript world (not the Valleywag of the JS world, thankfully :)

I wouldn’t be where I am in any possible way if it wasn’t for Ajaxian and Ben and Dion. Thanks for all the hard work guys!

As HTML5 grows and slowly eclipses the Ajax community, lets hope we get as awesome a common community space as Ajaxian has been!

Labels: ajax

// posted by Brad Neuberg @ Wednesday, July 14, 2010

Organizing any event of any magnitude takes exponential effort and cost to the resulting “feel” of that event.

This is something I have come to after years of starting small groups and increasingly large events. JSConf, or any conference as best I can tell, is no exception to this rule. I believe in part this is due to the veil that conference organizers (myself included) put up in order to hide the details in an effort to make the event seem perfect - the truth is very often far from. A conference or any event of substantial size is little more than herding cats with nothing but a spoon and a lot of faith that things will work out, despite any specific time instance. That’s it - complete and total chaos. If you don’t immediately understand what I mean, please continue.

Venue

Possibly the most complex and important decision of every conference is the venue. Trust me, the venue is also the most precarious and hazardous of all decisions related to the success of the conference. When an organizer selects a venue they are implicitly selecting the following items:

• Quality, variety, and costing of the food available
• IT capability for the entire conference
• Room cost and availability
• Total number of attendees
• General feel of the conference
• Location of the event

That is a tremendous amount of fundamental concerns that all must be done prior to even the first thought of the conference. Factor in that no hotel seems to be affected by the ongoing economic troubles suffered by everyone else, or at least that is the front they all put up, and before even setting forth, the organizer begins to question their decision. Think about this, at a technology conference, you are selecting the basis for every major component that makes or breaks the conference (internet, room rates, number, feel, food) roughly 6-8 months in advance with little to no validation that the conference will work or who will show up.

Lodging

Worse still, you are dedicating roughly 55% of your budget to a group that is only contractually required to turn the lights on and unlock the doors. Organizers have little to no protection in venue contracts, but bear all of the risk. If you assume a hotel for “ease of selection”, the organizer has to guarantee at their own personal risk a room block, meaning a set of rooms that must be filled by certain number of attendees otherwise you pay for the rooms to be vacant. You have to make the estimate on the size of the room block long before you really even know the numbers of attendees AND you cannot increase the size without going through another round of negotiation with the hotel. So you are stuck trying to fill rooms in a hotel to (normally) within a 5 room night space considered “acceptable” by the hotel. Worse still, the room rate is “offered” with little bearing to the market and little control over any “considerations”. Most hotels will offer the organizer a “price lower than any other available”, but will sell the rooms on Priceline/Hotwire for at or below the event price. Aside from the organizer or an attendee actually booking a room through such services, the organizer will never find out and therefore can never exercise the contract line item - rendering it completely useless. 

The mere selection of the venue is a precarious clusterfuck as well, if you choose a venue in the city which affords excitement and self-directed activities for the attendees, you can look for a room rate of $200-$500/night for your attendees at first negotiation. That pretty much prohibits anyone from attending except for local people who do not help you on the aforementioned room block issue. Also you have to factor in that the cost of the hotel room directly affects the cost of the conference, since you will most likely be providing a space for your invited speakers (yet to be determined) to stay. Consider a two day (16 speakers) single track conference, the cost of hosting speakers so you can ensure that they are ready and “on-call” normally runs roughly $15,000-$30,000 of the budget. This is also why negotiating the venue is absolutely essential, but it is very stressful, frustrating, and can build a tremendous amount of hostility between the organizer and the venue early on, yielding a less than satisfying relationship on going.

If you hold the conference outside the city, the price does go down to anywhere from $100-$250, but the organizer has to balance the likelihood of someone taking a taxi from the nearest airport to get to your conference, which decreases with every mile out from a major airport. Since you aren’t in a major metropolis (possibly in the suburbs) you likely will have to find (or create) things for your attendees to do/see/eat outside of the conference. Or you could just not care - but then the perceived quality of the conference rapidly degrades, because the attendees will just go back to their rooms and complain. So now you are looking at a social budget and the first thing you will consider is the hotel. Hotel parties cost anywhere from $10,000 - $14,000 for a group the size of 150 people, because according to their analysis people will consume $86 worth of food and drink over two hours. Stop for a second a re-read that, you could send everyone to the fanciest of restaurants in the region for that price, but instead you are going to pay that for chicken-on-a-stick and Bud Light. On top of that there is generally a 22%-30% gratuity that must be paid to thank the people cooking and serving the food - regardless of their performance. It is without a doubt, impossible to justify the cost so the organizer will now have to find a new venue for the social events, making it exponentially more complex. 

And then there is food and beverages during the day. Most hotels and venues will not let you bring in outside food, feigning rules of “state law” and “labor restrictions” - all of which is complete hogwash barring two states. So they will provide the organizer with the only option for food, which comes with prices that are outrageous. By outrageous, I mean $26 per person for a “continental breakfast” of day-old pastries and $40 per person for deli sandwiches. So for a given attendee, you are looking at spending anywhere from $50 - $75 per person per day. This amount will be even higher if you attempt accommodate your guests throughout the day with coffee and sodas which can easily range from $28 - $36 per person, per day. So tabulating that out, if you run a conference for 150 people spread over 2 days, you are looking at a base price for accommodating your guests of roughly $34,000 on average. 

So as a conference organizer, just to get started, you require about $50,000 to just secure the base essentials of speakers and food/beverage. So next time you complain about the price of admission to event X or conference Y consider this, in order to break even for an “ok” event in a reasonable place, the bear minimum the conference organizers should charge without expectation of sponsorship is $189 per day per person. That is just covering your attendance and the presence of the speakers for the event. Mind you that is only a one track conference, as you add more tracks the number of “compensated” speakers grows normally at the exchange of paying guests, which directly changes the cost per person per day. Furthermore that number does not cover the cost of speaker travel, which can range anywhere from $300 to $700 per speaker. 

I have been sitting on this post for a while, I do intend on continuing the series, but I wanted to get this out. Seriously, stop bitching about grass roots conferences, if you have an issue with them, then offer to help - it will be gladly accepted. The grass roots, organic conference movement has provided some of the most amazing events in the technology industry, but they are fading because the response is generally one of “OMG I HATE YOU” or “WTF YOU FAILED ON…” instead of looking at what positive things were done. If you think you can do better, I encourage you to go for it. You will have a new appreciation for every other event you attend thereafter. 

Charles plans on demonstrating the HTML5 love that SproutCore 1.1 comes packed to the brim with. Taking RIA and binding it with HTML5 - Brilliant! Charles also has some great things he is planning on demonstrating that will really blow your socks (or boots as the case maybe) off. This is going to be quite the presentation especially for building complex and very rich internet applications. We might even have some buccaneers with contrarian view points strategically placed in the audience to heckle him… You will have to be there to find out more!

All JSConf Speakers

Posted on January 29th, 2010 by Kevin Dangoor

CommonJS: the First Year

A year ago today, I posted “What Server Side JavaScript Needs”, inviting people to come and turn JavaScript into a competitive platform for applications on the server. Quite a few people answered the call. While the focus of the group has been on JavaScript in non-browser contexts, we’re ultimately shooting for as much of a standard that can cross between server, browser, GUI and command line applications as possible. That’s why we changed the name to CommonJS in the second half of the year. Ironically, most of my own personal use of CommonJS so far has been in the browser. I’ll come back to the personal perspective, though.

The Original Goals

As laid out in my original blog post, we were seeking to create:

• A module system,
• A cross-interpreter standard library,
• A few standard interfaces,
• A package system, and
• A package repository

Note that the idea here is that this group creates specs, which will have multiple implementations.

The goal is to have these things working across as many operating systems and interpreters as possible. There are three major operating systems (Windows, Mac, Linux) and four major interpreters (SpiderMonkey, Rhino, v8, JavaScriptCore). Plus there’s “the browser”, which is a unique environment unto itself. That’s a fair bit of surface area to cover.

Oddly, I think the one of those eight “platforms” with the poorest implementation support is Windows. Most of the CommonJS developers are using Macs or Linux machines, so I’m not sure how much time has really been spent on Windows. I would imagine that JavaScriptCore on Windows is probably the least supported combination.

The good news, however, is that there are projects using all of those JavaScript interpreters and platform compatibility issues will ultimately be ironed out.

CommonJS and the ECMAScript Standard

The CommonJS group is a grassroots effort, and not some formal standards body. In some ways, however, it works like a standards body in that the people working on the standard are also implementing the standard-in-progress and using it to build real applications.

We have no control over the ECMAScript language, which is managed by the TC39 working group. However, there are a few people involved in CommonJS who are part of TC39, and I have firsthand knowledge of others who are keeping an eye on how things are going with CommonJS.

The CommonJS standard-in-progress is designed to work on a subset of ECMAScript 5 that can be made to work on today’s ECMAScript 3 interpreters. ECMAScript 3 is the standard that is running in all of the browsers. In other words, in a CommonJS application you can count on Array.prototype.forEach to be implemented. Obviously, applications can do whatever they want (array destructuring? knock yourself out, but your app will only work on SpiderMonkey and Rhino).

One certainty about CommonJS is that inventing new language syntax is out of scope.

The Module System

The CommonJS group has been remarkably good at avoiding bikeshedding. While there is discussion about names of things, there isn’t heated discussion about it. People are far more interested in issues of functionality and ease-of-use. This is a very good thing, and it allowed us to get modules out of the way early on.

Of course, the lack of bikeshedding doesn’t mean that everyone agrees on things. The CommonJS module system has its controversial aspects, but I think it does well given the constraints:

1. must work with ES3 syntax (destructuring could actually be useful, but we’re not going to do it)
2. modules should have self-contained namespaces and be explicit about data the want to export
3. it should be possible to make modules tamper-proof, though this is not a requirement
4. using a module should be competitive with using modules in languages like Python and Ruby

TC39 had considered adding modules to ECMAScript 4 and there are module proposals on the table for ECMAScript Harmony that would add some syntax to JavaScript that would look similar to CommonJS modules. Here’s a short module to give you an idea of what CommonJS modules look like:

var sillymath = require("extramath/silly");

exports.addTwo = function(num) {
    return sillymath.add(num, 2);
};

Personally, I find this to be reasonably concise with a nice level of explicitness. Some syntax sugar would be good, and I hope we get that in ES-Harmony. But, this syntax works fine today.

Of course, this syntax is not without controversy. The biggest controversy has been that require() is synchronous – the “extramath/silly” module has to be available as the module above is loaded. However, there are a couple of reasonable ways to deal with this problem and I am happily working with CommonJS modules in the browser which is the environment that is least tolerant to synchronous loading.

Controversy or not, this basic module system was ratified last winter and has been implemented on all target environments of CommonJS.

Discussion is ongoing for a tie-in to the module standard: the module transport standard. Without additional help from the browser or some additional scaffolding running in the page, the module syntax above doesn’t work via a

The Standard Library

I had hoped we’d get farther on the standard library than we have, but it can indeed be a long process. system and unit testing are the only ones that have been ratified at this point. We have come a long way on file access.

“What!?!?”, I hear you say, “there’s no standard for accessing files yet?” That’s right. And there are a couple of reasons that it’s been challenging to get there.

Consider that JavaScript does not even have a standard object to deal with binary data. That is a basic prerequisite to working with files. JavaScript strings are not the same as a binary data container. So, there’s binary data to handle, streams to figure out and then file functionality built on top of that. There’s also the consideration of whether file access is synchronous or asynchronous. We’ve made tons of headway on this, and there are certainly implementations of some of the specs. It’s just a matter of finishing them.

I’m hoping to see promises become a part of the standard, because some form of that interface is very convenient to use for asynchronous operations.

Standard Interfaces

We do have a very useful interface with implementations and people actively using it: the JavaScript Gateway Interface (JSGI). That spec has not yet been ratified, but it is getting closer and there are apps being built against it today.

Database access has not yet been standardized. It will be interesting to see if we can come up with a good interface that can usefully target SQL and NoSQL databases alike.

Package System

We have a recently ratified spec for packages of CommonJS code. I hope this will bring about a collection of good package managers with different focuses and targeting different environments. There have already been a couple of attempts to create package management systems, and the most fleshed out one that I’ve seen is Tusk, which is bundled with Narwhal. Once a few more specs are ratified, Tusk should be able to run on other CommonJS implementations.

Package Repository

Tusk is using GitHub as a package repository, and that is working okay for the time being. A couple weeks back, we got word that the jQuery plugin repository is going to provide a CommonJS package.json file for the ~5000 plugins in their database. This is exciting, because this infrastructure could prove to be very useful to us going forward.

JavaScript: Bubbling Up

2009 was a terrific year for JavaScript. In the browser, we’ve obviously seen tons of growth in increasingly sophisticated applications. I think the interest is steadily building to use JavaScript more and more outside of the browser. The two JSConf conferences (in Washington DC and Berlin) were great successes by all accounts I’ve seen. PhoneGap, Titanium and Palm’s WebOS have created ways for people to use web tech to create installable apps for mobile phones. node.js has been a huge driver for people to check out building scalable, asynchronous JavaScript apps on the server. And, of course, CommonJS is finding its way into more and more applications.

My Personal View

I had hoped to personally have more time to devote to CommonJS in 2009, but I am delighted at how a great collection of people have stepped in and carried the specifications and implementations forward through a lot of hard work and force of will. More than 5,100 messages have gone across the mailing list, and more than 10% of those have been from Kris Kowal. Kris has done a ton of work in ironing out many of the specs and deserves a good deal of credit for where CommonJS is today. He and Tom Robinson even stood in for me when I had to cancel my trip to JSConf.eu (thanks, guys!).

Taking a look at the top posters on the googlegroup, you can see how many people have put so much into CommonJS. More than 10 people have contributed more than 100 messages a piece and, for many of those people, there was a lot of time spent in the email discussions, IRC chats, spec writing and implementation of those specs. Plus, as early adopters, they have the joy of tweaking things as the specs have changed over time. Thanks to all of you for the dedication and the will to get it done.

Bespin’s client side JavaScript code is all CommonJS modules now, partly thanks to the efforts of Charles Jolley to migrate the SproutCore framework to CommonJS and creating the Tiki module loader. From that standpoint, I’m already using more CommonJS now than I did in 2009. I’m also hoping that 2010 will bring a Bespin server “reboot”, where we start migrating server functionality to CommonJS.

On the whole, I think that 2009 was a great year for JavaScript and CommonJS and I think 2010 is going to be even bigger. I hope to meet more enthusiastic JavaScript hackers at JSConf.us in April!

Comments?

You can direct them to the thread on the CommonJS googlegroup or email to editor@blueskyonmars.com.

ShareThis

Comments are closed.

What a year for CommonJS and JavaScript in general. One has to wonder what 2010 holds for JavaScript and the JavaScript community!