DEV Community: jhiatt

Google Slides vs Ruby Powerpoint Gem

jhiatt — Fri, 26 Oct 2018 20:35:16 +0000

Solutions for a Ruby on Rails .ppt or .pptx export

For Ruby on Rails apps that deal a lot with reporting to external clients, it often adds a lot of value if you can export reports that are a little more user friendly. A client that receives a report that is more visually appealing and has data organized in a way that tells a story will likely feel that they got more from your service.

The downside to exporting pdf’s is that it is not editable. What if your app spits out a lot of great looking information but your client account manager wants to make some changes before sending it over. Exporting a powerpoint is one way to get an editable and visually appealing report format that is also easy to open. As an added bonus, you can of course create nice presentations that you can give to clients the way powerpoint was intended.

At our company we decided that the end goal would be to export a file with a .ppt extension (rather than .key or something else) because virtually all slide presentation software can open the .ppt format. After much research we narrowed it down to two options for a Ruby on Rails platform, creating Google Slides, through the Google Slides API, or using the Powerpoint gem in Rails.

Google Slides API Setup

It wasn’t until I became a developer that I realized how truly massive and nerdy Google is. I have seen a lot of API’s doing both basic and complicated things but entering the Google API docs feels like entering a foreign country. The Google ecosystem is huge and they handle things very differently than a regular API call or adding a ruby gem.

Google has a great quickstart walkthrough that you can find here. I won’t re-create that walk through but I think there are a few things to add if you are newer to programming and working in the Rails environment.

After the first step where you add your project to Google and download the configuration file, place the file credentials.json in your rails app. I placed it in the root directory and it is probably a safe idea to add credentials.json to your .gitignore file so that your Github wont add the file.

On step 3, Google gives you the quickstart.rb file. I placed the first 30 lines of code (through the end of the “authorize” method) into an initializer file config/initializers/google-slides-service.rb

require 'google/apis/slides_v1'
require 'googleauth'
require 'googleauth/stores/file_token_store'
require 'fileutils'
OOB_URI = 'urn:ietf:wg:oauth:2.0:oob'.freeze
APPLICATION_NAME = 'Google Slides API Ruby Quickstart'.freeze
CREDENTIALS_PATH = 'credentials.json'.freeze
TOKEN_PATH = 'token.yaml'.freeze
SCOPE = Google::Apis::SlidesV1::AUTH_PRESENTATIONS_READONLY
##
# Ensure valid credentials, either by restoring from the saved credentials
# files or intitiating an OAuth2 authorization. If authorization is required,
# the user's default browser will be launched to approve the request.
#
# @return [Google::Auth::UserRefreshCredentials] OAuth2 credentials
def authorize
client_id = Google::Auth::ClientId.from_file(CREDENTIALS_PATH)
token_store = Google::Auth::Stores::FileTokenStore.new(file: TOKEN_PATH)
authorizer = Google::Auth::UserAuthorizer.new(client_id, SCOPE, token_store)
user_id = 'default'
credentials = authorizer.get_credentials(user_id)
if credentials.nil?
url = authorizer.get_authorization_url(base_url: OOB_URI)
puts 'Open the following URL in the browser and enter the ' \
"resulting code after authorization:\n" + url
code = gets
credentials = authorizer.get_and_store_credentials_from_code(
user_id: user_id, code: code, base_url: OOB_URI
)
end
credentials
end

and then created a service file in the lib folder lib/services/google-slides.rb where I put the rest of the code.

service = Google::Apis::SlidesV1::SlidesService.new
service.client_options.application_name = APPLICATION_NAME
service.authorization = authorize
# Prints the number of slides and elements in a sample presentation:
# https://docs.google.com/presentation/d/1EAYk18WDjIG-zp_0vLm3CsfQh_i8eXc67Jo2O9C6Vuc/edit
presentation_id = '1EAYk18WDjIG-zp_0vLm3CsfQh_i8eXc67Jo2O9C6Vuc'
presentation = service.get_presentation(presentation_id)
puts "The presentation contains #{presentation.slides.count} slides:"
presentation.slides.each_with_index do |slide, i|
puts "- Slide \##{i + 1} contains #{slide.page_elements.count} elements."
end
# [END slides_quickstart]

Eventually I will want to create a class or module around creating and editing slides, but for now I just wanted to get things working.

To test the code, I copied and pasted the lines from my service file (google-slides.rb) into my rails console. The console then gave me instructions from Google to visit a particular URL. After visiting and logging in I copied the code it gave me back into my rails console and pressed enter. After that the connection to Google’s API was made and I was able to run commands normally.

What Does Google Have to Offer?

From my quick study it looks like everything you can do in Google slides on their web app you can also do through the API. It looks easy enough to create a new presentation, create slides and even export files from Google Drive. The API even will let you add transitions, speaker notes, and work with themes. The API can get as complicated as you would like it to and it looks possible to make the finest detail changes all through the API.

Because you have the ability to edit slides from the API, you have another advantage using Google Slides. Using the Google web app, you can create any kind of theme or template on the Google app and then make any kinds of edits you want through your app. This could be really helpful when getting started. You can even create an MVP offering where you do most of the work in the Google app and then add your data through the Google API.

On the other hand, if you use the Google API, you are bound to the Google world. This means that you will be storing all of your slides and presentations on Google Drive. Because Google is a dynamic and growing company, you are also more likely to encounter changes to the API than you would using a gem which is version controlled. Overall, you relinquish some control, but what you gain in adaptability is huge.

Powerpoint Gem

Definitely the biggest advantage to the Powerpoint app is the ease of set up. You can find the set up here, but it is literally just installing the gem and then you are good to go.

However, what you can do with the gem is kind of limited. It is really easy to add slides and create presentations. All you need to do is create a new object

@deck = Powerpoint::Presentation.new

and add slides (your options are textual slide, pictorial slide, or a mix of the two)

@deck.add_pictorial_slide title, image_path

“title” and “image_path” are variables you set ahead of time. Finally you save the new presentation

@deck.save(‘test.pptx’)

and it exports the file as a .pptx at whatever file path you specify. You can adjust picture position relatively easily but that appears to be the extent of built in customization.

Setting up and using the Powerpoint gem could not be easier, however, I have not found anything that will enable you to modify slides beyond adding text and pictures. The gem is cleanly built, so I would expect that it would be relatively straightforward to build out that stuff yourself.

In the end it really depends on your end goal. If you want to start exporting your data into nicely designed slides, it may be worth figuring out the Google API. If you are more concerned about owning your content and building a code infrastructure that you control, than the ruby gem might be best.

My PocketMoney Algorithm

jhiatt — Wed, 06 Sep 2017 03:09:15 +0000

When I made my first fully functioning Ruby on Rails app (on GitHub here), I wanted to create a powerful app that could answer real world questions. The question I wanted it to answer was: “How much can I spend right now? or in other words “How much money is in my pocket? (see what I did there?)
To get that answer proved a little more tricky than I at first anticipated. I have the recurring expenses from the user; I know what bills are coming up as well as how much money is coming in, and I can figure out how much spending money they would have for non fixed expenses. I can also calculate how much they have in the bank now because I have all of their non fixed expenses since the last time they gave me their bank balance. At first I thought calculating how much they could spend right now would be as easy as:

Calculating how much money they have in the bank right now
Calculating how much spending money they have that month that they haven’t already spent

Then I stopped to think about it and I realized there was another issue. What if you get paid $3,000 a month. $1,500 at the beginning and $1,500 in the middle, and your total expenses for the month are only $2,500, but your rent and car payments are all due the first week of the month totaling $1,800. You would run out of money after the first week of the month. The challenge is to find the lowest amount you would have to hold at the end of the previous month in order to meet your bills for the current month.

Buckets and Pits

To get this number I came up with an allegory called Buckets and Pits. Imagine there is a farmer, named Farmer, and like many farmers he is very conscious of conserving water. He has a reservoir full of water and several holes in the ground along his farm that for some specific and really important reason need to be filled with water. In addition to his reservoir he also has rain barrels next to each hole that may or may not contain some water. Of course, due to the complicated nature of his method of farming, the pits and buckets are of varying sizes and rarely match each other.

So if you are with me so far, hopefully you are picturing a man standing in front of a series of buckets filled with water and empty pits of varying sizes.
Farmer, being a somewhat quirky methodical man, refuses to make multiple trips back and forth to the reservoir so he goes to each pit one at a time to see how much water he will need to take with him.

He pours the first bucket in the first pit and sees that it matches up quite nicely, with neither extra water, nor water missing. He moves on to the second pit and realizes that he is missing quite a bit of water.
You may or may not have guessed that each pair of one bucket and one pit in this allegory represent one day in my code. The water is income and the pits are expenses. You will see these netted together to represent the variable Bucket later on.
Because he is quirky, Farmer refuses to take the bucket on the third pit to use on the second pit so he goes back and fills up a larger bucket, his Reserve, with just the amount of water he will need to top off pit number 2. He then moves on and realizes that pit 3 has way more water than he needs for pit three so he keeps the extra amount to be used in pit four.

Are you with me so far? Farmer refuses to run out of water at any one pit (much as your bank account refuses to run out of money without triggering an overdraft) so he goes through and calculates exactly how much water he will need to bring in as Reserve so that that doesn’t happen. he doesn’t care about having water leftover at the end, but he does want as little water in his reserve starting out as possible.

From Allegory to Real Life

Now lets look at the code. I’ll skip the methods where I pull in the transactions and such (if you would like to see the full model click here). Let’s go through this step by step.

Lets take all of the positive and negative transactions and add them together for one day. We’ll call that a Bucket. We loop through each day of the calculation on line 26 and then loop through each related expense (x) and fixed expense/income (y) on lines 29 and 34, respectively for that day.
Lets see if our bucket for the day is positive or negative (line 39). If it’s positive (or zero) we can move the amount in the Bucket on to the next day. If it’s negative we need to add that amount in positive to our Reserve (reserve_amount) and set the Bucket balance to zero because we have already accounted for that deficiency in the reserve.
Once we have gone through all of the days, we calculate exactly how much money we have in the bank right now (i.e. the reservoir, calculated in lines 45–58) and subtract the Reserve amount from our current balance. That then becomes our PocketMoney, the amount we can spend today without defaulting on our bills in the future.

Remember, just as the Farmer doesn’t care if he has too much water at the end, we don’t care if we have extra money in our last bucket, as long as we haven’t run out along the way. Whatever is left in the bucket variable (which can only be positive) does not factor into our PocketMoney balance.
I hope you have enjoyed my little algorithm. It was a stressful joy to come up with and I am a little proud of it. However, because GitHub keeps the history and the work is never really lost, I am happy to replace it with a better one. Let me know your ideas!
As always, also let me know if you catch any bugs in the code or see something fishy. Always looking to improve and, unfortunately, my experiment in TDD did not extend into this part of the app (see my article). Maybe some day!

When to TDD (Test Driven Develop), a Newbie’s Story

jhiatt — Sun, 20 Aug 2017 04:18:41 +0000

I just finished my Actualize coding bootcamp which culminated in a capstone project. After a while of struggling through my heavy backend code we learned about TDD (I know it’s Test-Driven Development, I was using the verb form in the tittle).
I was completely stuck on my capstone project when we had our TDD class. I had been coding for hours on the weekends completely in the weeds of huge Rails model methods and, of course, nothing was working. At first TDD looked like a pretty dumb way to do twice the work, but as we went through the dumb seeming exercises in class, it was as if the clouds parted and the angels started to sing, “Do this in your capstone…ah ah AH!”
Hopefully you have that image set squarely in your mind. In truth there are definite positives and negatives to TDD but for those of you out there who have no idea what TDD even is, this article is for you.

The Pro’s of TDD

I wont go into a lot of detail about what TDD is, and I only have real experience in Ruby on Rails using RSpec, but here are the basics. TDD is basically when you write the tests for the code before you start and then you code incrementally.
The idea is you write a test, starting as simple as possible, and write code to pass the test. Then you write another test, just a small step more complicated than the last, and write code to pass that test. As you go, you build out your tests just as you build out your code. You then have a permanent array of tests you can run every time you make a change in your code.
The main pro, is you write code that you know works and you catch your mistakes as you go. If I were to try and debug my code, I would have had to go through every element that could be the weak link and test it out. In my experience, the code I was most suspicious of was code that I hadn’t used before. It would take a lot of time and effort to debug my active record queries for example. Instead I rewrote my code using TDD and I was able to have much more confidence in those model methods.

The Cons of TDD

Though it was all worthwhile, I found that TDD worked great with methods that calculated some number or created/destroyed an object. It didn’t work as well recognizing dates or checking that specific routes worked. These were things that I probably could have figured out how to do in RSpec but they also weren’t hard to test just by doing them in the app and checking the result. They also weren’t the things that had been breaking before. In other words, there is a cost benefit analysis you have to do when deciding to use TDD. It does take a lot of work and there are many things that just aren’t worth it.
In the end, TDD really helped me to understand what my code was doing and made it more robust. I would recommend looking into it more, and trying it if you are stuck. I also wouldn’t recommend blindly implementing it just for fun, but that’s just me.

Why I made a Gem for my Capstone

jhiatt — Fri, 04 Aug 2017 02:05:12 +0000

My Ruby on Rails capstone project for my bootcamp is a budget app with a calendar component. I decided to keep some info in a monthly date format and other info in a weekly date format (more on the pros and cons of that decision in my next article). Basically I had two sets of incompatible data with no easy way to integrate them, which I needed to do any of the math in my budget. This was really annoying.
Then one day, toward the end of the bootcamp we had a class on how to make your own gem. We used plenty of gems but I had no idea how easy it was to make one. All you do is write some code in your terminal and then code it up in Ruby.
In reality the reason I decided to make a gem for my capstone was because I thought it would be awesome! (I’ve been using these things for weeks and now I can make one!) But I wanted to share some insights I’ve gained from the process.

Want to understand how languages work? Make a gem!
When should you make a gem for your own code?
Why you should just write code and not make a gem (most of the time).

1. Want to understand how languages work?

I remember being surprised to learn that Rails itself is a Ruby gem. While I admit I don’t know anything about how languages like Ruby are made, I assume the process is a little like creating a gem. You start with 1’s and 0’s and you write them in such a way that you can create a foundational language. Then you use that language to create a bunch of shortcuts to make it easier to code and the result is an entirely new language. The process continues until you get to Ruby. Ruby was then coded in such a way to create Rails, which makes Ruby much easier to use, the same way that Angular, React and Vue.js are written in JavaScript to make JavaScript easier to use.
In other words, creating a gem is a way to be a part of the process. Though I am brand new at this, I’ve always assumed that understanding how these languages work and where they’ve come from would be a pretty great way to deepen yourself as a programmer and prepare you for learning new languages.

2. When should you make a gem for your own code?

Fundamentally, a gem is a completely removed from the app you are working on. It is basically another app that is really easy to link to your current app. This means that it is more difficult to update your code, which can be a pain. On the other hand when it is more difficult to update your code, you can force yourself to leave the code alone which can be just what you need.
In my case, I had one specific problem that was actually pretty simple; I needed to convert from a year-date format to a week-date format and vice-versa. Aside from any bug fixing I knew I wouldn’t need to change that functionality and it would be handy to code it up and set it aside so I didn’t have to worry about it. After working on it for a little bit I realized it is also really easy to set up RSpec tests and run your own tests to test the functionality of the gem. If you find yourself with this kind of a problem, there isn’t a solution already out there you are happy with, and it’s a problem you might have in the future with a different app, it might be worth considering making a gem.
Of course there are plenty of downsides. The main one I found was that after using it for a while, I realized that my documentation for how to use the gem wasn’t complete and I still haven’t updated it as thoroughly as I should. There is a little more upkeep. It’s not difficult, just a hassle to remember.

3. Why you should just write code and not make a gem (most of the time).

This brings me to my last point. In Rails there are so many ways you can solve a problem. For simple ones like mine I could have easily made a model method that would have done the same thing. In reality the only time you 100% should make a gem is when the code is too complicated to hold in an app or too useful to hold in one app. For my personal preferences, making a gem made it easy to stay organized and focus on my other code (which needed some help). I also don’t know the impact of using a gem on things like computation speed and app size.
Please feel free to make any comments, correct any errors, or offer better explanations. I am happy to receive any feedback. I’m brand new at this and would love to get better. For those coders out there who have always dreamed of making a gem, but have been held back by naysayers: Do it! Live your dreams! I’m proud of you!