My Twitter Gem learning experience

I spent a lot of time working with the Twitter API in the last few weeks. Mainly because the code I originally wrote had a ton of errors for the metrics and verification.

I had previous experience working with the Twitter omni-auth for Chuych, but I actually could not get it working the way I wanted. I ended up scratching that functionality out of the app and moving on.

I now have a better understand on how to read the documentation for REST api for Twitter now, and looking forward to putting the Twitter features back in the my app.

Here are some cool things I did to work through some of problems.

1. Read the readme until it makes sense.

Since I now spend 8+ hours at computer researching Rails, I am able to take deep dives into documentation and look at code. The best advice I can give to anybody about learning or working code is, All code is written by humans. There is not not enough magic or witchcraft out there preventing you from figuring out something. Some problems might take a lot of time but its possible to figure things out.

Towards the end of my second week my boss mentioned in passing that he wanted me update the app to include the functionality to send photos along with your tweets. I did not know how to do that at first, but 2 weeks later and we just released that feature on Wednesday.

During my first look into the app, I actually found rather easy implementing the front-end functionality by following the Instagram functionality, but when it came to the back-end I was completely confused. I had a coworker pair with in researching possible solutions for implementation, and it turns out there is a Twitter-Gem. The unfortunate part was we were not using it.

A previous employee actual now is deprecated, and still use the Ouath1. Sending photos with Tweets requires Oauth2, basically everything needed to be updated just to send a Photo Tweet.


2. Really look at the gem code.

The best thing about the Twitter Gem is that it lays out the methods needed for easy setup, for example to setup the call to Twitter and credentials, it can be done in one block as opposed to our 100 line module.

The twitter_interface file we have does all the same and mirrors all things from the gem except for updating itself ;) , which I why I recommend to search for Gem. One of the best advice I got from a thoughtbot learnprime video was if you find yourself writing a lot of code to do something and talk to other components such as API's, you might want to check if there is a gem out there for you.

Programming doesn't have to be difficult if you do not want it to be.

After the gem was install I had to make the decision of pursuing updating the rest of the app to use the gem or just implement photos. Being an a newb I opted just for the photo functionality and put in a tech debt ticket to change the status updates portion later.

I actually spent an entire Hackday Friday on updating the Twitter functionality and failed miserably. There were too many components intertwined with the legacy code, it made it impossible to get done in only one day. I had to abandoned the branch, but will revisit at a later date.

To implement sending tweets now all that is needed to be done is one method. No need to create lines and lines of code to do this.

3. Just try things out.

Don't be afraid to try things out. I through in  the update_with_media  in the app and was surprised to find it worked on the first try. You can try out things in the rails console, which is something I do a lot to figure out how the app works.

I did say sending photos worked on the first try, but I did have to spend time writing test and adding in the collecting metrics for the tweets, which is something my company needed, but a simple personal app, you can probably implement tweeting rather quickly, try it out.

I spent some time looking the code for the gem, which I found to be a great exercise in seeing how the gem is made (searching through the lib file). For a service such as Twitter, the code is not entirely complex. Methods are clearly labeled stating what they do and even provides a great readme.

I challenge you to take a look at the code on gihub. This exercise has personal inspired me to have enough confidence to learn from different docs of different gems. I was able to easily update some Stripe info on our app without knowing entirely too much about it or ever using.

There is also a great Code School video and a Codecademy lesson this.

Quick note on my switch from Webrick to Puma

I have heard multiple times not to run WEBrick on heroku or in production but I have never received a reason why I should not until now. Most people recommend Thin or Unicorn due to the flexibility and future proofing your app. If you no plans to update an app after a tutorial or feel you will be using it for more than personal local development use, then there is no issue in sticking with the default.

The recommendation for Heroku is to use Unicorn and their reasoning is due to the use of less dynos. In a production environment your server is de

"If you continue to run WEBrick [in production,] it is likely that requests will take a long time, possibly timeout, and you will need to use many more dynos [on Heroku] than your application requires. Rather than doing this, ensure you use a production web server. A production Ruby web server is capable of handling multiple request concurrently."

Afshin wrote a good article in the study group transcripts a few weeks back that you should check out. 

I personally am now using Puma and liking how fast it spins. I got to a point in my Chuych app where it would take up to 30 seconds just to start development. Its crazy how one little thing can mke a huge difference, but I recommend anyone who is still learning from tutorials or just getting started in Rails to try out a different server other than WEBrick.