#100DaysOfCode Day 16: Developing a Twitter Client using Waterfall Development Cycle (Part 1)
By: Richard Russell
Tags: Programming, Python, Twitter

So, allow me to go step-by-step and explain the brainstorm in detail.

Requirements

The requirements I listed are fairly simple. Obviously, since we are using an API that will connect to Twitter’s server and send a request to Tweet a body of text, then I will need a working internet connection. Next, since we are going to use Twitter’s product, we will be needing a Twitter account (that is developer verified) and access to the Twitter API token — I will explain more on this later on. Lastly, the Python programming language should have been placed in the “Design” section rather than “Requirements”.

Now, on the technical side of the requirements, I asked myself the following questions:

How to access Twitter’s server so I can post a Tweet without having to go to their website? How to gain access to Twitter’s API? How do I get Twitter’s API to post my Tweet?

First, the way to access Twitter’s server so I can use their services to post a Tweet without having to go to their website is by using their application programming interface, or API for short. This is the essential definition of an API, as it grants developers the ability to use the service of other programs within their own applications.

Second, to gain access to Twitter’s API, I must make a developer account (I explained more about this process on Day 3 of the #100DaysOfCode series), which will take a few days for the Twitter moderators to process. After having a developer account, create an app from their website to receive the necessary API tokens.

Third, Twitter uses HTTP endpoints for their API requests — meaning things such as GET, PUT, POST, DELETE are used. Twitter has a list of all its API in its documentation, which can be found here. To post a Tweet, the endpoint required is POST statuses/update .

Analysis

The logical flow behind this project is also simple. The Twitter client that I will be making — let’s call it TweetClient to make it easier to explain — will embody a program that will take in input from the user. This input will be the status or the Tweet that I want to be posted. Additionally, TweetClient should have my API token ready for authentication purposes.

Afterward, TweetClient will shoot a request to Twitter’s server, requesting that they publish a Tweet on my behalf. Twitter’s authentication process should recognize my API Token and grant my request. Finally, the Tweet will be published to my Twitter account.

Design

Initially, I thought of making a graphical user interface to accommodate the project and make it visually more appealing. However, I thought to myself that this might be a little more complex, as I have not figured out how to get the Tweet published. And so, I decided that it will be at a Command-Line-Interface form first, and once I add several major improvements to this project, I can transform interface into a graphical one.

Coding, Testing, and Operations

I believe that these three sections are meant to be practically accomplished rather than just planned out. And so, I will leave this explanation as it is.

Generating API Tokens

Now, because my application requires a request that will post on my behalf, I need to make sure that TweetClient has the appropriate credentials to pass Twitter’s authorizations and authentication. To do so, I would need four things: API consumer key, API consumer secret key, Access token, and Access token secret. The difference between an API consumer key and an access token is that the consumer key/secret is used to authenticate the app that is using Twitter’s API, while the access token/secret authenticates the user. These four keys must stay a secret — it must be hidden at all times and should not be explicitly written in the source code.

To accomplish the following, create an auth directory in your root and vim a file named auth.py with the following code:

Afterward, run auth.py with python and you will get a JSON file with the appropriate credentials. You will then have to import this JSON file in your main script; however, if you are planning to commit your project into GitHub or any public repository, do not include your auth directory, as it contains your private credentials that should stay private.

Before I end today’s article, let me give a brief explanation of what is going on with the source code.

In the first line, I imported the JSON library, as you will have to create a JSON file. Next, I created a dictionary that will essentially become the backbone of the JSON file. The keys within the dictionaries are CONSUMER_KEY , CONSUMER_SECRET , ACCESS_KEY , and ACCESS_SECRET while their value depends on their respective codes. Lastly, we have an open() function to create a file. This function takes two arguments: the name of the file and the mode for which the file will be opened. "twitter_credential.json" means that the name of the file that will be created is twitter_credential.json while w means that the file will be opened for writing.

Call it a day

I will stop here for today and continue tomorrow!

Remember: stay consistent.