#nodefly buzz

Every two weeks NodeFly continues in its mission to spread the word of Node.js and how incredible it is. We do that by profiling cool, interesting and fun uses of Node.js in various products and projects.

Today we are scoping out NodeBB, which calls itself the Discussion Platform of the Future. We like bold statements like that, so we reached out to NodeBB’s team of three: Andrew Rodrigues, Julian Lam and Barış Soner Uşaklı.

NodeFly: Tell us about NodeBB. Why is it the discussion platform of the future? 

Andrew: It feels like forum software has been evolving slowly; web 2.0 features that are almost standard across modern software just do not exist on older forum platforms... at best these features seem tacked on. We haven’t seen much progress in responsive forum layouts and its quite evident to anybody doing a simple Google search for any given topic and running into a forum website. It’s ugly and impossible to maneuver without pinching and rotating ad nauseum. We believe that starting fresh with a clean slate will allow us to build a modern platform that will hopefully help shape forums of the future.  

NodeFly: Can you walk us through the early genesis of NodeBB? Did the Node.js portion come first, or the BB?

Andrew: We definitely had a passion for forums in the first place. I personally spent several years developing modules for phpBB, and we realized one day that maybe we could try to build something better than the platforms we were using. I guess the NodeBB name is kind of a tribute to phpBB from a lot of fond memories in that space. From that point on I think Node.js was an obvious choice for us given that we were primarily Javascript developers.  

  NodeFly: What made you decide to go with Node.js as the foundation of this platform?

Julian: Node.js was a great fit as a platform for NodeBB because it allows us to really produce something groundbreaking in the realm of forum software. The forum ecosystem is already a crowded one, but they all happen to run on the LAMP stack, or a similar variant. Our deciding factors were the performance benefits offered by Node, as well as the amazing community, both in terms of feedback, and in terms of the wealth of modules available to use.

NodeFly: Did Node.js bring any problems that you had to solve? 

Julian: The biggest problem was (and still is) adapting our programming style to Node.js “standards”. Coming from a PHP/js background, there is a bit of a learning curve, but once you understand the basics (such as event loops, etc), everything else becomes much easier. There are user-created modules for doing virtually everything, so in many cases, our development time was reduced. The PHP community is already embracing the idea of re-usable modules through programs like composer or bower, although the DIY mentality is still well-ingrained, and new programming practices are just chipping away at the monolithic iceberg that is the PHP development methodology. We found that using Node.js was like a breath of fresh air.  

NodeFly: Our users are definitely curious about how things are built and how performance is monitored. Anything you can share in those areas?

Barış: NodeBB in particular was built following aspects of the lean startup mentality. We built a minimum viable product, and have recently begun iterating on user feedback, in order to build a product that users want, not a product that we think users want. Luckily for us, our feedback tells us that we’re on the right track! In terms of performance, we are still actively looking for a system simlar to blitz.io, but we have not found a comparable solution yet, especially one that can reliably benchmark websocket performance.  

  NodeFly: You currently have an Indiegogo campaign going, right? Why did you go this route?

Barış: NodeBB is open source and free to use if you want to host it yourself. To further develop and add more features we went the crowdfunding way. Crowdfunding also means backers will be able to help in shaping the product which is very important for us. We want to build a product that people will want to use.  

NodeFly: We are stoked to hear you say NodeBB is free and open source. How did you come to this decision?

Andrew: We believe by open-sourcing NodeBB we can create a better product which in turn will be used by more people. Wordpress went the open-source+SaaS way to great success.  

NodeFly: Finally, anything you can share in regards to future plans for NodeBB or Node.js in general?

Julian: Right now, NodeBB is an open-source project that anybody with the technical know-how can set up. We want to go one step further and allow anybody to set up a forum at the press of a button. To that end, we’re working on releasing a software-as-a-service web application that will be tightly integrated with our hosting servers, so clients can focus on customising their forum and building their user base, while leaving all of the technical set-up and maintenance to us. The free and open nature of NodeBB allows anybody to customize and contribute back to the project, and we’re always in need of Node.js developers to proofread, extend, and awesome-ify our code, so if you like what you hear, join the project community!

Thanks to Andrew, Barış and Julian for their time. You can check out their Indiegogo campaign at this link and then scope out their web site for more info about NodeBB. 

http://www.nodebb.org/

Do you know of any cool, creative and fun uses for Node.js that you think we shoulde profile? Just email us at [email protected] to let us know. And if you want more NodeFly Buzz you can search our blog for more articles at http://blog.nodefly.com.

Every time we profile something cool in our NodeFly Buzz section, we are more and more impressed at the full potential of Node.js.  That’s why we continue to share all the cool, fun, awesome products.

This was especially true when we discovered Epiphany. This control system describes itself as a universal remote, an automation system, a lighting control system, a security console, an energy manager, an on-screen interface, a mobile app, a development platform, and a Ubuntu live image.

Still processing that amazing list? Us too. That’s why we chatted with Concierge Solutions’ CTO Jonathan Gould to get clarification and the scoop on Epiphany.

  (A look at some of the hardware you can use with Epiphany.)

NodeFly: I was about to ask you to tell us what Epiphany does, but then I remembered your feature list and started wondering if I should ask what it can’t do. Can you give us a rundown on Epiphany?

Jonathan Gould: The idea of Epiphany is to create an automation platform that is hardware agnostic and open for development. We were commercial integrators for 10 years before going back to our development roots, so we've spent a lot of time in people's basements trying to make all the other automation products out there do what our customers want. We realized a few years ago that those other systems are limited by the hardware choices the manufacturers made and are too closed for a developer to really have the flexibility to innovate.

 So, what does it do? Well, at the core, it boots up on just about any machine and provides a means of devices communicating. We defined a way of describing controllable devices (our driver stack) then connected each of those drivers on a central message queue. Beyond that, we started building drivers for the more common devices on the market - lights, thermostats, door locks, security cameras, alarm panels, and so on. Layer on top of that a theme-able HTML5 user interface and custom browser apps, and we believe you have a pretty powerful automation package.

NodeFly: The entire feature list looks pretty incredible, but are there any specific features that really have you excited from a user perspective?

Jonathan Gould: I'm a big fan of making things talk that shouldn't really talk, so for me it's the developer API. The possibilities are endless and we think a community will grow up pretty quickly sharing their innovations.

NodeFly: How exactly does Epiphany’s home automation software work?

Jonathan Gould: At the center is a scalable, reliable message queue. That's where most other automation systems fail. They build a monolithic application that has everything running in one place. That's not very scalable, and when you add new code for a new feature, you endanger bringing down the whole system.

We use the message queue just to move messages around the home - it doesn't really care what's in the message, just that it gets where it needs to go. That gives us scalability because the rest of the code can be distributed across hardware on larger systems and reliability because new code lives in new places. We don't mess with the old code when we build new features.

The rest of the system "hangs off" of the queue. Each piece is built as an individual server, connected to the queue and processing and sending messages. Servers are where the custom logic to control other systems live. So when a generic "light on" comes from the message queue to a server, it creates the command in whatever custom lighting protocol the lighting system understands. These servers are built in Node.js.

On the other side of the queue is the user interface. Built with Sencha Touch (all object oriented JavaScript), it displays controls for each of the running servers on the network, and can be modified by the end use through our theming engine. Epiphany comes with an on-screen browser so you can access the UI on your television, and there are iOS and Android browsers too.

(Temperature not quite right? Epiphany can help.)

NodeFly: What’s the background on creating it? At what stage did Node.js enter the picture?

Jonathan Gould: One of our requirements from the beginning was that the servers be easy to develop in place without us distributing compilers, libraries, etcetera and the developer setting up a complicated build environment. We originally built the servers with PHP CLI. It worked well, but as we developed the UI SDK along side it, we realized how cool it would be to have both sides of the system written in the same language (switching back and forward between JavaScript and PHP was becoming a pain). That’s where Node.js entered the picture.

NodeFly: What was the main reason you incorporated Node.js?

Jonathan Gould: Unity. Our UI and Server SDK's have virtually the same calls into the driver stack to control things. The developer does everything in JavaScript and we take care of all the communication and configuration in between. The workflow is so much simpler now that we are working in one language.

NodeFly: What challenges did you face in the development process, and how did you work to ensure quality and performance issues were taken care of?

Jonathan Gould: Automated testing has always been a challenge for web developers. We've managed to build a continuous integrations system with automated test using some great tools (Jenkins, Mocha, and Selenium). Every night a new build of Epiphany spins up in VMware and Mocha does its thing. JUnit reports push back up into Jenkins and we see every morning when we get to the office what we broke the day before.

NodeFly: We wanted to congratulate you for your milestone of completing version 1 at the end of May. Any tips of tricks you would pass along to our users when building with Node.js?

Jonathan Gould: Build your tests and test mechanism early. We started too late, and when we sat down to make a list of tests that needed to be written, it was in the hundreds. I think it would have been easier to write these as we finished sprints along the way. I guess we were just too excited to move on to the next piece of code.

NodeFly: Things are early for Epiphany now, but we were wondering if you had any longer-term plans you wanted to share?

Jonathan Gould: The goal for 1.0 was to reach a level of functionality that matched the other systems out there, but to do it in a way that we would be free to innovate beyond that. We met that goal, and now we have some exciting things brewing in the lab. Unfortunately, that's all I can say...

We’d like to thank Jonathan for talking to us about Epiphany. Check it all out on their web site today! 

Do you know of any cool, creative and fun uses for Node.js that you think we shoulde profile? Just email us at [email protected] to let us know. And if you want more NodeFly Buzz you can search our blog for more articles at http://blog.nodefly.com.

Node.js rocks, and we want the world to know it. And to help spread the word, NodeFly profiles cool Node.js projects or products every two weeks in NodeFly Buzz.

While we were using our patented Nodevision to find new Node.js things, we found this promising statement: “Datahero connects directly to the services you use everyday, giving you instant access to your data no matter where it is.” Intrigued, we investigated and chatted with Chris Neumann, DataHero founder.

NodeFly: The NodeFly team certainly likes superheroes. Can you tell us about Datahero and how it performs superheroics with data?

Datahero: Datahero’s mission is to empower anyone to get insights from their data. There’s nothing to download or install - you can connect to online services you use or upload data from your computer and, within minutes, get the answers you need. We think data-driven decisions for the masses are pretty heroic.  

NodeFly: We like that you’re making data accessible to the average citizen. How are you making this happen?

Datahero: Datahero represents something that’s never before been built: a data analytics platform designed from day one to be used by literally anyone. This meant making usability the centerpiece of our development process (something that’s rarely done in the data world). Using customer-centric design from the beginning makes all the difference in terms of ease of use, especially for people without technical backgrounds.

NodeFly: You’ve built your product with Node.js. What made you decide to go in this direction?

Datahero: We knew that to realize our vision meant we’d have to push the envelope in both UI and data analytics. Using Node.js allowed us to use Javascript throughout our codebase and to develop in an environment optimized for the type of asynchronous workflows we were architecting, helping us to realize both those goals.

NodeFly: What opportunities did Node.js provide?

Datahero: Beyond performance, the biggest opportunity that Node.js gave us was the chance to do more with a smaller team. Having Javascript both client- and server-side definitely cut down on a lot of unnecessary development. Moreover, whereas other server-side technologies have “adapted” to the needs of today’s complex web applications, Node.js is designed for them. It lets us do more, faster.

NodeFly: What has development been like with Node.js? Did Node.js itself throw any challenges your way?

Datahero: We had some struggles early on with limitations in Node.js’ database support at that time (which was pretty significant for us, as a data analytics platform). But that’s the price you pay when using a new technology. The Node.js ecosystem has improved by leaps and bounds since then, and we try to do our part to contribute. For example, we’ve contributed a number of authentication plugins to everyauth.

NodeFly: Datahero manages to effectively communicate with Dropbox, Google Drive, MailChimp, Stripe and others. Can you tell us about how you managed to interact with such diverse products?

Datahero: We knew that we had to make it incredibly simple for our users to be able to quickly and easily access their data from anywhere. We built something called our “Data Decoder”, which uses machine learning algorithms to classify the data. Each time you upload or import something, Datahero analyzes the structure of the data to identify headers and automatically detect datatypes (countries, currency, email addresses, etc.). By combining that with custom integrations with our partners, Datahero enables our users to import any data in literally one click!

NodeFly: You’ve received some great reviews. What have Datahero users said about your product?

Datahero: We’ve gotten some really encouraging feedback on our design and usability. One user recently wrote that Datahero “...was my best experience of using a new product since I sat for the first time in an Uber cab” (which is pretty high praise if you’ve ever used Uber!). People who are not familiar with data analysis find that they can get insights quickly and easily out of Datahero, which is exactly what we’re going for. There is obviously always room for improvement and we appreciate all the feedback and suggestions we get from our users.

Overall, we’re spurred on by the enthusiasm we’ve seen so far; it makes us feel like we’re moving in the right direction.

NodeFly:  Any future plans for Datahero that you’d like to share?

Datahero: We push out a new release each week, so we’re constantly building and improving Datahero.  Beyond that, we’re working on a number of exciting features that we’ll be rolling out this summer, so stay tuned!

And with that, we encourage you to transform your data visibility from mild-mannered to heroic. Just go to http://www.datahero.com and try it out.

NodeFly wants you to monitor your Node.js development from the beginning, which means we want you developing with Node.js. To support and spread the Node.js love, we profile fun, cool and innovative uses of Node.js every two weeks in NodeFly Buzz.

We recently heard about Insto, an API that brings “real-time web to your application, in the simplest way possible.” We tracked down Matt Collins to learn more about Insto. Matt describes himself as a 29-year old developer for centralindex.com who has left PHP behind (almost!) for the greener grass of Node.js.

NodeFly: Tell us about Insto.

Matt: Insto is actually my final year university project, I had to create a complete IT system and document the whole process. Most people in my class went for the classic website / database approach, but I have been making websites for almost a decade now and wanted to do something a bit more 'out there'. I had been doing some Node.js / websocket stuff at work and thought it was really interesting so I hoped to expand on that with my project.

I think most developers still really get a buzz from the simplicity of 'clicking this button makes this other thing happen', and this is a new and pretty cool way to do just that.

NodeFly: Insto makes real-time communication possible via HTML5 Websockets and Node.js. Why did you go with these two?

Matt: Well as I mentioned earlier, I had already been doing a bit of work in this area and really liked the whole Node.js thing. My background is in PHP and it is a big departure (although the fact it's javascript does make it easier!) at first, but the non-blocking/event based model of Node is perfect for this kind of app. Websockets was, I think, the obvious choice for doing this in the browser.

NodeFly: Did you have any particular challenges making your product work with HTML5 Websockets and Node.js?

Matt: The capabilities of some browsers to handle the Websocket side of things was a bit of a potential stumbling block. Fortunately, one of the great things about Node.js is that there are a lot of clever people doing lots of clever things with it and the community is amazing. I used the fantastic Socket.io (http://www.socket.io) module to handle all of the Websocket compatibility stuff.

Without that, this whole project would have taken a lot longer.

Also, I am usually the person using these services and tools so it was odd being on the opposite side of the process. I found myself having to re-write the client library a few times to make it more user friendly because even tho it worked fine, it wasn't the easiest thing to use for people who had no prior knowledge of the service.

NodeFly: Some folks challenge the use of the term “real-time” when it comes to Node.js. Do you have any thoughts on that? 

Matt: I haven't noticed this before, and I guess it depends on how you define "real-time". This service was designed to allow users to send/receive data as quickly as possible and I think it achieves that. There is always going to be some lag, some kind of delay, but in my opinion Node.js is ideal for this kind of thing. Microsoft use it for their real-time stuff I think, so it can't be too bad!

NodeFly:  We tend to agree with you. Real time can be loaded term, but Node.js is known for ability to respond as close to immediately as you can get.

You aim this product at developers, providing the system so that they can focus on app creation. IT’s probably too early to ask, but have you gotten any feedback from developers about Insto?

Matt: Unfortunately not. Because I have been so busy with the university side of things I haven't had much of a chance to try and get this out there and get people using it.

I would really love to get a few more people signed up and using it in anger to see what it can do, and of course there will be suggestions from other people for new features and bug fixes. I plan to keep on maintaining and improving Insto for the foreseeable future so I hope people do get in touch and get building some cool apps off the back of it.

NodeFly: We like that you provide options for what Insto can do with your Javascript library and rest API, but also that you say your users can maybe come up with better options. Have you heard back about any uses that have surprised or intrigued you?

Matt: Again, no, not really. There are a couple of people signed up and I got in touch via email asking if they had used the service and what their plans were, but they hadn't started their applications at the time.

I had interest from one guy about moving his online card skirmish game from an AJAX / database polling model to use Insto as he was planning to expand but that has yet to materialise.

I do think there will be some people out there with some cool ideas though, and I look forward to seeing what they can create!

NodeFly: Do you have any further functionality that you plan on introducing in the future?

Matt: At the moment there is only a client library for the browser, so there are plans for a Node.js Insto module.

I also have a few ideas to improve functionality for the users, make things a little bit easier. Sometimes it would be nice to have some kind of temporary data store, to store the current state of the application (i.e. a chat history, or the current position of some on screen element) for the connecting users to sync up to, so I am having a think about that.

Like I say, I am hoping to keep developing Insto so any ideas will be well received! 

NodeFly: What was your strategy during product development for keeping things running smooth? Did you monitor your product or have any special QA in place?

Matt: I don't think it would come as too much of a surprise to learn I used Git for version control, but apart from that I like to work in an Agile/Scrum way. Focus on the immediate next step and get that working before moving on, although it was important to keep one eye on the bigger picture. I have found that you get better at setting your goals and planning your work the more you do it, nothing quite like the experience of screwing something up and having to start again!

I had a few simple test scripts that I used to check that all the functionality was working, almost like unit testing but not quite as formal. This just made sure that everything was working when I had finished with a new feature or bug fix, although I have to admit that it didn't catch everything!

We’d like to thank Matt for telling us about Insto, and encourage you all to check it out if you want.

“Why Node.js?” is a very valid question. We answer by showing off cool products, pages or projects that use Node.js in our “NodeFly Buzz” every two weeks.

This time around, we are looking at The Node Security Project. This project asks: “We believe that the node.js core is well audited, but what about the modules on npm?”

To ponder this question more fully, we spoke with Adam Baldwin. Read his bio before you react to the name. Here's what he had to say about himself.

“I’m the team lead at Lift Security where I get to hack web apps and the CSO at &yet where I get to help an amazing team of developers build web apps (yes it’s a bit jekyll and hyde and I love it). The rest of my time is spent being a husband, father, and correcting people that think I starred in Firefly and Chuck.”

Ready? Let’s talk about the Node Security Project.

NodeFly: Can you tell us about the Node Security Project?

Adam Baldwin: The node security project is an ambitious (some might say impossible) project to assess the security of the modules published on npm. A lot of security projects stop at "let’s find all the vulns." I really want this to be a positive experience with getting vulnerabilities fixed, enable developers to know when they are using a module that may introduce vulns in their environment and most of all help educate node.js developers about various security topics.

NodeFly: You want to audit every single module in npm. Can you explain how you developed this goal?

Adam Baldwin: As the CSO at &yet it’s part of my job to think about ways in which the software we build can get compromised. We trust a lot of third party code. I could have stopped there and just audited what we use, but I wanted to have a bigger impact on the community.

NodeFly: You are quite open on your web page, telling everyone “we need your help”. Can you put your goal into perspective? How many man-hours might this take?

Adam Baldwin: Specifically we need the help of security researchers to validate vulnerabilities and we need the help of developers to write patches for projects that have been long abandoned or the project needs help fixing the bug. This isn't a point, laugh and move on security initiative, we really want to make things better. Also at the time of writing this there are 28,254 modules and that number is growing fast. There is just no way one person can audit this much code. It has to be a community effort. Another way to look at this is the fact that it will never be done. Security just doesn’t work that way. It’s a continual process of building, assessing, improving and so on.

NodeFly: Have you audited any of the modules yet? Can you share any details about the initial results?

Adam Baldwin: We are taking a bit of a different approach and we aren’t auditing one module after another for all the things. We are looking at a specific pattern across the entire module base. This way we can refine that pattern and apply it to new modules and updated modules in a more automated fashion to try and keep up. The auditors are currently working through the first initiative, child_process.exec. Which if used improperly can allow for command injection. At last count we have found 9 vulnerabilities. In one day.

NodeFly: How important is this project to the growth and future of Node.js?

Adam Baldwin: I can see this project helping with enterprise adoption. If we find a lot of things, we get a lot of bugs fixed, if we don’t find much, one might attribute that to the level of code being produced by the node.js community. Another is to empower developers to know if a module they are using contains a known problem. This isn't about creating trusted modules, just that we have looked for certain things and hopefully empower developers.

NodeFly: What’s the initial interest in this project been like?

Adam Baldwin: Amazing. Both from the node core community and from security researchers. I'm very grateful.

NodeFly: Why the focus on Node.js? Could this have been directed at any language?

Adam Baldwin: I enjoy node.js so I wanted to give back in a way that I’m skilled at. It’s a fairly new community and with javascript making it easy for front-end developers to move into the backend, I want a lot of the mistakes we have leaned in other languages to not happen again if we can help it.

NodeFly: Besides the security project, is there anything else Node.js-related that you are working on?

Adam Baldwin: I maintain the helmet project, an express middleware for security headers with secure defaults. I also help with development and security on And Bang, a team samepagification app built on node and redis.

NodeFly: Thanks for discussing this important project with us. We look forward to watching its progress!

If you would like to learn more about the Node Security Project, check out the web site at http://nodesecurity.io/ or write at [email protected]

The gospel of NodeFly is to encourage monitoring your development from the beginning, and part of our mission is supporting and spreading the Node.js itself. As a result, we are always curious about fun, cool and innovative uses of Node.js.

We discovered Atomic Brawl, which describes itself as “a game of strategy, collection, and jack-assery, where you compete against others for the right to call yourself “’That Guy Who Is Good At That Game’”. Sounds fun enough to pique our curiosity.

We talked the creators of Atomic Brawl and heard some words and phrases we’re always open to hearing: laying a trap, tropes of Tolkienesque fantasy, and shadow classes. Read on and enter the Atomic Age.

NodeFly: With Atomic Brawl you’ve got, and I quote, a “competitive collectible tactics game.” Tell us a little about the game and playing experience.

Atomic Brawl: Atomic Brawl is a little difficult to describe in that you can do so simply as Chess, lots of pieces - or as verbose as calling it an "asynchronous multiplayer browser-based collectible strategy and tactics game", but for those familiar with the games we would say it's like Final Fantasy Tactics hooked up with Magic The Gathering and made a little online baby.

The core game experience is you managing an army battling against someone else with theirs, both sides attempting to destroy their opponent’s core. Game turns can be taken over the course of several days, whenever you have time; or if both players are active, in about 15 minutes. All games are playable in your browser without any download required. Furthermore, you can start a game in your browser, continue it on your mobile device, and seamlessly take turns on either throughout your day.

At launch we plan to have about 180 different cards that you can take into battle, each offering very dynamic interactions and interplay. Instead of constructing a game where the biggest number wins, Atomic Brawl attempts to create a flexible and dynamic game system where we could go wild with ideas and have cards carry through with very complex mechanism. For a simple example, you could lay a trap (which would be hidden to your opponent) that when triggered allowed you to control their Brawler; once done, because you have control, you could then use this card to attack their own units and once that wraps up play another card allowing you to sacrifice this card and gain life. 

Finally the game is collectable. At start you have access to a limited number of cards. As you play you gain cards, and in-game currency allowing you to expand your collection and increase your strategic and tactical options.

NodeFly: Your blog provides a nice behind the scenes look at the development of the game. In addition to the fantasy element, there is also a quirky sense of humor. We definitely appreciate that at the NodeFly offices – can you tell us how that sense of humor helped shape the game?

Atomic: We felt like too often with tactics game, and potentially games in general, developers too often fall into the tried and true tropes of Tolkienesque fantasy, future war, or world war N - we feel this is brain numbingly boring. We wanted something more interesting, we thought if we could create a world that was similar to present day reality but quirky as heck that would be a more captivating and fun world to play around with. Drawing from the real world also gives us a broad range of ideas to pull from, as we're really free to do nearly anything we want - regardless of how crazy it is. The main source of inspiration for this approach was a fantastic classic game called Earthbound (or Mother 2 for the hard-cores) which really showcased how you take the world we live in, add some crazy, and make it super compelling.

  NodeFly: You built the game with JavaScript and HTML so it can work on mobile devices and PCs. Can you geek out with us and tell us about development and why you decided to use JavaScript and HTML?

Atomic: Geeking is what we do best! We've been developing this game for an almost embarrassingly long time at this point. We started just over 2 years ago and have had quite a few twists and turns along the way.

Working our way from the client backwards, our client, as mentioned before, is completely browser based. We construct the client UI using pure HTML elements. The animations are all done using CSS3 state transitions. We've constructed an abstraction layer on top of all this to simplify working with this such that we could swap out a canvas based approach (as we did at one point) if we every decided to go down this road.

The client talks to the server using a combination of REST based services and Websockets. We utilize basic REST services for things like leaderboard retrieval, deck management, game creation, login, logout, etc. This is all implemented in what we call the metagame server, which is a Node.js based server utilizing Mongo on the backend for state management. 

Websockets are then used to connect to, and communicate with, the game server. The game server is another Node.js server responsible for receiving game inputs from the browser, executing them, then returning the results to the client. In this sense the client is very "dumb" in that no logic is performed there, it simply relays to the user what input is allowable at any given time, submits what the user would like to try to do, and waits for the server to tell it what the result was. The browser also utilizes localstorage to cache data in order to reduce the dataset you need to retrieve when you connect to a game you've played before.

Finally, we also have 3 other Node.js server types to perform other functions. Firstly we have a "notification" server, which notifies users when there's an action they can do on the site. Next we have a "matchmaking" server, which is responsible for finding games for any connected user and intelligently matching them based on the users skill (which is implemented using the glicko2 algorithm). And finally we have our "overseer", which is responsible for spinning up new game servers when required. All servers communicate with each other using 0mq.

All of our server and client code is done in coffeescript. In doing so we share an incredible amount of code between both which is a huge win for software simplicity. 

Our infrastructure is all hosted on AWS, using Amazon Cloudfront to serve our game assets and javascript files. 

NodeFly: Any particular challenges using them?

Atomic: You don't work on a project this long without challenges :) Some of our bigger challenges recently have been related to getting our servers running and processing games in a fast and memory efficient fashion.

The V8 interpreter is an incredible piece of software, but you can cause it undo stress if you're not careful. Understanding how V8 uses shadow classes, allocates memory, and executes code has been very important in squeezing everything out we can. Once we started profiling and paying attention to these things we were able to pinpoint several places where we were able to reduce memory consumption by 2-3 times, even 10 times in some cases, and also reduce the processing time dramatically.

NodeFly: Right now you are still building. When are the floodgates opening? When do you expect Atomic Brawl to go public?

Atomic: At current we're in closed beta with about ~150 users, who have helped dramatically to improve the quality the game. We have a few big ticket items remaining, and a lot of polish left to do. We will launch in the summer of 2013. 

NodeFly: Who should check out this game?

Atomic: Everyone! All ages, genders, and experience levels! Some of our happiest players picked up the game after not playing games since childhood and they are loving it, although we have plenty of gamers as well. The breadth of appeal this game seems to have on people has surprised even us.

We’d like to thank Atomic Brawl for giving us a look at their addictive game and recommend you get ready to start playing by visiting their web site.

“Why Node.js?” some folks ask. In response, we like to show off cool products, pages or projects that use Node.js in our “NodeFly Buzz”. This time around, the NodeFly Buzz focuses on Jean-Clause Levy’s Chocolate. Chocolate is a simple webapp framework built on Node.js using Coffeescript.

In the 1980s Jean-Claude Levy brought “Tennis Championship” and Broderbund Software’s “Showoff” to Apple and the legendary action-adventure game “Prince of Persia” to Atari. He earned an M.S. in Computer Science at the Florida Institute of Technology in 1988. In 1991, he followed Steve Jobs adventure at NeXT by creating a NeXT Center in Paris. From 1997 to 2000 he helped top French companies use Microsoft technologies as Application Development Consultant. He was Information Technology Manager at Visiolis, the first company that enabled remote online expertise in the French motorcar insurance industry. For the last ten years, Jean-Claude Lev has been an Independent Consultant and Software Author in Paris, France.

That is one full CV. For now, though, we want to talk about Chocolate.js. 

NodeFly: What's the background on Chocolate?

Jean-Claude Levy: I have a long run project called Intentware. My goals are enabling non-programmers to easily program and to create a better experience with office-like apps. My main concerns were: having only one programming language to deal with servers, clients, database, user interface, workflow; having a programming language with a nice balance between imperative and functional orientation, and; having an immediate computing environment where, like in Excel, there is no time between intention and realization. In 2011, after an exploration in the Python world, I discovered Coffeescript. It was the language I was looking for. At that time, I also took some time with Node.js and I liked its simplicity. I, then, (re)started to build Intentware using Node.js and Coffeescript. I quickly needed an online web development environment, so I created one. I called it Chocolate. Why? Because I don't drink coffee!

NodeFly: Makes sense! Can you tell us why folks would want to use this framework?

Levy: Chocolate wants to make programming accessible. This means, anywhere you have a screen connected to Internet you can continue working on your code. And anytime you have an idea, or a question about your code, you can immediately test it. With Locco and The Lab, Chocolate allows you to edit every source code file online and test live code. Another basic idea is: specify, code and document should be one and the same activity. Chocolate goes in that direction with Specolate and Doccolate, which make those activities closer to each other.

Chocolate is free, open source and wants to stays as simple and close to standards as it can be. Chocolate can be used in conjunction other tools and framework like Express, Derby or Meteor.

I hope people will like Chocolate and help me make it clean, simple, and complete.

NodeFly: We love the naming conventions of Chocokup, Specolate and Doccolate. Can you tell us about these features and the other cool features of Chocolate?

Levy: As you will see Chocolate integrates great technologies created by really great guys. I discovered Coffeekup just after Coffeescript. It allows you to write HTML code using a pure Coffeescript syntax. It's what I was looking for: only one language. So I used it in Chocolate. However, I prefer panel oriented UI than page oriented UI, so I extended a little bit Coffeekup to introduce this panel orientation. And as I was looking for a new name I decided put some Chocolate in every name! So here came Chocokup. And now my templates are kups of chocolate! 

Jeremy Ashkenas showed me Docco, a nice tool he created to produce good-looking documentation from your code. And as I transformed it to be available client side, it became Doccolate. Now, when I want to document my code, I can immediately see if it's readable and useful.

And then, there is the spec part to complete the SpeCoDoc trilogy. I chose Jasmine.js so that I can have Behavior (or Test) Driven Development integrated in Chocolate. I made it available as simply as I could, client side and server side. With a nice chocolate layer it became Specolate. Of course it's not complete but I find it really useful to program and not only to test.

Other nice features in Chocolate are The Lab and Newnotes. The Lab is a place where I do pair programming with myself. I write code in Coffeescript and as it is translated in Javascript I can have a different look at it. It has a Chocokup view where you type HTML with Coffeescript syntax and see the HTML produced and the final result in a live view. There is much room for improvements but I already like it a lot. I also use The Lab to debug some code with the live debug view. It tries to mimic the tools shown by Bret Victor in his famous lecture (Inventing on Principles). I have to rewrite it for Javascript, to be more complete and also available server side, but it has already proved to be really useful. Finally, Newnotes is the tool I'm currently working on. The purpose was to have a place to note where I am in my development, test or debugging activities when I have to stop working on it. But it quickly became a project on its own. The most impressive part is currently that it can display a branch in my notes as an Impress.js presentation. I used this with my Webapps development students.

NodeFly: You built this with Coffeescript. How did the whole development process go?

Levy: I started with Node.js and Coffeescript installed on a Debian 5.0 server virtual machine, plus Notepad++ and Filezilla installed on a windows 7client machine. Online editing was my first goal. I selected CodeMirror and Ace. I started with the first one and then changed my mind and used Ace. I also decided that my main language would be Coffeescript and that my server would run with the Coffee command. A monitor service would see when source files change and then restart the application. Then, gradually, Chocolate appeared. It included:

 Online source editing

 Jasmine basic integration

 Git integration

 Docco integration

 Locco protocol development

 Coffeekup integration

 Coffeekup extended (Chocokup)

 Basic client side 'require' introduced

 Session and registration introduction

 Source file sync between clients with polling

 Studio creation to integrate all those tools

 Live debug (Bret Victor lecture) introduced

 Immediate Chocokup available

 Interactive Docco introduced (Doccolate)

 Jasmine improvements (Specolate)

 Newnotes development

 Impress.js in Newnotes

Also, I wanted to make it look like chocolate tablets and make it available on Github and npm.

NodeFly: What were the benefits of creating this with Node.js and Coffeescript?

Levy: It creates a basic, simple, lightweight and immediate environment.

Node.js is modular and the mono-process, mono-thread and asynchronous orientation is relaxing. It made me leave the Microsoft environment with a great relief. I could say that although I've had written tens of thousands of lines in JavaScript, I was not really good in JavaScript. Coffeescript helped me discover many things that were obscure to me.

NodeFly: What have your users said about Chocolate?

Levy: “It's literally chocolate!” Many find it impressive and would love to use it at work, but most are stuck to heavy tools and environment. I gave it to my students who learn web app development. They simply use it, and make good progress. I must say that I made them first use the c9.io service which is amazing but had load problems. With Chocolate it was really easy to share a virtual machine with 20 users developing online at the same time. It's light. I'm now looking for feedback, ideas and help.

NodeFly: What does the future have in store for Chocolate?

Levy: Many, many things. Simple and innovative database integration. Automatic user interface. User and security management. I will continue to go in the same direction: making it possible for enthusiasts to program. I'm only at the very beginning.

NodeFly: Sounds like you have a full plate. Do you have any other Node.js projects in the future?

Levy: Yes, I want we recreate all Office-like tools we use. I'm really not satisfied at all with the one we have. The first step is with Newnotes that could really be a breakthrough. I want to thank you for your interest and your questions that help me think and speak about Chocolate! NodeFly: Our pleasure!

You can check out Chocolate and try out a demo at https://chocolatejs.org/ to see Chocolate UI in action.

NodeFly is continuing our mission of spreading the Gospel of Node.js itself. As always, we use NodeFly Buzz to profile a project, page, or company that uses Node.js in fun, cool and innovative way. Today we are looking at BirdReader from Glynn Bird.

NodeFly: Can you tell us about the origins of BirdReader? 

Glynn Bird: On the 13th March, I woke up to find that Google was planning to close Google Reader, the RSS aggregation service that I used every day. I started looking around for alternatives but didn't want to beholden to another website that might close its doors at short notice. So I decided to write my own. Something that would do just what I wanted to do, for my own use. I wished I'd called it BirdFeeder now!

NodeFly: The app is a full-featured newsreader. What features were critical, and which did you decide would be nice additions? 

Bird: I needed BirdReader to be a website that was "responsive"; allow me to import my Google Reader subscriptions; give me a timeline of news in newest first order; provide a "favourite" function and social media share buttons; provide a tag of feeds; take no local storage; be installable anywhere - on PC / Mac, on cloud server, on a Raspberry PI, and; be open source!

NodeFly: What made you decide to go with Node.js? 

Bird: I have used Node.js professionally and its active developer community means that it has many modules ready to use; it's just a matter of finding the right packages and getting stuck in. I don't think I would have been able to fetch 25 RSS feeds in parallel in PHP, for example.

NodeFly: Did you experience any challenges going the Node.js route?

Bird: I happened to start my development just as Node 0.10.0 came out. That caused my some pain because some modules aren't compatible yet. "Forever", for example.

NodeFly: Any future additions planned for Birdreader? 

Bird: Well after open-sourcing it, I quickly added extra features myself such as "add a feed" (not just importing your Google Reader subscriptions), tagging and social media links. I've been promised a search facility by an open-source contributor, so watch this space!

NodeFly: Any future Node.js plans you would like to tease us with? 

Bird: I have my BirdReader server running on a free-tier Amazon EC2 instance. But wouldn't it be nice if my web-app "synced" with the server, for off line viewing? There's a technology called PouchDB which might be a good fit. So let's see what happens!

NodeFly: Thanks for telling us all about BirdReader today! All the best with your future Node.js projects!

Check out BirdReader at  https://github.com/glynnbird/birdreader for this great alternative to Google Reader.