Since React is getting so much buzz these days, I decided I wanted to try it out. But the problem was, where do I start? Getting started with React has always seemed so daunting because of all of the tools you need. Webpack, Redux, ES6, JSX, crazy build processes and more. It is a pretty big task just to get started.

Enter: create-react-app. create-react-app is a boilerplate app starter from Facebook. There are pros and cons in that since the build process isn’t configurable, it might not be good for a React veteran who wants a specific build process. However I think the simplicity of the build process is what makes it great for a beginner.

Once I installed the module I was able to download a new sample app and immediately start building. Exactly what I wanted!

The first thing I built (after Hello World, of course) was a sweet movie countdown timer. You can get out the code here and see the live site here. AND! This is probably the coolest part, James England used my countdown timer to make his own countdown to the Oscars.

Let’s get started!

My First Component

React components are basically modules. You can export them and use them anywhere through out your app. React is a little weird at first because the render() function is where your HTML lives. It’s uncomfortable at first, but also a pretty neat idea.

Component.js

export default class Hello extends React.Component {
  render() {
    return(
      <h1>Hello World!</h1>
    );
  }
}

App.js

import Hello from './Components/hello.js';

class App extends React.Component {
  render() {
    return (
      <Hello></Hello>
    );
  }
}

The things you should notice here is the render() function that returns Hello World wrapped in <h1> tags in the component.

Next we’ll talk about props. A prop is an argument that is passed into the react function through the Component. It might look like this:

Component.js

export default class Hello extends React.Component {
  render() {
    return(
      <h1>Hello {this.props.name}!</h1>
    );
  }
}

App.js

import Hello from './Components/hello.js';

class App extends React.Component {
  render() {
    return (
      <Hello name="Carmen"></Hello>
    );
  }
}

Oftentimes your app is going to have data that changes and then the DOM needs to be re-rendered. First the data needs to be attached to state, which is where the constructor comes in.

Constructor.js

export default class Movie extends React.Component {
  constructor() {
    super();

    this.state = {
      name: 'Carmen'
    };
  }

  changeNameThroughForm(newName) {
    this.setState({name: newName});
  }

  render() {
    return(
      <h1>Hello {this.state.name}!</h1>
    );
  }
}

You probably will be getting data from an external source like an API. The process for rendering the API data is identical. Once you have the data back from the API you’ll use this.setState.

export default class Movie extends React.Component {
  constructor() {
    super();

    this.state = {
      name: null
    };

    this.getNameFromAPI = this.getNameFromAPI.bind(this);
  }

  componentDidMount() {
    this.getNameFromAPI().then(function(response) {
      this.setState({name: response.data.name});
    }.bind(this));
  }

  render() {
    return(
      <h1>Hello {this.state.name}!</h1>
    );
  }
}

Notice I am binding to this in the constructor, as well as in the then. If you don’t use arrow functions in react, this will default to window. The way around that is the .bind(this) that I am using.

Next let’s talk about Lifecycle Events. Lifecycle Events take place at different points while your app is loading.

componentDidMount() {
  this.getNameFromAPI().then(function(response) {
    this.setState({name: response.data.name});
  }.bind(this));
}

componentDidMount is called directly after the component is rendered, so this is a good place to make an API call. There are several different Lifecycle Events including componentWillMount, which is called before the component is rendered, and componentWillUnmount which runs after the component is removed. You can see the Lifecycle Events documentation here.

This is what I used to get started with React. I’m really looking forward to working with it more!

What did you use to learn React? Are there any resources that I should include?

Questions? Tweet me!

In this post I’m going to briefly describe how to set and use environment variables.

You might be wondering why you need environment variables. Here’s an example: recently I wrote a twitterbot. The bot’s credentials were stored in a config file within the project. However, for security reasons, I couldn’t deploy the files to GitHub or to Heroku because anyone with access to those credentials would have unfettered access to my account.

So in searching for a solution, I found environment variables.

To set an environment variable in Mac is very simple. Open your terminal and type in the following command:

export NAME=CARMEN

And that’s it!

To verify that the variable was added you can use the env command to list out all of your environment variables.

Now that you’ve set your environment variable, how do you access it? Node makes this easy. Just use:

var whoAmI = process.env.NAME;
console.log(whoAmI); // CARMEN

This is extra handy because I was able to add environment variables to my Heroku project as well, and those variables can be accessed the exact same way. Meaning, I don’t need two separate sets of logic for my home machine versus my production app.

If you add an environment variable and need to remove it, that is simple too.

unset NAME

That’s all there is to it! Just be very careful and only use unset for variables that you’ve added. Otherwise you could easily break your machine by removing something important.

Another option, if you don’t want to add environment variables to your home machine (and I wouldn’t blame you if this were the case) is to use dotenv. This handy plugin takes key-value pairs from a .env file within your project and adds them to process.env.

If you decide to go this route, it is very important that you add the .env file to your .gitignore file so that your credentials aren’t shared with the world.

I hope you’ve enjoyed this post and learned something new!

Questions? Tweet me!

If you’ve worked with JavaScript for any length of time, you’ve probably run into promises. And if you’re like me, you probably shake your head and wonder why JavaScript has to let you down like that.

Promises are a pretty difficult thing to wrap your mind around. Andy Shora has a pretty great cartoon about promises that I’ve referenced a bunch of times trying to wrap my head around promises.

Basically you use promises when you need one thing to complete before the next function runs. If you’re thinking that this sounds very similar to callbacks, you’d be right. So why would we use a promise over a callback? Well there are a few reasons, but I think the most compelling reason is clarity. For example, a complex set of callback functions may look like this:

getData(function () {
  convertData(function () {
    convertDataAgain(function () {
      outputData(function () {

      })
    })  
  })
})

That’s pretty icky, right? Whereas the same code written as a promise might look like this:

getData
  .then(convertData)
  .then(convertDataAgain)
  .then(outputData)

Wow, what a difference! When you compare callbacks to promises, promises are much clearer about what is actually happening, and the order in which the functions are executed.

But how does one actually use a promise?

Let’s take a closer look. Sometimes you’re already working with something that will return a promise. Angular’s $https is a good example of this. In that case, your promise might look like this:

$https.get('someUrl').then(
  function success(data) {
    doSomeCoolStuff(data);
  },
  function error(err) {
    oops(err);
  });

Since $https already returns a promise, we don’t need to do anything special and we can just include our success and error functions and we’re good to go.

But what if we aren’t using anything that already returns a promise? Well that isn’t really a problem because we can create our own promises. Recent I built a Twitterbot which makes use of promises. The code looks like this:

var pickTheQuote = new Promise(function(resolve, reject) {
  getQuotes();
  if(quotesArr <= 0) {
    reject(pickTheQuote);
    return;
  } else {
    resolve(pickTheQuote);
  }
});

function chooseQuote() {
  // return random quote
}

function postToTwitter() {
  // post quote to twitter
}

pickTheQuote
  .then(chooseQuote)
  .then(postToTwitter)

The first thing I did up there was create a new promise. Then, based upon the contents of an array, I either reject or resolve the promise. In the event that my array is empty, I reject the promise and stop the function entirely. In the event that I have contents in my array, I resolve the promise.

Once the promise is resolved, I call the chooseQuote function and after that, I call the postToTwitter function. Obviously these functions need to execute in this specific order, otherwise, I might not have a quote to tweet.

And that’s the basics of promises. After you create a promise, based on certain criteria you can either resolve or reject your promise. Then you can execute functions after your promise has been fulfilled.

I hope that helps clear up promises for you!

Questions? Tweet me!

Many thanks to Devin Clark for helping proofread this post and writing some example code. Thank you, Devin!

I’ve done a weird amount of live coding lately, and unsurprisingly I’ve been really terrible at it. Live coding is hard. And like so many other things in life that are hard, the only real way to get better at is to practice. The unfortunate thing about live coding? There aren’t very many opportunities to practice.

I am friends with a lot of smart people and when I asked them for advice on live coding, the most common advice I got was to not live code.

They listed off several alternatives that I’ll go into here, but ultimately the advice I got was to avoid live coding.

Morgan Estes suggested using do it live or something similar to give the illusion of live coding without the live debugging. Paul Dawson suggested using a cheatsheet, or recording the live coding at home to then show during the live coding session. Mark Wissler suggested using the “cooking show approach.” Explain how you would write the file, and then show the completed file.

My personal ideal for a demo is to comment out your account and comment it back in during the demo to show off the functionality. This can be more tedious to prepare, but it gives the audience an idea of what each commented chunk of code contributes to the final product.

And even so, all of these are great, but what if you can’t fake the live coding? What if you have a job interview and you must do some live coding during the interview? Well I’ve been in that situation lately too, and I’m here to tell you I didn’t do well in those interviews. It is a super hard thing to pull off. In addition to having to code in front of another person – which by itself is never fun – you have the added stress of this being a job interview. In my experience those are never fun either.

So what do you do in this case? You can’t really fake it because you don’t really know what you’re going to be asked to do. You can try to prepare by doing some random code challenges in front of friends or family, but it’s not really going to reproduce the stress.

Well, I’ve put together some tips for dealing with this. Hopefully they’ll help you if you find yourself in a live-coding interview.

1. Try to relax

It is definitely the most overused piece of advice out there. Maybe the hardest to follow too. But it’s important to remember. Remember to breathe and avoid getting so worked up you lash out or shut down.

2. Talk through it

It’s not only awkward for you to sit in silence trying to come up with the answer, it’s likely awkward for your interviewer to sit there staring at you. Talk through what is going on in your mind as you try to come up with the solution to the problem. Do they have a whiteboard? Ask if you can use it to brainstorm a little bit.

3. Comments, comments, comments

I think this was the favorite piece of advice I got for this. Jesse Harlin suggested doing an outline of your program in comments before coding it. This allows the person interviewing you to see how you would solve it in case you run out of time, as well as give you something to go back to in case you go blank.

4. Ask lots of questions

Ask if there is something specific they are wanting you to show with this. Are they wanting you to use .map() or does it matter? Or perhaps use an object over an array. If your function is going to be accepting parameters, which types will be input? A string or an object or perhaps both? All of these are completely valid questions that will show you are thinking about the problem, and will save you some time writing the program.

5. Ask how you can improve

This can be really hard to do, especially if you feel like you didn’t do very well in the interview. But you might get some really good information that helps you in the future. I was told that I should slow down and think out the entire problem before jumping into the code. Pretty good advice since most interviews last an hour, and I spent a lot of that time writing what turned out to be wrong program because I hadn’t asked the right questions.

Most of all, remember that pretty much everyone comes out of a live coding interview feeling like they didn’t do well. It’s a tough thing to do in a very stressful scenario. No one really wants to admit that, but it is true. Live coding isn’t indicative of you as a programmer, it’s just indicative of how you did under pressure in this one very stressful 45-minute interview. So don’t beat yourself up too badly.

Do you have more tips for live coding? Let me know in the comments!

There are a lot people I talked to and sought advice from before writing this blog post. Here they are in no particular order: Rob Sullivan, Jesse Harlin, Mark Wissler, Devin Clark, Adam Rackis, Morgan Estes, Paul Dawson, David Roberts, and Ryan Hoegg. Thanks so much to all of these guys for chatting with me and giving their insights!

Questions? Tweet me!

Recently I built a Twitterbot to tweet 80’s movie quotes – because doesn’t the world need something like this?

I wanted to build something using Node.js. I’d never really done anything in Node before, outside of some tutorials. I think that learning by doing is the best way to go. At least, it is for me.

I started researching how to build a Twitterbot in Node and I found some really great articles on how to do it that I’ve posted at the bottom of this post. I used a tool called Twit to post to Twitter. I had to do a few things first.

First I made a Twitter account. Keep in mind that each Twitter account needs its own email address. You can’t share an email address between Twitter accounts. You’ll also want to verify the new account with a phone number. At this time I have been able to share my phone number across multiple accounts.

Next I went to https://dev.twitter.com/apps to set up an application for this account. I signed in under this account name, and then set the application to have permission to ‘Read, Write, and Access direct messages’. Next I headed over to the ‘API Keys’ tab and clicked ‘Generate API Keys’.

Once I had these, I created some ENV variables on my computer. I’ll be putting out another blog post that explains how to do that later. (It’s done, check it out!) The reason I did it this way was for security. I didn’t want my API tokens floating around on GitHub for someone to find and use. This allowed me to use an object like this in my code:

var twitInfo = {
  consumer_key: process.env.consumer_key,
  consumer_secret: process.env.consumer_secret,
  access_token: process.env.access_token,
  access_token_secret: process.env.access_token_secret
};

I later uploaded my project to Heroku to run, and this worked there as well, after I added ENV variables there too. (There will be another blog post about Heroku coming soon.)

Writing the actual code for the bot was surprisingly simple. Twit makes posting to Twitter incredibly easy.

var twitter = new Twit(twitInfo);

Basically we are passing the API token information into this Twit function in the form of an object.

var postToTwitter = function () {
  twitter.post('statuses/update', { status: quote }, function(err, data, response) {
    console.log(data);
  });
};

And then actually posting to Twitter is as simple as calling this function, and passing in the quote in an object. The quotes themselves are held in an array in a different file. Once the quote to be used is selected, it gets passed into this function and posted to Twitter.

If you want to follow the bot you can do so here. Some articles that were extremely helpful in this process are posted below.

• SouthBotFunWest TwitterBot
• Set up a simple JavaScript TwitterBot
• Creating a TwitterBot with Node

I hope this was a fun read, and keep an eye for follow-up posts, including one on promises!

Questions? Tweet me!