Good Morning,

Welcome to my small patch of the internet. This is where I write about web development, mostly Ruby, Rails, OOP and JavaScript

Ruby on Rails

Working with Calendar in the Google API Gem

Working with the refresh token and scheduling events.

September 10, 2016

I have started building a scheduling web app in my free time. Eventually a user will be able to choose which calendar you will want to schedule to but I am starting with Google Calendar. Because the gem is in alpha the documentation for the Google API and Calendar are sparse. So I wanted to create a short synopsis of my process getting it working. Read More


Welcome to My New Site!

I suppose I should put something like 'Hello, World' here.

September 04, 2016

Good morning/afternoon/evening to whoever you are. Welcome to my new site. Read More

Small notes and things I have learned from blogs, podcasts and training videos
Find an area noone cares about and care about it a lot

JavaScript Jabber Weekly iteration on testing APIs

This was a piece of advice about how to find an open source project to create. Find an aspect of the envrionment you work in that noone seems to pay enough attention to and then become the expert on it. This might sound relatively obvious but this line jumped out at me because it calls for focus and care. You not only figure out the need but focus on it and spend your time understanding it’s ins and outs. This is related to a blog post I read recently about mastering the domains that are central to your product.

Anything you don't own wrap in a class or adapter Weekly iteration on testing APIs

Ideally if you are interacting with the outside world either through APIs or outside gems you should be putting your connection to it into a wrapper or adapter class. This creates an internal API for the outside source you can control. So if you want to substitute the what is in the wrapper or if the outside API changes you have a central place to change or fix.

Testing is the canary in the coal mine. If testing is hard, refactor the code.

Practical Object-Oriented Design in Ruby

This is a type of code smell. If you are trying to test a part or all of your program and you are having a lot of trouble it should be a warning sign that the code is either not well structured or you need to consider refactoring the portion that is giving you trouble.

Keep Controllers Simple, ideally you should restrict yourself to the seven basic verbs TDD Rails Trail

This is a short-hand rule or code smell in Rails to avoid putting too much responsibility in the controller. Any Model related code should go into the model. And if you have a lot of extra responsibility in a controller consider refactoring that responsiblity into another controller.

Errors handling should be foundational to your program

8th Light University Facing Failure

How your programs handles errors should be as well thought out as how you structure any other large part of your program. Errors are often forgotten or intermingled in the execution code. Making the program hard to reason and hard to update.

Code should be designed like a M&M.

8th Light University Facing Failure

Ultimately this is related to separation of concerns. This imagines a program as a M&M With the center being what you want the code to do and the candy shell handling the connection outside world, this includes security, data access, and error handling.