Ok! It's time to do some heavy lifting.
What we want to do make a web service client framework for our twitter requests. This will consist of 3 classes:
Friday, July 29, 2016
Thursday, July 28, 2016
A visit to config files.
Well we have some rudimentary tests, with no test framework. However before we do any more work we need a place to store all those application keys.
The problem is that I almost committed the application keys to my github account, and once uploaded they're there forever! Of course I would generate new keys, but I could do it again. So the best thing to do right away is to find a home for these keys that are located outside the git repo, or put in the gitignore file.
When one of my former coworkers, a dev saw how I was storing all these values he was very quick to mention that if this was a production web service all those values would be stored in environment variables. Here's the thing... a web service is running 1 instance of a particular service. The api tests were testing against to 10 microservices, and 4 environments (dev, qa, beta, prod). That makes 40 sets of configuration settings we need to keep track of. In our example we would at least store 4 keys, and the twitter api url. That would start getting messy. So I devised in my config system a way to encrypt access keys, with a master key being stored somewhere else. Much easier to keep track of one key than 160!
We'll revisit the config system with encryption and all that later. For now all I want is a config file, and a way to read it. A way for specifying the config file name on the command line would be nice.
The problem is that I almost committed the application keys to my github account, and once uploaded they're there forever! Of course I would generate new keys, but I could do it again. So the best thing to do right away is to find a home for these keys that are located outside the git repo, or put in the gitignore file.
When one of my former coworkers, a dev saw how I was storing all these values he was very quick to mention that if this was a production web service all those values would be stored in environment variables. Here's the thing... a web service is running 1 instance of a particular service. The api tests were testing against to 10 microservices, and 4 environments (dev, qa, beta, prod). That makes 40 sets of configuration settings we need to keep track of. In our example we would at least store 4 keys, and the twitter api url. That would start getting messy. So I devised in my config system a way to encrypt access keys, with a master key being stored somewhere else. Much easier to keep track of one key than 160!
We'll revisit the config system with encryption and all that later. For now all I want is a config file, and a way to read it. A way for specifying the config file name on the command line would be nice.
Wednesday, July 27, 2016
So Let's begin!
At first I thought I would demonstrate against the Google Search API, but they don't really have one. A little poking around, and I found the Twitter Api. So that's what we're going with. This is good because we should be able to demonstrate all CRUD activities with Twitter, and also how to deal with authentication, and how to store api keys (that will be well into the future).
The first thing we're going to do is create a twitter application, generate your twitter keys, and then create some quick and dirty tests to verify your twitter access.
Twitter's authentication is a little complex. However I found a wrapper for httplib that will handle the oauth authentication, while still valid for our example. So we move forward!
The first thing we're going to do is create a twitter application, generate your twitter keys, and then create some quick and dirty tests to verify your twitter access.
Twitter's authentication is a little complex. However I found a wrapper for httplib that will handle the oauth authentication, while still valid for our example. So we move forward!
Subscribe to:
Comments (Atom)