node

Pushing a Node App to Heroku

If you're used to pushing Rails apps to Heroku, deploying your first Node app could be a pretty frustrating experience. 

It was for me. 

Here's some tricks to help you deploy:

  • Add Node as an engine dependency in your package.json file:
"engines": {
"node": "4.1.1"
},
  • Delete your node modules and reinstall all your dependencies in your production environment. To do this, run `rm -rf node_modules` and `npm install --production`
  • Double-check everything worked. Run `heroku local web` and visit http://localhost:5000 to see your app as it will appear once deployed.
  • If everything looks good, deploy as usual.
$ git add .
$ git commit -m "Added a Procfile."
$ heroku login
Enter your Heroku credentials.
...
$ heroku create
Creating arcane-lowlands-8408... done, stack is cedar
http://arcane-lowlands-8408.herokuapp.com/ | git@heroku.com:arcane-lowlands-8408.git
Git remote heroku added
$ git push heroku master
...
-----> Node.js app detected
...
-----> Launching... done
 http://arcane-lowlands-8408.herokuapp.com deployed to Heroku

For more information on deploying Node apps to Heroku, read through Heroku's very helpful instructions.

How Websockets Work

Oh, websockets. 

I had trouble conceptualizing websockets and understanding how information is passed from the server to the client. 

Here's the analogy I finally settled on: websockets are a lot like tossing a ball with a friend at the park. 

Websockets and Balls 

Pretend you're the server. You send out a message asking if anyone wants to play.

Your friend (the client) happens to hear and sends back another message, "Hell yea, I'd love to go to the park!"

This conversation is essentially opening the connection between two sockets. Now you're both listening to each other and can receive any messages sent. 

But here's the deal: Because you're the server, you can play ball with multiple friends at the same time. Your friend, the client, isn't so powerful. He or she can only interact with you. 

Set Up Your App

Before we dive deep into websockets, let's set up a basic Node app to work with them.

If you haven't already, make a directory and `npm init`. Work through the initial setup and then install Express: `npm i express --save`.

Within your app, create a server.js file.

This just requires some of the dependencies we'll be working with to get this app off the ground.

Create a folder called `public` and create a file within it called `index.html`. This will be the file we send to the client when they visit http://localhost:3000. Why 3000? Well, that's what we're setting on line 12 above. We're telling this app to listen on port 3000. 

In your console, type `npm start`. Then visit http://localhost:3000 and return to the console. You should see a message: "Listening on port 3000."

Cool, huh?

Ok, now we'll get to the websockets. 

We've set up the server above and now we're going to pass that variable into socketIo. (Don't worry about line 22 for now — that's for another piece of functionality.)

Now open another tab in your browser and visit http://localhost:3000. Return to your console and you should see a new message: "A user has connected. 1"

When you visited the site as a client, the server recognized the connection and notified you. 

Can you guess the difference between line 27 and line 29?

`io.sockets.emit()` sends information to ALL the sockets listening on your connection. 

`socket.emit()` sends information to one specific socket. 

How to Work with Websockets in Real Life

Now let's build some extra features to pass information back and forth between the server and the client. 

Add the following to your index.html file. 

Create a client.js file in your public folder. Then add the following.

Now experiment with your connections by opening up a bunch of tabs in your browser. See how the connection count increases and decreases as you open and close tabs.

The awesome part of websockets is that they're LIVE. You don't have to refresh the page. The connection automatically updates the information based on what's happening in real time. 

Got something to add about websockets? Feel free to comment below.

Starting a Node Project

Getting started is usually the hardest part of any project. Here's what to do. 

  • If you haven't already, download Node. 
  • Make a new directory and cd into it: `mkdir myapp` and `cd myapp`
  • When you enter `npm init`, you'll be given a series of options for your app. Press enter to accept the default answer or enter your own. 
name: (myapp)
version: (1.0.0)
description: An amazing app
entry point: (index.js) server.js
test command: mocha
git repository: https://github.com/{your username}/myapp
keywords: node, javascript, app
author: Emily Dowdle
license: (ISC) MIT
  • I'm going to use express and mocha. To install these dependencies, type `npm i express --save` and `npm i mocha --save-dev`

Turing as a great tutorial for creating and unit testing an express app. I highly recommend you follow along to get some more experience.

 

Video Code Along (Part 1)

 

Video Code Along (Part 2)

I was interrupted in the middle of recording. Here's the final part. 

Real Time Crowdsourcing App

For the next week, I'll be writing a blog series on an app I'm writing: Real Time. It's a polling app and the responses can be viewed in, you guessed it, real time!

Here's everything you need to know:

Basic Requirements and Features:

Crowdsource

Steve is an instructor at a seven-month developer training program in Colorado. In the middle of a long rant about the merits of CoffeeScript, he wants to check for student understanding. He could pause for a moment and ask the room if they have any idea what he's talking about, but he suspects they'll just smile and nod like they always do. He knows that some students may not want to admit in front of the whole group that they neither understand what Steve is talking about, nor do they particularly care.

  • Steve decides to use Crowdsource to anonymously poll the room.
  • He goes to the site to generate a new poll and adds three potential responses: "This is old hat to me", "I have an okay understanding of this", "I have no idea what you're babbling about".
  • He gets back two links: a admin view that shows the poll and a voting page that shows the options.
  • He drops the link into Slack and his students vote.
  • Steve feels pleased when he sees that 100% of his students are absolute masters of everything he has ever taught.
  • He turns off the poll before a certain student that comes late every day arrives and messes up his perfect score.

Ember + Electron

I started this week knowing nothing about Ember or Electron. So, naturally, I set out to make an app using both.

Ember

Ember is an open-source JavaScript framework developed in 2011 by Yehuda Katz and Tom Dale. It follows the MVC (Model, View, Controller) pattern of development for developers designing scalable single-page web apps.

The Ember stack includes:

  • Ember CLI: Build tools and command line utility. Like Rails, all you have to do is run `ember new app-name` to generate a new app with a standard file and directory structure, a testing framework, dependencies (managed by bower and npm), ES6 syntax support using Babel and asset management for minifying. 
  • Ember Data: A data-persistence library. Ember Data can save records via a RESTful JSON API without any additional configuration.
  • Ember Inspector: An extension for Firefox and Chrome to help developers debug Ember apps.
  • Fastboot: An Ember CLI addon to allow developers the ability run their apps in Node.js.
  • Liquid Fire: Animation support.

Electron

Electron is an open-source framework for desktop GUI applications. Built by Github, Electron used to be known as Atom Shell and is the framework Atom was built with. 

Electron uses Node.js, Chromium (the magic behind Chrome), HTML, CSS and JavaScript to build cross-platform apps — Electron apps can run on Mac, Windows and Linux.

Apps built on Electron include Slack, VisualStudio, Avocode, PopKey and GitKraken.

You can think of Electron as a mini Chrome browser, controlled by JavaScript. It uses Chromium to display web pages as its GUI.

There are two main processes: Main and Renderer. Main creates the web pages by using `BrowserWindow` instances. Renderer is the tool used to display web pages. But, unlike normal browsers, Electron apps have access to native resources. When a `BrowserWindow` instance is destroyed, the renderer process is also stopped. 

 

Development Philosophy

Ember's philosophy centers around the developer. Its creators used four ideas to drive the design:

  1. Full package: Unlike most JavaScript frameworks, Ember provides the full MVC framework for ambitious client-side applications.
  2. Productivity: Ember provides tools that make getting started fast. Ember CLI provides a standard architecture with countless options for enhancement.
  3. Stability: Ember's creators and maintainers recognize the importance of backward compatibility while continuing to innovate.
  4. Flexibility: Yehuda Katz is a member of the committee responsible for creating future versions of JavaScript and made sure Ember was an early adopter of ES6.

Ember adheres to the Don't Repeat Yourself (DRY) principle and prefers convention over configuration. It is opinionated but flexible, providing developers both freedom and guidance.

Electron is best thought of by its former name: it provides a shell that wraps around your JavaScript web app to provide it lower-level access to native processes and a desktop interface. It's a fast, lightweight way to build a desktop app for any platform. 

 

Why Ember + Electron?

Well, for one, it seems like it hasn't been done a lot before. That's kinda cool and leaves lots of room to learn through experimentation. (Or pull out my hair in frustration, you know, either way.)

Initially I thought Electron would be the most heavily used because the app would be a desktop app. But again, it's really just a wrapper. 

Ember does most of the heavy lifting. 

And, I'm sure there are some people who would argue I should have opted for a native app and not used a cross-platform tool like Electron. 

While I think there's a time and place for that, right now, I'm focused on learning. And I love that I'll be able to deploy it for any system. 

 

Challenges

The greatest immediate challenge was getting started. By the end of Monday, my understanding of Ember was about 15% and my knowledge of Electron was maybe 5% — and that's probably stretching it. 

I had no idea where to start. 

So, here's what I did:

(Warning, Steve Kinney makes a lot of appearances.)

After implementing edit and create on my own program, the flow of Ember started to make more sense. Ember follows an MVC philosophy, but in a very different way than Rails. I still felt unsure of how to pass information around.  

 

The Solution

One of the features we aimed to complete was a preview of the note (written in Markdown) in HTML, shown in a separate pane. 

So how do you get the note into another component?

Here's the code for the note:

<div class="note-content pane">
  <h3>{{model.id}}</h3>
  <hr>

  <p class="note-content">{{model.content}}</p>

  {{textarea value=model.content}}

  <br>
  {{#if model.hasDirtyAttributes}}<button {{action 'saveNote' on='click'}}>Save Note</button>{{/if}}
  <button {{action 'deleteNote' on='click'}}>Delete</button>
</div>

{{markdown-renderer note=model}}

 

That last line is the key: here we're passing an object to the markdown-renderer component of our app. "Model" is what it's referred to in the note template. "Note" is what it will be referred to in markdown-renderer. 

Starting to make a little more sense?

Here's the code from markdown-renderer:

{{markdown-to-html markdown=note.content}}

{{yield}}

 

Pretty simple, huh? Almost too simple. One of my complaints about Ember is it seems like there's a lot of magic and I'm still finding it hard to parse out exactly what's happening under the hood. 

 

Next Time

I think it was overambitious of me to take on an Ember + Electron app when I'm unfamiliar with both. Next time, I'll choose one and dive deep. 

I continually struggled to figure out what docs I needed to read: Node, Ember or Electron? 

I'd like to see more apps use both technologies because I think they can work together quite well. I'm just not there yet. Maybe soon.

 

Resources

Interested in learning either Ember or Electron? Here's where to start.