The Power of… Backups!

Code: Heroku, ruby, activerecord

Challenge: database restoration! During my almost-daily updating of during the NBA season, I accidentally updated ALL the records instead of a specific record. Whoops. I was instantly crushed, angry, and rueful. But much like this blog, present-Luke is very thankful for past-Luke…. say hello to Heroku backups! Luckily, I had taken advantage of Heroku’s daily backup feature and just a few commands would restore the DB to its previous glory. (BTW, I realize consoling into the production database for updates is a bad idea. I have a backlog item to better automate this with a script & endpoint, but personal projects typically take a slower path.)

First, the infraction:



Let’s take a look at what’s available:



And restore!



Takeaway: although not a DB administrator, I will always take a moment to ensure a backup database plan is discussed & implemented for any project! Too dangerous otherwise. And always… Trust the Process.





Pattern: Iteration within Interation (pt. 1)

Tech: Ruby

Challenge: need to iterate over a set of patient records…within the set, each patient has several records… so when the initial iteration gets to a new patient, the code needs to include a sub-iteration specific to the patient. For example, a patient’s subset of data includes their location & treatment history. We want to capture the patient’s last location, but their first instance of treatment. The data is extracted into a patient-specific data hash.


patients.each_with_index do |row, index|

i = index
until patients[i]['ID'] != patients[index]['ID']

update_patient_hash(row['ID'], data)

i += 1
break if !patients[i] # no more records




Takeaway: this could benefit from refactoring…

  1. The sub-iteration repeats the processing of records due to reference to the row for data capture, instead of patient[i][data]
  2. Could the initial iteration’s index be reset/moved to the new patient once the sub-iteration is finished?

Ruby Template => Data to JSON

Tech: Ruby, JSON, Docker

Challenge: data for daily reporting is captured in a class instance variable hash. If/when the docker container restarts, I want the data, which is regularly written to a JSON file, to be reloaded into the @hash.


def initialize

if FileTest.exists?('./data.json')

@instance_var_hash = JSON.parse('./data.json'))


@instance_var_hash = { ... }



Potential Pitfall: when sandboxing, I had an instance variable hash with symbol keys. When reading in the JSON file and writing to my instance variable, I generated an error in my methods… :key in original instance variable versus 'key' from incoming JSON.
Does the JSON file exist?

if FileTest.exists?('./file_name.json')

Read file


Open the file & write'./temp.json', 'w') do |f|





Reference: Git

Challenge: sticky post for Git!


git tag -a v1.4 -m "my version 1.4"

git show v1.4

git push origin v1.5 OR git push origin --tags

View Diff in Past Commits

git show -commit #-

Create & push repo locally to remote

git init

git commit -m "msg"

git remote add origin

git push -u origin master

Update author of commits

git author

What remotes do I have?

git remote -v

Grab all branches from remote

git fetch --all

Reset the index and working tree

git reset --hard *branch*

Redo commit message (prior to push to remote)

git commit --amend -m “new msg"

View # of commits and author

git shortlog -sn

Grab remote branch and force overwrite locally

%@#$! wants to use the “login” keychain

Tech: mac, keychain

Challenge: not really a challenge… more of a reminder for something irritating every 3 months. Work mac requires a new password every 3 months, and the keychain does not auto-update.


go to finderApplicationsKeychain Access

on left… Keychains… select login

go to… menu barEdit

click… Change Password for Keychain "login"

enter old & new pw




App Launch! ==> Redis RRF Data Cache

Tech: Redis, Ruby, Docker, Epic, AllScripts, SHA-2

Challenge/Description: create a central data repository for querying & discovering if a current emergency room patient has been discharged from any hospital network campus (read: multiple data sources!) within the past 30 days. If the current ER patient’s hashed data keys match a Redis key, then the patient is flagged as a Readmit Risk (RRF) on the ER Dashing dashboard.




Ruby Template => Map vs. Each

Tech: Ruby

Challenge: although all my code work flawlessly (sarcasm), I frequently wonder if my choice of .map or .each is appropriate and the best choice. I also look up the definitions and nuances… no more! I will take the time here to define, detail, and create examples for reference.


.each is used to iterate over an array. The original array remains.

arr = [1, 2, 3]

arr.each { |num| num + 1 }

arr.inspect => [1, 2, 3]


.map returns a new array with results from the block.

arr = ['a', 'b', 'c'] { |char| char + 'z'  } => ['az', 'bz', 'cz']

I think this is the key piece I have overlooked… .map creates a new array, but must assign to a new variable to effectively use it.

updated_arr = { |char| char + 'z' }

updated_arr.inspect => ['az', 'bz', 'cz']


.map! modifies the array.

arr = [1, 2, 3]! { |num| num + 1 }

arr.inspect => [2, 3, 4]


or better yet…

arr = ['Philadelphia', '76ers', 'are #1!']!.with_index { |char, i| i == 1? 'Eagles' : 'Fly' }

arr.inspect => ['Fly', 'Eagles', 'Fly'] # Yes, that looks better.


Takeaway: I think my code can be improved with a heavier reliance on .map!.

Ruby Class: Array

Ruby Class: Enumerable



2018 Commitment: Ostinato Rigore

Writing down goals and visualizing your progress/success works! So with the calendar turning to 2018, here we go again.

First, a quick 2017 recap. I nearly hit all my goals and was feeling a bit somber about not finishing the year 100%. Until this week. I read an article about Leonardo Da Vinci and my mentality rebounded. One of his favorite mottos was “Ostinato Rigore”, meaning “constant rigor” or “tenacious application”. Goals, and ultimately “success” (however you may define it), are about striving to be better and improve. Sometimes you have a bad day or week. Sometimes you stumble or regress. The idea is to keep going, undeterred!

And now, the 2018 commitments:

  1. Blog Posts (30): 3 per month (minus July/August due to life)
  2. Progressive Web App: a year-long commitment to learning React and other new technologies
  3. Robot: a few months ago, I purchased an mBot and commit to putting it to use (however minor).
  4. Automation/Hardware: like everyone else in America, Christmas delivered a smart speaker. Along with Raspberry Pis and the Internet of Things, the time is now to work on a project involving hardware, automation, etc. I have a few ideas, and commit to bringing one of them to fruition. More to come on this and mBot.
  5. Continuation of 2017 apps: while these version 1.0 apps are released, they still need work! I will be adding features, polishing, etc. and commit to making improvements.