Targeting a game at 10,000,000 people? Then come and find out how Pillow Pets World was built. Pillow Pets World is a virtual world built for millions of kids. Scalability and performance were aspects that were included from the start. The talk will dive into the design goals, architecture and end result of creating this massive virtual world. Come see how Pulse (a HTML5 game engine) and Node.js were combined to create a fast, expandable, mobile ready world. The technologies included in this talk are: Pulse | HTML5 Game Engine Node.js | Scalable small servers Socket.io | Real-time communication using Web sockets Redis | Small in memory storage used for pub/sub communication between servers
Learn how to automate builds, deployment tasks, and application scaling as we use OpenShift's platform architecture on-demand to build your own git-based release pipeline, including: development, testing, staging, and cloud-scaling production environments for node.js.
Node's callback pattern makes error handling difficult: throwing an exception kills the entire node process, terminating all current requests, and every callback initiates a new stack, so stacktraces are terse and don't indicate how you got where you died. You can solve these problems using some newer features of Node called clusters and domains. This talk with explore using these tools for better error handling.
A series of five minute talks.
What if your software knew about its environment and could react? With very basic electronics skills, and the ability to read a datasheet, you can be well on your way to a smarter and more responsive application. We will discuss some common hardware protocols and how to interface your code with them to build something even more cool.
In January 2013 I started the Voxel.js project project. Since then we have generated nearly 100 node modules related to 3D game development and distribution, e.g. voxel rendering and first person controls and physics. In the main module (voxel-engine) I've received 50 pull requests from 20 contributors. I'd like to talk about why voxel.js has been successful from an open source standpoint (open from the beginning) and also show off some fun 3D demos and inspire people to take up game development in JS.
Reviewing the online slides of this talk is the best way to get an idea of what module driven development is about. The speaker notes appear in the browser console. The main points are as follows: what constitutes a module why it is desirable to build smaller modules challenges and patterns for separating the application into independent modules process of pulling out a module from an application replpad case study how to become module driven phase1 and phase2 browserify and how it enables to even manage your client side modules with npm quick primer on tools like npm init, pkginit, travisify and npm link that help with module driven development
I've tested a half-dozen home sensor integration technologies over as many years and learned something important about architecture with each generation. I've replaced Arduino hardware with Teensy which offers much better USB support. I've replace C++ with Perl then with Ruby/Sinatra and now Node/Wiki each time feeling the fresh air of a more friendly and dynamic environment. I've plotted results with ascii-art, java-2d, flot and now d3.js which can be a career in itself. I'll share the good parts of each of these and suggest how you will know when it is time for you to move on.
A funny thing happened at the rock gym... I kept running into programmers. Rock climbing is a constant challenge. Physical? Hardly. Tired muscles is a concern once you're two pitches up and can't figure out the next move. I'm afraid of heights! The psychological and mental tenacity required to complete a wall feels eerily similar to the daily challenges of the Programmer. You will commit yourself to situations that you pretty much HAVE to find a way out of. Sound familiar?
How are people learning to program nowadays? MOOCs, tutorials, workshops, communities, books, degrees, internships, apprenticeships, code schools. What am I doing? What have I done? How many callouses have I built in the process?
Experiences shared from my own perspective and others I have met on my journey have shown me a number of great ways to help move forward those willing to take up the challenge. Finally, what can I do, along with sharp and helpful Node.js programmers, to build the knowledge base and accessibility into the community? How do I get programmers hooked?
And how can I convince all of these brainiacs to get out and punch a few rocks?
Horse JS and Continuous Delivery Unicorn make it happen.
Join Hanselman as he digs into the open source SDKs of Windows Azure. Let's access Azure from the command line and deploy and redeploy with Git. We'll fire up Linux VMs, setup Mongo and run node.js apps in the cloud. We'll look at things like SendGrid and New Relic. The future of the cloud is open and it's a hybrid. This very technical session will cover Windows and Mac, .NET as well as pinching pennies in the cloud.
A common problem in large scale computing, is coordinating workers when they can be scattered across compute nodes. For workloads like this, atomic operators like increment and decrement reduce contention between distributed processes. In this talk I'll show a full text analysis tool which ranks words in the Twitter firehose. By storing each token in a key based on its characteristics, we can provide word rankings both globally, as well as over time and space. We'll show the running application, and take a tour through the code, as well as discuss cluster sizing and how it is impacted by variations in the input data stream. For instance a tweet in English from San Francisco might say "Go Giants" so counters for 2012:go and usa-sf:2012-07:giants (among a few dozen others) are incremented. Even using memory like this, the counts from a full corpus of English text would only take a few gigabytes to hold, making this architecture more efficient than a traditional index-and-rollup approach.
Git is one of my favorite things to hack on. It's long been my goal to get a working (workable?) implementation of git running in pure JS, in the browser. My first attempt two years ago failed; and for a long time I've let the thought bounce around in the back of my head. Spurred on by the recent interest in js-git, I recently restarted the journey towards an in-browser git, in order to help creationix deliver the best possible js-git. Newly armed with browserify and the small-module ethos, I've come much closer to a working git in browser and Node, and in the process have really put browserify and its shims through their paces. This talk will be comprised of:
A quick intro to the git object model and transport protocol How browserify and the small module ethos have enabled great successes in the project. Difficulties encountered in the process, both with Node.JS itself and with browserify, and how I've worked through them. How I've diagnosed and worked through various performance issues. Where is this project going?
The node.js community is growing at an amazing rate. At the time of writing there was 27,757 modules publised on npm. Have you ever stopped to think just what you are putting into your project when you npm install somebody else's module? Do you trust that code? This is an insane project to find out the answer to that question. This talk will introduce the nodesecurity.io project, it's goals, current results in hopes of inspiring involvement and receiving feedback directly from the node community!
Sails.js makes it easy to build custom, enterprise-grade Node.js apps. It is designed to resemble the MVC architecture from frameworks like Ruby on Rails, but with support for the more modern, data-oriented style of web app development. It's especially good for building realtime features like chat. Sails empowers UX and design teams to build hi-fi prototypes in no time without waiting for the back-end to be finished. This means focusing more resources on the user experience, which means better products. One Sails.js project at a time, companies move their legacy architecture over to a simpler, more efficient Node.js cloud. Each new client-side code base is more maintainable, since it’s built using the universal language of the internet: a RESTful JSON API.
In this talk, I will start with a crash course on the basic messaging patterns
request/reply and then show a real example of how we have combined these patterns to build a custom message broker that we have used to build a fully distributed and modular architecture for the Harp Platform. I will share details about what we have learned and common pitfalls to avoid when building a messaging system for your needs.
Basic outline for the talk:
how messaging can be useful crash course on the basic message patterns how to get started with zeromq/axon common pitfalls when in production proven trade secrets we have learned
By the end of the talk, my hope is that everyone will have a new appreciation for what can be achieved with massaging and will know where to begin when attempting to integrate messaging into their next project. I feel this aspect of building modern web applications is often overlooked and viable techniques need to be shared and discussed.
As programmers we are wizards. Our job is to manufacture super powers. Like with the Manhattan Project, wielding such great technological power entails moral implications which we ignore at our peril. But we can recognize this power, embrace it, and use it for great good. Node gives us a tool kit to confront great problems and share in solving them. Specifically: radical decomposition, horizontal reuse, and positive community norms around testing and documentation. Audience participation requested: be prepared to share your expertise in a real world problem space like education, civics, social equity, environmental conservation, healthcare, or your own favorite "intractable" problem. If time and scheduling permits, I'd love to have a series of lightning talks in which people could introduce other developers to the problem domain.
Learn how easy it is to create your own monitoring system! Hobbyist components and a rich 'maker' community puts advanced system designs well within the reach of your average software wonk. Stop planning and start building! Our case study is 'GroMon', a solution for monitoring a tiny indoor lettuce garden. Our wireless sensor keeps track of temperature and humidity, if the plants get too hot or too cold then we are notified via text message. We will discuss the design goals and architecture, as well as component selection, prototyping and debugging steps. With a little bit of programming skill and patience, anyone can build this network. Learn how to easily extend this solution for your own use. Our stack is Node.js running on a Raspberry Pi. We connect over Bluetooth to an Arduino hosting a single sensor. All components can be purchased off-the-shelf, no soldering is required and the total cost is around $80. Code and bill of materials is available on GitHub, let's hack!
Join us for another installment of "Realtime Hardware with Node.js" as we take a look at just how exactly one should go about making a fool of themselves on stage with a bunch of electronics. We will cover the basics of getting started with hardware, demonstrate some cool tech, and conclude with a super rad (slightly hazy) and interactive dance party of epic (modest) proportions — if everyone cooperates. Questions are welcome throughout the presentation, and audience members are encouraged* to participate.
bribed with stickers
A series of short five minute presentations.
Pub/sub has been growing in popularity for various pieces of infrastructure due to how much bigger our networks are getting. The publisher being able to completely ignore if there is anything listening or not and just fire off messages means that if a part of your infrastructure goes down it doesn't bring down the other parts. I'll be using my bot, ZenIRCBot, as a case study for pub/sub that is more approachable. ZenIRCBot connects to IRC then sends the things it receives into a redis pub/sub channel, it also listens on a pub/sub channel for things to do such as sending messages to IRC channels. On the other side of these channels are services that listen for events, react, and send back things to do. Or maybe they just listen or just send things to do, there is no reason why they have to both listen and send commands, this is the beauty of this services based model. This talk will be comprised of:
A basic intro to Redis and what it is capable of. What pub/sub is and some basic examples. The case study: ZenIRCBot Problems and other various difficulties I've faced. Where is this project going?