When just starting out with Node.js, piecing together a front- and back-end and successfully deploying the app can be a bit intimidating. A great way to get your feet wet working with Node.js and deploying to Heroku without having a front-end to deal with is by making a Twitter bot. Not only are they incredibly fun, but because they’re only logic, they make a great stepping stone to bigger projects.
In this two part series, I’ll walk you through creating an interactive Twitter bot step by step, with examples from my own bot. My example bot, called Mom Bot, follows and unfollows users independently and scans tweets and @replies so it can respond accordingly. The source code and documentation for my bot can be viewed in its entirety here.
For the first part, we’ll review setting up Twitter credentials for the bot, ensure we have Node and NPM available, and begin working with our directory structure and Twitter API module. In the second part, we’ll go over using the API module to tweet, respond to tweets, follow and unfollow, and learn how to make the bot your own.
Getting Set Up on Twitter
First things first: please don’t use your primary Twitter account for this. There are exceptions, say if you are making a bot to handle follows or @replies for you, but for the most part, you don’t want to risk your main account being flagged as spam.
Once you’ve created an account for your bot, head over to the Twitter Developers page. This is the place for documentation on making all kinds of Twitter apps. In the navigation bar, navigate to “My Apps.”
Log in as your bot if you aren’t already, and click to “Create an Application.” You can name your application anything you like, but try to keep your name and description relevant to your bot. Your website can be anything; my suggestion is your repository URL for the bot on GitHub. Read and accept the Twitter Developer Agreement and click to “Create your Twitter Application.”
From there, you’ll see several tabs of information and settings. The only one that matters to us for this bot is the “Keys and Access Tokens” tab.
Go ahead and generate your Access Token and Access Token Secret, and then leave this window open; we’ll need the four codes on this page in just a few minutes.
Node.js and NPM
For those of you running a Linux box, the great news is that your distro may come with Node.js and the Node Package Manager (NPM) already installed. A good way to check if you already have it is to open your terminal. Go ahead and enter:
You could also just as easily check for a man page about nodejs:
$ man nodejs
Similarly, to check if NPM is installed, you can check for its man page:
$ man npm
If you already have both of these tools installed, go ahead to the next section. Let the others catch up.
Mac users, while you have some extra installations ahead of you, they’re not all that difficult,
First, make sure you have XCode installed. This is a free download from the Apple App Store, and it will allow you to compile software for your Mac.
The next Mac-specific install will be Homebrew, which is another package manager. To install it, go to your terminal, type the following, and follow the prompts:
Once you have Homebrew, installing Node.js and the NPM are fairly simple. In your terminal, simply type the following:
$ brew install node
Homebrew should have installed both Node.js and NPM. To verify this, enter two commands just checking the version of each piece of software:
$ node -v
$ npm -v
If you received version numbers, congrats! Move ahead to the next section and let those running Windows get to here.
Windows users, we’re actually only going to use the shell or command line to test whether your installation was successful. Go ahead to the Node.js web site, download and run their Windows installer (either 32-bit or 64-bit ).
You should be finished at this point. Go ahead and check for version numbers by entering the following in your terminal:
$ node -v
$ npm -v
If you got version numbers, you’re ready to move on.
Starting the Actual Project
Now we can actually start building the app. As with almost any Node.js project, we want to start by creating our package.json file. NPM actually makes that easy for us. Go ahead and enter the following into your terminal, and follow the prompts to create this file.
$ npm init
This file now holds some key information about our app, and it will eventually include any dependencies as well.
The next file we’ll create is our bot.js file. This will take the place of the server.js file in most Node.js projects and will be the source of all the logic for our bot.
Before we start writing the logic, though, we’re going to need to include a library of functions for interacting with tweets and streams. In this case, we’re going to use Twit, an API module that is useful for bot-making. To install it in your project, go back to your terminal and enter:
$ npm install twit --save
That –save term will include the module in the dependencies of your package.json file.
Of course, in order for your bot to do anything with a Twitter account, it needs to authenticate. You’ll need to create a config.js file to hold your API keys because you don’t want them to be in your main logic file. Remember the Twitter screen with the four codes? Enter them in the config.js file like this:
I keep having to remind myself that I’ve only actually been studying on Free Code Camp for ten days, in between taking care of kids and other daily necessities.
Sometimes, it’s to ensure I don’t get lured into a sense of hubris. I’ll be flying through tutorials, devouring them as though they were wrapped in bacon.
Riding That High
Regroup and Diversify
I’m still fully committed to the path Free Code Camp lays out to full-stack proficiency, and I am dedicated to completing it within one year, despite the challenges of finding time with two small children running around. As someone who has been interested in learning code for quite some time but — seeing the explosion of languages being sought — had no idea where to start, I this is the single most useful individual tool I’ve come across.
But I’m realizing that while learning by doing is critical to retaining and being able to use the knowledge, it won’t all come from one place. I went through and started evaluating what additional resources would be helpful for my learning path:
Flowcharts and maps. I’m a visual person in some respects, and especially when it comes to problem-solving, if I can separate myself from the problem and break it up into its parts, I’m golden.
Questions. I set up an account on Stack Overflow so as I get flummoxed, I can share my code and ask for techniques or flaws in my logic. It’s not easy to ask for help, but everyone has been a beginner at some point.
Journaling my progress. As I encounter problems or intriguing solutions, this will be a way to keep things fresh in my mind, especially since I am working with such a concentrated approach.
In addition to more specific resources, I am also taking advantage of practice that may come from day to day activities, like my blogging. Today, I needed to reconfigure my blog’s Twitter cards to enable photos and get the site whitelisted. It was frustrating, but I learned a great deal about Twitter’s integration, and I managed to create cards that should help drive engagement and conversation.
Of course, different forms of challenge and competition can keep things interesting, so finally I set up an account on HackerRank so I can progress through additional algorithms and participate in contests to show how my skills grow.
Needless to say, I’m not nearly ready for even the “Newbie” contests — if you want to feel better about your own progress, I’ll be happy to tell you how I scored. Eventually, I’ll get there, and in the meantime, the challenges and algorithms are helpful in gaining some of the academic knowledge I’m missing out on by not having a computer science degree.
And of course, lastly, I’m going to need to get more involved with other coders: share, comment, and interact as part of a community. Conveniently, Free Code Camp recommends local meetup groups for Coffee and Code and other types of events. The nearest one to me is in a neighboring city 30 minutes away, which is a barrier to attending; FCC recommends having the groups as local as possible, so setting one up for my town will probably be on the docket for tomorrow or the next day. And that’ll provide a great opportunity for some leadership experience.
Have you hit a wall (or many) yet in your coding adventures? How are you adapting to move forward? Feel free to share in the comments!
These two words have been typed countless times as developers take their first steps in new languages. So they should be fitting now, as I begin to chronicle my own path from fledgling coder to full-stack developer. This is the start of what is proving to be a fascinating, if vexing, journey.
To begin, I should probably take a moment to share how this blog came to be, particularly since it almost didn’t happen. Given the value and necessity of GitHub, I chose to host my page using their GitHub Pages tool. Of course, as it seems everyone new to code finds out on discovering GitHub’s utility, there is a steep learning curve to the tools. I ultimately created and deleted the site twice, staying up until 2 AM to set it up, so I hope that my experience makes it easier for someone else.
Forget Spooning; It’s Time to Fork
For my setup, I chose to use Hubpress to manage my blog. Other options are available, but they typically require pushing content using the command line, while Hubpress uses a dashboard interface. If you choose to go this same route, the most imporant thing is to fork (copy) the Hubpress repository to your GitHub account.
Do not create your GitHub page first. Once the repository is forked, you can rename it in the style .github.io that GitHub Pages would have used. You need to retain the fork relationship with Hubpress.io to ensure you can apply updates later on, which won’t happen if you push everything to an empty repository.
What’s In a Name — a Headache
If you intend to use a custom domain, this is a good time to ensure it is ready to use. I used Google Domains for my blog. Google Domains is in Beta right now, but my experience with it has been smooth so far. Most domains are available for $12 a year with free private listing and easy integration of services like Apps for Work.
From there, you can go into the Code section of your repository, under /hubpress/config.json. You should fill in as follows and merge the changes in your local master branch:
Go back into settings and scroll down to enter your custom domain in the applicable field. Click save.
Back in the root of your repository, enter the file CNAME and make sure your domain is listed on two lines, as follows:
Once this is all complete on the GitHub side, you can sync up your domain. If you used Google Domains, this part is manageable.
While managing My domains, click DNS and scroll all the way to the bottom. For your site to work with or without the www subdomain, you should include a CNAME entry with the www subdomain and your .github.io URL.
Do not use a * or wildcard subdomain to set up your GitHub blog. This will allow anyone to create their own page under your primary domain.
You also need two A records pointing to GitHub’s IPs. At this time, they are 18.104.22.168 and 22.214.171.124.
These IPs can change over time. Confirm the current ones at GitHub Apex Domain Help before pointing your domain to them.
Sweet, Sweet, Sweet Victory
From there, it may take a few moments or up to 24 hours for everything to point where it should. When you view your site, if you see the following screen, you have set everything up correctly.
Add /hubpress to the end of your domain to access the dashboard login screen, and use your GitHub username and password. From there, you will see a blank page — your posts screen — and a menu bar you can use to access settings like your blog’s title and social media links.
You must set your blog’s title before you start trying to save posts.
Congratulate yourself on a job well done, as this process trips many people up. Once you’re ready to write, pull up your favorite editor like Notepad++, brush up on AsciiDoc’s plain text syntax and you’re on your way.
How was your first experience jumping into GitHub? Share your experiences in the comments!